An essay by our lead game developer, Rob Mann, on converting the abilities and technology we saw on TV into gameplay mechanics.
Posted by Xavier55 on Feb 8th, 2014
Recently I was asked how one would go about taking what we've seen on screen and convert that into a playable mechanic for a game such as Excalibur. Truthfully it's an interesting question and one that isn't often touched upon in game design as most games are based on new IPs. This process does not however take into account the challenge faced with developing content for a franchise as varied and expansive such as Star Trek, in that you have 1000+ Hours of content from the live action movies and the TV shows (providing you accept traditional canon.)
If we take games like Star Trek: Bridge Commander, for example, the gameplay mechanics are focused entirely on what is needed for the game to progress and only the mechanics needed were coded. This is why we didn't have an extensive shuttle launching mechanic, saucer separation on the Galaxy class, the ability to walk around the bridge or the ability to manage your crew. In short they weren't a requirement for the final product. If we take warp drive as an example (and one which will be explored in depth as the article progresses), in Bridge Commander the warp drive simply serves as a method to move the player from location to another and the only requirement for its use is that the warp drive and warp engines be online, ignoring things such as hull integrity, available power and even variations in travel time vs. warp speed.
In other games such as Star Trek: Armada, Starfleet Command and Elite Force the mechanics are dictated partially by the environments and partially by the gameplay choices. It's an FPS so you wouldn't need to develop interactions with consoles or complicated ship controls for the game. Take for instance in Elite Force II when you fire pulse phasers from the underside of the Enterprise which has been damaged in an attack. This ability has never before been mentioned or seen in the series and exists only for the purposes of this specific set piece. For the FPS genre it makes for an acceptable inclusion as a traditional turret defence mission, albeit one out of place for a Star Trek game.
Turning back to Excalibur, this approach has been turned around. While we have an idea for a campaign, the content of those missions does not dictate the mechanics which are to be developed for the game. Instead the mechanics will be used by the player to advance the story. This allows unparalleled authenticity when it comes down to the player’s experience: Starfleet gives you an objective and it's up to the player to complete those objectives, while upholding Starfleet regulations. Liberating a colony does not necessarily mean destroy all hostile forces. The goal is to free the colony and it is up to the player how they do this. The story therefore needs to reflect this. Scripted events can still happen of course and at times there will be instances where certain ships are given "Plot Death Immunity" which limits what the player is capable of achieving, but the goal is to make these instances as rare as possible.
In keeping with the theme of maintaining authenticity and to return to the point at hand let's look at the warp drive. Warp drive is a vital component of the Star Trek universe and since Excalibur is a sandbox universe, vital to Excalibur too.
Warp drive has been seen and used in every series and movie in the show and it is indeed a very complex piece of technology with pages and pages of dialogue referencing its usage and its limitations, and equal numbers of pages referencing contradictions in its usage (VOY: Threshold for example).
So where to begin? Certainly with so much material it's difficult to work out what should and should not be used. One of the biggest advantages show writers had was that they had the luxury of putting something new in one episode and then never mentioning it again. With game development no such luxury is afforded, because in order for your game to have a consistent and reliable style of game play the mechanics must behave in the same manner every time, and just like in real life they must obey fixed laws.
What is required in that case is a Universal Law of Warp Field Mechanics and since the shows themselves do not provide such a law one must be created from scratch. This does unfortunately mean you need to go against the rules of canon. For example Warp 5 in Enterprise is stated to allow travel between Earth and Qo'noS in 5 days. This completely contradicts what we have seen on screen before as it would mean that Qo'noS is only a few light-years from Earth. Clearly this is a fault on the part of the writers but it highlights the methodology that needs to be applied when dealing with this situation. Either Qo'noS is a couple of light years from Earth or it is far away and the warp speed stated is wrong. Granted there are other options you could invent to reconcile both facts but none of those could easily be reconciled into a usable gameplay mechanic. Given that the most consistent speeds and distances are in TNG and DS9 due in part to the larger quantity of material and since this is the approximate era for which the game is set, we would disregard the erroneous statement from Enterprise in favour of the more reliable and in general more consistent figures used during TNG. This also means that we will be using the revised TNG era warp factors rather than the TOS figures as this is the most well-known warp speed system with a majority of episodes and movies utilising it. It also has the advantage of placing a limit on the drive which prevents technical issues surrounding high speeds which can produce large values that can create issues with the physics engine.
Next we look at the mechanics of the drive based on what is common within the series. This breaks down into several components which are consistent in all instances.
There will undoubtedly be instances where the 11 rules mentioned above are violated by on screen evidence but as stated earlier these instances are most likely plot requirements rather than a set standard. We could go into warp field theory by involving things such as intermix ratios, but we also need to keep the drive as simple as possible for non-Trek fans and the 11 guidelines decided above still give plenty of flexibility in the development of mechanics.
You might notice that environmental effects are mentioned in the list of rules. Since environmental factors influence the warp engines it is actually less efficient to code it the warp engine to respond to the conditions. Not only does this limit the number of factors that can affect the engines but it also means that potential modders face a more difficult task of adding different environments. The solution therefore is to create a separate mechanic for environmental forces and place these conditions within the universe. If each one is given a proximity trigger then any ship which enters range will have an effect applied to their warp engines, this effect can then be removed when the ship leaves the range. This way you can perpetually add new effects to the universe without the need to alter the warp engine code to take this into consideration. In practice you can shut down the warp engines of any ship which enters your designated affecter's range using a single line of code. This gives you unprecedented power as you can now manipulate a ship’s systems in certain environments with relatively little effort.
The key point to remember is that keeping true to the exact word of canon is not possible there are simply too many contradictions. The best approach is to work out the elements shared in the most instances and extrapolate a set of rules that when applied can simulate a believable imitation of the warp drive as its functioned on screen under optimal conditions.