Wednesday, December 17, 2014

Space Engineers: Super-large worlds, Procedural asteroids and Exploration

Today we released three large features and we want to tell you more about how they work and how we implemented them.

We are really happy to be able to deliver this to you as a Christmas gift :-) Hopefully there won’t be any major problems.

Super-large worlds

Even before we implemented “super-large worlds”, the size of a world in Space Engineers was not limited, but for practical reasons it was recommended to stay within a 10km radius of the origin. The reason for this was that floating-point calculations (vector and matrix multiplications) were gathering numerical imprecisions and after 10km you would experience shaky movements and rotations.

Super-large worlds are increasing this safe radius up to 1,000,000,000 km, which equals to 6.6 AU (AU stands for astronomical unit; 1 AU = 150,000,000 kilometers and it’s the distance from the Sun to Earth). For your illustration, 6.6 AU is slightly more than the distance from the Sun to Jupiter.

If you decide to use your ship to travel from one side of the game world to the opposite, and you will fly on maximum speed (115 m/s), it will take you 552 years (checking calculation: 2 x 6.6 AU / 115 m/s).

For all practical purposes, “super-large worlds” could be considered “infinite worlds”, but the limit is still there and we don’t want to lie to you.

How did we increase the precision of numerical computations? 
  • Until now, Space Engineers and its physics engine (Havok) were using single-precision 32-bit floating point numbers. This data format has a certain precision, leading to visible imperfections on objects located further than 10km from the origin
  • We have modified all game objects to support double-precision 64-bit floating point numbers -- this was the easy part
  • The harder one was to change the integration between Space Engineers and Havok (so Havok can keep using 32-bit floating point numbers). We solved it by clustering the game world into independent clusters of objects (minimal cluster size is 20km). Depending on dynamic objects density, cluster size can increase its size without limits. Common cluster size should be 50-100km. A clustering algorithm guarantees that no dynamic object can be closer than 2km to the cluster border. Clustering is totally transparent to users, it runs in the background and you won’t see it.
  • In other words, the world in Space Engineers is split into independent clusters, wherein each object has its own coordinates relative to the cluster center. As a result Havok doesn’t need to use double-precision math (physics calculations are faster in single-precision mode).


Procedural asteroids

The “procedural asteroids” feature adds a practically infinite number of asteroids to the game world. On top of that, all these asteroids are fully destructible and don’t consume RAM/memory.

Until now, Space Engineers supported only asteroids that were fully loaded during the loading phase and then kept as voxels and triangles in memory. There were only a few basic asteroid shapes.

From now on, there are two types of asteroids:
  • old version - that can be used for handcrafted asteroids in future scenarios/missions
  • new version – asteroids that are procedurally generated at the moment they are required (player enters an area near the asteroid, random floating object gets in a collision with the asteroid, etc.). This type of asteroid doesn’t occupy memory (except some small data for noise seed, position, etc.). Even after it’s generated and inserted to the game world for physics simulation, the voxels are not kept in memory. Only if something alters the shape or material on the asteroid then these changes are made permanent. Unaltered asteroids are removed from the memory, but when a player returns they are re-inserted with the exact same shape. Players won’t see a difference, for them all asteroids appear persistent
This new asteroid type should also reduce saving and loading times (because these asteroids are represented by a noise function, instead of an array of voxels).

We also implemented a new voxel LOD system (LOD = level of detail). The old one had only two levels of detail and required voxel data in memory. The new one has many levels of detail and helps with optimizing polygon meshes and voxel data as well (e.g. when generating geometry for procedural asteroids at a distance, the game requests only coarse low-detail procedural generation which is faster than high-detail voxels). In other words, distant asteroids  use fewer polygons and fewer procedural generation calls.

There’s also an “asteroid field generator” – which is used to allocate and deallocate asteroids as you travel through space. We can configure it to generate dense or sparse asteroid fields, or areas with no generated asteroids (this will become useful once level designers start creating scenarios).

We had changed the background skybox to not contain those “fake” asteroids anymore. We still keep quite bright fog, but you are free to alter it through modding.


An exploration feature adds a practically infinite number of ships and stations to the game world, so there will always be something to discover, explore, acquire and conquer. You can imagine it this way: you are traveling in some direction and there is an asteroid, so you decide to check it and see if there’s something in its tunnels, in its proximity or on its surface. Or you just fly around in empty space and boom, a lost wreck shows up near you.

Almost all ships used in this first phase of the exploration release are player created content downloaded from Workshop. Everyone can find his name in game credits.

More info in my previous blog post:


“Super-large worlds, procedural asteroids and exploration are among the largest and most complex features we have implanted in Space Engineers / VRAGE engine.

This is just a first phase; we plan to keep improving after your feedback.


Thanks for reading this! For the latest news, follow Space Engineers on Facebook or on Twitter.

Wednesday, December 3, 2014

Space Engineers: Exploration & Call for “player created content”

One of the bigger features that we are going to release very soon is exploration (together with “super-large worlds” and “procedural asteroids” – more details in a future blog post).

We need your feedback and that’s why I am declassifying it prematurely :-)


The exploration feature will add a practically infinite number of ships and stations to the game world, so there will always be something new to discover, explore, acquire and conquer. You can imagine it like this: you are traveling in some direction and there is an asteroid, so you decide to check it and see if there’s something in its tunnels, in its proximity or on its surface. Or you just fly through empty space and boom, a lost wreck shows near you. Exploration is an upgrade to how cargo ships work.

Because the game world will now contain millions of ships (of course, you will be able to observe and visit only a fraction of them), exploration had to be implemented in a CPU/RAM friendly way, so these ships will be inserted and removed to/from the game world as you get closer/further. In other words, only a fraction of all these millions of ships will be subject to physics simulation at any given moment.

This way, ships are procedurally spawned and don’t consume RAM. Only altered ships are stored persistently (e.g. damaging a ship, entering a cockpit, changing values in the terminal). You can fly for a long period of time and your RAM usage shouldn't change. Of course, if you spot a ship but don’t touch it, then fly away (it gets removed from the RAM), then fly back, exactly the same ship will get added at that location. You won’t notice any difference. For you, all ships will appear persistent.

Ships won’t have AI for now, maybe later. Some will have disabled reactors; some will be active with turrets waiting for you. Only cargo ships will be moving.

Call for “player created content”

Where to get all these ships and stations? 
  1. We could develop a procedural ship/station generator – this would require a lot of additional work and the result will never be as good as what creative humans can create
  2. We could hire dozens of designers who could design these ships (while not working on new scenarios/missions)
  3. We could use what the SE community has already created – more than 50,000 creations on Steam Workshop. We would browse all ships/stations/blueprints and decide which ones get included into Space Engineers

We like the third option the most and I hope you will too :-)

The Steam Subscriber Agreement allows us to include all workshop creations into our game, but since this may be a big thing for some people, we decided to ask what our community thinks. Please use this survey and help us decide. LINK

Everyone whose creation will be used in Space Engineers will get his name into the game credits.

What workshop works are we going to put into Space Engineers?
  • Small and large ships, asteroid outposts, hidden stations, mining operations, semi-automated drones, etc. 
  • Only performance friendly works
  • Only ships that are not using mods
  • No third-party intellectual property (e.g. no Star Wars ships)

The exploration feature will be highly moddable and you will be able to add your own ships, even those using mods (e.g. new blocks). This will work in multi-player as well.

Thanks for helping us!

-- EDIT --

One week after the poll went live we have some results: