Sponsored By

Featured Blog | This community-written post highlights the best of what the game industry has to offer. Read more like it on the Game Developer Blogs.

Learning from Failure: Post Mortem of an Unborn

Should I cancel or not a game development? If this question pops up in your mind it's a signal. Something is not going as you would like. In this article we explain our own experience cancelling our first big project. And the reasons behind the decision.

Javier Ansoleaga, Blogger

November 9, 2016

6 Min Read

                               The Swarm canceled

After a long period of silence we have decided it’s time for us to explain what happened since our last public communication regarding The Swarm, 9 months ago, and write a quick “Post Mortem”.

So first of all, TLDR: We’ve decided to cancel our last project, The Swarm, after roughly 6 months in development. Because we realized we didn’t have the resources the game was needing to be completed the way we wanted. Nonetheless we haven’t been idle all these months. We have been working on a new project we are very confident with, and we can’t wait to tell you all about it as soon as possible!

For those who are interested, we would like to tell you what happened along the way.

Design instability and Scope Creep

We started the development of The Swarm about a year ago. After roughly 3 months of pre-production we felt like we had something interesting, so we went full throttle and started development. We did our maths and initially planned for 1 year of development. Yeah, I know, you never plan long enough… Of course, after all, we are a little indie team trying to find our place in this industry. And as so, learning most of the time through trial and error along the way.

Early Prototype Mockup

The first signs of trouble came in the Design side, shortly after approving the initial prototype. Since the beginning we went through an iterative process with some of the main mechanics. We were feeling it was a normal process, because we all know video games evolve through development… It felt natural, we were changing mechanics and aspects of the game for the better. Most of the changes were implemented because we were convinced of them. Knowing the overall picture of the game was needing it in order to be what we wanted it to be.

It went this way for 3-4 months, until we started realizing we were far away from the initial concept for the game. A lot of little, not so evident, changes during an extended period of time made it difficult to spot the problem earlier. Which was not the fact the game changed, because it changed for the better. It was a richer and more coherent game overall. The actual problem was that along with cool new systems and features also the scope was modified, without us realizing. It basically grew out of bounds.

Summarizing, we had a better game overall. One we were really proud of. It was deep, innovative and, finally, with a strong working core. Just it was for a team double our size and doubled development time. None of which the team at that time was able to afford.

This was already causing us some headaches, but the final stroke came just when we realized about this.

Team fragmentation

I think there is no need to go in detail on how difficult or tough is to raise an indie studio from nothing, the internet is filled with plenty of good articles on the topic. But we did hit a bump or two along the road worth mentioning in case our failures help someone.

One of the main difficulties indie devs have while starting out is (from my experience and what some fellow devs have told me here, in Spain) to keep a compromised team during the whole development process. (without a dedicated HR person finding new talent and running interviews it’s quite time consuming and slows down the development).

On top of that it’s not strange for young, new teams to lack financial support, running on personal savings or having a part time job to pay the bills. So we sometimes depend on just pure passion and motivation to keep the team engaged. And sadly, it’s not always enough.

This was part of what happened to us. At some point we lost 2 out of 4 members, sadly due to economical or personal troubles. Which in fact set us back and made an already complicated development seem like an impossible task. Immediately we had a “crisis meeting” to decide what would be our next step.

Luckily we were both still crazy in love with our little studio and determined to accomplish our objective. We wanted to keep on going no matter what. So we decided to put all our efforts on building a new team and starting over. It was going to be new team, new office (or basement, depending on the point of view) and new project anyways.

The Swarm Gameplay Mockup

Conclusion & some tips

After some time of work in the “restart” process we ended up regretting nothing about our decision of canceling The Swarm. We think it was a good one, and today we can proudly say it all went fine for us and we are back in track with new team and new project, it was a throwback at least in timing, that’s true. But we kept all the lessons we learned along the way and that was a priceless reward, we learned a lot!
Looking in retrospective, I think it was a good move because I’m of the opinion that it’s always better to cancel a project when you realize it’s not gonna work, than keep pouring hours and effort into a zombie project, a project you know ahead it’s not going to work as well as you want.

At the end every single mistake we did while developing The Swarm has been a valuable gain developing our new project, saving us lots of headaches and time in the long run.

To summarize some tips in case it helps someone:

  • Be sure to define your core design principles, test them in a prototype a thousand times and, if they work, stick to them to have a good foundation ground to start from.

  • Don’t be afraid on changing aspects of the design, we still think it has to evolve along the way. Just be sure every change you do keeps the project between scope. And if the change you’re doing doesn’t help to better define or improve one of your core design principles in some way maybe it’s not worth it.

  • People comes and goes, try to have a backup plan in case you lose some team members, so you can minimize the negative impact in the development.

  • From my experience and in my humble opinion, if you’re building a team with a lack of financial support your most important resource is long-term commitment. So be sure you prioritize it above other qualities when looking for candidates. Think about it, you may hire an awesome coder with experience and  awesome skills, but in the long run if he goes away that extra skills are worth little compared to the time and effort you’re gonna spend in finding a new candidate.

I hope our failures can help anyone starting out as much as it helped ourselves.
Stay tuned as we’re almost ready to let you know the first details of our new project. And we’re so excited to do so. And so happy with the fact it’s working as we expected and we’re still so confident in it, even more than when we started it 6 months ago

The Evolve Games team.

Read more about:

Featured Blogs
Daily news, dev blogs, and stories from Game Developer straight to your inbox

You May Also Like