@madjack I don’t think it’s about storing a gazillion galaxies, it’s about being able to store coordinates for those celestial bodies that are actually materialized.
- JME and JME’s native Bullet interface deal only with floats. If you want a larger coordinate space, you can:
1a) Build Bullet with doubles instead of floats, increasing the coordinate ranges from 24 to 52 digits. You’re mostly on your own, because building Bullet requires dealing with cmake which is a bitch unless you already know it; also, it won’t take you beyond a light year even if you’re content with a precision of meters (and you want millimeters).
1b) Use longs (63 bits). The maximum distance you can express with that is a light year, or 1000 light years at meter precision. If you’re willing to give up on realism (something that you’ll do anyway), you can reduce many of the universe’s scales to it fits… but it’s a bit tight.
The problem with this is that you can’t leverage Bullet’s raycasting. Or any other library that does geometric calculations for you - not in Java anyway (in C++, some libraries can use any numeric type via templates, but Java doesn’t allow primitive types as generic parameters so Java libraries are typically built for a specific coordinate range). In other words, you’ll be doing several years of library development work before you can even begin to write your game.
1c) Use two longs. That’s finally enough (127 bits, as opposed to the whole universe in 99 bits at millimeter precision).
This has the same problem as longs, plus you need to implement two-longs arithmetic yourself (but we’re talking about massive library writing already), but at least this does eliminate the cramped coordinate space.
There’s another approach: Use a multi-tier approach.
In the universe, a galaxy is just a dot.
In a galaxy, the star clusters are just dots.
In a star cluster, the solar systems are just dots.
In a solar system, the planets are just dots.
On a planet, the towns are still just dots (at millimeter precision, no scene can be larger than a two-digit kilometer size with floats).
In a town, you finally have floats with a scene.
You will need all kinds of special-case code. E.g. you can’t sensibly calculate whether a light beam shot at a distance of half a light year will hit a planet-sized region of space, much less a space ship in it. (On the other hand, no player will want to wait half a year after shooting - they’ll warp there and fire a torpedo. Still, the problem persists e.g. for ballistic missiles shot from one town to the next.)
A “chunk” would then approximately the 10 km around the player.
You’d also want to load condensed data.
I.e. at a distance of more than 10 km, just a simplified terrain plus points of interest.
At a planetary scale, a grossly simplified terrain (or none at all, depending on whether the player needs to see maps or not), plus points of interest (e.g. if he controls an ICBM site, the points of interest that he might target, but just their positions, no detail data).
At a solar system scale, only the positions, size, and overall color of the planets and the start.
Etc. etc. - level of detail, essentially.
Given the number of LOD levels and that you’ll need to code every level twice, once for the case with details and once for the case without details, that’s quite some work.
You can reduce that work by making it impossible for people to interact at multiple levels at the same time. I.e. a laser (personal weapon) that goes outside the 10km range always misses, bullets vanish after travelling 10 km, ICBMs will never be allowed to leave the planetary scale. It is a restriction on game design - you won’t be able to have sharpshooters between the asteroids because they’re more than 10 km apart, typically. (But having such a restriction is still less worse than having no game at all.)
- You don’t want to even store the individual stars of a galaxy:
If you store position, color, and brightness as floats, you have five floats = 20 bytes per star.
At 300 trillion start in the Milky Way, that’s 6 gigabytes of raw data that need to be processed, and just to generate a merry skybox - that’s a bit over the top.
(Usually, the overhead associated with raw data is somewhere between double and quadruple that. I.e. if it’s in a database, indexes will take at least another 6 GB, if it’s just in RAM, you still need tree nodes and memory management overhead.)
You might generate starfield densities in voxels. As long as you subdivide each voxel until it’s smaller than a screen pixel, the difference won’t be visible.
That’s going to reduce the data volume from gigabytes to mere megabytes - still too much for modern hardware to easily deal with it, so you’ll spend a lot of time optimizing that via precalculations, trying larger voxels while keeping the visual effects to a “reasonable minimum” (for whatever definition of “reasonable”), and generally spend a lot of time pulling your hair.
Is essentially the same as (2), just at a different level of detail.
You’ll want to keep the game state and the scene display in different coordinate spaces anyway. Mostly for precision reasons: if you fly a fleet across the galaxy, a distance of 500 m between ships will be rounded down to 0 at a light year’s distance - ka-boom!
I suspect you’re thinking a client-server game, in which case the clients can use scene coordinates and the server can use game coordinates. The bottleneck is the network, you’ll always have enough CPU to convert coordinates.
Whenever a ship leaves a chunk, simply load enough neighbouring chunks. Keep enough data around so that no effect that the ship can experience or cause can leave the set of loaded chunks.
The art is to keep the game design within the limits of what can be kept in RAM - shooting at a light year’s distance is going to require a lot of chunks loaded.
Whatever software you find, it will use a different data model than what’s useful for your game.
Of course, you could simplify your life and simply generate a starfield background (I think there is software for that). Players won’t be able to reach the stars seen in it, but then who needs a playing field of more than a few hundred stars.
That might indeed be the better approach. Eve Online has just a few hundred stars, simulated in a cluster of a LOT of servers - I don’t know how many, but it was enough that they got a special offer from Microsoft so they’d migrate to it (I think they did take the offer, only to revert to Linux a few years later).