Supercruising to another star system reveals design flaws

[OnePercent]

Unsubstantiated. Though if that were the case, and considering all the other missing/poorly implemented features that people commonly attribute to the game being multiplayer, I would have to wonder if perhaps multiplayer was the design flaw since it's apparently the source of all evil, though I don't agree with that assessment.

I understand that your a proponent to a "seamless galaxy" it is entirely possible, but in order to track all 300 thousand players (which is what the severs currently do) you need to instance the players in islands. Otherwise you don't have enough compute power to do so, or use quantum computers to carry out that task. Further instancing of each system as an island too is required for the back ground simulation that the servers handle, this is a LOT of information you need to keep track of, thus it's impossible without portioning off your galaxy into processable chunks.

Look at my avatar picture, that was taken on the surface of an inferno planet in an mmo i use to play called shores of hazeron - it too also had a large procedurally generated galaxy with billions of stars and even it needed each system to be instanced, though there was no need for further supercruise and normal space instance because each system was orders of magnitudes smaller than the systems we have in elite dangerous, so SOH didn't run into the technicl problem of "floating point errors" if FDEV didn't include instancing then this game would be full of floating point calculation errors.

It's unfortunate but it's just a fundamental design barrier with our computer technology as a whole.

 

[deMangler]

I remember the discussion about whether to have seamless SC travel between systems.
It was not considered a technically difficult thing to do, but decisions needed to be made like how do you handle the transition? When do you redraw the skybox? What if there are many players around the halfway point? Things like that. Mainly it was decided to leave these debates for later because it was probably going to be the case that the fuel mechanic (different fuel consumption rates per LY for SC and hyperspace) would mean that you would never have enough fuel to travel to another system that way anyway.
This turned out not to be the case.
The way FD have done it at the moment is (I find myself saying this to myself a lot as I play this game) Placeholder.
It is messy at the moment. This isn't exactly by design but it is a result of design priorities. I am 100% sure it will be addresssed at some point. I remind myself of DBOB's analogy of the house, build a great house, get that bit right, and then fill it with furniture. I would add to that analogy that also when you start living in a house is when you discover the little things that need fixing, or maybe a door needs putting in somewhere. We are at that stage with ED now it seems.

 

[Johnny Spaceboots]

I understand that your a proponent to a "seamless galaxy" it is entirely possible, but in order to track all 300 thousand players (which is what the severs currently do) you need to instance the players in islands. Otherwise you don't have enough compute power to do so, or use quantum computers to carry out that task. Further instancing of each system as an island too is required for the back ground simulation that the servers handle, this is a LOT of information you need to keep track of, thus it's impossible without portioning off your galaxy into processable chunks.

Look at my avatar picture, that was taken on the surface of an inferno planet in an mmo i use to play called shores of hazeron - it too also had a large procedurally generated galaxy with billions of stars and even it needed each system to be instanced, though there was no need for further supercruise and normal space instance because each system was orders of magnitudes smaller than the systems we have in elite dangerous, so SOH didn't run into the technicl problem of "floating point errors" if FDEV didn't include instancing then this game would be full of floating point calculation errors.

It's unfortunate but it's just a fundamental design barrier with our computer technology as a whole.

Isn't FDEV using doubles at this point, which should largely reduce the need for all the instancing/different realities, at least at the solar system scale. Still bugs me how SC is an entirely different dimension than normal space, seemingly.

 

[BrewerGeorge]

Those of you wanting to restore the "immersion deficit" this issue is causing should consider relative velocity. Those two star systems aren't just some number of light years apart, they are moving at vastly different velocities. When you are "in" a given system, you are orbiting it - matched to that system's velocity vector at a galactic scale. A hyperspace jump doesn't just change your location. It also decouples your velocity from one star system and takes on the velocity vector of the destination system. That's why jumps always come out at the sun - because it is reference point for a given system's velocity vector. The result of this is that those objects that you can supercruise to become by definition those which have a close enough velocity vector for the FSD to catch it. Those you cannot supercruise to need the hyperspace shortcut to accomplish the match.

This idea can help explain supercruise, and its 2001c limitation as well. Engaging supercruise gives a ship the ability to easily separate from its orbital position and operate freely within the paradigm of the system at large. Dropping to normal space inserts you into the orbit of whatever - station, ship, planet - you decided to match. The 2001c supercruise limit then becomes the maximum velocity at which a ship can operate while maintaining the ability to slow down enough to match things in the system. 2001c is effectively the "escape velocity" of the star system. Since this is a hard limit across all ships, it must be due to some handwavium limitation of the FSD drive itself.

