August 16
2011
Limitless and fully dynamic environments in Miner Wars!
Recently I started looking more into how are we’re going to generate the environments for Miner Wars. The game is going to be played within the whole Solar System, an area which has about 1000 million kilometers in a radius, real planets and moons, real travel speeds, no boundaries and a fully dynamic environment.
Before I continue – when I say “real planets and moons” – I actually mean pieces of planets and moons scattered all around after the disaster of 2071. You will get more details on this later in our story.
The player will be able to fly to Earth, visit its ruins, land at any place, destroy whatever they please, then fly to the Moon, Venus, Mercury, or even burn themselves in the Sun (if he wants to). I believe this is going to be the first game where you will have this kind of freedom – free-roaming the Solar System with the ability to land anywhere and destroy anything! 🙂
We can’t manually design all these objects, there’re going to be millions of them. We have to generate them procedurally.
Positioning objects – objects will be placed on a roughly real positions (e.g. the distance between Sun and the Earth will be 149 million kilometers). Other not important objects will be placed on semi-random positions – something like fractals.
Object types – voxel asteroids, space stations in open space, space station inside asteroids, static and indestructible asteroids, dusty areas, debris fields, space cities, etc.
Voxel asteroids – current max size is 8x8x8 kilometers, although I believe we will be able to increase it in one of the next development iterations. There’s one idea I got just recently – if interior parts of an asteroid will be non-destructible, than we can save a lot of memory by compressing those places and we can support much larger asteroids than if they were totally destructible. Also procedural generation of asteroids is simple, we have about 100 basic shapes and the only thing we need to do is to randomly merge these shapes. If you do a couple of additive and subtractive merges, you get an almost unlimited variety of asteroids.
Space station in open space – these will be handcrafted–as we don’t believe we are able to procedurally generate stations that would be fun to visit–they need to be done by a human designer.
Space stations inside asteroids – same as space stations, except we need to dig tunnels into an asteroid before we place a space station inside.
Dust clouds, debris field – these are simple to generate procedurally.
The game doesn’t render all these millions of objects in each frame; that would be impossible. Instead we split the space into a regular grid of sectors, where each one is 200 x 200 x 200 kilometers in size. The game holds objects only within the current sector. When players travel from sector to sector, the game has to reload all objects from a new sector. This isn’t a burden at all because it takes about 16 minutes to travel from one side of a sector to the other.
Memory requirements – the game is designed to fit within 1 Gb of RAM therefore we need to save memory as much as possible. For voxels it’s achieved by using many levels of real-time compression. For space stations it’s similar, each one is made from prefab modules and the game needs to hold just the position, orientation and type of a prefab module. If we place 100 prefab modules of same type into a sector, it doesn’t increase memory requirements by factor of 100, only by a fraction of it.
What about objects in the background – since the game only really renders objects within the current sector and remaining objects needs to be put on screen too, we pre-render them into a cube texture, which is then rendered on-screen. This texture doesn’t change while you are in a sector, only from sector to sector.
And here comes a new challenge: Because a year ago our plan was to have just few of these standard backgrounds with the Sun, Earth, other planets, some galaxies and stars… but we have changed the story a little and now it’s possible to travel to the Earth, Moon, near the Sun, etc., so we now need an arbitrary number of backgrounds. You need to see Earth’s ruins while you’re traveling to it–even if you’re sectors away. I don’t know yet which way are we going to choose: whether we possibly pre-render them in-game during the loading phase, or maybe during the offline game build process; alternatively we may just generate them in 3DSMAX using a script. It’s still open. I just know that the backgrounds need to look great!

EDIT: I forgot to mention that all objects are stored only on our servers and client downloads only what’s in his close proximity (in his current sector).  Therefore no worries about having gigabytes of data on your local hard drive.

  1. And using a spherical system to render the objects? like 2 spheres, one to render the objects and other to load the objects?

    Because there are sectors with many objects and other with few or even none.

    This spheres can increase or decrease they radius, fitting to memory and complexity of objects.

    When the game will be launched 8GB of memory its normal.

    Sounds good about the recreation of solar system, but concern me about space in disk, will be many GB? I have a SSD, so its important for me. Unless I use a SD card or USB disk to have the game, and you can think about have cache in SSD.

  2. How about using a sufficiently fine grained octree and have a moving ~ 200^3 km sector around a player? That would give you seamless travel and yet help to reduce the amount of objects to be managed.

PUBLISH