Tuesday, March 13, 2018

Space Engineers: State of Development, Open Development in Early Access, Changes to Release System, Xbox One

  • Open development in early access is very challenging, both for players and developers
  • Each new feature, every fix and every optimization opens up new possibilities of what you can try in the game and where you can discover new errors, limits and problems
  • Announcing new development cycle with primary focus on major releases
  • The status of Space Engineers Xbox One version
  • Questions & Answers


What led me to write this post?

While reading comments on our social media, I often see people commenting about the way we develop our games in both positive and negative ways. We are lucky to have a very passionate community but sometimes not everyone agrees with, or understands, our development process.

Our vision was always to be honest with you, our players.
Because you deserve to know.

Space Engineers: State of Development Q&A Stream

From the very beginning  we made it very clear, that Space Engineers is in development and everything is subject to change. In general we do not speak about our future plans however, there have been a few exceptions. When we discuss our plans it has been in general terms, such as now we are focusing on polishing, fixing, user interface, and not on adding new features.

Of course, the decision of being in open development / early access was made by us. Now we must continue to live with this development choice and the pros and cons that come with it.

Pros: We really appreciate the feedback we are getting from our community. Without it, we wouldn't discover a lot of things and be able to move forward so quickly. One example I’d like to mention is that players are playing and experiencing the game in ways that wouldn't occur to us, or we simply would not have the time to explore the game in such use cases.

Cons: On the other side, players are playing a game which we know is unfinished. Some features are not fully implemented, not everything is optimized, the game is not tested in all aspects, and so on. Players can blame us for everything, and we can’t always defend ourselves. This is because we know it takes years to finish a game and we will not be able to fulfill every requirement from our community. Also, even though we try our best to keep backwards compatibility for mods, worlds, and creations with every update, it is not always possible as we strive to improve the game and its engine. This is an unfortunate situation.

Doing an open development project is very difficult.
We are thankful for everyone who is, who was with, and who stayed with us
during the entire process.

Very experimental game

Looking at the Space Engineers today, we have three main challenges:
  • Space Engineers is an extremely ambitious and challenging project.
  • We are doing it in “open development” / early access so the game is always changing.
  • The environments are of huge scale, dynamic, destructible, and feature voxel realistic physics with hundreds of interconnected systems, and full modding support.
We started to work on Space Engineers five years ago. Back then, it was just an idea, there was no prototype and no rules existed for most things we do in Space Engineers (actually the only exception was StarMade which I still have a lot of respect for). We didn’t even know if it was possible or if it was a good idea to create a game with no limits to what players can build, destroy, change etc.

We’ve experimented a lot while developing Space Engineers and have had a lot of fun doing so. On top of this, players are continuing to test the boundaries and capabilities of the game. We understand that not having any limitations can put extremely high demands on computing power, especially if there are situations that go beyond what we originally designed the game to do. Then we often got a fire back about an unoptimized game. Some unintended consequences, e.g. one ship in a world is ok, but what if 30 players start crazily copy-pasting their ships in creative mode, the multi-player would start choking, CPU would choke under all the physics calculations and integration of all entities, memory would run out, etc. It is important for players to understand that optimization is not simply a miracle which can solve all performance issues, but that there are limitations to what can be done in the game. Sometimes too many physics calculations can lead to lower sim speed regardless of optimization.

It’s good that it’s hard because we can learn new things and
show others that they are possible.

At the beginning, it took us 7 months to deliver the first prototype. We decide to do “open development” in early access, which means players who purchased the game were to try the game while it’s being developed, and to get weekly updates.

The following 2 years were full of new features, improvements and additions. It was quite easy to add new stuff at this stage, because the game still wasn’t overly complex and we didn’t have to polish every feature to perfection. We were working with our community and we wanted to make our players happy. Even despite our original plan, we have added many new blocks, various systems and large features (e.g. planets, solar panels, magnetic boots, parachutes, etc).

We were able to have weekly updates where each update brought significant changes (new blocks, new functionality). But as the game grew and became more complex, it started to be more and more time consuming to add, polish, optimize and fix things. Since then, the rich weekly updates changed, mostly to fixes and optimizations. We focused on polishing what is already in the game. We are still in this stage and it will take some time until all is done.

During the last 2 years we focused on polishing and putting it all together. Many things were not visible to players, but there was a lot of work being done in the background.

Today, Space Engineers has 100x more features than we originally dreamed about, it’s much more complex, rich and polished, with more details of how things can interact. Many of the features we do are not just pure software development, but actually computer science R&D. There’s no manual for how to do it, no precedence. We must invent it. For example: large scale solar system, multiplayer with hundreds of dynamic and interacting entities where changes can occur instantly, all sorts of physics issues that can’t be pre-programmed, but the game must adapt and adjust to what players are doing, etc.

This is how we do it in Keen: we start an ambitious project and
then keep going on until it's finished

Our current goal is to perfect this first stage of Space Engineers saga, to build a solid open-world, open-ended, physical volumetric sandbox, where players can build complex machinery in believable worlds, working flawlessly in single-player and multiplayer, with rich modding support.

The last 10% takes 90% of the effort

We are very happy that Space Engineers ecosystem is a living world, with over 200,000 monthly players, a growing number of creations on Steam workshop (more than 310,000 player creations and mods) and a flourishing YouTube and streamer community.

Listening to our community is very important for us. We have our Keen feedback site open for anyone who’d like to share an idea or suggestion about the game.
  • There were more than 1200 ideas already submitted so it gives us a lot of things to looks at.
  • We have already addressed 94 ideas which we implemented into the game.
We are also active on Discord and our social medial, so we gather as much feedback as possible.

Why is open development in early access particularly challenging?

New features, or fixes of issues always open up doors to new ways of using the game, what to build and what to do in the open world. This allows players to push the limits.

For example, originally we didn't plan to have wheels in Space Engineers. We added them, because we saw that players want them for building their machines, and we were also curious what kind of things they would build with them. We didn't aim for car type wheels with suspension and other technical features. However, players started to use them in this way, especially after we introduced planets and there was gravity and a larger surface where they could drive. After we finalized the proper implementation of car/wheels physics in 2017, players started to use them more in multiplayer. These cars are more performance demanding than in other games, because Space Engineers do not distinguish if something is a car or a ship or any other machine. Space Engineers is a universal physics simulator and it has to simulate all components. And if a car is made from hundreds of blocks and a set of wheels, it all has to be simulated and propagated through multiplayer. And this takes its toll on simspeed (performance). Unless we also optimize this, it's going to run slowly.

We can’t hold back every major release until all possible issues are solved, until everything is working. If we do so, you would see only the final version of the game, not intermediate updates, and Space Engineers would not be in early access (open development).

If our development model wasn’t an open development (early access), there would be none of this. There wouldn’t be the game itself until it was 100% finished, QA certified and released.

Space Engineers has hundreds of blocks & hundreds of mechanisms and systems.

Many times our first implementation was just a quick prototype that worked in the most important cases, but didn’t cover them all. For example the antennas, rotors connected to merged grids, and many other.