We can even extend this further to explain the ship top speed in normal space. Ship mass vs thruster power does matter here, so the top speed is simply that which a ship can achieve without "overrunning" it's thrusters to the point where it couldn't catch back up to its starting, matched environment without engaging supercruise to reset the baseline velocity.

TL;DR - Every transition between game instances can be rationalized as velocity vector matching between your ship and your destination.

 

[CaptainKremmen]

How to prevent players accessing those systems that are off-limits in terms of gameplay? eg.

- Reserved for future use (nobody allowed there)
- Per-commander restrictions (special content for some commanders only)

You'd need some alternative mechanism to the ones we've seen to date ("Hyperdrive Malfunction" in beta, "Permit Required" in release).


As it stands now, the system is unambiguous and straightforward... You're either allowed in, or you're not.



In my book, we should strive to do more than just stating that "the current mechanism is poor". See if you can propose a graceful alternative method that meets the system lockout requirement.

And, no, a message saying, "You are approaching simulation boundary" doesn't cut it.


Thinking caps on...

 

[deMangler]

Those of you wanting to restore the "immersion deficit" this issue is causing should consider...

Spoiler

relative velocity. Those two star systems aren't just some number of light years apart, they are moving at vastly different velocities. When you are "in" a given system, you are orbiting it - matched to that system's velocity vector at a galactic scale. A hyperspace jump doesn't just change your location. It also decouples your velocity from one star system and takes on the velocity vector of the destination system. That's why jumps always come out at the sun - because it is reference point for a given system's velocity vector. The result of this is that those objects that you can supercruise to become by definition those which have a close enough velocity vector for the FSD to catch it. Those you cannot supercruise to need the hyperspace shortcut to accomplish the match.

This idea can help explain supercruise, and its 2001c limitation as well. Engaging supercruise gives a ship the ability to easily separate from its orbital position and operate freely within the paradigm of the system at large. Dropping to normal space inserts you into the orbit of whatever - station, ship, planet - you decided to match. The 2001c supercruise limit then becomes the maximum velocity at which a ship can operate while maintaining the ability to slow down enough to match things in the system. 2001c is effectively the "escape velocity" of the star system. Since this is a hard limit across all ships, it must be due to some handwavium limitation of the FSD drive itself.

We can even extend this further to explain the ship top speed in normal space. Ship mass vs thruster power does matter here, so the top speed is simply that which a ship can achieve without "overrunning" it's thrusters to the point where it couldn't catch back up to its starting, matched environment without engaging supercruise to reset the baseline velocity....

TL;DR - Every transition between game instances can be rationalized as velocity vector matching between your ship and your destination.

This is brilliant!

 

[OnePercent]

I remember the discussion about whether to have seamless SC travel between systems.
It was not considered a technically difficult thing to do, but decisions needed to be made like how do you handle the transition? When do you redraw the skybox? What if there are many players around the halfway point? Things like that. Mainly it was decided to leave these debates for later because it was probably going to be the case that the fuel mechanic (different fuel consumption rates per LY for SC and hyperspace) would mean that you would never have enough fuel to travel to another system that way anyway.
This turned out not to be the case.
The way FD have done it at the moment is (I find myself saying this to myself a lot as I play this game) Placeholder.
It is messy at the moment. This isn't exactly by design but it is a result of design priorities. I am 100% sure it will be addresssed at some point. I remind myself of DBOB's analogy of the house, build a great house, get that bit right, and then fill it with furniture. I would add to that analogy that also when you start living in a house is when you discover the little things that need fixing, or maybe a door needs putting in somewhere. We are at that stage with ED now it seems.

A completely different approach is need to make the transition seamless, the approach is to actually render the points of light from stars in our skybox and nebula, as you approach the star you will begin to see parralaxx of the stars around you appearing to move and then you start to load in system data and assets from the procedural code.

This is possible to do in space engine but is not possible when your game is multiplayer and you wish to keep track of your playerbase.

 

[Agony_Aunt]

LOL, calling something a design flaw when its a design decision.

And OP, really, you could have saved yourself a lot of time by picking two stars close together. When i tried it the stars were 2.5 million LS apart, took me less than an hour.

 

[OnePercent]

Isn't FDEV using doubles at this point, which should largely reduce the need for all the instancing/different realities, at least at the solar system scale. Still bugs me how SC is an entirely different dimension than normal space, seemingly.

As it seems even double precision is not enough. The universe is enormous and we are just too low in technology to completely and seamlessly reproduce it on our capable hardware yet.

 

[Johnny Spaceboots]

This is brilliant!

