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.
- Warp Fields are created using Warp Coils - therefore we must somehow represent the warp coils effectively as these are what will become your Warp Engines.
- Warp Fields require high energised plasma in order to generate a field - we need some way to represent this ingame.
- Warp Engines can overheat through excessive use - potential for a gameplay mechanic?
- Alterations to the warp field are handled by the ship’s main computer.
- Warp Engines operate in pairs, except in certain instances where they can operate with one or three engines, so a single engine needs to be able to operate as a pair (perhaps toggle-able)
- Certain engines can be offline but the ship can still go to Warp (see Prometheus Class when not separated).
- Warp engines can only be run for a certain period of time before they need to shut down.
- Warp Fields are affected by the environment.
- A Deflector is required to allow safe travel at warp speeds.
- A ship must be structurally sound to survive acceleration to and deceleration from warp.
- Course corrections can be made at warp within limitations.
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.
Nice :)
I remember in Bridge Commander where I went to warp to save the ship. It was burning and cored... and it only had one nacelle.
I'm looking forward to seeing more canon warp mechanics. Also, will it be possible to warp-strafe? You know, fight at Warp speeds?
maybe shooting at each other in warp but i cant see ships doing maneuvers or even dodging just firing torpedoes at each other
A ship is limited to one direction of travel in warp and must drop out of warp for at least 3-4 seconds to calculate a new course, according to cannon. So you are right. That is why most starships when they come under attack at warp drop to sublight speed, because they are then capable of maneuvers. Maneuverability of a starship at warp is like a brick flying through the air.
You might be able to strafe drop out of warp. then come about and warp again, but it would not be worth it, I think.
It would be an interesting mechanic to add for an Alpha strike. You know, you detect the enemy, say, 10 light years away, you lay in an intercept course, and then order your crew to perform a warp strafe. They leap to warp, fire all the torpedoes they can, then drop out of warp an appreciable distance from the enemy. The photons torpedoes impact at speeds the enemy can't dodge, before they can raise their shields. A downside might be that there's a higher chance of missing your opponent? Tradeoff is that if you're on-target, you'll hit your unshielded opponent, guaranteed.
In the Next Generation, they already have torpedoes that travel at warp. Why would you need to take your ship to warp and have a huge energy signature aimed at the target. A few warp torpedoes would be less likely to attract attention. Unless you like the idea of over-kill or your target seeing you coming.
A solid read. Well done.
This is good stuff. I think about such things often when imagining converting existing IP into a game, though I have the benefit of not doing the heavy lifting to put it into practice.
I did take issue with one point though. When dealing with warp speeds, I don't see how the physics engine and its limitation with high speeds makes any difference, as unless you're going to allow in-warp-combat (Startrek Into Darkness style), as soon as a ship goes into warp, no hit detection is necessary. In fact, you don't even need to track the position of the ship, as it should be a probability curve anyway right?
I want to warp from A to B. The game looks at the distance from A to B, and decides how long it should take to get there. My ship 'enters warp' visually, but is actually just removed from the universe and put into a nice looking space-tunnel, while the game just counts down until arrival.
Admittedly, I'm more familiar with non-StarTrek FTL theories, and am only a casual ST fan.
There is limited in-warp combat in Star Trek, though it is seldom shown as an exterior scene. Before Into Darkness, we see it in Nemesis (The Scimitar disabled the Enterprises warp drive while at warp)and there are many point in Deep Space Nine where Dominion ships attack a shuttle or the Defiant at warp.
That is the easiest and most traditional way to code a warp jump, but I agree with the developers that the warp drive should be more accessible in more situations. The tunnel would limit the creativity for a player to solve certain problems. The Picard maneuver would be very hard to pull off if warp was an isolated tunnel. Also, it would be nice to have to drop out of warp if you came under attack.
This is an exciting development that should help make this an amazing game. I did have a few thoughts about the warp "rules" though
I don't remember warp rule 7; could I have a reference for that one.
Also, number 3 only happened when ships were going at more than the recommended cruising speed for long distances. the Enterprise NCC-1701, for instance, could travel at warp 8 in an emergency, but routinely only
went at warp 6. Warp Six worked for extended periods provided there was
enough dilithium (lithium in season one TOS) to focus the reactor.
Lastly, number 11 is simply flat wrong according to Tom Paris on Voyager. He stated in one episode that the first thing they taught pilots at the academy was, "When faster than light, no left, no right". There is probably conflicts in the cannon, but Paris seems very certain about this, and he is acclaimed to be one of the best helmsmen.
Hello TiberiousKirk, you are right on your notes, but mostly, because it was only a single line of text above and not further explained. Lets go point-by-point:
3) Only applies, if the ship is above cruising speed. Cruising speed means the point, where the heat generation and the heat dissipation are in balance. Speeds above cruising speed heat up the warp coils until a critical level of heat has been accumulated, where the engine must reduce its speed or must be shut down. Maintaining critical temperatures causes damage to the coils, which may only be repaired in docks/starbases or special ships. TOS as reference is also outdated.
Point 11) The Nav-deflector projects a frontal dispersion field to both: Destroy small debris and to lead it out of the way (depending on the size). As this protective forward barrier is not a single point but has an area, the ship can correct its course to the outer edges of the field where the space is still free of debris. In gameplay-mechanics, the course-correction is very small (maybe a degree per second or even less)
In general, it makes more sense to go out of warp, correct the course and go to warp again instead of flying a curve that is as big as 5 star systems.
Cheers,
Shevchen
Thank you for your reply. I'm still not sure about number 7. Your number 3 explanation makes sense. I appreciate the clarification. I don't think referencing TOS is outdated though as the tech for all series, except JJ Abrams movies, are based on TOS; yes, the time at which Excalibur takes place the TOS tech itself may be dated, but the idea behind the tech still applies with some exceptions (ie: Dilithium recrystallization).
I still don't think point 11 makes too much sense though. Will the inertial dampeners and structural integrity fields handle turning a ship at warp? Despite the nav-deflector field, which is not the the issue I meant to address (sorry for the confusion), and only a degree of turn, the energy requirements would be large. I think it would be more likely that the either the ship would mostly survive with the crew being smears on the wall or the ship would crack like an egg. Imagine traveling down a highway at 120 miles per hour (193 kph) and then attempting to turn. Even at small increments you'll feel the stress of the turn as pressure or a sudden lurch. Since warp speed is an exponential measurement, it would be hard for me to imaging a ship capable of making even a one degree turn at 186,000 ^9 mile per second (300,000^9 kps).
11) You travel inside a warp bubble, meaning there is actually no stress involved as long the bubble covers up the whole ship. At very high warp speeds, the warp-bubble will start to buckle, causing structural stress. The turning rate of the ship is thus pretty much independent of the structural stress, but more on the warp field mechanics themselves (bubble-stability, area of coverage) and the Nav-Deflector coverage (Is the space you travel through free of debris).
7) Point 7 is linked to point 3. If they overheat, they have to shut down. You also consume anti-matter, which means that for Federation and Klingon ships, you may run out of "fuel" after some time.
Very well thought out and put together. I like it.
You certainly put a lot of thought into this. Your work continues to impress. I can't wait to see the final product.
This article gave me an idea for a tactical maneuver. However, I'm not sure the game engine would allow it.
Lets say you have two federation ships under your command. You are being attacked by a prototype Romulan warship that has you outgunned.
One of your ships is heavily damaged but the engines and warp drive are still operational. The weapons on that ship would be destroyed or offline.
Your second ship has only taken minimal damaged.
Could I set my damaged ship on a collision course with the Romulan prototype and rig its warp core to blow?
The crew of the damaged ship would man the escape pods and shuttles to escape.
This would give the first ship time to retrieve the escape pods and shuttles and escape. Hopefully, crippling or destroying the Romulan prototype in the process.
The game engine is able to allow such behavior, but your situation is rather special. Federation commanders would not really try to "ram" a ship - this is more the behavior of Dominion or Klingon ships. Also, ramming an enemy ship might be futile, if it still got shields - remember: Everything you could do should be possible for the AI too. So if ramming a fresh ship would be a valid option for YOU, it is also a valid option for the AI against YOU. Thus ramming should only work on ships, that have a very low shield integrity and are unable to evade - which implies, they are already disabled, which defeats any reason to ram. It depends on the game logic. In general, ramming should be handled to be only valid in very narrow margins and even then not always possible to be executed (you still have to hit)