As we have our internal roadmap, some players may see things being implemented in different order than they expect (e.g. “why instead of fixing multiplayer you worked on visual tweaks?”). But they don’t see the details and the reasons behind it. Back to the multiplayer example, we have actually been constantly improving multiplayer for the last 3 years, but everytime we improve it, people start pushing the game in that direction more and it seems as if nothing was actually improved. It will take some time to get the multiplayer perfect. So while working on this long term project, we want to finish shorter projects that help the community in other directions (e.g. better visual, audio, wheels, intuitive interface). The direction that will help new players, or that will help to grow the game ecosystem also for oldtimers.

Looking back at the last 5 years I can say that the game grew more than I expected. It may seem slow if you look at it on a monthly basis, but if you zoom out and observe how much experimental, complex and risky stuff have we made working... it's fascinating.

We have been on Steam Early Access for over 4 years, and are one of the oldest games there. This shows our commitment to such a challenging project and our community. This is what Early Access is all about.


While building Space Engineers, we also built our team. There were 5 people at the beginning, now we have around 30, working on both Space Engineers and Medieval Engineers.

Everyone who ever built a company, or a team, knows that building the team should precede building the product. Now we feel very confident in the strong abilities of our team and I don’t think there are better programmers for making a SE-like game.

I’ve worked with many developers and I wouldn't trade my team for anything else.

I stayed as the CEO and creative director of both games - because I still love making games, especially with my colleagues, and I would miss it if I would go away from it. So I try to split my time between games and AI.

New way of doing releases

As Space Engineers is nearing its final release date our focus is on polishing, bug fixing and overall game quality rather than adding new game features. Therefore, we’ve decided to change our development cycle. This new development cycle is probably not the final one, but we think that it will work perfectly fine at this stage of development.

We have decided to eliminate the number of weekly updates and handle them on a case by case basis, in other words, when necessary.

Our main focus will be on major updates, which will bring more impactful changes to the game. This way we can focus our development and testing teams on major updates. This will give them time to do proper development and to test the entire game. The number of test cases we need to run prior to a major release is over 8000, and it requires 3 weeks of full time work of the entire QA team.

Once a major update is released, we will spend few days or weeks hotfixing the most important crashes and game breakers, but we really hope there will be a minimum of those game breakers after the release.

Comments from the Community

Xbox One version

Together with Microsoft we announced that there will be an Xbox One version of Space Engineers four years ago.

When players ask us these days about the progress of the Xbox version, we usually say “it is currently under development”.

What I can say is, that we have a dedicated team working on this project with very good progress. We do not want to comment on the target date at this moment, but we would like to assure you, that we are working on it.

Questions & Answers

Q: Does it mean that you have stopped developing the game?
A: No. Quite the contrary. We are just switching from weekly updates to more long-term focused major updates. We are focussing on quality rather than quantity. If we didn’t stop the development after 5 years, why would we stop it now?

Q: Why are there bugs in the game?
A: What you see is an experimental game, in open development, and it’s natural that there are unfinished parts that may appear as bugs. If we did closed development, you wouldn’t see this because you would only see the final product.

Q: Do you think you can improve performance of the game, better simspeed?
A: Yes. It is one of our current priorities.

Q: Are you still working on multiplayer?
A: Yes. It is also one of our current priorities.

Q: Why did it take 2 years to get rid of Clang, and is it still somewhere in the game?
A: It took a lot of time because inventing a robust solution to the physics we have in Space Engineers is a hard scientific problem, especially if you consider the sheer size of our game. Things get even more complicated when you add multi-player into the mix.

“Rome wasn’t built in a day.”

Q: Is it true that the game is slow because you are bad programmers?
A: No. Quite the contrary. The programmers at Keen Software House are some of the best in this universe. They know where to optimize and how to optimize. If something appears as not optimized, it’s only because their attention is focused on something else - more pressing issues, tasks more aligned with the development steps, etc.

Q: What are you going to do after Space Engineers is finished?
A: We do not usually talk about our planned features, products etc. Just in case they change. Everything is still subject to change.

Q: Do you even care about Space Engineers community?
A: Yes, very much! We love what you keep creating and building (and destroying). You are co-creating this amazing piece of work with us. We are in this together!


I am very satisfied with what we ALL have achieved in last 5 years. Some may feel that we could have done more, but if you look back and realize that 5 years ago there wasn’t Space Engineers, nor its ecosystem, there was no prototype, no design, no example to follow, I think we are doing well.

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

Thank you for reading and we look forward to hearing your feedback.

Marek Rosa
CEO, Founder Keen Software House
CEO, CTO, Founder GoodAI

For more news:

Space Engineers: www.SpaceEngineersGame.com
Medieval Engineers: www.MedievalEngineers.com
General AI Challenge: www.General-AI-Challenge.org
AI Roadmap Institute: www.RoadmapInstitute.org
GoodAI: www.GoodAI.com
Keen Software House: www.keenswh.com

Personal bio:

Marek Rosa is the CEO and CTO of GoodAI, a general artificial intelligence R&D company, and the CEO and founder of Keen Software House, an independent game development studio best known for their best-seller Space Engineers (2.5mil+ copies sold). Both companies are based in Prague, Czech Republic.

Marek has been interested in artificial intelligence since childhood. Marek started his career as a programmer but later transitioned to a leadership role. After the success of the Keen Software House titles, Marek was able to personally fund GoodAI, his new general AI research company building human-level artificial intelligence.

GoodAI started in January 2014 and has grown to an international team of 20 researchers.

At this time, Marek is developing both Space Engineers and Medieval Engineers as well as daily research and development on recursive self-improvement based general AI architecture.

Thursday, February 15, 2018

The results of the Space Engineers Physics & Engineering Contest

Hello Engineers!

The big day is here! We are ready to announce the winners of the Space Engineers Physics & Engineering Contest.

As you saw and heard during the online award ceremony on Thursday, February 15 on the Keen Software House Community Network on Twitch, which was hosted by Xocliw, we announced four category winners and many others were awarded for their great submissions. They all followed our rules to try to capture the original visual styling and feeling of the Space Engineers, moreover they all added their bit into their work.

Due to the low number of submitted entries, we have decided do not award winners in two categories, “Crash Test” Recreation  and “Crash Creations” Recreation. However, the rest of the submissions were awesome. It was really difficult to choose from the total of 51 submitted creations. So with no more delay, here are the winners:

Engineering Ingenuity

Vanilla Epicness

Modding Epicness

And here are the prices for the best creations:

Congratulations to winners and big thanks to all who participated!

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

If you have any questions or requests, please do not hesitate to contact us, we will do our best to solve your problems.

We would be also very happy if you can submit your feedback at our Space Engineers Steam store page and encourage us to do better. We welcome both positive or negative comments, it helps us to create better game for you.

Thank you for reading and we look forward to seeing what you can engineer and come up with!

Marek Rosa
CEO, Founder Keen Software House
CEO, CTO, Founder GoodAI

For more news:

Space Engineers: www.SpaceEngineersGame.com
Medieval Engineers: www.MedievalEngineers.com
General AI Challenge: www.General-AI-Challenge.org
AI Roadmap Institute: www.RoadmapInstitute.org
GoodAI: www.GoodAI.com
Keen Software House: www.keenswh.com

Personal bio:

