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:


Tuesday, November 4, 2014

Space Engineers – development progress and retail release

A few words and clarifications about the retail release

This blog post begins with the same words I used in my Space Engineers for Xbox One post: let me assure you that the retail release of Space Engineers in US/EU/AU stores has no effect on our development plan, priorities or the game you are playing and following right now.

To put it simply: the retail release is just another distribution channel, just like Steam, GMG, Humble Store, etc. Our mission is to bring Space Engineers to as many people as possible, which is beneficial to everyone: bigger community equals more modders, content, ideas and friends. We took this decision so that we could enable new players to buy the game. There is still a large number of people, especially in Europe, who are not purchasing products online for various reasons (don’t want to use credit cards, etc). We knew from the beginning that this decision contains a big risk, since the actual profit that we will get from selling in retails is much lower than the one from online distribution, but we wanted to give the chance to these players to play our game. Also, if we speak about money, more sales mean larger budgets, more developers and more features. This is a total win-win situation.

We treat this retail release as “experimental” – our game is probably one of the first early access games launched in retail stores. Customers are not used to this and the entire thing can backfire. But someone has to try this approach. On the other side, I believe that the distributors made sure that the information about early access is communicated to customers properly (through a label on the box or an educated retail clerk). We all know that hiding this fact or lying about it wouldn’t be an option – even if someone tries that in the future, the consequences would be brutal.

