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.
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.
Looking at the Space Engineers today, we have three main challenges:
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.
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.
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.
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.
We are also active on Discord and our social medial, so we gather as much feedback as possible.
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.
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.
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 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.
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.
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.
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.
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.
Thank you for reading and we look forward to hearing your feedback.
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
Keen Software House: www.keenswh.com
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.