Marek Rosa is the CEO and CTO of GoodAI, a general artificial intelligence R&D company, and the CEO and founder of Keen Software House, an independent game development studio best known for their best-seller Space Engineers (2.4mil+ copies sold). Both companies are based in Prague, Czech Republic. 

Marek has been interested in artificial intelligence since childhood. Marek started his career as a programmer but later transitioned to a leadership role. After the success of the Keen Software House titles, Marek was able to personally fund GoodAI, his new general AI research company building human-level artificial intelligence, with $10mil. 

GoodAI started in January 2014 and has grown to an international team of 20 researchers. 

At this time, Marek is developing both Space Engineers and Medieval Engineers as well as daily research and development on recursive self-improvement based general AI architecture.

Friday, February 2, 2018

Space Engineers: Major Overhaul of Visuals, Audio and Wheels

  • Motivation: playing Space Engineers should feel good
  • What we did: Massive overhaul of visuals, audio, wheels, and tons of other improvements
  • Replay & Offline rendering (our internal tool for recording ingame videos) used for the first-time
  • Nvidia Ansel
  • Render blog post - a guest post from Jan Hlousek, Keen Software House VRAGE Engine Lead
  • Wheels blog post - a guest post from Martin Pavlicek, Keen Software House Physics programmer
  • Better immersion => Happier Engineers
  • Official Russian language translation

With today’s major update, 1.186.0, we are releasing a massive overhaul of visuals, audio and wheels, together with a huge number of additional improvements to the core of Space Engineers.

The following video was all captured in-game, using our new replay and offline rendering tool (currently internal use only).

In this trailer we wanted to illustrate major visual, audio and wheel improvements. On top of that, we felt the need to create a new story-driven video from Space Engineers. This is the trailer I wanted to create since beginning of Space Engineers idea - crash-landing of a large ship, repairing, and heading back where it started.

We are encouraging all Space Engineers content creators (youtubers, streamers, modders) to start using these new visuals and to follow our original art style when creating new content, or even consider redoing past creations with these new capabilities.

Why is this important for us? Space Engineers was started with a very particular vision in mind and we want to keep it. It was authentic, unique at its time and made our game stand out. People loved it.

You can find the changelog listing all the new features, tweaks and improvements on our forums: https://forum.keenswh.com/threads/7399609

Archived Release Stream

The stream peaked at more than 1400 viewers!


Space Engineers should feel good to play. Therefore, the major goal for this update is to enhance your experience by improving the way our game feels. Our new changes, including improved sound and visuals, make the game more realistic, more rewarding and ultimately more enjoyable. 

The last major update brought an overhaul of physics. The current one brings massive improvements to visuals, the rendering engine, animations, audio (arcade and realistic), wheeled simulation, and much more.

Visuals are important, they mediate the first impression. Audio is also important, it’s adding the emotions (feelings, depth) to all interactive works.

Space Engineers was inspired by reality and by the “need to create”. The best way to enable both, is to try to think about how all the components in our game would work in the real world. The answer is: get as close to realism as possible, but not too much, so you don’t jeopardize the intuitive gameplay.

We are aiming for not only realistic physics, but also realistic rendering and audio.

Why now?

We are wrapping up things and the first-minute impression is important. Polishing visuals and audio are things that you shouldn’t keep for the finish line.

Moreover, there’s this “broken windows syndrome” where unfinished features signal that it’s OK that the remaining features will stay unfinished. This is not a feedback loop we want to encourage - not internally in our team, and not externally to our community.


Our original visual style was particularly designed to help players grasp complex geometries of their creations. For example, a low-frequency high-resolution texturing enables players to understand the surface more intuitively than high-frequency texturing would.

We always aimed for AAA visuals. Not only because they look awesome, but they also help to understand the surrounding in a more intuitive manner.
When we talk about visuals, we mean specifically: the rendering engine and its configuration, art, 3D models, textures, character animations, interaction with the world, particle effects, lighting, shadows, environmental ambience and reflection, the way we build and color template ships, etc. Everything that affects what you see and how you interact with the game.

Things in Space Engineers should look similar to what they would look like in the real life, if they were built with the technology of today. However, we didn’t want to just copy reality. We wanted to add something on top of it using our own artistic license, making it special and unique.

Visuals have been a top priority for me and the Space Engineers team during the last months - but the work on it had already started years ago. It was a long, continuous and gradual process. For example, this picture illustrates how the visuals of armor developed over time:

Left: original from Oct 2013 / Middle: later version / Right: new one from 1/2018
We tried to get back to that original armor look & feel - metalness, the feeling of heavy and strong steel.
The following three pictures illustrate the evolution of the basic color palette.

Left: Basic armor palette (2013) / Middle: Prototypes (2017) / Right: Current look (2018)

What we did:

  • New GPU particle engine, so the game can render richer particle effects and a higher number of them at the same cost (before there were  only CPU particles)
  • All transparent geometry rendering is now tweaked and aligned with the rest of the visuals
  • Almost 90 unique particle effects
    • Particle effects: explosions, thrusters, jetpack, bullet hit, crashes and collisions, damaged and destroyed blocks, meteorites, missile trail, dust from thrusters and many more
    • Debris after object damage and total destruction
    • Debris after voxels cut out or missile explosion
  • Gravity and physics influences particles, e.g. bullet hit sparkles will fall down in gravity, collide with the ground, bump up
  • Selected particle effects emit a point light (explosion, gun muzzle, bullet impact, etc)

Camera shake
  • Now there’s a very subtle camera shake whenever there’s a collision, near explosion, crash, player shooting or using a tool, falling or landing on feet, ship acceleration, etc.
  • It’s a very simple effect, but it adds one more layer of immersion

  • New high-quality armor edges, small and large. This is actually very funny because the original (temporary) triangle-like armor edges have been with us for a very long time, longer then I would expect.
  • Polished color palette - saturation and brightness. Back to original Space Engineers colors.

  • Artists designed the glass so that it looks good from both sides, renders proper dynamic reflections and subtle details inform the player that there’s glass present (absolutely translucent glass wouldn’t be visible, players would be hitting it all time)
  • Window block, ship cockpits

Depth-buffer clipping avoidance trick for tools and weapons in first-person mode
  • We had this feature in DX9 version of our render, but when we switched to DX11, we didn’t implement it
  • It’s now back again - basically it means that near objects (tool, weapon) are rendered with closer depth and thus don’t clip with the remaining geometry.
  • The result is that when you get close to obstacle, your tool or weapon won’t be clipping through it
  • It really adds depth to drilling, grinding and welding in first-person mode. It just feels so satisfying now!
  • The best part of this story: we originally estimated it will require 2-5 days of work on our render. But because we didn’t have this much time, Petr Minarik and Jan Hlousek managed to implement it in one hour! I wouldn’t believe if I didn’t see it!

