Miner Wars post mortem
From the blog of Marek Rosa http://blog.marekrosa.org/ thought it was an interesting blog about the game.
Answer a few question about why the game did not turn out as originally proposed.
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.
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.
It is an interesting read. And I do not think it's a bad game.
Well hopefully the lessons they learned from MW will be applied to their new project.
Like to see them go back at some point and do a Miner wars 2 There were some great ideas that never made into the first game.
I look at it that I was in early on this game way before it turned out like it did when it was going to be a sandbox game and I was a bit turned off by the game when they took it the route of Descent instead of keeping it a sandbox exploration style game. I would hope that we see a game like that or least be able to create one with mod tools because they game could be a cult classic with a bit more refinement.
It must be tough sometimes hiring/firing people from your development team since now you have to pose the question whether to strip all that they did out and replace it or repair it. Both of which cause a lot of time and money. Hard to develop on a small budget because those great programmers he speaks of cost money 🙂
I was also in on this as a supporter from the get go. I spent many hours in the early sandbox just drilling/blasting tunnels and flying around. As a fan of Descent and anything w 6DoF, it felt great. I got MW 2081 and played most of it but ended up drifting away before finishing. There was no real hate or disappointment, I was just distracted by other shinier objects. Its a solid game and I have no problem with it. I enjoyed reading this post and can really appreciate the important lessons learned about having the right team in place. Absolutely critical.
Right now my sons and I are heavily into Space Engineers (another Keen House project) as a very fun space sandbox. We've all built some fantastic ships and bases. This early game has a great feel to it. I will have my eye on this one for some time.