Regarding the extra content that we added, as you know video game retailers don’t have the same advantages and flexibility as digital stores, so we wanted to support them as much as we could by differentiating the product compared to the online version. The digital extra content (soundtrack, digital art) will also be available for everyone later in the future (there are some technical reasons why we don't want to include them in the digital version right now). Retail customers don’t get any in-game content that’s not available in the Steam version as well. It’s still exactly the same game. They get some extra physical items and our older games, but the higher package price justifies this.

The talks with retail publishers started almost a year ago (when they noticed Space Engineers in the top seller lists). It took some time to finish the deal and prepare the packages. Retail release has nothing to do with the current “temporary feature freeze” stage.

This is an “experimental” early access retail release, that’s why we treat it as a limited edition –we don’t want to end up with a crazy number of boxes in stores in case this thing doesn't work.

More info about the retail release:

Development progress and future plans 

I also want to give you some more info about the development progress and our future plans, since the feature-freeze period has just started and some players might be worrying about it. As I have already informed you in my previous blog-post, Space Engineers has entered into a temporary bug fixing and stabilization period. This doesn't mean that all bugs will be fixed within the first weeks, neither that there won’t be any bugs in the future. Our team is doing its best to have everything done as soon as possible so we can start focusing again on implementing new features. 

Moreover, the retail release doesn't mean that the development of Space Engineers has stopped or that it has reached beta. The game is far from finished; there are still major features in development: in-game programming, projector and 3D printing, scenarios, properly textured models, polishing and optimizations… we will give you more info about other planned features later in the future.

Thanks for reading this and don’t forget: we are here to make the best game possible - for YOU!

Wednesday, October 15, 2014

Level design & Stabilization period

A few months back we realized that Space Engineers had already almost all of the core features we originally planned to implement and that now would be a good time to start adding game scenarios -- something that will give players goals to achieve; something that will make Space Engineers more of a game and not just a creative sandbox.

We think that the best way to accomplish this is to create a set of interactive scenarios (levels, missions, etc.). We knew we couldn't do this alongside our other priorities, so we decided to start looking for people whose only job would be designing, prototyping and testing these scenarios.
We decided to hire level designers.

For these reasons, we launched a creation contest (where you can win NVIDIA graphic cards) and a job ad for level designers. Anyone can apply but relocation to Prague is required. I hope we will find some great new colleagues who will help us add new scenarios to Space Engineers.

The creation contest has another benefit for Space Engineers as well - if enough people apply, we will get a lot of material and ideas to choose from when implementing official scenarios in Space Engineers.

The second thing I wanted to talk about is that we started to reduce the amount of new features and now we are more focused on bug fixing and stabilization of things that are already in the game.

This doesn't mean we have reached BETA or anything like that. It only means that there's  plenty of development time in front of us and it’s better for the community that the game be in a more stable state while we keep developing it.

The first stage of this stabilization period starts now and it means that we will split our focus 50/50 between new features and bug fixing. After a few weeks, once all work-in-progress features are implemented, we will focus 100% on bug fixing. This will be a feature freeze phase when we won’t add any new feature. This will allow us to focus only on bug fixing, testing and scooping forums for bug reports. We don’t plan to include any special performance optimizations in this stage (because that could lead to new bugs), except performance issues that happen due to bugs.

Thank you for reading this.

Monday, September 15, 2014

Programming is coming to Space Engineers

Programming is making its way into Space Engineers. The first version will come this Thursday (September 18th, 2014).

You will have four different ways to "program in Space Engineers":
  • Modding API – This will be the first one. It’s not for everyone, because it will require modding the game. Some programming experience will be required. It will allow you to alter the game by writing C# scripts that have access to in-game objects (at first, only some type of objects will be accessible, but we will keep opening up the interface). These scripts will be shared through Steam Workshop and the game will insure they will run in a safe sandboxed environment (scripts won’t be able to access your local files, send packets over your network, launch applications, etc.). Example scenarios:
    • Dedicated server log: player will know what happened on his dedicated server while he was offline (ships destroyed, players logged in/out, ore harvested, etc.)
    • Robots! (with AI, sensors, logic, behavior)
    • Mission script, large ship fights, search and rescue, etc.
    • New custom weapons
    • Scripted ship spawning
    • Modifying existing blocks (e.g. refinery priority)
    • And more
  • Programmable blocks and HUD – I wrote about this in my previous blog post. It will come in a few weeks after the modding API. The main difference between programmable blocks/HUD and the modding API is that the former happens inside the game world. You will have access only to functions that would be available to an astronaut in-game. We will try to make it user-friendly and easy to use. You will be able to program robots and machinery, but you won’t be able to use this to script a mission or alter the game.
  • Modding API (total access) – this will be an extension of the modding API and all safety restrictions will be lifted (no sandboxed environment). You will be able to write DLL files that can access in-game objects and essentially do whatever you want. These scripts/DLLs won’t be shared on Steam Workshop (it would be too risky).
  • Interactive blocks – this idea came to us after we’ve noticed how you are using sensors and pistons. Some of you were able to create drones that track objects, logic gates, timed lights and other interactive works. The best part is that there was no text-based programming involved. We want to widen your options and we plan to add some new interactive blocks (“timer” block was the first one).

I believe that adding programming to Space Engineers will trigger a flood of creations, the possibilities are infinite. I am already looking forward to see what you will create (I already have an addiction to watching your Youtube videos, Steam Workshop worlds and mods, Reddit…).

Wednesday, August 13, 2014

Space Engineers for Xbox One

First of all, let me assure you that the development of Space Engineers for Xbox One won't affect the PC version.

In the past months, our team has silently grown. We have people who are dedicated to weekly updates, people who work on long-term features, people who work on our super-secret AI project and people who will work on Xbox One port.

On the other side, I must admit that I personally can’t be 100% focused on Space Engineers as I was when we started it. Now, my attention spans over many more areas.  But I believe we have the right people in the team for things to work. If nothing else; the last 6 months are proof that this already works.

We are not abandoning Steam or PC – this is where we started and we will continue here. The PC ecosystem has many advantages, from its openness, community of workshop creators (almost 40,000 creations!), to a starting modding community. Who would want to abandon this?

Porting to Xbox One was a logical choice, especially when you consider how close is the technology to the actual PC/Windows version.

12 months exclusivity relates to consoles only. PC version and possible other ports (eg. Mac, Linux, mobile, tablets) are unaffected by this.

Will the PC version get more console friendly? No. However at this moment it’s hard to predict what UI changes will be required when porting from PC to Xbox, but I doubt we will need to change the PC version because of console version. Why not customize only what’s needed by a target platform? If we won't find a way how to do modding on Xbox One, why would we remove this feature from the PC version? And the same applies to programmable modules and tons of other things.

If you have additional questions on how the Xbox One port will differ from PC version, what will be added, what will be missing, please wait until we get much closer to the release. At this moment, it’s too early to say anything.

Trust me, everything will be good.

Wednesday, June 4, 2014

Programming in Space Engineers (programmable blocks and HUD)


Some time ago I was playing with the idea of adding “programming” into Space Engineers. Today, I would like to share with you my design document - still in its early version.

Please keep in mind that everything that is mentioned below is in a very preliminary stage and is subject to change.

This is a first “design draft” that needs to be specified in higher detail before we start the implementation (e.g. we need more specific GUI and HUD drawings, we need to design how the copy-pasting of programs will work, etc.).

This feature is not about modding. Programming and HUD customization will be a natural part of the game environment.

Programs could be edited, copied and pasted inside the game environment and also between players in multi-player – for example, one player writes a simple HUD program and he copy-pastes it to chat, so that others can integrate it to their HUD. A Similar idea will apply to all types of programs, but we should come up with a more user-friendly version, accessible even for the players who don’t have programming experience.

Lastly, this will be a great way for people who want to learn programming the entertaining and easy way!


Players will be able to write small programs that will be executed in computer blocks or computer components. This feature will be an integral part of the game’s environment, it’s not modding.

Computer Blocks versus Computer Components: I am still not sure if we should make a new computer block which will be the only entity where programs can run or allow programs to run in any computer component (if we allow the later, then players would write programs for doors, reactors, etc. and it could get messy).

Programming language: I would prefer some C# interpreter - instead of compiled code (DLL), mainly for security reasons. The interpreter should be object-oriented and support all standard C# features, perhaps .NET, LINQ, garbage collector, etc.

Editor: The program code can be edited from the Control Panel (similar to how we configure block attributes). Don’t forget that some blocks can have multiple computer components and player should be able to distinguish between them and program them independently.

Programs can be set ON / OFF.

Damage: when a computer component gets damaged (below operational integrity), its program is completely wiped out and lost and the program will not be executed anymore.

Execution:  these small programs can be compared to pixel/vertex shaders. They have a “main” function which is executed in every update (60x per second), on server or by object-owner. They can have variables/members that keep their value from update to update – so they can hold an internal state. These variables can be accessed from other computer components (they are public by default). Each computer component is an instanced object, not a class.

Access: programs can access attributes and methods of other blocks and components, but only within one grid (station or ship). Wireless connection is not available yet. Computers within a grid can be searched by a block name (e.g. GetByName(“rotor_on_the_left”))

Code editor:
  • Syntax highlighting
  • Syntax check
  • Suggestion wizard (e.g. after writing a dot it will offer all available members)
  • Text copy-paste-delete
  • Other features which are standard in code editors
  • Programs can be copied to/from blueprints (program is a special type of blueprint)

Exception/error handing: (examples: NaN, divide by zero, etc). In case of error, the interpreter will stop execution of the program in the current update, but it will not rollback to pre-update state. It will run the program again in a following update but it may end up with an error again. Error info is written to “program debug window” (see scheme above), but there are no runtime crashes and assert windows. (I remember that Visual Basic used to work this way).

CPU time and memory: we need to avoid situations where players create infinite loops, programs with extensive operations, huge memory allocations, etc. Is this possible? We don’t want network clients to run extremely complex programs on servers.

Replication: There can be a function for copying/replicating code to other computer components or block from within a program (code injection). Players could write viruses :-)

