"Need to create" - Builder, accelerationist, and Founder/CEO at KeenSWH.com and GoodAI.com - Working on AI People and LTM, Space Engineers, VRAGE3 engine and Resilient Civilization
Some of you were asking how many copies of Space Engineers were
already sold. We just crossed “the magical number” and I want to share it with
you: over100,000 players have purchased Space Engineersin its first 3 weeks.
It is a big pleasure to see how the community has accepted
the game and how you are helping to make it one of the best sandbox games.
Thank you for your support and we are looking forward to the
following updates that are about to come.
---
Like us on Facebook
or follow us on Twitter
and you will be notified on all updates.
Warning: Space Engineers is still in
development. Everything in the game is
subject to change.
It is one week since we launched Space Engineers on Steam Early Access, a time for some recapitulation.
On Friday we managed to do our first post-launch update – adding the Workshop integration, some small improvements and new languages.
However, the most important story of the last seven days is the response of the players. We expected that the players will start creating works, but not in this amount and quality. There’s so much creativity in you. One week and there’s already more content than we can actually observe. We have seen awesome things that we would never expect players to create.
Every day we see so many surprising creations – it’s amazing: the best thing on Space Engineers is its Community.
These are currently our most favorite internet places:
Then there are various suggestion & idea threads that we try to read, to get a better understanding of what the players want.
We plan to keep making frequent updates for small improvements – every week or two. Larger updates will come less frequently, please be patient.
After all that has happened in the last week, we are now 100% sure that the idea of Space Engineers is good, viable and has high potential. We are going to expand our team – just a little, we still want a small and effective team – a sandbox game such as Space Engineers requires this type of development.
A quick summary of the development during the last two months: September and October 2013.
“Early access” to the Early Access
A week ago we realized that Space Engineers is in a good shape and so we decided to make it available for purchase during two 3-hour and 24-hour windows. This allowed us to make some people happy and to perform a large scale testing.
We were very surprised and pleased by the response of the players. Not only the interest was 10x bigger than what we hoped for, but also the community “got the game” surprisingly quick and started to create amazing works and post screenshots and videos. The response was really great. You can’t see this from the outside but I can assure you that the already good morale of our team has increased 10 times.
The other positive outcome was the feedback that we started to receive. It appears that 95% of the community suggestions are already in some form in our project plan. This is a good sign because it means that our taste is very similar to what our community wants.
What’s next
We are preparing the integration of Steam Workshop. I hope it will be available within a few days after Oct 23.
Then we want to look on the max speed of the jet-packs (probably just a temporary hack since we want to do it properly later and with regard to “realism”). We also did some tricks to increase memory limits (also, just a temporary solution).
There are tens of other features that are in progress – the most important is multi-player. We have an internal deadline when we want to release it, unfortunately this is a big and hard-to-estimate feature, so I don’t want to disappoint you if something gets in our way.
Of course, then there’s the manual building, inventory, drilling and harvesting – all is done, we just have to un-disable it, test it, polish it and give it to you.
Localization
We have set up a crowd-localization project and during the weekend the community managed to translate 8 languages, while 10 more are in good progress. It’s very likely that we will add most of them to the release on October 23. Thank you very much!
We didn’t have a “full game” optimization phase but we already performed tens of intermediary and very specific optimizations. Mostly during implementing a new feature - we knew that some algorithm will be performance or memory demanding and so we didn’t waste time naively with a brute-force approach. Instead we implemented it with optimization in mind. Sometimes it’s better to implement a new feature already optimized than to postpone it and do it later (when you have forgotten most of the details already).
The players say that they were expecting the game to run poorly but instead it runs very well. This makes us programmers very happy.
Anyway, there are many opportunities for more optimizations in the future.
Testing
October 1 was the “feature freeze day” (we stopped adding new features and worked only on the important polishing and bug fixing tasks). From that moment on, we focused entirely on making sure that the game is stable and bug free and that Oct 23 won’t be a fiasco.
Testers created a list of testing scenarios: various HW and OS configurations (Windows XP, Vista, 7, 8, 32-bit/64-bit, different language packs), alt-tab, sleep or hibernate computer while game is running, CPU from Intel and AMD, GPU from NVIDIA, ATI, Intel, multi-monitor settings, load tests, game-play tests, etc.
We also ordered some testing at a HW lab – www.quanticlab.com – where they performed tests on even more HW configurations. I can only praise these guys, great professionals.
During this phase, we caught many HW incompatibilities and so I am glad we did it. If we were testing this on the players, it would be a shame.
BTW, we have an “automatic testing tool” for Space Engineers – we capture mouse and keyboard events while doing something in the game and then we can replay it automatically. This allows us to automate “boring” moments of testing.
Thanks
I want to thank each and every one of my colleagues, without them we couldn’t get Space Engineers to the stage it is now. Together, we were able to meet all milestones on time and with the expected quality.
I also want to thank our growing communitywhich provides great feedback and gives us more reasons to continue making Space Engineers what it deserves to be.
We can’t reply to every comment, but I can assure you that we read all of them and they will influence how Space Engineers develops. Corrections: actually, after the explosion of interest it’s very hard to keep track of all comments :-)
---
Thanks for reading this!
Like us on Facebook or follow us on Twitter and you will be notified on all updates.
Warning: Space Engineers is still in development. Everything in the game is subject to change.
I was looking forward to this movie since I read about it years ago. It was better than I expected. Gravity is a great technical, visual and audio experience! Some of us are so thrilled that we are going for a second rep with colleagues who couldn’t join us the first time.
The film’s title is Gravity, but it’s actually about the absence of gravity in space. It shows how even the simplest moves can become impossible if you lose a steady ground.
The authors adhered to the laws of physics, avoided fantasy elements and story-shortcuts and created a compelling and believable story.
For example, there’s no sound in space. And so in this film the only sounds you can hear is radio communication, the heartbeat and vibrations on the astronaut’s body. If something happens outside of the astronaut’s suit and she isn’t touching that surface, we don’t hear that sound because vibrations can’t transfer. The lack of sound effects would decrease the emotional energy of the film and so they “fixed it” by having music score that resembles those sounds.
The film opens with a continuous shot that lasts 17-minutes, without cinematic cuts. The camera flies through space, spins around the actors, zooms in and out and there’s no single cut. The whole film has only 156 shots. I truly admire this type of craftsmanship. The process they achieved is interesting as well: an actor was strapped inside a 6 meter tall box that had 4096 LEDs on its sides, where simulated scenery and lighting was projected. A computer-controlled camera was the only element that moved inside this box and did all those fly-bys.
I have never seen a camera transition from third-person to first-person with such smoothness. There’s one scene where the camera gets close to the astronaut helmet, enters the helmet, turns around so we can watch from the astronaut’s point of view, then we see the HUD on her helmet, we see her face and all emotions she is experiencing, then the camera spins again and flies away. Amazing!
You can see part of it in this trailer:
Real astronauts were impressed by the film as well. Buzz Aldrin (the second person to walk on the Moon) says: "Going through the space station was done just the way that I've seen people do it in reality". Mr. Aldrin has noted one defect: "This movie gave great clarity to looking down and seeing the features of Earth … but there weren't enough clouds, and maybe there was too precise a delineation from space".
Here is an article if you want to read a more elaborate analysis of what’s right and wrong on Gravity:
I recommend watching this film in IMAX. Not just because of the 3D, but also for the big screen and excellent acoustics. You will feel like you are there, in space with zero gravity.
Gravity seems to be a commercial success as well, grossing $82mil in the opening weekend. I am glad that people like these types of films.
Go see Gravity while they screen it in IMAX and let me know how you liked it.
Answers to Space Engineers related questions posted on our Facebook page and our forum.
Will there be early access to the game?
Steam Early Access date will be announced during the first week of October 2013.
How does building work?
We have two building modes: creative and manual
Creative mode is what you can see in this video http://www.youtube.com/watch?v=75GGK5NMkMk.You have unlimited resources, adding and removing blocks is instant, you can build at large distances, you can add/remove multiple blocks by holding Ctrl key, your space suit energy doesn’t deplete and reactors have infinite fuel. Creative mode building is possible only when your world runs in creative mode (this can be switched on/off in world settings).
Manual mode is what you have seen in the alpha video http://www.youtube.com/watch?v=R3b9e_KWO-I. This is the “realistic” building mode. To build a block, you first install its frame and then finish the construction in several stages. The components required for the construction are supplied from your backpack and are installed layer by layer (like an onion). For example, to build a door you need 40x construction components (screws), 4x metal grid, 10x interior plate, 8x steel plate, 4x small tube, 2x motor, 1x display and 2x computer. Disassembling works in the opposite way; dismounted components go to your backpack.
The topmost layer is usually a steel plate – if there’s a hypothetical situation when an attacker wants to get to computers in a door module, he has to get through steel layers first and only then he can gain access to the computer layer.
The welder is the hand tool used for assembling and repairing. The grinder is used for disassembling. Damaged layers can be repaired by replacing components in those layers (e.g. if a turret is damaged and its integrity decreases to 80%, you most likely have to only replace the first few layers of steel plate).
We already implemented both modes. The creative mode is 100% functional and will be available on day one. The manual mode is 99% finished but we still haven’t tested it as much as we need to and most probably it will be disabled during the first few weeks of Early Access (otherwise people would try to use it, get into confusing situations, get upset, etc.)
How do you create an object?
Press “G” key - open “Toolbar Config” screen
Click one of the buttons: “New small ship” or “New large ship” or “New station”
A new object will be inserted in the empty space right in front of you
This new object contains one armor block only
You can start attaching additional blocks to it (cockpit, reactor, thrusters, gyro, etc.)
Features?
Prior to Early Access launch, we plan to publish a list of features, split into three categories:
Finished features – those that can be considered final (at least during the whole alpha phase)
Work in progress – they work well, but are not perfect yet
Τemporary disabled – features that are work in progress but not in presentable state, have known bugs, were not tested enough or don’t have intuitive interface
We will release a walk-through video, showing the state of Space Engineers on day one of Early Access. People who are willing to purchase the game will see what they are getting.
At this moment, the core of the game lies in the creative mode building, physics simulation and destruction. These are the features that must work on day one. Everything else can wait.
In this blog-post I will describe the solutions we considered and tried in Space Engineers regarding artificial gravity, I will reveal the one we finally chose and explain how close to realism it is.
Warning: Space Engineers is still in development. Everything in the game is subject to change.
Why do we need gravity in Space Engineers?
Humans need gravity to avoid adverse health effects of weightlessness during long-term space travel and habitation. Natural movement such as running and jumping requires Earth-like gravity as well.
A game with no gravity (player moves only by jetpack) offers limited experience. Furthermore, the construction constraints that are imposed on players building space stations in a gravity-enabled environment are vastly different from a situation where gravity isn’t possible.
Scientifically correct solutions
These are the scientifically correct methods for producing artificial gravity. Unfortunately, none is suitable for our game.
Rotation (centrifugal force) – generated by a large rotating ring (example: “2001: A Space Odyssey”). The gravity felt by the objects is simply the reaction force of the object on the hull reacting to the centripetal force of the hull on the object. This method wouldn’t work on static asteroids and it’s too impractical for our game. Although, this method may become available if we decide to implement the “rotating motor module”.
Linear acceleration – when a spacecraft accelerates in a straight line, it is forcing objects inside the spacecraft in the opposite direction, thus providing g-force. Gravity would be present only during the acceleration and deceleration. This method is impractical as well and is not “player friendly”.
Mass – this is in fact the natural gravity. To create Earth-like gravity, you would need an object of equal mass (not necessary size). Asteroids don’t have enough mass to generate noticeable gravity and can be discarded as a gravity source.
Magnetism - similar effect to gravity has been created through diamagnetism. It requires magnets with extremely powerful magnetic fields; yet it required a magnet and system that weighed thousands of kilograms, was kept superconductive with expensive cryogenics, and required megawatts of power. With such extremely strong magnetic fields, safety for use by humans is unclear.
Solutions we tried and discarded
Magnetic boots – those would allow an astronaut to attach himself to the ferrous floor or hull and walk. This must not be confused with artificial gravity, as the person would still perceive weightlessness. Running, jumping and advanced movement wouldn’t be possible. Boots wouldn’t work on an asteroid surface and the astronaut would get pulled down only if there’s a surface under his feet - if he steps out of a platform and the closest surface is meters below him, nothing would pull him down and he would just float in space. He wouldn’t fall.
Spherical gravitational field – a hypothetical gravity generator that would exert an attractive force on all objects in its proximity, equally in all directions. In other words, objects would fall towards the generator’s center. This is how it works on Earth – every object falls to Earth’s center. We tried this method and it’s not suitable for small surfaces found on mother ships. It would require a very large surface to neglect the radial nature of this type of gravitational field. Imagine this: you move on a flat surface and a gravity generator is somewhere below you. The gravity force pulls you to the generator’s center and this vector keeps changing as you move on that flat surface.
Artificial gravity in Space Engineers
We had to accept the fact that there are no feasible solutions for producing artificial gravity. Therefore, the direction we followed is shaped by the requirement of intuitive game-play and not by our drive for realism.
Gravity generators are modules that consume energy and produce unidirectional gravitational force – a vector that’s parallel to the generator’s main axis. Let’s put it this way – a gravity generator installed on a platform will pull down all objects above and below this platform.
A gravity generator has an effective radius of 150 meters. Gravity forces from multiple overlaying gravity generators aggregate.
Gravity generators don’t have mass proportional to their gravitational force, as this would require extremely powerful thrusters to move a ship if it had gravity generators installed.
The purpose of this screenshot is to show how gravity generators
aggregate their force. There are five gravity generators; green lines
demonstrate the direction of pull/fall. Notice the gravity indicator in
the right-bottom corner: grey lines show all gravity vectors and the
white line shows the final aggregated gravity.
The HUD indicator tells you that there’s no gravity source near you.
Actual limitations in Space Engineers
Gravity affects astronauts and small objects only.
Gravity doesn’t affect asteroids, small and large ships, static objects and astronauts who have jetpacks on.
We plan to reevaluate this model and enable gravity on more types of objects. Right now we have to stick with this. Also, in the future we should redo how gravity influences character animation (running and jumping in high gravity environment, running in multi-gravity environment with vectors changing each step, climbing on a ladder heads-down, etc.)
Since our implementation of gravity is not natural (we are breaking the laws of physics here), some obscure situations have emerged and we have to solve them carefully before we enable gravity on every type of object:
Imagine a scene with two mother ships, each one having its own gravity generator. The problems occur once the gravity generator on the first ship starts pulling the second ship, and the gravity generator on the second ship starts pulling the first ship. The ships get in contact and one ship will push (not pull) the other. It’s funny that sci-fi movies don’t consider this effect; probably nobody ever tried to simulate it.
Imagine operating a jetpack in gravity-enabled environment, especially if there’s no certain way to tell where’s up and down and there can be potentially multiple gravity fields
Imagine piloting a small ship in a field of multiple arbitrarily oriented gravity fields
Conclusion
It’s interesting that our universe is configured precisely the way it is. One slight deviation to the algorithms and constants that regulate it and things don’t work anymore.
Trying to replicate the reality – when developing a sandbox game – proved to be useful. No need to reinvent the wheel; nature already did its job.
I am going to describe the decisions that led to this project and some details from its development.
Space Engineers is in alpha stage of development - the core gameplay is almost finished (constructing modular grid-like objects in manual and creative mode, volumetric physics, piloting ships, character animations, deformable and destructible objects, electricity, reactors, thrusters, artificial gravity, etc.), some art assets are still placeholders and there are no sound effects. It’s still a “work in progress”, far from “feature complete”.
I could say that the idea of Space Engineers emerged as a logical extension to what we started in Miner Wars - but it’s actually much older. Ten years ago, I wanted to make a game that would be like a computer version of “LEGO TECHNIC” (volumetric objects made of modules interconnected in a grid, with real physical properties and interactions).
Miner Wars 2081 was our first shot and it only touched this idea. Space Engineers is our second attempt and I believe we are going in the right direction.
After finishing Miner Wars 2081, we could have proceeded with a sequel or an MMO, but we felt that first we need to focus on construction and sandbox mechanics, integrate them into our VRAGE engine, build a game that represents them in a best possible way - “Space Engineers” and then reuse them in our future games: a sequel to Miner Wars 2081, an MMO or something else.
In Space Engineers, every object is made of block-modules interconnected in a grid. Every module is a real entity with volume. Depending on the purpose of a module, it can have storage capacity, electricity consumption or production, etc. If you want your lights to operate, better connect them to a grid so they can receive power from a nuclear reactor, which needs uranium to keep running. If you interrupt the grid, the power is lost. If you overload the grid, some consumers get shut down.
Space Engineers is inspired by reality and is played in an environment that can be completely altered by the player. No fake buildings with empty interiors. No fake doors leading to nowhere. No lights, computers or thrusters receiving power from some abstract source. No inventory located “somewhere” in the ship. Everything in the game has some use. There are no "decorative" assets.
Design and development of Space Engineers is guided by our pursuit for realism. Every design decision is shaped by questions such as “how would this thing work in real life?”, “is this technology feasible in the 21st century by extrapolating our current knowledge?”, “what would NASA do?” etc. Not making design-shortcuts proved to be useful and I can say that “the reality is the best designer”.
The foundation of this new technology is a modular grid with real-time deformation and destruction physics. The development of breaking physics took us about a month of work, but it was worth it. It would feel weird if you could build a mother ship, crash it into an asteroid and have it just bounce away. Now it will deform blocks in collision and if damage reaches a certain point, destroy them completely. The video above shows how this works.
On a side note, the modular system is an interesting idea for real space stations and space ships and perhaps if future space engineers have enough resources and 3D printers, they will use it :-)
Another significant difference to Miner Wars and our original plans is that we added character animations. The player is no longer “a ship”. This change adds new gameplay possibilities.
The art style of Space Engineers isn’t finished yet (many models are still just placeholders), but I am already satisfied with the way it’s going - simple colors, low frequency textures with little noise and clutter, current-era look and no flashy, “too sci-fi” surfaces. The “stripe pattern” design that we use when constructing ships was an idea that emerged from the block-nature of how ship construction works and also by the “tourist signs” we have in forests here, in Czech Republic. I am not yet satisfied with how boxy the small ships appear; we may redesign that in a future iteration.
We started working on Space Engineers in April 2013, right after we finished with our post-release works on Miner Wars 2081. I am writing these lines in August 2013 – so that’s 5 months of development. Not including me and a few other people, the major portion of Space Engineers alpha was carried out by 3 programmers and 1 artist. No overtimes and no crunch periods. I am amazed by what my colleagues achieved and I’m very proud of them.
If you want to see some actual game-play, watch these three unofficial teasers that we released in August):
I want to show you the process of story writing, mission designing, voice-over recording / post-processing, game-play polishing and testing during the development of Miner Wars 2081.
Spoiler alert: following chapters reveal the story.
Decisions
When I started to work on the story of Miner Wars a few years ago, I decided to proceed with the following order:
First, I wanted to decide on the main features, the game mechanics and the technical constraints – in this case it was the destructible environment (voxel asteroids) and space ship combat in open space.
Then I chose the main characters, their attributes, relationships, motivations and goals. In this case, it was Marcus and Apollo – two miners and space engineers who also happened to be brothers, high-achievers and mature personalities. I wanted them to be thrown into a situation where they have to fight against many, with little chance to win.
Then I looked on the concept of the game’s universe: a year when the story takes place (2081), what has happened before the player got involved (world history between 2012 and 2081), why is the world in the state that it is now (warring factions in space, asteroid belts with no planets, etc.)
Then I wrote a detailed list of game features, mechanics, mission types and art assets. I did it because I knew that when we start working on actual missions, we will have a list to pick from, and we won’t get into a situation when the mission requires a feature that hasn’t been planned and there’s no spare developer to implement it.
I wanted to have a game universe built (based) on realistic foundations – if we give factions and characters a reasonable motivation, they would start interacting like in the real world. If we begin in the year 2012 and “simulate” how and why would things progress to where we wanted them, we would build a believable world with authentic characters and be able to avoid tricks such as in “Deus ex machina” or “Creative license”.
The Story
Player and his brother Marcus are on a routine mining operation when suddenly they are attacked by a Russian commando. After fighting back, they discover that Russians came, searching for a secret. The player follows this lead and later finds out that the Russians were looking for something they considered to be an alien artifact.
Player realizes that this could be the biggest discovery in mankind’s history and he tries to get his hands on the artifact first. He travels through the solar system, makes friends and enemies and tries to get closer to the source.
In one moment he and his brother get ambushed by their own faction and Marcus is supposedly killed. As the story progresses, the player finds out that his brother survived and is held in a prison. Apollo understands that he needs help with the rescue mission and he allies with the Fourth Reich faction (whose generals are held at that prison as well). After a successful rescue, the brothers continue their quest for the artifact and at the very end they find a massive but abandoned structure, remotely evoking a gate - The Alien Gate.
That’s where the story of Miner Wars 2081 ends.
Intro video:
We created an encyclopedia where we describe the game’s world, characters, factions and the history: http://wiki.minerwars.com/
Story-writing
I like fast-paced action games, where things happen quickly and I have to push forward. I also like when high-intense moments alternate with low-intense moments (2 minute fight, 2 minute traveling, 2 minute fight, etc.). Nice example is Left 4 Dead and Call of Duty.
While developing the prototype missions of Miner Wars, we had observed that if the environment and action (or absence of action) doesn’t change for a prolonged time, it gets boring. That’s why we wanted the player to move from place to place with sudden and fast changes in mission objectives, especially, if the visual atmosphere changes as well (icy blue sectors, red Mars sectors, yellow near-Sun sectors, etc.).
Missions and story were designed in a modular fashion, which means that we could insert a mission between two other missions, shift missions, and the story would still make sense (although, there were limits). The reason was, that for a long time we were not certain what should be the length of the missions and the game and which missions work best. At the end, only few prototype missions got discarded and the final game is composed of 31 missions, each one lasting 30-60 minutes, so that they would make 15-30 hours of gameplay.
The main characters are Apollo (the player) and his older brother Marcus. The third one in their party is Madelyn, who pilots their mother ship and helps from distance. There are also a few more main characters that appear in the story from time to time. We didn’t want to include too many main characters, which may confuse the players and they would not form an attachment with them. There are much more secondary characters, various radio operators, generals, soldiers, enemies who come and go and we didn’t feel a need to build up their presence.
We wanted the player to build a relationship with his brother Marcus - to like him, care about him, respect him, and so when he loses him in the middle of the story, he feels a real loss. So later when he goes to rescue him, he has a real reason. Imagine if we let the brother get captured in the beginning, the player wouldn’t build the emotional bond and he wouldn’t care about the rescue. Moreover, I think that Marcus has a great voice and he is a good character. You would want him to be your older bro.
The story presents many “cliffhanger” moments, always keeps an open mystery, a question or a secret. This motivates player to continue. The whole story ends with a big cliffhanger (which is supposed to continue in the sequel).
The disadvantage of a space ship simulator where the player doesn’t leave his ship is that all communication must be made over the radio. We could convey the story and emotions only through the dialogues (no body language). The other disadvantage is that the player doesn’t see any object he knows from real life (car, house, tree, etc.) – so he can’t perceive the scale of objects. Space buildings seem too small, ships too large, etc.
Dialogue is a good tool for introducing the characters (moods, opinions, goals) and for describing the world and the history. In my opinion, you need to be very careful with the length of each dialogue (too long and it’s boring , too short and it has no purpose) – try to think of it as having a “word budget” and now it’s up to you to decide how are you going to use it.
One helpful advice is to finish your text, put it away, go back and reduce it by 20%, put it away, go back and reduce another 20%. Personally, I prefer movies with fast and brief dialogues, avoiding unnecessary parts. Other way of thinking about this is to look on your text and ask yourself: if I remove this part, is it going to impair the story? If the answer is no, better remove it.
We wanted to present the story as an integral part of the gameplay. We didn’t want intro-sequences and cut scenes that take the control from the player and he has to passively watch. In other words, the story plays around you as you go through the missions.
There’s one trick that we used for very long dialogues – they start when the player is traveling through remote places. He has nothing better to do than pilot his ship and listen. It’s very non-intrusive story-telling.
The result was 31 individual mission scripts, formatted in standard film industry screenplay style. Here’s a snapshot from the “Laika” mission:
Survival Gameplay
We wanted the player to feel a hard-core space survival experience– e.g. having to look after the consumption of his supplies, oxygen, fuel, ammo. I like this style; it feels more challenging when a wrong move leads to unexpected and brutal consequences.
Tutorial
I didn’t want to include a tutorial mission, I don’t enjoy them in other games and I try to skip them if possible. Tutorials just hold me from the real action and, in most cases, are boring and “force” me to learn the same skills over and over.
What I prefer is to learn the game while playing it, step by step. We implemented some on-screen hints, player sees actions available to him (e.g. “Press SPACE to open door” or “Press T to see GPS path”).
Prototype Missions
Before we started to implement the final missions, we created a set of prototyping missions, just to test a few questions:
Optimal size for a space station / Is a 10 meter tunnel too narrow? Is a 200 meter room too big?
Optimal travel distances – you arrive to a mission and you need to fly to the next objective – is a 1 minute flight in an empty space too boring? Can we enrich it with a dialogue between main characters, so the player will use this time for learning something about the game’s universe?
Optimal number of enemies in a closed and claustrophobic area – one, five, ten?
GPS
Navigating in a 6DOF (six degrees of freedom) environment proved to be non-intuitive. Even we - the developers - keep losing sense of the direction once the ship is turning.
We quickly came to a conclusion, that we need a better way of navigation.
First attempt was based on adding arrow labels in tunnels and stations. This approach had a disadvantage - it was too stationary. If the player had to go back, arrows were still pointing in the original direction and it was confusing.
Second attempt was with dynamic GPS system. It consists of two systems:
Navigation / path-finding – the game can find the shortest path between two arbitrary points. We use this system for AI/bot navigation too.
HUD visualization – after pressing “T”, the game displays an on-screen 3D arrow pointing to the mission objective.
Everyone gets this system on first try, so I guess it was a good idea.
Development
When I plan a project, I triple my estimations and then I try to do the job during the first third of the allocated time. Second third is a reserve for polishing, bug fixing and errors in estimation (in reality, this second third gets always consumed, see “Planning fallacy”). The last third is something I actually don’t want to use: it’s there just as a backup in case that the estimations missed too many details, or if I decide that I want to have more room for a particular feature, or just an unexpected event. In other words, I like having this last third, it keeps my mind in peace and I am not forced to act under stress and do short-sighted decisions.
Of course, the development of Miner Wars didn’t go exactly according to the plan, but in general it followed these milestones:
From the diagram above, you can see:
First 12 months were about developing the basic blocks of engine and game
Last 6 months were about implementing the missions:
First just the rudimentary missions with no dialogues – to test if missions make sense (game play length, traveling distances, difficulty, novelty, fun factor, impact on story, etc.)
Finish the dialogues and integrate them to missions, play again
Record voice-overs, add music themes, play again
(last 3 months were about polishing, bug fixing and last-moment changes)
Level Designing & Mission Scripting
Writing the story and the dialogues was just the first part; second part was the actual implementation: level design and mission scripting (programming).
The Solar system in Miner Wars is split in sectors. Each sector is a cube of 50x50x50km (you can see that there are billions of sectors - of course, most of them are empty). Every mission takes place in a sector, player travels from sector to sector as he progresses into the game.
The sectors were designed in Miner Wars in-game editor and they strictly followed the requirements of the mission script. 70% of the design was about laying out the structures (buildings, hangars, tunnels, mother ships, asteroids) and the remaining 30% was mission specific, various dummy points for mission events, spawn locations for enemies, atmospheric sound effects, etc.
After this was finished, the next stage was scripting – a programmer took the mission script and wrote the code so when the player accomplishes an objective, an event should happen, a path to the next objective got unlocked, a dialogue would progress, etc. This was the place where we implemented special events such as arrival of a group of mother ships, wave attacks, large scale explosions, escaping from the enemy, and so on.
It took 5-10 days to design the sector, then another 5-10 to fully implement the script and then again 5-10 days to polish and bug-fix it. Important part of this job was to play-test the mission and preferably let other team members play to it as well (so things not obvious to the creator can be spotted early).
Voice Over
Miner Wars has approximately 2600 dialogue lines.
First rule of voice-acting is to start working on it only after the missions and the text dialogues are completed. It’s easier to change a dialogue while it’s still a text.
The process:
Casting - chose the right actors who fit the roles. We found our actors via www.voice123.com, where you submit a project, specify if you are looking for a male or female actor, age, accent, and price range, describe what do you want and include part of the script. The best thing about www.voice123.com is that you get access to hundreds of professional voice actors, and you receive 50-100 replies for each role. I believe that a successful audition requires access to as many actors as possible.
Candidate actors sent us their audio demos (based on our script). This helped in picking the right actor, because we could hear if the actor could perform our character in the way that we wanted. We picked a few actors for the main characters (each one had to be unique) and about 10 actors for secondary characters (each actor also did 5-10 secondary characters)
We sent the full script to each actor, set the deadlines and waited
In about two weeks, actors delivered their recordings (I was positively surprised how professional they were and that there were no “misunderstandings” with deadlines and quality)
Most actors usually delivered their whole recording in one file, so we had to split it by lines
We ran every line through audio effects (radio noise, distortion and beeps, background voices and sounds when character speaks in a room full of people or computers, etc.)
We imported it into the game and listened to it again
Occasionally we decided to remove a line here and there, mostly to speed up the pacing
I recommend to be careful with non-English accents (Chinese, Indian, Russian) – if you work with American actors, they may not know these accents very well and it could end up sounding funny and with wrong pronunciations.
Music
In my opinion, music and sounds generate all the emotions in an audio-visual work. Just try to watch a movie trailer with muted speakers.
We decided to have an orchestral Hollywood-ish score, covering the full range of emotions, from victory to sadness to horror and fight. You can listen to the demo here: http://www.youtube.com/watch?v=X9z_GwX4cqI
Music themes switch dynamically – triggered by an in-game event or a mission script. For example, when nothing special is happening, “calm atmosphere” is being played. Once the player gets attacked by an enemy, the theme switches to “light fight” or “heavy fight” – depending on the type and amount of enemies. Once he kills all the enemies, music switches to “victory”. Also, the mission script adjusts the music theme once an important objective gets accomplished, a dialogue gets triggered or a player enters a designated area.
There are few special musical moments in Miner Wars which I enjoy - one of them is the moment when the player attacks the prison and gets to rescue Marcus. The music switches from battle to more emotional “I thought you were dead” theme. I love it!
Multiplayer Co-op
Multiplayer was integrated in a very late stage, just 3-4 months before we shipped the game.
We didn’t have enough time to make significant design changes to missions (to fully utilize cooperative game-play), so we decided that only the player who hosts the game can progress the mission, and others who joined him are just visitors (this means that they can help with the battle, but they can’t advance the mission by accomplishing the objectives).
Balancing, Bug Fixing and Polishing
Three months before the release, we approached “feature freeze” stage – from then on, it was only about polishing and bug-fixing. As we kept approaching the release date, the amount of polishing decreased and we basically did only bug-fixing. Any change brings a risk of causing a new bug and we wanted to minimize it.
During this period, we invited a lot of visitors and let them play our game while we were watching what they were doing, how they play, where they get stuck, how often they die, etc. We didn’t interfere; we didn’t guide them neither helped them. We let them on their own. Each testing session resulted in a report, pointing on problematic spots, which we tried to fix before the next testing session, etc.
Customers who pre-ordered the game had access to beta version of the game, and they provided valuable feedback as well.
Post-release Changes and Fixes
Shortly after the release, we started to integrate customer feedback. We wanted to make our game more approachable. We made a series of small modifications; for example:
Reduced strength of enemies in the first mission
Removed one small-scale enemy attack in the first mission - we have observed that players tend to fly in a wrong direction (not where the mission is supposed to continue, but in the direction where their attackers came from and players were getting killed by a powerful mother ship)
Decreased the overall difficulty (player survives more and it takes less bullets to kill an enemy)
Switched from XNA to DirectX 9 (better stability and more HW control)
Localization
Czech translation was carried out by our Czech-Slovak retail publisher Playman.cz, two months after the release.
Italian translation was a voluntary project by Vito Dipinto and his team of localizers - www.dipintovito.com (Thanks!)
Translation process:
all in-game texts (GUI, help, controls, etc.) and dialogues are stored in a XML file
we export this XML file to Excel and send to translators
hey send us back a translated version
we import it to our game, build a new version of the game and upload it to Steam BETA branch
translators play the game and check for errors - mostly for translated texts that are longer than their original English versions (so they wouldn’t fit into designated area - e.g. buttons)
Translations are available for all customers as an integral part of the game, free of charge.
Questions
If you have any question, please don’t hesitate to send them at info@keenswh.com and I will try to answer in a follow-up blog post.
It’s been a long time since I’ve written a blog post, so you might be wondering what we’ve been up to all this time. Well, we were finishing Miner Wars 2081, which took up most of the team’s focus and energy, along with the post-release bug-fixing period. Then, we worked on the design document for our new project, which, luckily, is now 100% complete, freeing up my time to work on whatever I want, including reflection and future improvements.
This post will serve as a brief summary of the history of Miner Wars 2081, and an analysis of what went right or wrong, what we can learn from it, and what we plan to do in the future.
A little bit of history
2009 – I was single-handedly programming Miner Wars.
2010 – I sourced volunteers and began to look for external funding to speed up development.
2011 – I acquired investors and started hiring a team of regular members, expanding from just a few volunteers.
2012 – Our team finished and released Miner Wars 2081.
What went right?
It only took us 18 months, from the day our investors came onboard, to finish and release the game. Some might argue that the game remains unfinished because it lacks sandbox, but in my view, the game is complete and 18 months was a good performance. Many games don’t even produce a prototype within the same time frame.
Miner Wars 2081 is fun to play - The controls feel good, the graphics are impressive, the characters are interesting, the missions are engaging. The game has a likeable flow to it and I personally enjoy playing it.
Missions and sectors are much richer and more interesting than I envisioned, and more complex than expected.
We actually finished the project - We didn’t end up in a never-ending feature-creep nightmare, we didn’t go over budget, and we didn’t bankrupt ourselves. For me, as a CEO, the latter is a very important point, especially since the financing wasn’t flawless and it was quite tedious trying to find the right people for my team.
We kept our independence - We are still a privately owned indie studio, we don’t depend on money from a publisher or stakeholder, and there’s no middle man between us and the community. Many won’t understand the importance of this or how many compromises had to be made to preserve it, but I believe it’s worth it in the long run.
Music, sound effects, voice over – Although, if we had more time, I would probably re-record some of the non-English characters, I am very satisfied with these elements overall.
We were able to implement multi-player (coop and basic death-match) in just two months.
We have all gained a lot of experience - We now have a better understanding of game development and the business side of things; what works, what doesn’t, and what is a simple waste of our time.
What went wrong?
Open development, communication and sandbox – All three elements are interconnected. During the development period, I was bursting with ideas and plans and didn’t fully consider how much our community was counting on it. My original plan was to make a game that was a combination of campaign and sandbox, but I always saw this as a long-term goal, and wasn’t sure if we could fulfill all of it in the first installment. In the heat of the moment, I overlooked the fact that other people didn’t see it the same way and took sandbox for granted and I failed to communicate that to our loyal fans. Now I realize that I should have placed more emphasis on this point and clarified it with everyone. Some might say that we should have continued until the sandbox was finished, but I am positive that releasing Miner Wars 2081 in its actual state was the right call. Our situation wasn’t as stable as it may have appeared from the outside, and it was better to finish one project and then move on, than to postpone it and risk losing everything. I hope that’s understandable and forgivable.
The final version of the game represents only 70% of my vision (not counting sandbox). What I mean by this is that there are certain things that I would want to be implemented differently, or rather not have them in the game at all. I am assuming that this is what every creative director experiences: you delegate a task, then wait for a first version, consult changes, wait for a second version. This process can continue over several iterations, depending on how effective communication is and how compatible you are with the person who actually carries out the relevant task. Sometimes, it gets to the point where you have to take a step back, compromise, and just see the product to completion. The result may not be 100% what you wanted, but you must move on.
Mission scripts – Admittedly, this was the most defective part of our game, and full of hard to find bugs. Programmers implement a mission script, which is then thoroughly analyzed by a tester in various ways, but there is still a limit to the number of tests possible. When a programmer implements a branch that is rarely run, it will potentially escape testing, so you basically end up shipping untested code. The only solution I’m aware of is to implement only well-tested game components and cover every reasonable scenario. This sounds simple in theory, but in practice it can be challenging for programmers and they can end up missing certain elements.
Bugs even after BETA – It’s disconcerting and regrettable that the game had bugs even after BETA. One possible explanation is that BETA testers assume and expect more problems than a real customer would when they purchase the final product. BETA testers also have better performing computers. For these reasons, BETA testers can report fewer issues than true consumers. The lesson we have learned for future games is to rely more on internal testing.
Always online DRM – In my opinion, this was a harmless “feature” left in the game as a legacy of MMO plans. There was nothing wrong with it; we didn’t hide it and the game didn’t have problems with server outages. Unfortunately, people just don’t like DRM, and we suffered a backlash because of it. A couple of days after the release, this was the most discussed “feature,” even though it was the least important thing we wanted to focus on or discuss. After two months, we removed the requirement to be connected to our servers to play.
What could I have done better?
Slower hiring – I should have raised the bar when hiring new people and evaluated them more thoroughly. Right now, when we look for a new programmer, we would rather not hire anyone than hire the wrong person for the job. We also need to find candidates that fit in with our culture and complement the rest of the team. Anything else is just a waste of time for everyone involved.
Faster firing – There were people on the team who I knew from the beginning were not a good fit for us, but I still gave them multiple opportunities to improve negative behaviors, which never led to significant changes. I should have let them go right away and spared everyone the trouble.
More controlled development – I should have delegated less and had tighter control over development. I know this probably sounds funny to some people who think I’m a control freak, but actually, I think I was too soft on some people, resulting in Miner Wars 2081 not being exactly how I envisioned it.
No hiring of average programmers – They’re simply not able to produce the code we expect. Two average programmers do not equal one great programmer. Even 1,000 average programmers do not equal one great programmer.
What could my team have done better?
Points of information and advice for team members:
Accept responsibility and ownership for your job; don’t blame others when things don’t go as expected.
Communicate your plans with others, don’t make surprise changes, and don’t change stuff that’s already finished.
Always think about how your actions are affecting your colleagues – are you helping or just adding more work? For example, a programmer finishes a task and decides to not test it properly, because he thinks that’s a tester’s job, and then later, the tester discovers it is buggy and unfinished. This creates a snowballing effect that leads to wasted time and inefficiency, when the situation could be avoided if the programmer did his job properly to begin with.
Understand that we - the whole team - are in the same boat. If it sinks, we all go down. There’s no point in avoiding responsibilities.
Conclusion
Some people say that Miner Wars was overly ambitious; I think this is a bad perspective through which to view any project.
I am willing to start an ambitious project, do it with constrained resources, experience discomfort, and risk failure. I know that even if I don’t succeed on the first shot, I can still learn from it, try again, and eventually succeed. As they say: “Aim for the moon. Even if you miss, you may hit a star.”
For those who believe that we falsely advertised, overpromised, or lied: I am most likely not going to change your mind. I am not worried about being hated or despised. I set myself long term goals and I deal with their consequences, both positive and negative. If criticism is the price I have to pay, I have no problem with that; criticism just strengthens me, and nothing will stop my vision.
For those who still feel that my intentions were right: I believe in my vision, and even if it’s going to take longer than I would have liked, I am absolutely certain that one day I will deliver the ultimate space sandbox.
By the way, the development and marketing costs of Miner Wars 2081 were approximately $500,000 and we sold over 50,000 copies – not that bad after all.
What's next?
After we finished Miner Wars 2081, I got back to planning the next item on our agenda. I gave it a lot of thought, considered our strengths and weaknesses, and came to the conclusion that we are going to restart the whole space building and mining idea. But first, we need to build a strong core.
I don’t want to go into much detail about our new project, especially following my previous experiences with promises and such. All I can say right now is:
We are focusing on hard science – every game mechanic must have a rational and valid explanation based on current scientific knowledge. Well, some things are extrapolated, but believable.
Every object in this game has real mass, volume, and physical properties. We try not to cheat the physics.
Sandbox, no campaign.
We will use this game to try to popularize science and space exploration.
This game’s going to be awesome.
If you are curious about what exactly this new project is, and how it is related to Miner Wars 2081 and Miner Wars MMO, please sit tight for a couple of months. We want to provide more information only after we get through the prototyping phase (there’s still a chance we will have to change our design due to technical constraints).
We will stay in touch and keep the community updated.
