Starting up a game business: The First Production

Originally published in Epic Owl's blog: http://blog.epic-owl.com/

As my fifth Epic Owl blog posting I decided to write about something that is very topical for us at this very moment [July 2015]. Our very first game has now been submitted to soft launch in specific markets and while we wait for the metrics, I’m going to describe how we did it, production wise.

Here goes, enjoy!

The Premise

When we started, we knew that we had money to operate for about a year, including the possible public funding we were going to apply for. This meant that our first game couldn’t be a behemoth of 2+ years of development time, we needed to start with something that can be produced from scratch into a full-fledged product within the timeframe of about 9 months. With the planned soft launch period of 3 months, that left us with 6 months of development time for our Minimum Viable Product.

In January 2015 we had the quick prototype ready and the preliminary playtesting suggested that it’s a winner. We needed to start the planning of the production.

Production Phases

The first thing we did was we divided the project to a set of phases, planned their content and their length:

Phase 1: First Playable, 5 weeks

Building of the production environment and developing the first playable version of the game in the production environment.

Phase 2: Pre-Alpha, 4 weeks

We divided the full feature set of the game in two parts. In Pre-Alpha, roughly half of the feature set was to be implemented.

Phase 3: Alpha, 6 weeks

In Alpha the full feature set was to be completed.

Phase 4: Beta, 6 weeks

In Beta we were to develop the rest of the content for the game.

Phase 5: Soft launch preparation, 2 weeks

Final phase before soft launch, in which we were to polish the game for soft launch.

In retrospect it’s easy to see how well the production went. Even though we did have our share of setbacks and changes in the scope and we iterated on many aspects of the game, our soft launch submission date was only 4 days later than what we planned 6 months earlier for it to be.

Sprints

When talking about Scrum, one of the questions to be answered is the question about the length of the Sprint. Usually we’re talking about something between 1 and 4 weeks. Balancing is the key; the longer the sprint, the more you sacrifice the agility. Shorter the sprint, the more you have overhead. But the most important thing is to consider what suits the team and the project.

Initially, what we decided to do was to start with weekly sprints for maximum agility and then move to 2-week sprints when the project got more robust after the First Playable and we would be able to plan for 2 weeks ahead.

After reaching the First Playable milestone, however, our way of working was so established around the weekly cycle and we still felt we needed the agility provided by the 1-week sprint, we decided to continue using it. So in fact, we are still working with 1-week sprints and it works, there’s no real pressure to be changing it.

Dailies

I have used Scrum with about 10 development teams and one of the most difficult things there is is scheduling the Daily Scrum. This project was no exception.

Usually I would like the Daily to take place early in the morning, for everybody to start their day by planning what they are going to do and also let others in on it. Therein lies the problem. Working with game teams especially, everybody’s got their own rhythm. As a leader, I’m all for allowing people to work when it suits them the best. As a manager, it gives me nightmares!

In a perfect world all people would wake up early, be at the office at 8am and we’d have the Daily at 8:15am. At some point with one team I was able to have the Daily at 9am, which is already a very good accomplishment. Usually with game teams, we’d have the Daily at 10am, which is OK. At Epic Owl, we scheduled the Daily to start at 11am.

Not too bad, right? Still in the morning but late enough for everybody to get to the office in time? Well… After a few months of fighting windmills and several mental breakdowns by me, we finally moved the the Daily to start at 12pm. Not the ideal time, no, but it is crucial to have everybody participating in the Dailies consistently. If that means that our dailies start at noon, so be it. And to be honest, it’s not too bad. Some people come to the office by 9am but everybody is at the office by 12pm so things are flowing smoothly and the Dailies fulfill their purpose.

Day by Day

After planning the production and setting up the needed processes, it was time to execute. Sprint by sprint, phase by phase. We implemented, iterated, tested and re-did.

As you may be aware, we are working with the two-headed eagle management structure: I’m responsible of the game production and Risto [Holmström] is responsible of the game design and creative department. This works perfectly and we are getting the best results by me pushing for keeping the schedule and Risto pushing for higher quality. It’s a perfect match, neither is ever happy but the balance and the friction will result in the best possible product in the best possible time.

All in all, everything went as smoothly as in any production and slightly surprisingly, I can’t find anything insightful to say. We executed the plan and suddenly we had the product in our hands. Almost.

The Last Mile

The Last Mile. The Release Candidate. We’ve now built something that can be called our Release Candidate. This is always the most difficult phase of the production. We already have everything we need for the launch. Except for a few small features and some bug fixes. The stress can be seen on everybody, we’re so close we can touch the goal but we’re not there yet.

There are some bugs. Nothing is crashing the build but it would be great if we could just fix these. And, one of our play testers suggested that there is this feature that would make all the difference for her. Easy to implement.

Yes, I’ve seen this all before. And it’s always the same. I get to be the one who tells everybody that we’re not making this or that easy fix or feature. Even though we all know the game would be better with them. This is one of the most difficult phase of the production and here are some reasons why it’s absolutely crucial to keep your head calm with any changes:

Of course, sometimes the feature is actually worth doing and the bug worth fixing, even after RC. To help myself put it into perspective, with every additional RC build fix, I add at least a week of production time (in addition to the actual implementation time) and prepare for it. If the fix is seen to be worth the extra production time, then it will be done.

The Soft Launch

“Ship it!” – And we did!

-

Thanks for reading, I hope you enjoyed this! As always, I’m happy to discuss these things with you and answer any questions you might have.

– Juha

More information:

Twitter: @yuuhaw

LinkedIn: www.linkedin.com/in/juhavainio

Epic Owl:

Web: www.epic-owl.com

Twitter: @epicowlltd

Facebook: www.facebook.com/epicowl