Classes & inheritance: my actual opinion is that these small programs are classes but not of the same type. I will explain it by using this example: imagine having two doors in the game (door1 and door2). You write one program for door1 and another program for door2. Even though you are still working with doors, these two programs you just wrote are two different classes – they may have different attributes, state, methods, etc.

Example code:
public float some_state_variable = 10;
private float some_other_private_variable = 20;

void main(void) // main function gets called on every update
var rotor1 = GetByName(“rotor1”);

var light1 = GetByName(“light1”);
light.SetColor(255, 255, 0);
Sample list of objects (computer components, attributes and methods):
  • base class for all blocks
    • IsPowered() // is electricity powering it now?
    • IsEnabled()
    • some access to block’s Inventory if that makes sense
  • Door
    • Open()
    • Close()
  • Light
    • Color (we probably have diffuse, specular, etc)
    • Radius, Falloff and other range parameters
    • Type
  • Thruster
    • AddForce() // or something like that

Examples in other games:

Possible visual/text programming language:

Proximity sensor

Proximity sensor is a new type of block that can be placed on top of other blocks (similar to how we put interior lights) that scans the cone area on its front side. Large and small block sensors will look the same and will have the same proportions.

Scanning: sensor keeps scanning a cone area in front of it with every update (60x per second) and whenever it detects an object (moving or stationary – this depends on the velocity threshold) - an event function on sensor will be triggered –> on_detect() –> this function is executed inside the movement detector computer component.