Visual tweaks
  • Point light with proper attenuation (not so linear, correct specular contribution)
  • Suit headlight with proper glare, dust cone, correct light settings
  • Glares for all major light sources - thrusters, interior lights, spot lights, sun, etc
  • HDR - high dynamic range colors and lights, enabling higher contrast between dark and very bright light sources
  • Eye adaptation - when you move from dark place to a brightly lit open space location
  • Tone mapping
  • Bloom
  • HBAO - screen space ambient occlusion shader, adding little dark shadows to corners
  • New Skybox - almost monochromatic, very simple, coming back to our original skybox but without impostor asteroids, with dust and slightly bright to make the space not look so dark (players can change the skybox through mods)
  • Global illumination and dark in shadows/interiors now working much better
  • Cinematic feel (can be disabled)
    • Lens camera dirt
    • Vignette
    • Chromatic aberration

3D Models
  • Cockpit chairs - less rounded, more squared (fitting original art style better)
  • “Under construction” blocks have more metallic texture, less chrome, more matt, galvanized metal
  • Overhaul of Particles!
  • Driller Head metal material is now more metal shiny/scratched
  • Astronaut boots with proper stripe for magnetic effect
  • And many more

  • Gravity for character is now more closer to real gravity on Earth. It may feel like the character is now falling faster, but it’s actually correct and also feels better - unlike the moon style gravity that has been in our game for the past year or two.
  • Original Space Engineers from 2013 had similar gravity as the one present in game in this update and we liked it this way

Character movement
  • Jetpack has faster acceleration and faster deceleration, the movement doesn’t feel slow and unresponsive. It’s easier to navigate in closer corridors and faster to travel longer distances.
  • Faster walk/run/sprint, closer to how it was in Space Engineers in 2013, and also how other first-person-games do it. Moving around now feels more responsive and satisfying.

Character animations
  • Polished all animations to feel more realistic
  • Character fall and landing animations - now finally with bending knees :-)
    • Landing from a jump
    • Landing from a fall (e.g. turn off jetpack)
  • Holding and using tools in first-person and third-person - now the hold is stabilized and  the player feels more in control
    • Improved interaction between the tool and the environment (lighting, particles, sounds, timing)
    • Tools engage faster (after key/button press), not a delayed feeling anymore
  • Rifle shooting is now more precise
  • Movement cool down animation - when a character suddenly stops (because the player stopped holding the movement key), the character needs to blend from current movement animation to a stand-by pose. This transition needs to be quick, but it must look realistic. Other games usually don't have both first-person and third-person camera, so they can choose only one method to stop a moving character (fast or slow). In our games, both are possible, so we have to make a compromise - the game feels responsive in first-person mode (you don’t see your body), but movements blend nicely in third-person (you see your body).


  • We reused our new voxel engine from Medieval Engineers for Space Engineers
  • Faster loading times: Easy Start Earth about 60% faster! 
  • Instant changes/damage to voxels (e.g. explosion, voxel hand, etc): more than 400% faster!
  • Fixed a problem when drilling to the center of planet - discovered thanks to this video from farrell1701 
  • Grass switching when removing voxels fixed

  • The basic interior doors open faster and with cooler sound effects
  • Better feeling opening and closing  doors :-)

  • Configurable LOD (level of detail) distance - for screenshots and offline rendering. Turn the LOD distances to extreme values (almost infinite) in Graphics Options by setting both Model Quality and Voxel Quality to Extreme. IMPORTANT: This setting is only for offline rendering and capturing screenshots and is not recommended for regular gameplay!
  • Bullet hit decals / bullet holes - now working on all surface with only one exception: deformed armor.

Planetary visuals and voxel/asteroid
  • This major update focuses on general visuals - mainly in space. We touched the planetary visuals a little, but it wasn't the main objective. In other words - we really didn't focus on planetary visuals. We focused on space things.


The audio in Space Engineers worked well, but after years of changes in all areas of the game, it was  time to tweak and polish it all.

Space Engineers has two audio modes which can be set in world settings - arcade and realistic.

Arcade mode sounds are how they would sound if this was a regular movie, or if space wasn’t a vacuum. It’s the default option.

Realistic mode is how the sound works in real life. Sound waves travel only where there’s a physical connection between a sound source and a listener. The medium can be either the atmosphere or a solid object, and influences how  you hear the sound: clearly or muffled / low-passed (through vibrations). The game simulates this property. The end result is that you won’t hear an explosion of a  ship nearby if you are not standing on it. However, you will hear a muffled explosion and cracking of your ship if you are standing on its surface. This mode is very realistic and very cool. It is a must “hear” for all Gravity fans - see my older blog post.

What we did:

  • Small and large ship sounds - emphasizing feel of accelerating by adding additional sounds
  • HUD voices reenabled (e.g. “low energy” warning)
  • Footsteps retweeked and aligned with new speed of character movement. It also supports different ground materials (ice, rocks, metal, glass). Now you should hear and feel when you are running.
  • Footsteps also start sooner
  • Character landing/fall sounds are now more prominent, you should really feel it, this is very important for immersion and different surface materials
  • Polished where the sound listener object resides - before it was sometimes in camera and sometimes in the center of a ship. Now it's always in camera and the only exception is when you are piloting a large ship from cockpit - listener is in camera, but you will also hear sound of the ship
  • New sound when your character dies - very subtle, but giving you important feedback
  • Magnetic boots, on/off sound, different materials, you should really feel how they stick you to the surface
  • Character jumping sound - emphasizing the rubbing of textile, making the jumping more satisfying :-)
  • Ships colliding and crashing (and sliding and scratching)
  • Small ship cockpit - enter/leave sound - now has heavier sound, feels rewarding. You just want to keep entering a leaving the ship
  • Bullet impact on rocks has the standard wild west "pew" sound as it had in all our games. Must “hear” feature!
  • Max sound instances - reworked completely - this is when there are many sound sources close to the listener and it would negatively affect CPU performance to play them all. The game will start prioritizing sounds by distance and slowly turn of less relevant sounds. It is difficult to notice, but it helps with realism and CPU
  • Sound occlusions - if there’s an object between the sound source and the listener (you), the sound will be tuned down. This feels awesome!
  • Distance to sound source - this is an older feature but it’s so awesome that I must  mention it: when the distance between sound and listener increases over a certain threshold, you will hear it a bit muffled and with “long distance effect” applied on it. Awesome for gunshots, explosions, etc.
  • Jetpack sound tweaked
  • Tool sounds tweaked, better timing
  • Decreased default music volume to 50%, so you can hear the sound effects better, but you can also raise it back to 100% if you want


In 2013 we added a first barebone version of wheels. It was just an experiment, we didn’t know if this feature would be relevant for a space game. It proved to be quite important for our community, so we decided to implement fully fledged wheel/vehicle mechanics.

“The cars we drive say a lot about us.
The cars we build say even more.”

Wheeled vehicles in Space Engineers should be strong, robust and endure more. They should enable effective off-road transport, be stable on most surfaces, and not slide or flip over unnecessarily. They should be stable under harsh physics conditions and stable in multiplayer.

“We all have a need to race. We also have a need to create.”

We are aiming for a realistic experience, but not to constrain your experimentation when building vehicles of your imagination. This is still a sandbox open-ended vehicular simulation.

