ByteClub

Earlier in the week, Noel Llopis (@SnappyTouch) floated an idea of organizing an overnight game hacking session with a simple goal - start coding in the evening and finish an iPhone game by morning - a kind of an Iron Man event for game developers. Thanks to support from Tom and John of 360iDev, the event got a green light - by the time Tuesday night rolled around, we had a room full of people, with anywhere between 15 and 20 projects being worked on. The biggest team had 7 people (!), but majority of games were created by lone developers. I came up with a physics-based multiplayer game called BattleFlick. Let me share some of the experiences from the event.

Scope creep for fun (and profit)

As it turns out, it's hard to come up with a "complete" game in 10-12 hours (surprise-surprise!), especially for those of us that haven't developed many games before (myself included) - mostly due to scope creep and a constant desire to add cool-looking things early on. If you have enough discipline to come up with a crude project plan and stick to it, you will have higher chances of finishing within the time constraints - but the chances of getting struck down by an unforeseen technical problem (that will easily set you back an hour or two) are still pretty high - especially if you use unfamiliar technologies in the process. A lot of developers at the event were inspired by earlier sessions that covered physics engines and especially Cocos2d framework, and decided to try using some of those APIs for the first time during the Jam. From the perspective of time, it's about the balance between how much coding a framework like Box2D saves you vs. how long it takes to learn it. Knowledgeable people, Google and code samples are your best friends. All in all, learning something new and cool was definitely a big part of the experience - but please don't ask me to show you the Frankencode that came out of it... I'm afraid to look at it myself. I am fully expecting some of those classes to haunt me in dreams for days to come.

Lessons learned

Below is my personal take on what it takes to successfully make a fun game in 10-12 hours of non-stop work with a semi-hard deadline. But don't take these guidelines too seriously - unless it's a competition for a million dollar prize, of course. Main point is to have fun and learn something new, but it doesn't hurt to be realistic about your goals at the same time.

Short summary: It comes down to very clearly understanding what is the CORE of the project that you will be working on and focusing on it. It starts with finding a suitable idea. Then, you move on to figuring out what constitutes the essence of the gameplay. What is the absolute minimum that's required to make it work?

- If you have an idea for a game that you will want to code, take your time to define the scope of the project beforehand. Carefully assess your skills, make sure you understand what is achievable and what is not. If you need to learn some new framework, make sure to account for it - it WILL take more time than you think, regardless of how much sample code you can dig up. Try to enlist help from somebody who really knows how to use particular technologies that are new to you. Make sure to be courteous - most of the time those people will have their own stuff to worry about and won't have too much extra time to babysit you.

- After you define the scope, cut it in half! In the cases like this, there is a big difference between FINISHING a limited game and STARTING an ambitious project, and most of it comes down to one simple thing: when morning comes, you will feel a lot better if there is something that you can hand to OTHER people to play with, something more than screenshots and explanations. Plus, if you do finish early, it'll be easy to think of some additional features to add.

- If you decide to try a few ideas before settling on the final project, try to stick to rapid prototyping and don't invest too much time into building code infrastructure that you might not even use because that particular game idea turns out to not be fun enough to go with.

- Remember: you are building a prototype! Dirty code is ok. Unless your idea is to build the next generation graphics engine in one night, don't spend too much time trying to make your class structure clean. On the other hand, source code that looks too much like a bowl of spaghetti might slow you down if you do need to spend significant time debugging it or you start forgetting what calls when and why after taking a break. Find your own balance here.

- "Layer" your work: Finish the basics first, and then start adding more advanced features on top. Don't get carried away with trying to perfect one particular area of the project. Each successive iteration should make the whole thing better incrementally - because if you have to bail out early, at least you will have SOMETHING working. Good example: if you have some characters in a game, don't implement graphics/animations for those characters right away - do it with primitives first. This might not fully apply to a game where some intricate graphical/physical model is the centerpiece (i.e., a sophisticated ragdoll game), but I bet you could defer graphics and sound until later stages in a lot of game projects.

- If you can find somebody to produce artwork and sounds for you, do it. Each minute that you spend in Photoshop is a minute that you are not coding. But then again, don't get carried away with the outsourcing process - it can be remarkably easy to get sucked into spending lots of time trying to "guide" your artist and formulating feedback - each minute that you spend writing those emails or IMs is a minute that you are not coding.

- If you are a perfectionist, this can be tough, because the balance is heavily tilted towards "how fast you can do it" and away from "how good it's going to come out". Some people aren't prepared to compromise like that. Try to make an exception (this one time) and focus on getting there as fast as possible. One other potential way out is to severely limit the scope and focus on quality. Instead of having a "game", make a cool "toy".

- What if you don't have any game ideas? There seem to always be a couple of people that are better at generating ideas than implementing them. This might be a good opportunity to team up.

- Keep track of time - it's important to be aware of how you are progressing and adjust scope if necessary.

- Debugging when tired can be a b*tch. But you already knew that...

Bottom line: it's all about having fun while trying to accomplish something under pressure. It's not as dreadful as it sounds, you just need a bit of determination and inspiration. Oh, and don't forget to stock up on chocolates, fruits and caffeinated beverages...

-- Peter Bakhirev

P.S. More info about the event