Detected objects: the sensor detects all types of objects - blocks from its own grid, asteroids, ore, small items, even animated doors or player or rotor or active thrusters... perhaps even particle effects.

  • Range - from 0 to 300 meters (Note: consider performance implications and decrease if necessary)
  • Angle - max 180 degrees
  • Laser projection of scanned area (player can observe the scanned area; transparent red polygons, similar to what we had in Miner Wars’s scanners)
  • Velocity threshold (if this is easy to implement) – if set to zero, even static objects are detected. If more than zero that only objects with higher velocity are detected.
  • Visual signaling – true/false – when true and object is detected, sensor will blink
  • Energy consumption – a little higher than spot lights; depends on angle and range

3D model: inspired by semi-spherical ceiling light; example:

HUD programs

This idea is very similar to “block programming” – however, instead of writing simple programs that run in blocks, HUD programming is about writing simple programs that run in the HUD and their output can be displayed on player’s HUD screen.

HUD programs can access (read and write) only the information that’s accessible to the player:
  • astronaut info (health, energy, velocity, etc.) – available at every moment
  • ship and station info – only when sitting in a cockpit or connected to terminal/control panel (although at this moment the player won’t see the HUD because the GUI screen will be on top of it)
  • remote – once we add wireless communications, players would be able to “communicate” with ships and stations even when not sitting in a cockpit

Current HUD: I am talking about displaying character and ship parameters such as speed, energy, etc – we need to redo them as a customizable program that players can modify. This should be easy and it will also show how to use this feature.

GUI versus HUD: In my opinion the difference between the GUI and the HUD is that the GUI is also for things that are not part of the game world (e.g. Save, Exit to Main Menu, Options, etc.). The HUD should be only for things that are an integral part of the game world.

Storage: HUD programs are per-world and per-player (so they are stored in the world file and are specific to player – even in multi-player). Example: if player wants to use his cool new HUD in some other world that runs on a dedicated server and where this player is not even an admin, he can copy-paste it there through the game’s GUI/HUD and use it.

CPU and Memory: HUD programs run in every update (60x per second) and there are no limits on how complex HUD programs can be written – if the player makes an error, only his computer will be affected by low performance

Errors and debugging: errors are ignored (no crashes) and error messages are written to the HUD screen so that player can instantly see if there’s a problem.

Example code:
public float some_state_variable = 10;
private MyGuiSlider slider1;
private MyGuiLabel label1;

// called only at start of HUD or whenever HUD program gets changed
void init()
slider1 = new MyGuiSlider(...position...default color...etc);
label1 = new MyGuiLabel(...position...default color...etc);

// main function gets called on every update
void main(void)
GetByName(“player character”).Color = slider1.Value * 100;
label1.Text = MyUtils.GetFormattedFloat(slider1.value, 2);

Editing: HUD programs are accessible from the terminal screen (control panel) under a new tab of HUD. The player can see a list of all active HUD programs there, modify the position, shortcuts, etc.

