A 360idev Game Jam post mortem… some useful things we learnt that you can apply elsewhere

In the last 24 hours we’ve been participating in the 360idev Game Jam along with a whole bunch of other developers in Austin and around the world. We’ve come out of it with a game prototype that’s solid and a bunch more enthusiasm for the original idea and getting it finished than we had before we started.

We did the bulk of the work from the UK, with @deltamikealpha on the ground in Texas keeping an eye out for the mammoth pizza delivery and proving much needed QA and general technical gubbins.

So, what did we do?

Directly following our game mechanics #idevblogaday post last week, we developed the Status & Ownership mechanics into a hex-based iPad-only game of domination and leveling (okay, the leveling’s not implemented yet – but we’ve got a good feel for how it’ll work). The project’s been titled gjat, Gobble and now Shingles. Yes, we’re going to come up with a better title. I won’t go into the detail of the gameplay right now – mainly as we’ll be finishing it up as soon as we can and getting it out there for you all to play.

What I thought might useful to both us and you is a recap, post-mortem style of what we’ve experienced and learnt.

"Feel" is important, specific game art not so much

We spent a lot of time (probably the first 3 hours) discussing and trying art ideas. It turned out that the art itself didn’t matter so much, but the “feel” of the game was crucial. The brainstorming we did about vector and painted styles, actual and abstract representations and dynamic art-based environments led directly to how we felt the game should play. It didn’t, however, get us to a final art-style. The in-game art we’re using now probably took about 2 hours in all and will likely take us another 20 or more to get to v1 release, but it carries the spirit and desired feel sufficiently for us to assess the “fun” of the game.

Mercurial, bitbucket, Google Docs, Skype and Dropbox FTW

This is kind of an obvious one, but our toolset is important. Yes, we needed XCode and Photoshop – but it wasn't them that held the thing together. It’s setting up and pushing a source repository in 4 lines, collaborating line-by-line on specs and bugs and seeing each other’s faces (this really helps at 4am) that got us through. Yes, the WiFi at the venue could’ve been better but it just about did the job.  As we all work from our homes and various offices anyway we’re used to this, but intensifying the requirement to collaborate through the 12-hour deadline forced us to use what does the job. Happily, this turned out to be what we use day-in day-out (yay for our normal efficiency and effectiveness).

Having a comprehensive framework is facilitative

Prior to the start of the Game Jam we spent a little a time isolating the component architecture we’ve put together for the other titles we’re currently working on and setting up an empty iPad+cocos2d+said architecture project. Whilst this took time it facilitated features that we just wouldn’t have been able to do in the time otherwise (including: duplicating AI players; having UI indicators for player/piece state, and; implementing a reasonable sound effects system in about 14 seconds).

We should’ve implemented a controller/player interface

This is pretty specific – but important, and something I may write a follow-up on if useful?

It was clear going into the first lines of controller code that the “correct” way of implementing both human and AI players was via a controller interface. But, we were still pinning down the hex map tools and it made sense at the time to consolidate human player control validation with consequential actions. When we came to the AI, a good chunk of this ended up be mirrored (not quite replicated, but not far off) because we didn’t have the interface layer. Suffice to say some of the bugs we were ironing out right at the end were solely due to the rule set being manifested in two separate place. Writing the proper interface layer is now a must before we embellish the core gameplay features.

Sometimes there just isn't a shortcut

I spent a good amount of time trying to sort out performance issues (performance issues that were making the prototype close to unusable) that were due to hacky AI loop. After an hour or two of plugging holes I ripped it all out and started again. I should’ve known better (although I had overestimated how long it would take to hook together the behaviors and components that now make up the AI loop). Performance went from being a massive problem to completely irrelevant – and actually gave us scope to do something we hadn’t anticipated in the prototype: multiple concurrent AI players.

Resources don’t need to be utilized 100% for them to be required

There were three of us working on the project: me, Gareth (@36peas), project lead and sole coder; Goose, artist (@goosemouse), and; Dave (@deltamikealpha), QA, asset management and general technical resource. Thing was, the bulk of the work ended up being in coding, and neither Dave or Goose were required for the full duration of the event. Initially I felt a little uncomfortable about this but on reflection I wouldn’t have had it another way – whilst I didn’t need them the whole time, the support they provided was invaluable.

--

Right, time for some sleep – we’ll get back to you just as soon as we have a real title, if not before. Hope this was useful, hope those of you who participated had fun too – looking forward to seeing more of the Game Jam projects over the coming days and weeks.

Comments

[cherry]

good

[cota]

Fear not that the life shall come to an end, but rather fear that it shall never have a beginning. terracotta warriors