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.
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
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
|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
|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|
|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”)|
|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.
Like us on Facebook https://www.facebook.com/SpaceEngineers or follow us on
Twitter https://twitter.com/SpaceEngineersG and you will be notified on all updates.
Warning: Space Engineers is still in development. Everything in the game is subject to change.