Focus: HUD screens don’t have keyboard/mouse focus unless player presses the shortcut key, after which everything under the HUD screen gets darker and player can access the GUI controls on the HUD screen (e.g. move slider). Player will leave this mode after pressing shortcut again (or ESC).

Controls: all standard GUI controls should be available for HUD programming: textboxes, sliders, labels, buttons, comboboxes, etc.


Please keep posting your feedback and suggestions to the comments section below. I can’t reply to every comment, but I can assure you that I try to read as much as possible and your comments will influence how Space Engineers develops.
Marek Rosa

Thursday, May 29, 2014

Space Engineers – Dedicated Servers and Multi-player

Today we released an early version of dedicated servers for Space Engineers and we also added multiple fixes and performance improvements for multi-player.

We kept testing dedicated servers during the last 7 days, but we still consider them to be in an early stage: only large-scale testing can prove them to be working correctly and also they will need some additional functionality (better user rights, remote control, integration with game hosting companies, etc.).

The dedicated server is a new application in your Space Engineer’s folder; but it’s built on the same code base as the client version of Space Engineers. The difference between them is that the dedicated server has disabled graphics – no rendering and no texture loading. You can launch the server either in the command line mode
or with our config application
 or as a windows service
If you plan to host your dedicated server at a data center, we recommend running it as a service (you can control auto-restarts, etc.)

Dedicated servers are available for everyone who owns Space Engineers. You don’t need to purchase a second copy to host a dedicated server. Dedicated servers are currently allowed only for non-commercial use, so companies that host game servers or everyone who wants to host his server at such company, please wait a few days. We will be working on making this possible.

Multiple instances of a dedicated server may run on a single machine when each instance is configured to use different port. The dedicated server comes with a configuration tool which can be used to define what world will run on the server and what port will be used by the server. The server may run on the same machine as the game.

Dedicated servers manual:

Together with the dedicated servers, we also released a major multi-player overhaul. Ondrej has spent the last two months with networking optimizations that are specific to our fully destructible and dynamic environment. If you consider that in Space Engineers you have a vast number of objects that can be instantly created, moved, accelerated, deleted and changed their shape– all this generating tons of data packets where events have to be predicted and/or interpolated, yet still maintaining proper object ownership and server authority - you will understand that he didn't have an easy task.

We also hope that multi-player lags are history, except in situations when there are too many dynamic objects that need to be synchronized between server and clients, generating large data packets that may not get easily through servers with slow up-link.

Hopefully, the following weeks will show that we were successful. We need your feedback too: if you encounter weird multi-player situations (crazy spinning objects, disappearing objects, strange movements, wrong synchronization between clients and server, etc.) – please send us an email:

We want to give you a 100% operational and bulletproof multi-player - once and for all.

Please let me know your opinions in the comments below. Thank you.

Friday, April 4, 2014

First-year anniversary of Space Engineers Development


This month we have reached the first-year anniversary of the development of Space Engineers. You can think of it this way: a year ago, there was no Space Engineers. Not even a prototype. We only had the vision of how the game should look in 12 months.

Today, we have this :-)
Numbers represent “simultaneous players”

The development started in 4/2013; the game was announced in 9/2013 and released in 10/2013.


From the beginning we knew that we want to release the game as soon as possible:
  • Validation of the idea – it’s better to develop additional features based on real feedback from the players than just on our own assumptions
  • Morale boost – seeing how people play your game is priceless

We knew that in 7 months we couldn’t implement all of the features we wanted. So we looked at the project plan, picked what we assumed were the core features (physics, creative mode building, character animations, etc.) and focused entirely on them. All other non-essential features or features that could be implemented later were pushed to the “post-release” period.

