Game Jam to Shipped Game

After this year’s global game jam, I wanted to share some experiences about shipping games to encourage first timers to get their games out there. First thing you need to understand is that you are not near to done. Our industry usually thinks in terms of features but this is misleading. We think “Camera system, it works… Done!”, but what we really we need to ask is “is this feature shippable?”. And in there lies the rub, what is shippable to you?

Game jams are rapid prototyping sessions. They are hugely valuable to determine if you are heading down the right track. They help to find the fun fast, so you know the general direction you will be taking on your game creation voyage. If your prototype is not fun to you, its probably not a good idea to pursue it. I am speaking from the heart here, spending may hours of time I will never get back trying to make something that is not inherently fun, fun. If you have a choice, and as indies you do, don’t to it if your prototype is not fun right now.

Once you have the fun, its time to do time estimates. It does not matter if you schedule or you scrum, you still need to estimate time. If you are new to scheduling, once you are done, double your time! I mean it. As developers, we are hugely optimistic and love what we do and sometimes we forget the bad times. Shit happens… on a regular basis and you need to account for it. When you are doing time estimation, be as specific as you can. You should spend at least half a day on this. Why so long? Because you need to think about all the things you haven’t even thought you will need. You might say “We need a store so users can buy coins”. Awesome, what platforms will you support? iOS? Android? Amazon? All of them? Well then, you will need API integration for all three of them, transaction testing for all three of them and store configuration time for all three. Not to mention, you will need actual devices to test it on.

Once you have your time estimate, you also have a list of things to do. Two birds dead with one long and heavy list. Use this as a burn down list and add to it so that, when you make your next game, you can see all the items you missed and can plan better. A very quick and effective technique I use is to have a simple spreadsheet on Google Docs with a list of tasks, a column for priority and a column for developer. This way, if you have a team, you can assign items and track progress. Highlight the row orange if you are working on it, highlight it blue when it is done and then highlight it green once it has been tested or proven to work. Even if you are a one man team, it is very useful to see your progress and to be encouraged by the fact that you are actually making steps forward.

Mid project slump. I get this often. I get to the point in a project where I am just not making progress and I am not motivated at all. The game is realistically 50% complete, all the heavy lifting is done but there are unknowns somewhere and there is just nothing that I feel I can get stuck into. All the challenging stuff has been completed and now I just stare at the computer and fiddle. Welcome to mid project slump! The only solution I have found to cure this is to polish a vertical slice. Polish it to 100%. I find that the slump is due to the difference in just standing everything up in the game and getting it shippable. The mentality for standing things up is just making it work, its broad strokes. So you get a point where everything is stood up. Your mental task list says “We are done” but your eyes and gut tell you that this game is far from finished. So polishing a slice of the game is the best way to make the transition. Find a small portion of the game and take it to the level of expectation you have of a finished product. Once you have completed a slice, you will feel a lot more motivated, have a better understanding of what to do next and you will feel a little bit of pride that is essential in moving forward, especially if you are making this game after hours.

One of the biggest contributors to mid project slump is “keeping it open”. Games are usually nebulous clouds of ideas revolving around a gravity well of a concept. Along the way, things get more and more crystalized until the day you ship. Some people call this the Funnel. The thing is, decisions have to be made at some point and everything can’t be kept open forever. Sure, keep your architecture flexible but by half way through the project, you should have almost all of the ideas nailed down. UI should be designed and ready for implementation. You might say, “well halfway… I should only have half the ideas nailed right?”. Incorrect my friend. I find that it is only in picking a course and moving forward where you find the real path you should have taken. That sounds very Mr Miyagi but it is the devil that lies in the details that needs to be found. You need to start implementing and testing to see if a concept works in totality. There is always stuff you could never have thought of and thats why you need the other half of your development time to come up with creative solutions. In summary, I have found that in picking a strong direction early, you get to a good end product faster, rather than leaving the decision making until later. At the very least, you know what won’t work and why.

Lastly, never underestimate the publishing cycle. It can totally break you, especially when dealing with console. Indies can easily loose their shirts here. Publishing to any platform can be a headache, so do your research upfront, especially if you have never published to the platform before. I am a Unity fanatic and it publishes to a lot of platforms beautifully, but its usually not the tech thats the problem, its the process. Take XBox, you make your build, it works, you upload it, done… nope! If you read your docs, you would have found some obscure tests that you never accounted for and XBox QA rejects your build. Now you cant submit for another month and your whole time line is pushed out but you have already paid for media placement. Another example; you are releasing an android game but forgot to check your app size limit. Your game is 61mb, the app limit is 50mb. Now you have to figure out how to split your binary and if you will host with Google as a OBB or on your own server as some other format. You have to have another test cycle to test your OBB downloader but Google Play take more than half a day to update your hosted files so now every time you test, its a 4 hour wait. You get the point, whether self publishing or not, its still a beast. If you are making mobile games, especially on iOS, don’t forget all the store meta data. You need things like descriptions (in multiple languages if you are translating), screen shots for multiple device sizes, promo images, multiple icon sizes, yadda yadda yadda. Its not fun to try and get this all done at 3 in the morning and all your artists are asleep!

So, make your game! Do it hard and make it a slice of awesome pie. And have everyone tell you how amazing it is. But the only way that is going to happen is if you finish it and get it out there. And the only way you are going to do that is if you have a realistic understanding of what you have to do.