This blog was also featured on Gamasutra on 01/05/2016.
I have met a lot of creative people in the past few years. Most of them have high ambitions and great ideas, but there is one thing most creative people are really bad at: deciding the scope of their project. Part of their strength is being able to look outside the box, to think of outrageous new concepts. By doing just that they tend to overlook other important factors. These are money, time and polishing. A project, for most people, is the great concept materialized in a playable prototype and from there on the process of playtesting, iterating and playtesting some more. But when is it time to call it quits, when do you decide when your game is finished? Well, not by working till you think it’s perfect, because it will never be perfect. As an artist you’ll always find new things to add, things to change or omit. Like a painting, it takes discipline to decide when your game is good enough to be released in to the wild.
When we worked on Lumini, we made a pact to release the game before we’d be finished with school. That date was two years away from then, but it was important for us to have a goal to work towards. We had two years to create a polished, finished project and have it released on Steam, starting from just a concept that got approved just prior to that. By setting that goal, we knew that every decision we made for the game, would have to fit into this time span. Without really knowing how much time everything would take, we decided that this would be a sheer impossible task for us to do. First we were going to make a vertical slice of our game. A demo that people could play, so we’d know what we did right and what we needed to change. But also a marker, to see what we could do in three months time. The demo was going to be as long as it could be within this time span. We ended up with a shorter game than we personally anticipated. It was about 10 to 15 minutes long and still missing a few things here and there. It did however give us a number with which we could work.
Announcement trailer (November 2013)
Accepting the fact that the full game could never be something more than a few hours was hard. However, we decided to stick to our plan to finish the game in two years time. If we decided to stray from that path, it would’ve meant that we also needed to focus time on getting funding beyond our schoolproject. Something we were not comfortable with. Releasing the game withing these years also meant that if we were going to quit the team after graduating, we’d have a fully released game on our resume, thus considerably strengthening our position in the highly competitive field that is game development.
So knowing that we had two years, minus the three months it took us to finish the demo. It was easy to decide the length of the game and how much content we could fit in. Lumini had to be a bare minimun of two hours long. So that would mean eight times the development time we took for the demo. So in 24 months it had to be finished. That was a problem, because 24 months is exactly two years, but we had to do our internships, Steam API implementation and we had already spent three months on the demo. So we were forced to either make an even shorter game, or get more people involved in the team. We decided the latter was the best option for us. Mind you; going to college here in the Netherlands, meant you got financial support from the state. So we didn’t have to pay fellow students for the project, making it relatively cheap to expand our team. So other people might be forced to take another route.
Having expanded our team from six to nine people (of which two worked for half a period) we had tackled one problem and were confident we could finish a two hour game within the time we had left. The fact that one of our programmers built a toolset, so we could build levels more efficiently and thus faster, also helped a lot. The next thing we had to do, was make a list of everything that had to be done. This had to include stuff a lot of people forget about until the very end. Like Steam API implementation, achievements, option menus, localization and marketing. Also factoring in buffer periods that would be necessary to counter bug problems, events and other things you can’t plan ahead. And of course, leave room for polishing the game.
We made a MOSCOW list (for those who don’t know what it is: http://www.dsdm.org/content/10-moscow-prioritisation) of all components of the game. Mechanics, features, assets, audio, technicalities and pre-production work. That way we could make a rough schedule of milestones that we needed to clear. We also had a few deadlines from our school that were mandatory, helping us a lot, since we had no choice but to deliver on those dates.
This, of course, doesn’t mean we knew what would and would not make the game. Nor prevent us from thinking of dozens or more awesome features that we wanted to implement. The list changed a lot, but with every iteration, we needed to make sure that the deadline never changed.
So how do you handle the ever growing amount of new things you want to implement, when you have a tight deadline to keep control of? Simple, about four months before our final deadline, we sat down with a long list of all the things that still needed to be done and additions from every team member that they would like to see in the final game. We went by them one by one and decided on a few simple premises if it would make the cut or not.
1. Could it be implemented within the time left?
2. Does the majority agree it will make the game better?
3. Does it possibly interfere with core elements already in the game?
4. Could it be implemented within the time left? (This one is really important!)
For every possible addition we started with question one. If it didn’t pass, we crossed it off, however cool it may have been. If it passed we put it through voting for question two, etc. If it met all four the requirements we scheduled it in. A lot of hearts were shattered that day and a lot of great features are catching dust on a shelf now.
We also agreed that if by the time we needed to deliver the game, a feature wasn’t finished or poorly implemented, we’d omit it from the game, no questions asked. In the end, only one big element failed to make the final product (big emotional set piece, in which you walk with a herd of giant dolphin-giraffe-dinosaur creatures).
So, why did we decide not to take more time to implement really awesome features that would’ve surely made the game better? One, we had negotiated an official release date with our publisher. Two, we wanted to finish the game within school. Three, money. While three wasn’t the most important for us, it is for developers who are on a budget. For every month you develop, you need to sell more copies to break even. So if you decide to take a month extra to implement something, that extra feature better sell you more than a month’s salary worth of copies. In reality, most features don’t. Most make your game better, but aren’t part of the equation that people make to decide if they’ll buy your game or not. So to postpone your deadline, it either needs to gift your game with another strong hook that can be used to sell it, or must be so memorable, that people will talk about it afterwards with their friends. This decision isn’t easy and takes a lot of discipline. If you’re not sure, talk to people about the feature and ask them for their opinion.
Now for some honesty that I didn’t mention yet. I made it look like we never had to change the final deadline didn’t I? Not true, even while taking all these precautions, we made one big shift. When negotiating the official release date with our publisher, we had set the date on early July 2015. But when it came to signing the contract we talked about making that deadline and how it would leave us with very little time to do QA testing. Our programmers were also uncertain about implementing the Steam API on time, since they had no experience doing so. So we decided to postpone the date to early September 2015. It still fitted within our timeline, since we officially needed to be done before August 30th.
So that’s how we finished our game on schedule. While doing our internships, graduation presentations and other irrelevant stuff a school makes you do. We started in September 2013 and Lumini released on Steam on September 3rd 2015. I won’t say it definitely works like this for everyone. You’ll have to try out a few things yourself, but I hope it helps teams to have a better grasp on their scope and release games within budget and within time.
Lumini teaser trailer (April 2015)
Bonus tip: When working on a project for a long time, you’re bound to run into some motivational issues. Keeping motivation high is mandatory to keep meeting your deadlines, while also keeping the content of sufficient quality. What we did to prevent motivational problems, was to write down parts of our MOSCOW list on a big whiteboard in our office and when an asset or feature was done, cross it of with a big red line! That way you keep clear track of your progress and the entire team knows what to do next. Also, don’t forget to have fun! Making games is the best job in the world after all. 😉
If you have any questions or don’t agree with something I wrote, let me know! You can contact me on Twitter (@Ithunn) or send me an e-mail (steven[at]speelbaars[dot]com)