Here are some good pieces of advice for managing an experimental game development project:
  • Time-estimates are irrelevant – even if they are correct, you may later decide to spend more time on a feature. Or a completely new idea/direction worth pursuing may arise
  • Every day you know more about your game than you knew yesterday, a week ago, a month ago – therefore, today’s decisions are more valuable
  • You can always add or remove features, but never alter the milestone/deadline! Obviously, don’t compromise on quality
  • Start by implementing the most important features first - every time you are going to work on something ask yourself:
    • Is this really the most important thing I should be doing at this moment?
    • Isn’t there something more important?
    • Is this the most effective utilization of my time?
    • Isn’t there something which takes less time to develop but has higher benefit for players? (ROI for players)
    • If I work on this thing now, won’t I later regret that I didn’t do some other thing instead?
  • You won’t be able to implement 100% of what you want. Start with the most important tasks and you may never get to do the less important stuff. If you change the order, you will end up having the unimportant stuff but not the important stuff.
  • Deciding on which features won’t be implemented at all is equally important as deciding on what features will be implemented. If I don’t do one thing, I just gained some free time that I can spend on something else.

We were not expecting that we will miss deadlines or that something will halt the development completely, but for the worst-case scenario we assumed: if we had to stop the development at any moment (for whatever reason), we wanted to have a game that’s as finished as possible and preferably in a playable state.

Early on we decided to do public relations with 100% focus on community and not rely on the press (which is what many indie developers do). These were our principles:
  • Do things that are good for players
  • Do things that make players happy: today, tomorrow and in the long-term
  • Don’t push the game via press or advertising; If the game doesn’t get picked-up by the community naturally (word of mouth), then it’s probably not a good game and there’s no reason to force it

Interesting facts

Our working name was “Sandbox”. It was not until the last month that we finally went for “Space Engineers”.

In the initial prototyping phase, we didn’t plan the deformable and breaking physics. We implemented it almost as a byproduct of the volumetric design. The story here is that I asked Ondrej if he can do it, he said yes, and in a few days he showed the first working prototype - with deformable skeleton, meshes, splitting ships in half, etc.

We planned to have post-release updates every 2-4 weeks. But the day after the release we made our first little update and it felt so good that we immediately wanted to make another one. The decision for regular Thursday updates was a no-brainer. Yeah, we are update junkies :-)

Time-lapse through the first 7 months

April 2013
Grid system in its infancy – everything is static
Still using Miner Wars 2081 code base

Prototyping block-based volumetric concepts in 3ds Max.
Trying to maintain believable scale for astronaut, small ship and large ship

May 2013
First prototype of creative mode building mechanics (LMB to add, RMB to delete)

Large and small blocks
Ships can fly - however they don’t use thrusters to fly and mass
is not calculated dynamically

Our first “astronaut” – we are adding movement animations and jetpack flight

June 2013
Decided on Havok physics
Destruction and deformation mechanics are implemented
Basic block-types are in game

Prototyping “manual mode” building (now it’s called “survival mode”)

July 2013
Preparing the game for the announcement video

Improving everything we need to look good in the announcement video

Concept art of the engineers – blue parts represent fabric parts, grey represents leather,
yellow is reflexive/emissive material

We didn’t like this concept for the helmet – it doesn’t have a NASA-look and
is very militaristic
This concept is better, we just need to lower the headlights – otherwise the
silhouette looks like Mickey Mouse
This is it! Space Engineer in its glory!
High poly model

Development of Space Engineers: From an idea to Early Access in 7 months

The following video was recorded in 11/2013 at a Game Developer Session held in Prague. I had a presentation about “how we got from an idea to Early Access in 7 months”.

English subtitles included (you have to enable it in Youtube).

Presentation slides are available for download:


Please keep posting your feedback and suggestions to the comments section below. I can’t reply to every comment, but I can assure you that I try to read as much as possible and your comments will influence how Space Engineers develops.

Marek Rosa

Like us on Facebook or follow us on
Twitter and you will be notified on all updates.

Warning: Space Engineers is still in development. Everything in the game is subject to change.

Monday, March 31, 2014

Results of the "How do you play Space Engineers" survey

Thank you all for participating in the survey. Now we have some useful data that will help improve Space Engineers and take it in the right direction:

6424 of you have responded to the survey.

Only 13% of you prefer the creative mode over survival. This is interesting, considering the fact that the survival mode was made available only a few weeks ago.