What we did:

  • Changes in Terminal Screen
    • Reduced number of wheel/suspension settings - the game takes care of the details
    • Tuned default settings
    • Simplified for easier usage
  • Modified contact point response for wheels
    • No more wild voxel bounce-off and sliding
  • New wheel static friction simulation
    • Wheels will maintain expected path in turns, no more sliding
  • Progressive steering
    • Max steering angle is automatically adjusted based on car speed at the moment
    • Naturally reduces chance of car flipping
  • Dynamic center of mass changing
    • Center of mass for Wheel-Suspension connection is adjusted to further improve car behavior
    • Reduces chance of car flipping
  • Low friction mode for wheels
    • To maintain backward compatibility for existing creations
  • Air shock suspensions
    • Jumping vehicle will extend and strengthen suspensions in mid air to better absorb the shock impact upon landing and prevent damage of the chassis (example video)
  • Unsticking via jump
    • When your off-road adventure gets you into rough terrain and your car can’t get out of it  (wheels are spinning, the car sits on its belly) - press X and the car will make a small or large jump
    • Wheels need to be in contact with ground. The car is using the suspension springs to quickly push itself up.

  • Acceleration / deceleration / stopping / braking
    • We tweaked the vehicle mechanics and configuration so that you will have the correct experience from your vehicle accelerating and decelerating
    • Braking and stopping the vehicle now has the right feeling as well as being more responsive, intuitive and enjoyable
    • Mass of a vehicle influences its inertia - e.g. heavier vehicles continue moving forward with more energy than lighter ones when left unattended with no braking force applied to them.
    • Cars feel more like real cars!
  • Different friction on different surface materials.
  • Fixed Multiplayer support for Wheels.
  • Increased robustness and endurance of wheel and suspension blocks - so they don’t break after jumps.

Replay & Offline rendering

This is a new internal tool for recording ingame videos. We used it to record footage for the newest update video.

This tool helps us in two areas:
  1. Replay: With this tool we are able to record actions of multiple characters and ships in exactly same way as it was in Miner Wars 2081. You record the first character, then another and another, then a ship and another ship. You can then replay it all together and the final scene seems like multiplayer, or a well prepared cooperation. It is designed for our internal use for trailers for now.
  2. Offline rendering: pre-recorded sequences can now be replayed in offline non real-time mode, where physics tick and render tick go in sync, one after another. Therefore, it’s impossible to get missed frames, lags, stuttering, etc. Because the rendering is offline, you can run it in higher resolution and quality. This is how we are able to get lag-free 4K @ 60 FPS scenes, no matter how complex.
It can be used for staging screenshot scenes with multiple ships and characters.

Offline rendering at 4K @ 60 FPS takes its time. Let’s do some math:
  • Our experience is that a 10 second shot at 4K @ 60 FPS takes approx 20 minutes to render
  • A 3 minute long video would then render for about 6 hours
  • You may be asking: but doesn’t the game run 60 FPS at 4K on my supercomputer? Yes that’s true, but the rendering generates and saves thousands of 4K lossless PNG images. This takes time. Hard drives have their latency and bandwidth (even after we upgraded to high speed SSD)
  • Just as an illustration:
    • If the game renders 60 frames per second, a 10 second shot will generate 600 images
    • 4K images have 8,847,360 pixels
    • There are 4 bytes per pixel
    • So each 4K image is equal to 35 Mb
    • Therefore, a 10 second shot  equals to 21 Gb of data
Another benefit is that the game can be render on Extreme graphic quality = no LOD switching, with very rich shadows.

The bad news is that this tool is for internal use only - mainly because it’s very hardcore, not user friendly at this moment and not all game features are supported it. We understand that this in the hands of our community creators would be a gold mine of great footage!

Official Russian translation

I am also happy to share with you, that we have added an official Russian translation of Space Engineers into the game. More than two hundred thousand Russian speaking Space Engineers players can now enjoy the game in their mother language. My big thanks goes to our community, but especially to Sergey Leonidov, our Keen Software House developer, who went through more than twenty thousand words in the game and did a proper review and correct translation.

Nvidia Ansel

We also worked closely with Nvidia who asked us to implement the support for their Ansel technology.

From Nvidia website:
  • NVIDIA® Ansel™ is a powerful in-game camera that lets you take professional-grade photographs of your games. Now, you can capture and share your most brilliant gaming experiences with super-resolution, 360-degree, HDR, and stereo photographs.
  • FREE CAMERA: Freeze your game for that perfect moment and reposition the camera for just the right angle. Ansel overcomes the limitations of traditional screenshot capture, giving you the power to capture truly unique photographs.
  • POST-PROCESS FILTERS: Adjust the look, feel, and mood of your screenshot. You can even add filters or manually adjust brightness, contrast, or other options to suit the mood.

What we did:

Using Ansel, players can capture screenshots in default resolution, super resolution (similar to multiplier we already have, but without limitation on GPU memory, as it captures screen in multiple small tiles, so the limit is 64k resolution), stereo screenshots, 360 degrees (up to 8k resolution), and 360 degrees stereo.

Enabling Ansel by pressing Alt+F2 shortcut will pause the whole game (even particles). The player then has the ability to set the camera position / orientation / roll precisely how they want it along with other properties such as field of view (FOV).

Before taking the screenshot, the player can add a filter (b&w, half-tone, retro, sepia), adjust various post-process effects (sketch, color enhancer, vignette, vibrance, contrast, brightness) or enable / disable HUD.


The following technical post goes into great detail about the changes that were made to wheels. It was written up with diagrams and videos by Martin Pavlicek, one of our programmers here at Keen Software House who worked heavily on this iteration.


by Martin Pavlicek

You've been asking us over and over again for a long time now, and today we are really proud to bring you entirely new physics for wheels. We've been working extremely hard to make driving of all wheeled designs in Space Engineers a really pleasant experience, and we hope that you'll enjoy the new driving, at least as much as we enjoyed making it.

In next few paragraphs I would like to familiarize you with some of the steps we took to make the driving great again. So without further ado let's jump right on it.

Static friction

One of the main issues you may have immediately noticed when driving old wheels was the fact that they weren’t  actually steering the car at all. Even at high friction setting the wheels would slide sideways on rock solid surfaces. Keeping to the track while turning was basically nonexistent. This wasn’t really the behavior one would expect from rubber-tyred wheels, so we focused on this and made steps towards creating tires that better reflect real world behavior.

When working on this issue we found out pretty soon that the reason for this unexpected behavior was missing so called “static friction.” The tires were basically not making any resistance when forced to slide sideways during turning or on steep slopes.

In order to fix this issue, and make the wheels behave more naturally, we introduced a new system that will watch the state of each tire on your car and  dynamically simulate the static friction on each wheel, making your car (or any wheeled design) behave more naturally, as one would expect in real world.



Dynamic center of mass

The vision of Space Engineers is to be based on reality, however sometimes we found it necessary to sacrifice elements of realism for improved gameplay. Immediately after making the cars turn by the system described above, we noticed that it's actually quite difficult to drive common designs one can find in our workshop. Blocks in SE are large and quite heavy, which ultimately makes heavy cars with a high center of mass. Combine this  with the high speed that you are usually driving in our game and you'll get a car flip in every second turn.

Space Engineers player: "I drove my car only 70m/s on a flat planet surface and my car flipped over while turning. This doesn’t happen when I drive in real world. Literally unplayable."
Keen support: "Sir, can you remember when was the last time you drove your 15 ton truck 250km/h on a field?”

