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.

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.