Archives For February 2014

Our Game Jam ran over Valentines day which was a rather obvious cue to take for the theme. The theme we chose was One Heart to Break which I think is pretty nice because it immediately suggests a whole host of mechanics, flavors and narratives. Team Maggi were the stand out winners though for taking the theme completely literally. You have one heart to break… your own, and you do so by eating yourself to death. The game was a card game themed around a dubious fast-food place that sits next door to the CCP office. Your aim is to lose your starting life points before anyone else and you do so by eating meals and their toppings. At the same time you have other cards you can play immediately on others to reduce the effects of their meals. Send another player to the gym and they lose some of the points value of their meal. Make them projectile vomit and one of the meals in their stomach is violently deposited into your own.

Team Maggi had a reasonably huge team as a lot of them couldn’t make both days. For the most part they are EVE developers with the additional talents of our CEO Hilmar, his daughter and Hinrik one of EVE’s game masters. Again it’s pretty hard to demo being a physical thing so here is a shot of the game in the final stages of production.

Team Maggi making the final preparations to demo their game.

Team Maggi making the final preparations to demo their game.

Our first award category is the “Saaaay Whaaat?” Award for Oddness. One of the nice things about Game Jam’s is it gives people a chance to experiment without fear of wasting a lot of time to get nowhere. Team Chickenheart who mostly comprised of EVE’s Security team definitely took that spirit to heart. Their game Achy Breaky Heart is controlled via a physical game board watched over by a webcam. The tech stack behind it comprised two networked PCs and a fearsome collection of code tools to represent the board as a web app. The game itself involved sliding a marker onto the board in order to hit a heart on the screen which is quite a tricky bit of spatial reasoning. It’s a bit hard to show in action so you’ll have to make do with a screenshot.

gamejamchickenheart

The physical game board in action.

About a year ago I floated the idea of running an internal game jam and got a lot of interest from not just the developers but from our business and support staff. Actually implementing that idea got waylaid by being too busy with development (we were on a very tight deadline revamping the hacking in EVE) and by my not really being senior enough to co-opt things like people and budget to help out. The idea was revived by my immediate manager Bjossi and along with a crack team of others interested in helping out we assembled what I think was the first Game Jam organized within CCP.

Eating pizza at the end of day one.

Eating pizza at the end of day one.

My part in things was to work with a few other people to come up with a format and generally sort out how we would run things. In the end I actually facilitated the whole thing as Bjossi was unexpectedly unavailable. I think our format was pretty good and the results really speak for themselves. I’ve reproduced the important details below so that others can use it as a template:

Organizing a Jam

Game Jam Rules

  • All game code and content must be made on the 14th and 15th of February.
  • All games must be based on the theme of the jam. The theme will be announced at the beginning of the jam.
  • There is no restriction on third party libraries or tools although you must only use software with a valid license (e.g. trial license).
  • There is no restriction on preparation for the event so long as no content or game code is written prior to the theme being announced.
  • Games may be digital or paper based.
  • All digital games must run on Windows.
  • We’re going to share source code internally as it can be a great learning tool.
  • All IP created is the property of CCP Games.

Forming Teams

Teams will be formed immediately after the jam theme has been announced. We’ll have a mic ready so people can make small pitches if they have an idea and want to get people on board. We’re going to try as far as possible to leave this as a self-organizing effort but please bear these things in mind:

  • Teams shouldn’t really be larger that 6 members.
  • Try to recruit of join up with people you don’t normally work with.
  • Attempt to spread people that work on games directly during the day out between teams.
  • If you have special requirements about when you can or can’t work just let your teams know. I hope most people will be glad of the extra pair of hands even for a short while.

CCP very kindly gave us permission to run the Game Jam using one day from the working week and the use of the office facilities over the weekend. We also got budget to feed the troops pizza and beer after day one, for some beers to available during a showcase afterwards and for some free drinks at a local bar as an after-party for the participants. We also block booked out some of the meetings rooms in the office for the exclusive use of the teams and allowed people to work offsite, although only one team actually did. For communication before and during the Jam we had a couple of mailing lists setup and a chat-room open for all the participants.

At the beginning of the work day on the Friday we announced the theme ‘One Heart to Break’ and after a bit of a false start everyone quickly formed up into teams and disappeared. I spent most of the day trying to make sure everyone had what they needed. There was a hard submission deadline of five PM on the Saturday evening which all the teams made, although some only just! After they submitted everyone rushed to get setup to demo their creation in a showcase open to the rest of the people from the office. Beer was consumed, fun was had and then each team gave a little presentation about their game before I announced the prize winners. After we’d packed up we all adjourned to the pub where the event was dissected in detail.