It's really boring to drive at a realistic 20m/s. and while it's perfectly physically accurate to make your car flip when driving faster than that on an uneven surface, it's not a really good user experience and we know it.

For this reason we introduced another system that will dynamically adjust the center of mass of your designs for force impulses that come from wheels to the car chassis. Keep in mind that the behavior of other forces acting upon your grids, for example impacts of other objects, will remain the same. This change will take place only when wheel interaction comes into play.

This will allow you to make more sharp turns in higher speeds, without risking a flip over.

While the system helps, keep in mind that it's intentionally limited, so that your design still matters and the engineering aspect of the game stays preserved. The better you build your car, the more you get out of it in terms on driving properties and gaming fun. See section best practices below for more info on this topic.

Adaptive steering

It's natural for drivers in the real world to adjust the amount of steering they apply based on speed, driving surface and mass distribution of their car. If they miss-judge these, they will end up drifting their car or worse they'll flip it over.

The same applies for our game, so we implemented a system that will take these properties into account and adjust the maximal steering angle based on current conditions. This will further help you avoid accidental flip overs and make your driving experience even better.

Physics surface materials

Another new feature we are introducing to Space Engineers in this update are physical material properties for voxels, like lateral and forward friction. This does not apply to wheels only but it's related to all contact with voxel surfaces. From now on you will notice that ice is much more slippery than grass, which is more slippery than a rock. Physical restitution is also a thing now, so solid rock is more bouncy than grass for example.
Enjoy your ice cold lake drifting!

Surface bounce-off

One might have noticed on old wheels, and it eventually came even more obvious with new wheels, that the voxel surface is actually not really flat. In physics it's represented by a triangular mesh and driving on such surface at high speeds can be quite bumpy as the wheels are hitting different surface triangles.

This made the driving experience quite unpleasant at high speeds and from time to time cars started to unpredictably jump off the surface.

To combat this issue, we are modifying the contact points between the wheel and the driving surface in real time to imitate a “flat surface” and smooth out the driving as a result.

Impact absorption (aka AirShock)

To further improve your driving experience in challenging terrain we are introducing the so called AirShock system. It is designed to automatically detect situations when you are about to land hard after a large jump and temporarily increase the impact absorption properties of suspensions, namelly suspension spring strength, dampening and height offset of wheels. The amount of energy absorbed is obviously proportional to the number of wheels that are in contact with the ground at the moment of impact, so keep that in mind while designing your cars. The more energy that is absorbed into the suspension system, the less chance that you'll strike the ground with your belly.

Braking and Air friction

High speed driving is fun, but sometimes one also needs to slow down, or eventually stop. That's why we simply could not forgot about the braking system. We paid close attention to make braking as responsive and strong as possible, while keeping it within the boundaries of realistic expectations. With a little bit of artificial stabilization, to compensate for higher center of mass, than is usual in real world designs, the overall feeling from this part of driving felt really satisfying to us. We hope you'll feel  the same way when you try it for a first time.

Hand in hand with manual braking there is also other force that is usually making cars stop in real life. It's called air friction and we are adding it for the cars in this update too.

One minor issue, but huge quality of life improvement, which we solved along the way is a (parking) brake issue. Wheels will now correctly steer and suspensions will stay functional while the brake is engaged.


When it comes to off road you never know what trouble you might encounter on your journeys, so it's better to be prepared for anything. If you get stuck in a deep bank, and can't get out using conventional methods, you'll definitely appreciate the new jumping feature. By using suspension springs as a device for vertical emergency propulsion, you'll be able to get yourself out of any trouble. And if not, well, you are engineer after all, so use your skills and engineer your way out of the trouble.

Simplified terminal

There used to be huge amount of sliders and other settings in terminal for wheel suspension block which were actually used by a small percentage of players. Most of players were probably scared of that wall of sliders :)

We decided to reduce the number of rarely used setting here in favor of a simpler user interface. Some of the setting are now automatically handled by the game in real-time and some of the less important ones are set to good defaults and changed only when needed.

Improved multiplayer (By Sandra Lenardova)

As you know, wheels in multiplayer used to bounce around a lot and never moved straight. This was mostly because wheel position corrections from the server kept putting wheels underground. Our solution was to significantly tighten position corrections for cars, while simultaneously significantly loosening corrections for wheels. In fact, wheels are not corrected from the server at all at high speeds, relying solely on wheel constraints on the client. At lower speeds, we no longer correct wheels on their suspension axis. The result is an experience comparable to driving in singleplayer.

Best practices

In this section I would like to point out a few tips that will help you get the most out of the new driving model.

Low center of mass: When designing your vehicles, keep in mind that overall mass and the center of mass matters. Same as in real life, the lighter your car and lower its center of mass, the shaper the turns you can take without risking a flip over.

The more mass, the more wheels: Wheels are usually the only parts of your car that have contact with the surrounding environment. This means that they are the main contributors to overall vehicle acceleration and braking. The more mass you wish to accelerate quickly or stop, the more surface contact you need to make it happen.
Also the more wheels you have, the more points there are to support all that mass in turns, improving your chances that you will survive the next sharp turn you take in one piece.

Adjust your suspension to your needs: While the game handles a lot of the driving model parameters on its own, there are still some that are dependent on your personal preference and might both improve, or ruin, your driving experience when set up incorrectly.

First of those is suspension strength. This parameter sets the stiffness of the main suspension spring. For general driving we recommend setting it to low, so it correctly leans into the turns and helps the car in natural turns without having the tendency to flip over.

On the other side there are some engineers that will benefit from a stiffer setting when building low profile sports cars or heavy duty trucks. It might be important for them to make the suspension more stiff to improve the behavior in these cases.

Another rather important setting is steering angle. There are basically infinite amounts of configurations that you can use your wheels for in various designs.  It is next to impossible to make a software that would correctly recognize all of the configurations and set your wheels to correct steering.

It's in your hands to engineer correct angles for your wheels.

Each and every one of us has different feelings and needs for specific designs, about how fast a car, or any other wheeled design, should drive and how fast it should accelerate. Some like it when wheels squeal when they press the gas, while some like a smooth controlled launch. For this purpose there is a Power slider in terminal which will allow you to tune the power of wheel propulsion to exactly fit your needs and make it feel right.

We know that wheels are used not only for cars but there are a variety of use-cases for them including a role of sliding pad for example. Even though wheel mechanics changed deeply during the process, we wanted to preserve this functionality and make sure all the great creations on our Steam workshop stay intact. That’s why we are keeping the Friction slider in suspension terminal even though it’s functionality has changed quite a bit now. For old blueprints the game will automatically distinguish between wheel and sliding pad functionality and set appropriate friction settings. Default values chosen by the game should work for the vast majority of you, but just in case you need some special setting the slider is available.

Enjoy your new driving experience and remember, safety first!


The following technical post goes into great detail about the changes that were made to render engine, art and visuals. It was written up with diagrams and videos by Jan Hlousek, Keen Software House VRAGE Engine Lead

Visual Tweaks

by Jan Hlousek

