Posted August 20, 2016
![avatar](http://images.gog.com/8ecbd0abc689d077e4f106af5516b22d7effb7efa6dfebd69aa3c725d7b3596b_avm.jpg)
It's like saying that it makes sense to make a car with one specialized engine for each gear.
But what does make sense is that HG might have become convinced that they shouldn't spend time on implementing longer distance space-flight, instead of mashing the planets closer together. Which.. is sort of what they've been saying. That everything has been geared, specially since this year, into making the close space surrounding the space-station easy to reach. To the point where they have "toned down" planetary movement (to nothing) because it was "confusing" to some players, etc.
I would have preferred some sort of more dynamic speed on the flight, I guess. The same type of pulse-drive they have now, just with another step in between planets. So the longer distance, the more empty space, the higher speeds.
I mean, again, just making the point that when they have implemented different speed phases depending on proximity to stations and planets. Does it really make sense that they wouldn't have had a similar system for the other jumps? Like - "oh, awesome, we managed to solve something no one has ever done properly before. But now, let's not take any risks, so let's write a traditional engine solution for everything else in the game, just so we can have some normal loading screens. And then pump the surfaces full of blur-effects so it looks like everything else on the market. Really, let's not be arrogant here with our graphics tech! Remember, we need to give people what they expect, or we'll bomb!".
Doesn't strike me as the most obvious way they'd solve this.
What is probable is that they'd remove the transition steps completely. For avoiding the possibility of having to spend "too long" traveling (imagine the comments - I'm so bored with all the warping!". It takes so long to travel between the "spheres in the heavens". I feel very disoriented. Etc. Disaster!
And also have no fetches of any kind outside the local system to stop unpredictable things from creating "potential issues". (I've talked to a middle-manager at a dev once who insisted that it didn't matter that heaps were faster and more resource-efficient in a project. Because he knew that linear and brute force eventually would get the job done every time. We'd go.. "but, but.. you see, math.. here's logic.. proof... running time analysis. Determined maximum number of node jumps given abstract framework limited to 24 character sequences. Wouldn't have any of it - so boss demanded that the solution should be /safe/. Turns out, they made a lot of money, so they must have been right!).
But the way you transition between planets and space is the same method they'd use, right... Except that part is much more elaborate, and with objects that have more detail meted out in a very short amount of time.
I mean, we do get that, right? That when you see the landmasses from orbit, and travel down to land on the specific large blob that turns out to be a mountain - this is the same process as approaching another star-system. Just with more detail dropping in at a much higher rate?
Seamlessly approaching planets from a distance as well, determining how it looks at every step of the way (that is, instead of swapping out the flash-card for a new one real fast when no one's looking). It's the same impossible feat here. And it has just not been done before.
But no - there's a wall behind the last planet, and the sun is fake. End of discussion. Clearly, there's a skybox there, because otherwise the ram would be too small from the number of stars in the galaxy having to be sored. Thank you for being open-minded and respectful of other people's views. *sigh*