Not really. It's more than a bit hand-wavey, and doesn't really make much sense in the context of an alcubierre drive... like, at all. I mean, if you want to rationalize it like that, more power to you, but what we have is still horribly immersion breaking.

 

[OnePercent]

The only thing i can think of in turn to be able to deliver a truly seamless and extremely detailed universe would be a hybrid of euclideons unlimited detail point cloud technology and procedural generation to avoid making terrabytes of data.

 

[Johnny Spaceboots]

As it seems even double precision is not enough. The universe is enormous and we are just too low in technology to completely and seamlessly reproduce it on our capable hardware yet.

I don't know about that. At the very least, solar systems shouldn't be running into precision issues, and Vlad gave a good explanation of how he does it
http://en.spaceengine.org/forum/20-1717-31766-16-1381697620

Using hierarchic coordinate system. I.e. planets position/rotation are calculated in double precision float relative to system barycenter (it have coordinates (0,0,0)), system barycenter is stored in single precision float (that's enough) relative to galactic center (it already have coordinates (0,0,0) in this reference frame), and galaxies coordinates is stored in single precision float relative to universe origin (that is the Sun smile )
Camera position is stored in 64.64 fixed point number, that is used to precise calculation of a position relative to local reference frame (galactic and planetary system), to avoid lost of precision. It is possible to set coordinates of the camera with precision of 1 mm in the scale range of 15000 gigaparsecs. However I will shift it down to 1 micron - 15 gigaparsecs, for better precision on the small scale.

First, I use double precision calculations. I compute all matrices on CPU in doubles, and convert it to float and load to GL before rendering only. Second, I use hierarchical coordinate system: universe -> galaxy -> star. This mean that when the camera enters a galaxy, a new coordinate system starts to use origin at that galaxy's center. All stars are placed in this system. All updates of the camera position are made in two systems (universal and galactic) simultaneously. When the camera approaches the star, the third system starts to use it with origin at planetary system center. Maybe in the future I make a fourth system - planetary. Another way to handle space scales - is making your own huge 128-bit fixed point numbers and arithmetic functions with them. These numbers can handle a scale of 100 billion light-years with precision of... 1 micron! smile

It would be nice if a developer, who is familiar with FDEV's own unique challenges could clarify this.

 

[OnePercent]

I don't know about that. At the very least, solar systems shouldn't be running into precision issues, and Vlad gave a good explanation of how he does it
http://en.spaceengine.org/forum/20-1717-31766-16-1381697620





It would be nice if a developer, who is familiar with FDEV's own unique challenges could clarify this.

Yes but this only works for a single player experience, the FD servers need to keep track of hundreds of thousands of players AND the back ground simulation of trade, politics and geopolitics.

 

[Johnny Spaceboots]

Yes but this only works for a single player experience, the FD servers need to keep track of hundreds of thousands of players AND the back ground simulation of trade, politics and geopolitics.

I'm not convinced that it's impossible to make it work in multiplayer. Keeping track of players and the very much so anemic background simulation that we have thus far should be possible, and I haven't heard any convincing arguments as to why it wouldn't be.

 

[BrewerGeorge]

Not really. It's more than a bit hand-wavey, and doesn't really make much sense in the context of an alcubierre drive... like, at all. I mean, if you want to rationalize it like that, more power to you, but what we have is still horribly immersion breaking.

Of course it's timey-wimey; it's fictional technology. It is simply an attempt to supply a consistent, background logic to the reality of the game design choices.

 

[OnePercent]

You also must understand that space engine's planet detail will be dwarfed by that of FD's intended level of detail (imagine no man's sky but it's elite) thus this adds another level of precision required that space engine cannot do simply to limitations of our technolofy UNLESS you instance portions of your universe.

 

[OnePercent]

I believe we need to completely rethink our definition of "precision" in games if we are to ever face this issue of precision requirements and barriers.

Or just make 128 bit CPU's

 

[Johnny Spaceboots]

You also must understand that space engine's planet detail will be dwarfed by that of FD's intended level of detail (imagine no man's sky but it's elite) thus this adds another level of precision required that space engine cannot do simply to limitations of our technolofy UNLESS you instance portions of your universe.

That's pure speculation. We have no idea what Frontier will deliver, and you have to clearly understand that Vlad has been working primarily on space related things, barely even getting to the vast majority of planet improvements that he has planned, similar to how FD hasn't polished the fidelity of their current celestial objects yet http://en.spaceengine.org/forum/21-11-1

Planets:

Decrease of loading/generation time
Improving the level of detail, reaching of 1 mm per pixel detail
Lighting of planets with quasar, galactic core, clusters and nebulae
Distortion function for elevation map (terraces, horizontal shift)
Modeling of continents
Illumination of planets with globular clusters, galactic core, close nebulae, supernovae
Self-shadowing of the terrain, ambient occlusion, global illumination
Animation of clouds, cyclones
Clouds shadows on the landscape
3D clouds with lighting and self-shadowing
God-Rays from the landscapes and clouds in the atmosphere
3D water with waves animation, simulation of the tides
Refraction and reflection on the water surface
More types of atmospheres, generation of models at run-time, binding to astrophysics
Volcanoes, volcanic eruption, animation of explosions and ash clouds
Glowing lava flow animation
Magnetic field modelling
Lighting of the planetary surface with aurora
Dust and the asteroid belts around stars and planets (rings), animation, or simulation of the motion
The shadows of the satellites and other planets on rings and vice versa; volumetric shadows inside the dust rings and self-shadowing of the rings
Illumination of a planet and satellites by the rings
Improving gas giant atmospheres
Surface components (stones, plants, roads, buildings)
Terramorphing
Landscape with water and thermal erosion
Tectonic plates
Modeling of asteroids collisions with lighting, explosion and the formation of the crater
Animation of meteorites and meteor rains
Holes in the surface (caves, mines)
Right cone of the shadow of the eclipse from moons and rings in the atmosphere
Refraction in the atmosphere (up to the "bow-tie world")
Weather conditions (rain, snow, fog, lightning, rainbow)
Seasonal changes (snow cover and polar caps, dust storms, evaporation or freezing of the seas and the atmosphere)
Climate and surface generation of "lying on its side" planets (like Uranus)
The planets floating in the interstellar space (planemo)
Modeling of 2D gas dynamics of the atmosphere on the GPU
Modeling the tectonics and evolution of planets
Simulation of the collision, tidal or artificial destruction of the planets, formation of the asteroid belt and the dust disk around the sun, its further evolution
Modeling the evolution of the planetary system when the sun goes in the red giant phase
Simulation of destruction of the planetary system in a supernova explosion
Improved modeling of the structure of the planetary system, taking into account migration of the planets, resonances, high ellipticity and inclination of orbits
Different types of clouds, multiple layers
New classes of planets, binding to astrophysics, geology and geochemistry
New classes of surfaces
Linear and radial structures (rivers, grooves, scarps)
Checking of collisions with the surface
Fixing of bugs with ellipsoidal planets
Asteroid belts and comet clouds
Underwater World
Different types of hydrosphere (water, methane, lava sea, etc.)
Different types of terrain in different places
Animated aurora
Asteroids
Comets with an animated tail
Evaporating planets with an animated tail
Planets, tidal locked to their suns
Ocean worlds
Ice worlds with hydrocarbons oceans (titans)
Brown dwarfs
Lights of the night side (hot planets, lava, cities)

Again, I'm not seeing a convincing argument that seamlessness, at least approaching Space Engine if not rivaling it, is impossible for a multiplayer game. Especially when it's just 1 guy working on space engine who for the majority of development has been doing it in his spare time until people recently donated enough for him to quit his job.

 

[WalterHWhite]

Heh, I was thinking a simple splash 'approaching new system' screen would appease.

Constantly redrawing the sky (every 5 minutes or so should be fine, 99% of the sky and pixels unaffected) seems like the kind of minutae that just isn't economical processing-wise or rewarding enough for (most?) users. A player would have to sit there for 30 minutes in supercruise and would have to stare constantly to see the new pixels.

If there was a real-time continuous journey at 100000c or whatnot then sure, seems like something that'd be relevant.

The servers reboot every 24 hours so there's a fairly small limit in how much the celestial surroundings would change.

 

[Johnny Spaceboots]

Heh, I was thinking a simple splash 'approaching new system' screen would appease.

Constantly redrawing the sky (every 5 minutes or so should be fine, 99% of the sky and pixels unaffected) seems like the kind of minutae that just isn't economical processing-wise or rewarding enough for (most?) users. A player would have to sit there for 30 minutes in supercruise and would have to stare constantly to see the new pixels.

If there was a real-time continuous journey at 100000c or whatnot then sure, seems like something that'd be relevant.

The servers reboot every 24 hours so there's a fairly small limit in how much the celestial surroundings would change.

I think that a real-time continuous journey at 100000c, or whatever, would be preferable than the current hyperspace loadscreen. It would be visually spectacular, and could open a lot more doors for engaging exploration gameplay than clicking on a menu and choosing which level you want to load.