Work on this update started a year ago, when we decided to convert the game to full HDR rendering. At first, we had to make sure the lighting pipeline does not clamp the intensities, then we added automatic exposure adjustment (eye adaptation) and HDR bloom effect, which is essential in communicating bright areas of the screen. The result itself blew our minds: exposing details in dark areas, interiors and undergrounds, while keeping bright areas feeling believable.

So we decided to go full production, reworking all parts of the renderer and artworks to HDR, sometimes even adjusting gameplay. And now we are happy to present you the results of this long endeavor. I hope you will appreciate it at least as much as we did the early HDR prototype.

Let me share with you some of the challenges we experienced along the way.

So what does it take to deliver an HDR image to your monitor? As we use deferred rendering, the geometry part of the pipeline filling the g-buffers stays more or less untouched. Once we have g-buffers prepared, we start our lighting pipeline by accumulating results of each light to a so-called light buffer. Unlike in LDR rendering, where all the rendering is bound to the 0-1 range and anything higher will just end up pure white, HDR rendering has a wide range of intensities of all the lighting contributors. Below are the ranges we settled on in the end:
  • Sun: 150
  • Atmosphere: 17
  • Clouds: 17
  • Emissive textures: 0 - 40
  • Spot lights: 4 - 40
  • Interior lights: 1 - 20
  • Skybox: 5
Fig.1: Various lighting conditions and their histograms
In order to be able to work with such a wide range of values, the lighting buffer has to be in floating point format.

When lighting is done, we can not just send the image to the monitor, as most of the monitors are still operating in 0-1 range (LDR) and most of the image would just be  a saturated mess:

Fig.2: HDR image displayed without exposure correction and tone mapping
Therefore, we have to scale the ranges of the HDR image to LDR range. This is done by applying exposure correction, similar to that seen in photography. And as in photography, we have to find out what value of exposure to use, as the image intensities may vary wildly.

Every frame, we start by analyzing the light buffer and creating a histogram. Based on the histogram we can find the optimal exposure, the same as with a real camera, and apply it on the resulting image. This process is actually quite complicated. Imagine having an uber effect in photo editing tool that would help you fix the exposure of any picture to something perceived as aesthetically pleasing, making sure the result is not either under-lit or over-lit and still fits your creative vision. It’s a job worthy of AI. Although at times, we toyed with the idea of employing our GoodAI colleagues’ technology in this task, in the end we improved the exposure detection algorithm to the point where it is giving very good results.

The Histogram consists of the pixel luminance values accumulated into multiple bins (vertical lines), containing the amount of pixels in its luminance range. The Histogram of the scene above looks like this:

Fig.3: Histogram of Easy Start Space
We are prioritizing the pixels in the center of the screen and de-prioritizing the skybox pixels. We find the bin with the highest amount of pixels, ignoring 25% of the darkest and 2% of the brightest pixels. If such a luminance bin is outside of the allowed area (in the histogram visualised as green), we will clamp the resulting exposure. If the picture has most of the pixels in those areas, we clamp the resulting exposure and won’t adapt further (so we won’t make the picture too bright in the dark for example). The actual exposure is animated in time, always converging to the exposure detected from the histogram, with faster adaptation to light and slower to darkness. After applying the exposure the image looks like this:

Fig.4: LDR image after applying exposure correction and tone mapping
Bloom effect is essential in HDR rendering to communicate bright areas on screen on LDR monitor. See this image without bloom, you can not tell the bright spots from the medium ones.

Fig.5: Image without bloom highlights
We had to improve the bloom effect and get it on par with the rest of the game’s visuals. The bloom shader consists of three stages: filtering out the image (bright pass), blurring it, compositing it back to the original image. We had to make the bright pass filtering luminances based on the current value of exposure, as we don’t want for example screens to glow in daylight. We made a new blur pass, which allows us to have much wider kernels. Compositing is later done in tonemapping.

Fig.6: Image with bloom highlights
As the first thing after creating the HDR prototype, we realized we needed to update our global illumination solution. Global illumination is the system responsible for bouncing the light from one surface to another, transferring the intensity of the light and color properties of the material:

Fig.7: Global illumination exercising red color bleeding over white surfaces
There are various systems which can solve global illumination, but most of them need precomputing static data in build time or have a huge impact on performance. In Space Engineers, the environment can change significantly at anytime, so we can not really precompute much data in advance. We also didn’t want to sacrifice high performance for realtime global illumination.

In the end, we settled with the simple trick of rendering the surrounding of the camera to HDR cubemap and using it as a source for global illumination for close proximity pixels.

Fig.8: Environment probe cube map
For distant pixels, we are using just skybox / atmosphere if it is not obscured.

We have also noticed artifacts in the lighting, which were caused by simplistic attenuation. Attenuation is a light decay over the distance travelled. Modelling attenuation properly we ended up with this result:

Fig.9: New attenuation in effect
We chose different attenuation for diffuse and specular lighting. We wanted specular to be visible in most of the range of light and to attenuate diffuse realistically.

Fig.10: Diffuse attenuation with different falloffs and Specular attenuation
Next in line was a transparent pipeline. Most games render transparent geometry in LDR and just compose them with an HDR image after applying exposure. We wanted to have coherent lighting, ambient, emissivity and bloom on particles, as in the rest of the game, so we decided to go HDR. That meant redoing the rendering of all transparent objects.

We started with particles and decided to go all in and rework them from scratch. We recreated all the particle texture atlases (this time in 8K instead of 2K) and particle setups, adding lots of functionality to our particle system along the way, to get it on par with the rest of the game’s quality.

Fig.11: HDR particles
We wanted particles to look believable in all lighting conditions - an underground passage without any light should have bright flames and black smoke. On the other hand, a burning block on a lit platform should have a nice volumetric smoke based on the direction of light. In order to achieve this, we had to rework the lighting of particles and let them use global illumination.

Next we wanted to improve glass shading. We have used same lighting formula as for standard blocks, to achieve the dirt on windows to be accentuated in specular angles, as well as indirect lighting matching the tint of windows dirt to the color of the surroundings.

Fig.12: Glass with lighting and gloss based reflections
For reflections, we use an environment probe cube map for indirect lighting. It is updated every few frames and then blended on top of the previously rendered probe because of performance reasons. For lighting it is perfectly fine and helps smooth out transitions of lighting conditions. For reflections it is not looking perfect  (eg: ghosting effect of the blended reflections). We have added a gloss map to achieve variably blurred reflections and hide blending of the probe.

For new effects like vignette and chromatic aberration, we use a subtle barrel distortion applied on each color channel separately (with different distortion) and reduced color intensity the further it is from the center of the screen.

Colorization shader was a difficult case to solve. Space Engineers was released in 2013 with a wildly different renderer based on DX9 technology. We switched to DX11 rendering 3 years ago. While converting renderer from DX9 to DX11 multiple design decisions were made, like completely changing the texture layout for models. In DX9 magenta color was used in color texture to let the shader know which parts should be colorized. In DX11, it was changed to a more convenient half-gray color, which removed magenta color bleeding artefacts. This was a good call. As DX11 was a prototype at times, we decided to adjust colorization later, as there were higher priorities. So from the very beginning of using the DX11 renderer, we had inaccurate colorization in place. Not only was it displaying wrong colors of grids created in DX9, it also reduced the ranges of colors that could be used.