One of the teams looking a bit stressed out.

One of the teams looking a bit stressed out.

Lessons Learned

Game Jam’s are awesome, most people that have taken part in one will have enjoyed it. Ours was no exception and the event generated a tremendous amount of good will from the participants. At the beginning I was a little worried that teams wouldn’t end up making very much but every single team made at least one game. People did mix up who they worked with a little but most of the big organization boundaries weren’t crossed. I think that’s about all you can expect running this sort of event for the first time.

I would like to make more of a thing out of the showcase when we do this again. The organization was a bit last minute and we could have done more to make the event something people wanted to attend as well as easier for the teams to setup and be distinct from one another.

For those interested in technology choices by far the most prevalent choice was a variety of web platforms with most code written in JavaScript. The only big game engine used was Unity by one team. We had one team make a card game and another using a physical game board to control a videogame. By far the most unusual choice was the piece of interactive fiction a team created in Confluence our project wiki software!

Over the next few days I’ll post about each of the prize winners before summing up the remaining entries.

As a software developer I’ve always had an affinity for the Agile Manifesto. However as someone who has spent their professional life creating games products I know that the environment stymies many of the bigger principles involved. The purpose of this post is really to state my experience before I try to go on and talk further about Agile so those words can be set in context.

Previous jobs and other group projects had no or ad-hoc project management but my introduction to Agile “in practice” was actually intuitive. It occurred whilst I was working at Realtime Worlds and had finished APB and there was suddenly a decision vacuum from our project leaders about what exactly we should be working on next. Previous suggestions were in the vein of “go wide” with game districts themed around things like a zombie apocalypse or a “no-rules” districts (which was awesome fun). The state of the project was such that many of us were deeply unhappy with the core game prior to shipping but could do nothing about it because we were in heavy bug-fix and polish mode. The project was organised in classic functional silos myself on a Gameplay Programming team with other silos representing special engineering interests and disciplines. A core group of us spread across these teams really wanted to tighten up and juice the core experience. In the decision vacuum I pitched an idea to organise a cross-functional team working iteratively to improve the core game experience. We had a set of really good ideas formed from feedback about where the main pain points were and how to tackle them. We knew we wanted to move quickly but not too far with each iteration so we avoided unnecessary work. We also knew we needed to work closely in a collaborative relationship between developers. In short we accidentally formed our own ‘agile’ team. Sadly Realtime Worlds died soon after we released our first iteration so we didn’t learn some of the lessons about project management I’ve since come to appreciate but the core of what made us successful was the core of what makes Agile tick day to day for developers. Caring about the customer, creating something simple in a cross-functional team, tight collaboration and improving on things in an iterative fashion. The work we started was continued by GamersFirst who transformed APB into APB: Reloaded a pretty successful F2P shooter.

After Realtime went bust I moved to CCP Games to work on EVE Online. EVE itself a marvelously interesting product but I was also drawn to CCP because they used Scrum and were organised in a way that I thought was closely aligned to how I wanted to work. After three years here working in myriad teams on myriad things I can state that it’s reasonably true, we may still be doing Scrumbut however people are at least receptive to working improvements and the EVE project is pushing towards different way of working and has come far. One of the nice things we have is a fortnightly Agile Community of Practice which is not a cabal of senior managers deciding working practices from on high but a collection of interested developers from the project discussing Agile and how we can improve our working practices. This has lead to some interesting developments in working practices with some teams now running on one week sprint cadences (after their Scrum master gave a great evidence filled presentation on why they should), the questioning of our own general working practices, release practices and such like. Last week I chaired a discussion where we took each Agile principle and looked at our how well we as a project meet it. It was illuminating not only because different perspectives on our situation were shared but because it made me question some of the validity of the Agile principles (or at least their wording) to game development. Working here has definitely shown me is that Scrum is probably not the answer (but it might be part of it) to large scale projects for a whole load of reasons. Both topics for future posts.

An amazing amount of Agile literature and methodologies have been generated by the general IT community but very little has been game specific. Over the course of this blog I’d like to try to put together my own thoughts on the subject into something a bit more organised that goes beyond the usual siren call to “adopt it and see magic happen”. A colleague Rob Galanakis is already blogging about this sort of thing and is part inspiration for restarting a blogging effort.

A talk I gave at Unite Nordic in 2013.

Basically an exposition of my thoughts on prototyping, how to do it right and what value it provides to game developers.