Only 7% of you play with a competitive style, which can be explained by the current lack of differentiation between friends and enemies. Or it can be explained by the fact that Space Engineers is an engineering game and not a FPS.

On the other side 41% of you use weapons which contradicts the 7% competitive play. So I have a question: what do you use weapons for?

The most flattering feedback was to "How did you found out about Space Engineers?". Only 7% of you found Space Engineers through the usual sources (magazines and blogs). The rest of you found it through the community (Steam, friends, Youtube). This is awesome and a proof that our initial plan of "focusing on community only" works.

Full results are available below:


Please keep posting your feedback and suggestions to our Facebook page or our forum at

We can’t reply to every comment, but I can assure you that we try to read as much as possible and your comments will influence how Space Engineers develops.

Marek Rosa

Like us on Facebook or follow us on
Twitter and you will be notified on all updates.

Warning: Space Engineers is still in development. Everything in the game is subject to change.

Thursday, March 13, 2014

Space Engineers - “Survival mode” update


Today’s “survival mode” update is the biggest since Space Engineers launched on Early Access. Even the multi-player update didn’t bring so many changes.

We chose to name it “survival mode” and not “realistic mode” as we originally planned. Everyone seems to have a good understanding of “survival games” these days - it’s a common term for describing a gameplay mode where players have to harvest and process resources, craft and build things and watch their stats to survive.

Survival mode comes in three variants:
  • Survival (default) – realistic inventory capacity and processing  times
  • Survival x3 – inventory capacity and assembler efficiency and speed increased by a factor of 3
  • Survival x10 – same as “x3” but only multiplied by 10

Differences between creative mode and survival mode:
  • In survival mode, you can get hurt and die, e.g. falling from a height, high-velocity collisions, depleted energy in your space suit, explosions, etc.
  • If you die, you respawn in your nearest medical room
  • If you don’t have a medical room, then you respawn in a rescue ship at a distant location in the sector and you will respawn as a new player (this will get important in later stages of the development, once ownership of things becomes useful)
  • Energy in your space suit depletes as you use it - life support, jetpack, welding, grinding, etc.
  • Medical rooms aren’t just for respawning – you can use them to recharge suit energy and fix your health
  • Nuclear reactors need uranium ingots to produce energy. You can save energy (and thus uranium) by turning off energy consumers such as thrusters, lights, refinery, assembler, gravity generator, etc.
  • Building is now a complex activity, here’s how the full cycle works:
    • Gather ore by drilling and harvesting asteroids (iron ore is the most used material in block components)
    • Use refinery to refine ore to ingots (e.g. iron ore to iron ingot)
    • Transfer ingots to assembler and create block components (e.g. steel plate)
    • Put components to your backpack (inventory), move to a construction site and place the first stage of a block. Then use welder to continue all development stages - you need block components to finish it
    • Deconstruct blocks by using grinder - removed components are transferred to your backpack (inventory)
    • Repair blocks by removing damaged components and installing undamaged components
    • If you want to see the inner structure of a block -> get welder or grinder in your hand and aim at that block from a close distance. You will notice an overlay screen that shows all you can know about a block: integrity, components installed, etc.
  • Survival mode has copy-paste disabled
  • If you get into an unsolvable situation (e.g. you are stuck inside a ship with no tools to get you out of there) and you don’t want to wait for a slow death –> just press Backspace and commit a suicide

Block integrity – this parameter defines the level of completeness or damage of a block

Blocks are built from layers of components - each component is installed on top of the previous component.

When building a block (using welder) – you are actually adding components to block and welding them together - which increases block’s integrity as well.

When deconstructing a block (using grinder) – you are actually separating components, layer by layer, and putting them to your backpack, therefore the integrity decreases (it can get decreased by damage as well, e.g. explosions, collisions, etc.) Please note that non-armor blocks don’t display damage yet – if they get zero integrity they just disappear.

When block integrity drops under a certain level (each type of block has a different threshold), the block will stop functioning. Blocks that have a computer component usually stop working once integrity gets below the computer layer. Another example is reactor - it wouldn’t do its reactor-job if it had only one steel plate installed and 5% integrity.

