When generating a system, time can be taken into account. Planets move around their orbits for example, but even a catastrophe could be set at a specific time with that procedural algorithm, rendering the system different than before that time. So, changing systems are very much possible with such a system. And of course there is a database override. Whenever a system is in the database (earth and surrounding systems for example), the procedural part will be skipped or at least changed by it.
Confused about procedural universe
- Thread starter YoBuck
- Start date
Impressive ... MOST Impressive! Thanks for chipping in Ben, really appreciate it.
P.S. I will never complain when the system map is a tad slow to pop up ever again
Last edited:
It takes several seconds to load the system map, and gets annoying quickly when repeatedly entering the same map. Nine times out of ten the map won't have been updated between views - after all the dynamic galaxy isn't really very dynamic at all. This topic has been talked about already - I was only replying to a dev's post in the hope that they might see it.
Procedural generation in terms of ED's "stellar forge" isn't random, however it will most likely use some features of computer "random" number generators to aid with it. The important thing to know is that without some very clever coding and external input sources (sometimes even a hardware random number generator), computers cannot and do not generate truly random numbers. However modern systems will put all manner of variable seeds into the calculations to make the numbers effectively random.
For those that aren't aware, a computer's random number generator takes a "seed" value and from that returns an arbitrary value. When the same seed value is given to the random number generator, the same value is always returned (and the next number to be used is generated from this as well). Therefore a random number generator can be used to generate a sequence of numbers that while "random" are always the same given the same starting seed value.
The following is speculation based on how I'd design Stellar Forge, I haven't looked into the ED files at all:
It's no coincidence that Stellar Forge is broken down into sectors, these will be used to control the generation of stars in each sector. Each sector will be tagged as to how the stars in it a generated - either manually placed fixed stars (often with names) or the type of sector that the stars contain and the density of them. For example, stellar birth sectors will have lots of young stars, sectors further out in the galaxy may contain older stars that are further apart. Even with this the number of sectors in the galaxy will be huge, but not an unmanageable number but sectors could be grouped together to further reduce what needs to be recorded.
Within a sector stars where stars are procedurally generated, they will be generated based on the type of sector, star system density and a fixed (random number generator) seed for the sector. This last bit is important, because if this value changes then the stars in the sector will change as well. Most likely the first thing to generated is the number of star systems in the sector, then they will be placed based on this value and, most likely, the types and densities of star systems in neighbouring sectors. This is where the real procedural generation "magic" starts to kick in, if a sector borders a really dense sector then there should be more star systems on the edge of that sector than on an edge which neighbours an less dense sector - in technical terms this is likely to be visualised as a 3D density curve skewing the generation of stars in a sector to the higher number regions, which is a pretty similar technique to various normal techniques however in 3D rather than 2D (these things are much easier the visualise in your mind in 2D!).
Once a star system is placed then a seed value, likely generated from the same as the placement value for data space saving, is used to generate the number and types of stars in the star system and the bodies that orbit them. Again, this is procedural where if a star is a certain type then it there be certain expectations as to the number, size and distance of planets and the age and type of the system will help to determine the type of the planets and whether or not they have other bodies orbiting them or not.
The position of every body in a star system is generated as a time delta given a generated path for the body, therefore at the arbitrary zero point in time "e.g. 1st January 3000", all the system bodies are at their starting positions and then it's a relatively simple process mathetically to calculate the current position of each body in the star system. This keeps a suitably stable and predictable system in place which won't be reset to a starting point every time you re-enter the star system. This will also be reason why the mathematics of system body motion is simplistic rather than truly Newtonian because otherwise the maths gets far too unpleasant for a computer game and the processing power available.
While star systems themselves are also on the move - often at rather high speed, given the galactic scale FD won't have modelled the motions of the stars themselves as the game won't be around for 20,000 years or so in order to be able to observe and motion.
For those that aren't aware, a computer's random number generator takes a "seed" value and from that returns an arbitrary value. When the same seed value is given to the random number generator, the same value is always returned (and the next number to be used is generated from this as well). Therefore a random number generator can be used to generate a sequence of numbers that while "random" are always the same given the same starting seed value.
The following is speculation based on how I'd design Stellar Forge, I haven't looked into the ED files at all:
It's no coincidence that Stellar Forge is broken down into sectors, these will be used to control the generation of stars in each sector. Each sector will be tagged as to how the stars in it a generated - either manually placed fixed stars (often with names) or the type of sector that the stars contain and the density of them. For example, stellar birth sectors will have lots of young stars, sectors further out in the galaxy may contain older stars that are further apart. Even with this the number of sectors in the galaxy will be huge, but not an unmanageable number but sectors could be grouped together to further reduce what needs to be recorded.
Within a sector stars where stars are procedurally generated, they will be generated based on the type of sector, star system density and a fixed (random number generator) seed for the sector. This last bit is important, because if this value changes then the stars in the sector will change as well. Most likely the first thing to generated is the number of star systems in the sector, then they will be placed based on this value and, most likely, the types and densities of star systems in neighbouring sectors. This is where the real procedural generation "magic" starts to kick in, if a sector borders a really dense sector then there should be more star systems on the edge of that sector than on an edge which neighbours an less dense sector - in technical terms this is likely to be visualised as a 3D density curve skewing the generation of stars in a sector to the higher number regions, which is a pretty similar technique to various normal techniques however in 3D rather than 2D (these things are much easier the visualise in your mind in 2D!).
Once a star system is placed then a seed value, likely generated from the same as the placement value for data space saving, is used to generate the number and types of stars in the star system and the bodies that orbit them. Again, this is procedural where if a star is a certain type then it there be certain expectations as to the number, size and distance of planets and the age and type of the system will help to determine the type of the planets and whether or not they have other bodies orbiting them or not.
The position of every body in a star system is generated as a time delta given a generated path for the body, therefore at the arbitrary zero point in time "e.g. 1st January 3000", all the system bodies are at their starting positions and then it's a relatively simple process mathetically to calculate the current position of each body in the star system. This keeps a suitably stable and predictable system in place which won't be reset to a starting point every time you re-enter the star system. This will also be reason why the mathematics of system body motion is simplistic rather than truly Newtonian because otherwise the maths gets far too unpleasant for a computer game and the processing power available.
While star systems themselves are also on the move - often at rather high speed, given the galactic scale FD won't have modelled the motions of the stars themselves as the game won't be around for 20,000 years or so in order to be able to observe and motion.
Last edited:
It only takes several seconds the first time a system is referenced - subsequent views are always much faster (well, for me they are) so I'm guessing it is temporarily cached anyway. As for non-updating screens, maybe that's a bug with the local cache not being flushed, but it's not a problem with the rendering per se. I expect they will get this a little bit slicker over time, but long-term local caching might not achieve much if the data has to be checked against the server anyway. Just guessing.
It can't work in reality. You see a supernova several hundred light years away, it's over and forgotten by the time you get there because it actually happened hundreds of years ago. All you would see is the residual dust cloud.
It's trivial to have a single timestamp which reflects the last time the system map 'changed' which can be used to (in)validate any cached version of it. A few seconds isn't a lot, but it's enough to be annoying when it's a system you were in 20 minutes earlier and you want to quickly check something while in SC.
A question - sort of related - do the various bodies within a system move over time, or are they welded into position?
[video=youtube;fMXzhbGuKY0]https://www.youtube.com/watch?v=fMXzhbGuKY0[/video]
[video=youtube;fFJbK5Ryygw]https://www.youtube.com/watch?v=fFJbK5Ryygw[/video]
Last edited:
Beautiful, when people like Ben see what their "straightforward formula" can produce it must send shivers down their spine
The procedural generation is based on grids as well.
People have noticed these "walls" of increased star density, and I've measured some of them.
Each cube is 160ly x 160ly x 160ly.
A sector is made of 8x8x8 (512) of these cubes, making a sector typically 1280ly x 1280ly x 1280ly.
Since those are binary integers, we can make some assumptions about storage requirements.
160 requires 1 byte of data (10100000).
Let's assume it's 1 byte for each star type, so with 16 types that is 16 bytes per cube.
512 of those is 512 x 16 bytes = 8192 bytes = 8KB of data for each sector to describe the star density in a given grid.
We don't know exactly how the naming algorithm works, but it doesn't take terabytes to describe the galaxy. With good optimisation, the galaxy could reasonably fit within megabytes rather than gigabytes or terabytes.
Remember that DB and IB managed to encode 8 galaxies of 256 stars along with names, locations and markets within a small part of the 32KB for the original Elite on a BBC Micro.
People have noticed these "walls" of increased star density, and I've measured some of them.
Each cube is 160ly x 160ly x 160ly.
A sector is made of 8x8x8 (512) of these cubes, making a sector typically 1280ly x 1280ly x 1280ly.
Since those are binary integers, we can make some assumptions about storage requirements.
160 requires 1 byte of data (10100000).
Let's assume it's 1 byte for each star type, so with 16 types that is 16 bytes per cube.
512 of those is 512 x 16 bytes = 8192 bytes = 8KB of data for each sector to describe the star density in a given grid.
We don't know exactly how the naming algorithm works, but it doesn't take terabytes to describe the galaxy. With good optimisation, the galaxy could reasonably fit within megabytes rather than gigabytes or terabytes.
Remember that DB and IB managed to encode 8 galaxies of 256 stars along with names, locations and markets within a small part of the 32KB for the original Elite on a BBC Micro.
For further insight into how the Stellar Forge might work, and it's interesting anyway, check out these articles about FFE/Frontier:
http://jongware.com/galaxy1.html
http://jongware.com/galaxy1.html
I think it's always worth remembering that
And they had a galaxy's worth on a single floppy disk- - - Updated - - -
You hurt my brain. I don't like you anymore
A short expiration cache would make sense though, even if it's just the system your currently in. If you do a lot of opening the system map it'd speed things up.
Last edited:
Agreed. Maybe a cache per play session would make sense, if possible.
Last edited:
Only problem I see here would be the ability to scrape that data for other uses, i.e. 3rd party trading, mapping, etc. I agree that a cache utilized to make map use quicker would be a good thing, would be nice. Just worried about the security of the data stored locally.