Fig.12: Washed out DX11 coloring
Fig.12: Fixed DX11 coloring
And now we got to finalize it. It was a tough call. On one hand, we will have a wider range of colors at our disposal and the original color palette and grids created in DX9 will start to look as intended. On the other hand, carefully selected custom colors used in players creations made on DX11 render may change significantly.

In the end we decided to go with this change as, from a long term perspective, it had many benefits. We hope you will appreciate it.

Last but not least we integrated nVidia Ansel technology, which is essentially a spectator camera in paused world able to capture stereo, 360, HDR and multi-res screenshots.

Fig.12: Ansel 360° capture
Once Ansel is started, it takes over the controls. It lets us know the camera properties and we can override the in game camera with them. Capture itself separates the image into a grid, then tells our renderer to render each cell of such a grid separately. Later Ansel stitches all the rendered images into one huge image. Rendering of each cell needs to preserve the projection of the original image using an asymmetric projection matrix. All render systems had to be revisited and made compatible with such a rendering approach. In the end, we support all the features Ansel has to offer and you can take images up to 64K.


Comparison - before & after this update

For those who are curious about the comparison of the state before and after this update (v186), we are sharing some data in following text. The testing have been performed using following setting: High (16GB DDR4, GTX 1070: 8 GB VRAM, 1080p). The pictures on left represent v185 (previous build), the pictures on right represent v186 (newset/current build).

Easy Start Earth:

v185 committed memory: 8,9 GB
v186 committed memory: 9,2 GB

v185 sim speed: 1.00
v186 sim speed: 1.00

v185 FPS: 75
v186 FPS: 90
Easy Start Earth; v185 - v186

Easy Start Space:

v185 committed memory: 6,6 GB
v186 committed memory: 6,8 GB

v185 sim speed: 1.00
v186 sim speed: 1.00

v185 FPS: 120
v186 FPS: 120
Easy Start Space; v185 - v186

Star System:

v185 committed memory: 6,1 GB
v186 committed memory: 5,6 GB

v185 sim speed: 1.00
v186 sim speed: 1.00

v185 FPS: 83
v186 FPS: 120
Star System; v185 - v186

Empty World:

v185 committed memory: 5,2 GB
v186 committed memory: 5,8 GB

v185 sim speed: 1.00
v186 sim speed: 1.02

v185 FPS: 120
v186 FPS: 120

Empty World; v185 - v186

Our community

To express our value of our community and players we added a Welcome screen for everyone  who runs Space Engineers for the first time. There is a message directly from me.

Quotes and reactions from our community: 

“It feels so good to be able to drive around a crater on the moon and have the wheels actually work over hills, and get realistic suspension response. Not only that, but you don't have to fear clang when you catch some air.” - Phoenix84

“If you're KEEN on some hot new deals, come look at our shiny new wheels” - NikolasMarch

“The new suspension wheels are great, just don't try to jump to the moon. For your own safety and sanity don't try jumping with a trailer attached.” - GrindyGears

“I'm not the most advanced vehicle builder out there, but it was such a pleasure to finally be able to make a truck and have it just work as I'd expect it to. Now I need to learn not to drive my vehicle into a ditch.” - Malware

“No longer being shackled to flat plains and slight hills I have been able to explore and discover new locations that were previously unreachable if you were stuck on the ground”- DoctorOctonagopus

Questions and Answers

Does this mean you've polished all visuals, fixed all the bugs, optimized every use-case and the game is finished?
A: Not just yet. We have made very good progress in the last couple of months, but there is still more to come! Stay tuned for more updates!

Q: I liked the visuals from before this update
A: We are upholding the original visuals from the Space Engineers launch, circa 2013. These new visuals are just pushing it more towards triple-A quality where the game belongs.

Q: Are these new visuals taking up more performance? Did the game become slower?
A: No. There were actually performance improvements during this visual update. On top of that, our QA (quality assurance) process is doing both manual and automated comparison of the game performance in selected scenes. We would know if the performance gets slower (CPU, GPU, memory).

Q: I really hate the bloom / vignette / flares / chromatic aberration etc. Can I disable them?
A: Yes. There are options in the Graphics settings screen called "Enable PostProcessing" that let you decrease flares intensity or disable post processing effects like bloom etc.

Q: I want to disable eye adaptation / have more saturated colors / have darker shadows. Can I mod the game’s look?
A: Yes. All settings are data-driven. You can tweak the settings in the Environment.sbc file and upload it as a mod to share it with other players! You can even use debug build from MOD SDK to tweak the settings in real-time through debug screens.

Q: I am used to the old blueish skybox. Can I have it back?
A: Not in vanilla steam game as the current skybox is part of the game’s original vision. But you can use custom skyboxes through workshop as a mod. We released old blueish skybox to workshop as well: http://steamcommunity.com/sharedfiles/filedetails/?id=1286315367

Q: Can nVidia owners  use Ansel to cheat in multiplayer? (i.e. observe interiors of my base)
A: No, we implemented similar restrictions as to spectator camera. When spectator camera is disabled, you won’t be able to move with camera in Ansel. But you can still acquire Ansel captures from anywhere you get to with your character.


If you have any questions or requests, please do not hesitate to contact us, we will do our best to solve your problems.

We would be also very happy if you can submit your feedback at our Space Engineers Steam store page and encourage us to do better. We welcome both positive or negative comments, it helps us to create better game for you!


I am super happy with the work our team has done and super excited to share it with you all!

Space Engineers now looks and feels the way we have always envisioned.

As Space Engineers is still under major development, there may be bugs (our testers spent hundreds of hours testing, but this is nothing compared to tens of thousands of hours played by our community immediately after every update). Nevertheless, we will do everything we can to fix any issue as fast as possible.

I truly enjoyed working on this update, it took a lot of hard work and determination, the whole process consisted of over 600 tickets (work tasks) for me and my team! It has been been my main priority over the last few months and the whole process been an absolute pleasure.

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

Thank you for reading and we look forward to hearing your feedback on this update. For full list of new features and improvements continue to https://forum.keenswh.com/threads/7399609

Marek Rosa
CEO, Founder Keen Software House
CEO, CTO, Founder GoodAI

For more news:

Space Engineers: www.SpaceEngineersGame.com
Medieval Engineers: www.MedievalEngineers.com
General AI Challenge: www.General-AI-Challenge.org
AI Roadmap Institute: www.RoadmapInstitute.org
GoodAI: www.GoodAI.com
Keen Software House: www.keenswh.com

Personal bio:

Marek Rosa is the CEO and CTO of GoodAI, a general artificial intelligence R&D company, and the CEO and founder of Keen Software House, an independent game development studio best known for their best-seller Space Engineers (2.4mil+ copies sold). Both companies are based in Prague, Czech Republic. 

Marek has been interested in artificial intelligence since childhood. He started his career as a programmer but later transitioned to a leadership role. After the success of the Keen Software House titles, Marek was able to personally fund GoodAI, his new general AI research company building human-level artificial intelligence, with $10mil. 

GoodAI started in January 2014 and has grown to an international team of 20 researchers. 

At this time, Marek is developing both Space Engineers and Medieval Engineers as well as daily research and development on recursive self-improvement based general AI architecture.