Damaged components are turned to scrap metal, which can be recycled in the refinery to iron ingots. Last-moment change: please note that this will be added in a later update, we didn’t make it for the first survival update.

Last-moment change: block repairs may not be very intuitive in this first version of survival – if you don’t see a block damaged or deformed and only its internal parameter “Integrity” is bellow 100%, you may easily miss it. We are working on this.

There’s a limit on how many freely floating objects are allowed in the world (ingots, components, ore, etc.). When the limit is reached, the game will erase the “oldest object” - like a FIFO buffer. I understand that some of you will not like this but every object requires physics calculations and if we allow infinite numbers, your computers wouldn’t be able to simulate the game. On the bright side, there’s a new parameter in the “Custom World” screen where you can set this limit up to 1024. This limit doesn’t apply to asteroids and grids (ships and stations). Also, items in your inventory and cargo containers won’t get removed as well.

Thrusters now inflict damage on objects (your days of thrusters installed one behind another are over!). Though, the effective distance of damage is limited, so you can still put thrusters inside interiors – if you leave some empty space in the discharge area. Last-moment change: please note that this will be added in a later update, we didn’t make it for the first survival update.

Hand drill has a low-distance ore detector which is activated every time you use it. Medium-distance ore detector is available on your small ship (as a distinct block type) and long-distance detector on large ships.

The “Toolbar Config” screen now shows what components are required to build each type of block.

We have modified the world generator code to produce higher amounts of iron ore – it’s more realistic and also block components are made mostly from iron.

Inserting a new object into the world has been reworked as well. For example now when you click on “New Small Ship”, the game will display a landing gear positioned in front of you (it moves as you move). If you move it close to some other surface, magnets will snap and the landing gear will get attached. This small change should improve the process of building new ships – they will appear more solid and will not fly away in case you suddenly bump to them.

There’s no oxygen, food or water. Your engineer has only two stats: energy and health. We have chosen this direction because we believe that Space Engineers should be about the things you create and not about your body functions.

I enjoy playing the survival mode very much – the building process feels natural and rewarding. Sounds are not final yet, but they already emphasize the process. I hope you will like it too.


The development of survival mode started at the end of summer 2013 (you can see the welder in our first Space Engineers trailer). We kept working on it alongside with other features such as multi-player and all those weekly updates.

We have approx. 300 new 3D models because each block needs 2 to 7 models for its construction phases, there are small and large blocks and we needed floating objects such as components, ingots, ore, etc.

We produced some new animations as well: welding, grinding, etc.

We decided to finish multi-player first and only then do the finishing touches on survival, mostly because multi-player is a feature that spans throughout the whole source code, every little thing has to be considered in terms of network synchronization, packet updates and authority.

The development of survival mode will continue and it’s the area where we will focus our attention in the upcoming weeks. We need to polish it, make it more intuitive and easier to use. We wanted to release it rather sooner than later, so we can play-test and balance it together with you. Please let us know what you think - what parts are annoying and boring, what parts are hard to understand and last but not least: what do you enjoy.

Once this first phase of survival mode is completed, we will work on dedicated server support, factions (very needed for survival multi-player!), wireless communications, etc.

You can find all our previous updates at

Survival Tutorial


Internal structure of a block: integrity and layers with components

Deconstructing a block with grinder

Adding a new block

Constructing a new block with welder (block components are retrieved from your backpack)

Constructing a new block with welder (block components are retrieved from your backpack)

Steel plate block components in your backpack (inventory)


Recharge suit energy and fix your health in medical room

You are receiving damage

Survival mode selection in “custom world” screen

Inserting a new object to the world - small ship landing gear


Please keep posting your feedback and suggestions to our Facebook page or our forum at

We can’t reply to every comment, but I can assure you that we try to read as much as possible and your comments will influence how Space Engineers develops.

Marek Rosa

Like us on Facebook or follow us on
Twitter and you will be notified on all updates.

Warning: Space Engineers is still in development. Everything in the game is subject to change.