Introduction
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.
I recommend reading On Writing by Stephen King; it’s a good guide to writing.
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.
Thank You
Marek Rosa, CEO at Keen Software House
