A Modders Q&A
How will the SDK actually work?
We are taking a sandbox approach for our development tools, so pretty much every piece of the functionality will be built directly into the game.
This means that modders will be able to tweak their mods mid-game, which will in turn enable them to get things set up and "feeling right" in much less time.
What parts will there be to the SDK?
The first thing to say is, that after the Quick Battle release we are aiming for a regular release cycle to gradually bring more functionality to the game. This means modders can start creating content for the space combat element of the game while we finish up other areas.
So with the Quick Battle release of the game, you will find a lot of ship and space focused tools like the Hardpoint Editor and the Universe Editor. As time goes on we will add more functionality, such as the FPS mode, the Deck Editor, and Prop Editor.
After QB, our first focus will probably be the Cutscene Editor since that will open Excalibur up to Machinima video creators, and we are very keen to see what they come up with. This will also help to propagate publicity through the web showcasing much of what the Evolved engine is capable of and reflect what our campaign release will embody.
Will there be documentation for modders?
Yes, we are writing internal documentation for the different types of content that is going into Excalibur. Eventually, I think we will need to expand that into an online wiki which can be expanded by modders but that will probably arrive a little later.
How will the development tools be accessible during game-play?
The tools are not going to be part of the game-play itself, they will be accessible through a "development" sub-menu which will be available from the in-game escape menu.
We are considering locking this down for later versions of the game which are player focused, but for initial versions of Excalibur we want to encourage modding as much as possible.
How will Excalibur's learning curve compare to other Trek games?
It's difficult to say. The game engine allows for more complex modding, but at the same time that complexity makes it possible to do things much quicker. Hopefully with the documentation available and the innate curious nature of Trek fans, it won't take too long.
One of the main difficulties for modders coming from other communities will be avoiding some bad habits they may have picked up in other games. For example, there should really be no need to model in escape hatches on a ship for Excalibur. Our renderer offers you alternatives that provide comparative visual effects with a much lesser GPU impact.
How will Excalibur's "Main Game" work and will it be moddable?
The Quick Battle release won't have a campaign or main game in itself, and our intention is to build the main campaign using the same tools that we will release to the public so, in effect those missions will be "mods" in themselves.
Beyond that though, we want to really embrace modding and bring it into the heart of the game. One feature we are trying to factor in for the Mission Editor which reflects this is a classification system for ships which allows the author to add ships to a scenario without specifying a particular class or even a particular species. The game engine will then look at the ships that the player has installed and pick the right ones based upon the mission author's specifications.
Features like this will mean that 3rd party content will appear in missions even if they weren't released when the mission was created. That should really build on the re-playability of all missions and give players more of a reason to download modded ships.
How far can the modding go? Could I create a completely different game?
All of the game logic is written in Python, and we will be releasing those scripts to the public as open source once we have reached the right time in development. If we do our job properly there shouldn't be any need to overwrite these scripts. However, if you wanted to entirely change the behaviour of the game you certainly could do that.
Models and Textures
Will Excalibur require a particular model and texture format?
As part of the documentation we will recommend a particular standard which the Excalibur team has worked to. This standard uses open file types which can be exported from many software platforms and should be much easier to work with than proprietary formats used by other games.
That said, our "Evolved" game engine uses a library called "Assimp" to read 3D model formats, which means you could theoretically export your models to anything that Assimp supports and it should still work. The same can be said for texture formats, and we support many including .JPEG, .TGA, .PNG, and .DDS.
What is the recommended texture map size for Excalibur? What poly counts are the developers working to?
Map sizes vary dependent on the size and importance of a ship, however it will be important to keep file sizes reasonable especially if you are utilizing all of the map types available to you. The most textures we have on a ship right now are two 4096x4096 texture sets however those will probably be scaled down before we finalize the game.
Poly counts are also difficult to put a number on since the artists needs to use discretion based upon the size and detail of the model. Shuttles should typically be no more than 8K triangles, ships never more than 20K, and stations no more than 30K.
How complex can animations be?
Animations are created within the game itself in order to make them work with physics and the hardpoints themselves. This means that really complex animations will be a bit of a challenge to do but technically speaking there isn't any limit. The most difficult we are likely to take on is the Scimitar and her sinister wings!
Will it be possible to port ships from other games into Excalibur?
So long as you can convert the mesh to a supported file type then yes. Keep in mind that in order to get them looking as good as possibly you will need to create some new map types and of course set up new hardpoints.
We won't be building tools to directly convert ships from game X, Y or Z into Excalibur because we think artists need control over the process.
What new features will artists be able to take advantage of?
Animations, projected decals, greater control over illumination, 3D hardpoints, and much more. The game has been designed from the ground up to be as easy to mod and to offer the most advanced features as possible.
Generally speaking the best thing about modding Excalibur is that everything is open and standardized. From our ship definition files which use XML through to the wide array of model and texture formats we support, there should never be any compatibility issues etc.
How are ship hardpoints constructed?
The Hardpoint Editor is built directly into the game and can be switched into at any time. This means that we can quickly test things out without even saving our changes.
Creating a hardpoint is mostly about placing and sizing models within a 3D space and then configuring them. You start by placing the hull meshes and then add the components which exist within that hull.
Because we use 3D models for all of our targetable or visible components we can display these to the player as part of the user interface both during targeting and for damage control. The interface is much clearer than a traditional list based system and gives the player a clearer understanding of the damage they have sustained.
Once you have added a component to the hardpoint it is then a case of configuring it. What exactly needs to be configured depends on the component; so a hull holds information about the mass of the ship whilst the impulse engines can be configured to give more or less thrust.
How does Excalibur handle ship variants?
There are two main ways. For simple changes such as ship registries we can override information within a hardpoint from the "ship definition" file where the ship's name and affiliation is stored.
Where changes are more complicated, such as additional secondary hulls or different weapon load-outs, we can overlay hardpoints together. So for the Nebula class ship which has several different "pods" we can create a base hardpoint which will be the same for every Nebula class vessel, followed by a secondary hardpoint which will apply to only one variant and will detail the secondary hull.
Can we create entirely new component types, e.g. propulsion systems?
Yes, the entire hardpoint system is modular which means you can create new component types and define special behaviours for them in the game.
A good example of this is the cloaking device, which adds a button to the user interface and when triggered calls a graphical effect and makes the ship far more difficult to detect.
How will Excalibur handle mod requirements?
Excalibur itself is pretty flexible when it comes to the types of files that can be loaded into the game. If you've seen our screenshots of the Intrepid interiors from Elite Force you can see how this is demonstrated. Since they are .BSP files being rendered directly by the engine and have not been converted to an Excalibur compatible file type.
However for some things, locking to a single file type is unavoidable. Things like ship and stations for example have specific requirements which can only be handled via a specific file type which means ship models need to be in .DAE format and textures need to be in the .DDS format. Effects like hull weathering are also done through the texture file.
In other areas the flexibility is a great help to us things like hull decals can be almost any standard graphics format, this includes .PNG, .JPEG, .BMP, etc. For now we prefer to stick with .DDS as we like to have a standardized approach and this file type supports layers, making things like registries much easier.
How do separable ships like the Galaxy class or Prometheus class work in Excalibur?
First you have the set up process, whereas both ships need to be hardpointed and you need to ensure that when separated both also have the equipment needed to operate. If for example you gave the Galaxy's saucer section warp engines but did not include a warp drive processor in the saucer section's computer, then the ship will not be able to go to warp. So that's something you need to bear in mind when hardpointing and modding!
As for the game-play mechanics, the most likely scenario is that you will choose which section you command while an AI crew takes command of the other section. That being said, you can still give commands to the secondary/tertiary sections of the ship as you would with any other AI ship.
Will we be able to create new planets and add them to solar systems?
Yes, to varying degrees of customization you can create an entire star system by clicking a single button which would generate a randomized star system or you can use the QB Universe Editor to place and modify everything in the system, from the number of planets, the placement of these planets, number of moons, planet type, population of inhabited worlds, ships, and station placements. The team will be using the tool to create all the locations in game so you can expect a great deal of customization options to be available.
Will there be some kind of editing mode for taking beauty shots?
You can create such shots using the QB Scenario Editor which allows you to drag and drop ships and objects into a solar system and move existing objects. Then, by disabling the AI you can prevent ships from firing on each other or moving out of position.
Will there be support for Binary and Trinary star systems?
Yes, many of the key systems in the Federation were made up of multi-star systems including Vulcan, so these systems will be making an appearance. Also consider that some systems on our reference star charts can be made up of 4, 5, 6 or even 7 stars!