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.