Level up: +1 creative output; +1 communication; unlocked “play” skill

I’d thought about writing a resolutions post for this #idevblogaday a few times, but each time hesitated as I had thought it was something of a get out. However, after having thought through what that might mean for 36peas, I realized that’d it actually be very useful – at least for us.

So, here it is – 2011 resolutions for 36peas:

1. Create
2. Communicate
3. Play

1. Create

We’ll be doing a lot more of this in 2011. Last year was something of an odd one, we started with a few months of dedicated development time, but without a fully developed and resilient business plan and underlying guarantee of resources for something that’s a relatively high-risk, unpredictable business. We now have a commercially viable plan and the surety we need to just get on with it.

I’m deliberately avoiding specifically stating how much we plan to create (all credit to Noel though for doing so) – I’m just stating that we’ll be doing a lot more creating. Having said that, I can’t see much stopping us from publishing the two iPad games we’re currently working on: Dead West and our as-yet-to-be-titled 360idevgj project (which we’ve only actually spent about 6 hours on since the game jam itself).

2. Communicate

Our greatest achievement in 2010 was actually getting involved and communicating with others via twitter, various events (including 360idev) and obviously this blog.

There are specific ways we plan to apply what we've leant in 2011 – both internally and externally. But most can be boiled down to sharing what we do and sharing in what others are doing. We never could have expected a growth in monthly unique visitors to this blog from <100 to over 3,000. In retrospect this is obvious – we shared what we cared about and found ways (obviously including #idevblogaday) to get that information to others who care about it too.

3. Play

This is as much a personal one as it is a team one – but I’m sure the rest of team won’t complain. We need to do more playing. I’ve done more in the last couple of weeks (Rock Band 3’s pro keys & drums, Dungeon Hunter 2 on the iPad and some excellent marble kit – thx Lisa for the latter) than I have in the last 8 months. This has reminded me of exactly how directly important it is.

I’ve done more thinking about how to balance Dead West as a result of playing Dungeon Hunter 2 end-to-end than I have from any other gaming experience since playing through Dragon Age: Origins nearly 12 months ago. It’s not that I haven’t played games either… it’s that I haven’t fully immersed myself in a game since Dragon Age. In that 11-month gap I hadn’t exposed myself to the full extent of the experience laid out by a game designer: and as such hadn’t had the opportunity to reflect on that analytically and apply it myself to our own games.

This realization is actually pretty timely – Dead West’s at the point that it needs some pretty consequential decisions making about the overall game balance (I was actually planning on writing about that this week for #idevblogaday but wasn’t getting anywhere fruitful). Dungeon Hunter 2 – whilst quite a different game – shares some of the same balance issues and though I did very much enjoy playing it, it couldn’t have given me better examples of how to (mis)manage some of end-game situations and problems I was trying to evaluate for Dead West.

Play as an input to game design is something I talk about a lot – I think I’d just forgotten how useful it can be in facilitating immediate design decisions.

Of the three resolutions above, “play” was probably the most lacking last year ("create" was similarly lacking – but for good reason) – whilst it’s ostensibly an easy one to change, I suspect it’s this that I’ll have to put the most effort in to. Looking forward to reporting back the results of all three resolutions throughout the year.

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.