Before I continue, let me emphasize that everything I say in this blog post is subject to change. The process of game development at our studio goes through multiple stages (idea, concept, development, testing, feedback, more development…) and during the later stages it’s likely that some of the earlier stages get changed due to feedback and the experience that we gain later.
When we started working on Space Engineers we were not sure whether we wanted to add oxygen and planets. We didn’t know if people wanted us to go this direction and we also didn’t know how challenging it would be to develop. But now we see that it’s one of the most requested features and we are also confident that we can deliver it.
First we will focus on oxygen in space ships (grids). The algorithm will traverse through the volumetric grid, check if there’s a closed or open area, and if the oxygen can expand or stay contained. We may use solutions already developed for conveyors (it’s an obvious graph traversal / flood-fill algorithm).
The next stage will be planets, which will basically be asteroids ranging in sizes from tens to hundreds of kilometers across. We need to be careful with the expensive procedural generator here and the simplest optimization is to avoid generating terrain for volumes that are too far from the planetary surface (because they are almost always full or almost always empty and there’s no need to run the generator there).
Then we will need to add some sort of terraforming: oxygen generator, trees, grass, etc.
One of the open questions we haven’t decided yet is how to place station blocks on planets. If we keep our axis-aligned approach and the player starts building a station at some place on the planet and then keep adding blocks to it, soon the blocks will deviate from planet’s spherical surface. One idea is to allow rotation of the base block and so the player could align the station with the spherical planetary surface. The other idea is to add a new type of block grid: one based on spherical coordinates.
Also, we still don’t know if oxygen will just be an aesthetical function. We need to come up with the advantages that players without helmets or suits would have – something that can only be done if the character has no space suit. Otherwise nobody will take off their helmet and the whole point of air in spaceships will be lost. On the other hand, we can’t penalize players in suits because that’s how almost everyone plays the game now.
A natural landscape generator, trees, grass and sky are already finished – thanks to Medieval Engineers.
During the development of Medieval Engineers we created a brand new DirectX 11 renderer. Its main feature is PBR (physically based rendering) that allows us to define surface textures with very realistic appearances.
EDIT: Older DX9 renderer will stay in place (for those who don’t have DX11 hardware)
This new renderer will soon come to Space Engineers. Our artists have already started work on finishing our 3D models up to their final quality (you may have noticed that most of the models in Space Engineers are just temporary concepts, low-poly, no textures).
We are keeping the original art style and just making the models prettier. During this change we will also reduce unnecessary polygons and add multiple models for LOD optimizations (LOD means that objects in the distance are rendered in a lower quality). The positive thing is that we can keep working on this iteratively, block after block.
Havok is a physics engine developed by Intel and we use it in Space Engineers and Medieval Engineers.
Havok is able to utilize multiple CPU cores for its physics calculations. At present our games don’t support this and some work on our side is required to rectify this.
We will need to handle callbacks from Havok to our game, so that when they are triggered from different threads they will not cause any problems. For example, when Havok detects any contact between two physical bodies, it sends a message to our game so that it can play a sound or render a particle effect.
The other big piece of work will be extending thread safety in voxel polygonization and procedural generation. Right now this runs asynchronously (so the game doesn’t lag when large terrains are requested), which can be a problem in situations where Havok needs real geometry to calculate potential collisions between objects that suddenly approach each other.
Benefits of multi-core physics:
The bottom layer of our networking engine relies heavily on Steam networking and we can’t use this on the Xbox One port of Space Engineers.
The new networking library we chose allows us to better control message and channel priorities and reduce multiplayer lag and waiting periods.
This upgrade comes thanks to our decision to port Space Engineers to Xbox One and in future will lead to increased platform independency of our game engine.
Thank you for reading this!
Space Engineers on Facebook: https://www.facebook.com/SpaceEngineers
Space Engineers on Twitter: https://twitter.com/SpaceEngineersG
Medieval Engineers on Facebook: https://www.facebook.com/MedievalEngineers
Medieval Engineers on Twitter: https://twitter.com/MedievalEng