I Support A Drastic Zag For QT (And Jump Points)
Based on the design notes they've previously expressed, let's take assume a couple of firm priors that limit how QT can function.
1. Travel time factors into multiple elements of the game's design. There are the economic factors for trade of course; but combat reinforcements, medical gameplay, exploration and a host of other planned mechanics also touch on in-system or cross-system travel times. Maybe the times are too long as they are now, but they can only get so short before they no longer have any relevant impact on these other systems. 2. During QT, ships should be vulnerable to interdiction. Either by faster ships intersecting them or by specialized devices laying in wait to trap a target. 3. Larger ships are intended to be faster in QT with longer range, while smaller ships are faster/more maneuverable in normal space and atmosphere. Smaller ships are also able to access more convenient inter-system routes by fitting through smaller jump points. 4. Ships are intended to be able to "link" their QT drives to travel with escorts or as a fleet. 5. Ships *CANNOT* be allowed to travel freely in QT. All QT trips *MUST* be destination based. This connects to the exploration, scouting and data courier roles. *IF* a pilot could freely fly across the system without any beacon or pre-set destination, it undermines a principal role for data-couriers. If a scout or explorer finds something at a certain set of coordinates, they could securely relay those coordinates to a friend via chat and that friend could manually plot a course to meet them there. This completely eliminates the need for a secure data-courier to relay that information in game.
Now, what is the most common underlying complaint about QT?That it's boring. That it's a "loading screen". Essentially, that it stops play and zeros out the engagement curve of the game. That's not a complaint about how long it takes to get somewhere, that's a complaint about what you're being asked to do during that time (which is nothing).
What is the anticipated "zig" based on past statements by CIG? Essentially, they wanted to offer distractions. Wander around your ship, do some maintenance, check your mobi-glass, talk to friends, fiddle some dials to optimize QT, reduce fuel ranges to force more stops at rest areas, increase the number of interdictions and anomalies that interrupt travel... But none of these change the underlying problem, especially for single seat ships. In every one of these solutions, there is nothing for the pilot to do, except sit and wait for an interdiction or anomaly. In terms of game design and the engagement curve, this creates a flat line with intermittent spikes. That is not a curve, that is a heart attack.
​
What do I anticipate is their "zag"? I think they're planing to take their ["jump point" travel plans](https://youtu.be/Jn5FBGfXACM) and swap them with QT, and I fully and enthusiastically endorse this.
​
This would give the pilot something to do, and create knock-on roles for a co-pilot that could be split further to scanning, navigation and engineering roles. The scanning station could look ahead for hazards, the navigator could try to adjust the course slightly to avoid those hazard tens or hundreds of thousands of kilometers ahead of time, while the engineer can optimize performance and mitigate any heat or damage caused by hitting those hazards.
There could be calm space with gentle solar winds and stable gravity wells. There could be more dangerous space with increased solar flare activity, churning gravity waves and spatial anomolies. There could be established trade lanes with buoys designed to make QT more stable. Rather than dying in a jump point, getting knocked out of QT would simply cause some system damage and at worst leave you stranded in need of a Vulcan or Crucible. There could still be an auto-pilot feature for those that want it, with blade upgrades allowing it to deal with more hazardous routes.
How does this interact with those 5 design points we started with?
1. Travel times can continue to be adjusted by CIG based on their design preferences. 2. Interdiction is where it gets interesting. Interception would be no different than currently planned, but I think traps would be better served by this method. Instead of a bubble, imagine interdiction fields as magnets that draw ships off course until they are within range to stop. This would put the navigator of the targeted ship in direct conflict with the operator of the interdiction device. The navigator trying to maintain course, while the interdictor tries to keep drawing them in. 3. I think this option creates an even more interesting balance between ship sizes in QT. Perhaps a small ship is better able to dodge hazards in QT without having to change course, and a skilled pilot can accept that risk with the reward of making up a bit for having a slower speed. Maybe larger ships are better able to crash through certain hazards, taking only a modest heat spike where a smaller ship would be thrown out of QT. 4. What if the ships could fully link their QT drives, not just their navigation? What if all linked ships were put in the same QT bubble, with the largest ship determining the size of the tunnel? I think that'd be an interesting sight, and it would allow for that awe-struck moment when an entire fleet pops out simultaneously. 5. This system still requires a point of origin and a destination. It allows for some slight tweaking of the spline by the navigator, but would present the same difficulties trying to exploit as the current navigation system.
The main issue with this is, how do you anticipate and dodge hazards at such great distances moving at such intense speeds? I think there are two possible solutions.
**-A:** The easier but less "precise" method would be instancing. Each time a QT jump is initiated, the ship or ships involved in the jump would be put in their own instance. The route and hazards would be generated at relative sizes and distances to allow for pilot response time. The instance would remain connected to a placeholder entity on the main server, so the navigator would maintain accurate information on their actual position as would anyone watching them on long-range scanners. This same position is where they would be dumped if they were forced out of QT early. If done correctly, none of the players in or out of the instance would actually notice this was how it was being done.
**-B:** The more difficult to manage solution would keep the ship or ships in the same "real space" as everyone else. The hazards would have to be narrow enough for the ship to move vertically and laterally to evade them at speeds the pilot can manage. Maybe 10m to 100m. They would also have to be long enough that they last more than a couple of frames as the ship passes by. Maybe 100km - 100,000km. There would also be a lot of work from UI and VFX to set up an AR for the pilot that dilates the appearance of these hazards so they can see them coming.
I would vote for method A, the difficulty on the back-end is monumentally less difficult to engineer and again, if done correctly the players would be hard pressed to notice the difference.
​
That leaves the question, if we transplant jump point gameplay into QT, what do we do for jump points? Personally, I'm fine with jump points being 100% down time. They will represent a smaller portion of our in-game time, and if there is any risk involved in jump points the consequence is 100% death with no chance of recovering your bodies. Let jump points be the time we spend wandering around our ships and checking our in-game email with no risk of interdiction. When it's almost over, give me a quick warning to get back to my seat in case there's an ambush waiting on the other side.
​
I'm curious to hear what others think on what the zig and zag options are, and how they'd like it to play out in a way the respects those five primary design elements?