Archives For game jam


Last week I took part in the fifth GBJAM. A popular game jam that pays homage to Game Boy games but allows for modern sensibilities to creep in. Initially I had no plans to take part but a developer on the newly formed Icelandic Gaming Industry Slack mentioned it. Soon I and a handful of others decided to join in. The basic format gives you ten days to make a game. There are two significant constraints, a four color palette and a ‘pixel resolution’ restriction of 160×144. After the ten days are up competitors then rate one another’s games.

In the end I spent around 16 hours making Void-Dogs and finished in 82nd place out of 402 entries which I’m pretty pleased with!


I’ve been working pretty much continuously for 12 years making games and playful things. My emotional makeup is such that I really invest in the thing I’m making at any one time so I find it hard to juggle multiple creative projects at once. I don’t have the headspace for it. As such I’ve found it hard to work on sideprojects. I’ve made things during both my recent paternity leaves as good contiguous blocks of “free” time. Development time was “luckily provided” thanks to Autodesk laying a bunch of us off in August. Since then I’ve been working for two hours a day on a small game called What Now Earthman?. But that is still a big project I won’t complete for the foreseeable future. So I was already motivated to make something smaller in scope. The GBJAM popped up as a good enough answer.


Void-Dogs took sixteen hours in total to finish. I started a day late but I don’t think that made any real difference. I started off working two hours per day but eventually did a little more from Wednesday onwards. In general it was quite a relaxed affair tucked around child care. Void-Dogs was made in Unity which is probably my favourite engine for making a myriad of games and prototypes quickly. I task tracked with lists on graph paper. I wrote all the code and made all the art and SFX by myself but found some Creative Commons music to use as a soundtrack. My main source of inspiration was the game Space Harrier but I wanted something that involved a little less spraying bullets directly forward. After a bit of brainstorming I came up with the concept of “skydiving in space” and went off to work! You can download and play the result here.

The most interesting technical challenge was creating the sense of depth and motion with a limited resolution. In the end I actually opted to use a perspective camera and Unity’s particle system to create some ‘dust’ that gives the impression of hurtling through space. Another important addition was the use of a ‘sine wave’ shake script I wrote some time ago. I initially intended it for cameras but it works just as well applied to other objects and captures that never still motion of a skydiver falling at terminal velocity, not realistic but it feels good.


All the asteroids and players are positioned in 3D space with one unit equal to one pixel. This let me simply calculate the depth into the camera where I would get pixel perfect rendering. I initially tried rendering the sprites moving through space directly but the resolution makes for ugly pixel artifacts as sprite pixels pop in and out across real pixel boundaries. This wasn’t an unexpected problem, it’s part of the reason you see games like Space Harrier do 3D by changing sprite sizes (also hardware optimised sprite rendering). Moving to this approach required a bunch of labor to make art assets but is much better visually and thematically. In the end all the sprites sit on the ‘focal plane’ and are represented by colliders and transforms moving through 3D space. I then switch sprite depending on depth and reposition the sprite correctly on the focal plane to simulate the perspective of the camera. Everything is then snapped to the nearest pixel to allow for fluid motion without pixel artifacts.


Unlike the above image the colliders actually ended up being boxes and pushed back behind the sprite. It seems obvious in hindsight but it felt all sorts of wrong with the collision as it was above. The inner collider is for the asteroid itself and the outer collider is the zone for the proximity bonus.


What went well?


My art drew a lot of positive comment and was a reasonably highly scored feature of the game placing 54th in that category. As someone who only started making game art again when I went on paternity leave this felt pretty good. Even more so as I hadn’t made any pixel art or pixel art animations for games before. A lot of this I credit to time spent sitting down cranking out bad vector art for What Now Earthman? it’s getting better but I learnt a lot in the three months I’ve been drawing semi-regularly. I’ve got a much stronger understanding of color theory, shading and other basics than I ever did before. On top of which I learnt that good art takes time (duh!) and not to try to rush through making something. Even a game as simple as Void-Dogs contains a surprising amount of art and it took perhaps half my development time to make it all. Including remaking art for the page.


I ended up with my highest placement ranked 48th for the gameplay. I’m pretty pleased with the gameplay mechanics I added and how they work together. There are three essential layers. First the asteroids arriving in patterns forcing the player to dodge through waves of obstacles. Second the player scores more points for flying in proximity to the asteroids adding a risk-reward mechanic for people that find the dodging gameplay simple adding a layer of mastery. Third other divers will arrive next to you and fight for a short amount of time, the only means of killing them is to hit them with a laser bolt that stuns them and have the splat into an asteroid. This sets up a complex timing problem for the player to solve whilst dodging asteroids and incoming laser fire. These were strong fundamentals to build a fun game on and the feedback I’ve received seems to agree.


The AI itself is a simple steering behavior that has a target, avoids the player and asteroids then occasionally fires towards the player. It’s surprisingly good at hitting you!


I carefully managed my scope throughout the project. Mostly in the classic manner of frontloading the risky items I hadn’t done before. I also kept a Kanbanish working list also meant I could rearrange and remove tasks easily as I went along. I pretty comfortably worked through to the weekend when the days are taken up by looking after a boisterous three year old and two month old! Then I managed to snatch enough time to pull things together and enter my submission with quite a bit of time to spare even if it wasn’t time I couldn’t use on my entry!


Architecture in a jam game? I saved a whole heap of time by doing simple things like separating the component implementing the actions of the diver from the component that controls how those actions are used. Both the player and the AI use the same actions. Similarly the components for sprite scaling and screen positioning were written to be easily shared and meant it was trivial to add in scaling for the enemy entering the game. I have a simple Events system I wrote for WNE that drives a lot of the UI update and game flow between objects that should be decoupled as much as possible. All my bullets and asteroids live in object pools local to where they are used and are drawn from them as needed. Finally the stage design is done within a coroutine and a library of helper functions so it looks a little like this:

yield return new WaitForSeconds(2.0f);
yield return new WaitForSeconds(2.0f);
yield return new WaitForSeconds(2.0f);
yield return new WaitForSeconds(4.0f);

yield return new WaitForSeconds(2.0f);
yield return new WaitForSeconds(16.0f);

I’d attribute finishing this game at all to keeping on top of the code design as I went. Then hacking madly at the end! But keeping things neat made the hacks easier to implement.

What went badly?


I’ve done precious little audio work and it really shows in Void-Dogs. My two lowest ratings were for Sound (#100) and Gameboy Feel (#177). My music selection was a big contributor to the latter, it was the best Creative Commons licensed track I could find which didn’t really suit the Game Boy era and slightly bends the rules on Audio as it wasn’t an asset made for the jam. SFX were made using BFXR and whilst I think they are serviceable as placeholders they don’t really hold together or excite. I think rather than taking on yet another task were I to do this again I’d try to pair up with someone that knows what they are doing. Although I’m trying to get a basic handle on how to make better SFX and where to even start with music just to understand the processes.

Stage Design

I was pretty sure at the start of the jam that I wanted to have hand crafted stages rather than trying to create a procedural generation algorithm in such a short space of time. In the end I only had time to make one stage and iterate on it a little bit after some playtest feedback. Finding fun sequences and building them out whilst also trying to deal with the problems with perspective and the screen getting messy was really challenging! To be frank the result is a mish-mash of ideas in a steady progression punctuated with ‘clone’ fights. One of my biggest missed opportunities was not front loading a clone fight. I think many people probably played the game without reaching the first one! My goal was to have a series of escalating stages that lead the player in but this wasn’t really realised.


Could I have done better in the time I had? Perhaps? I look back through my notes trying to find places I wasted time and it’s really hard to say. I think I could have picked either the obstacle dodging or the clone fighting as the focus and doing both was perhaps unnecessary for a jam. Though I do think they compliment one another and was keen to push outside of the shooter norms. Mostly I think I wish I had more free time to put into it or had planned on taking part and done some prep work.

The single biggest thing I didn’t budget time for was setting up the page which took a lot longer than I thought. Presentation matters in terms of first impressions and to get eyes on your game. Annoyingly the Jam entry page misses most of the instructions and theming which was an issue as I’d included the instructions on the site proper. Hopefully most people clicked through to give it a read but players didn’t have too.

Lessons for future Jams?

This was fun and I’d like to do it again when I have some free time, in particular I think the constraints made for a really fun jam format. The biggest takeaway I have is to team up with other people to cover the bits I’m rubbish at. I’d also like to try my hand at just working on the art and design whilst leaving the lion’s share of the programming to someone else. I like the art process, it’s not what I do in my day job and jams feel like a good venue to practice. Then the usual things for game development in general were really validated for me; have a small scope, make something you know how to do, get the game up and running quickly, playtest and iterate.

It’s time to wrap up the CCP Game Jam posts with a round-up of the remaining games that were made during the jam.

First up is the eminently beardy Team Clean Shaven who made two games, or three if you count that one of them was split into two separate executables! The first game H.E.A.R.T. was a schmup made in Unity divided into a general vertical scrolling kill all the things game with the second portion being a specific example of a boss battle. The second game they made One Heart to Make was a pattern matching board-game where up to three players as the club, diamond and spade suits battled to reassemble the heart.

Team Heartless very nearly missed out on the Player’s Choice Award with their take on dating in Heartbreak Date. The game consisted of a few minigames all bonded together to make a terrible dating experience. Players get the opportunity to try to attract a waiters attention, try to stay awake whilst your date is talking and a brutally hard game where you have to say the things that your date is thinking about to feign interest. Their game was also very well put together and a special shout-out has to go to Scott Rhodes’ excellent audio including some inspired voice acting.

Last but not least is Team Pheasant Preserve who quite possibly made the first game ever in Confluence. Ultimate Wingman Simulator: Heartbreaker Edition – Tragic Confluence was a piece of well written and illustrated interactive fiction. The game was initially intended to be a point-and-click adventure but time pressure forced them into a different format.


Ultimate Wingman by Pheasant Preserve

Ultimate Wingman by Pheasant Preserve


Heartbreak Date by Team Heartless

Heartbreak Date by Team Heartless


H.E.A.R.T. by Team Clean Shaven

H.E.A.R.T. by Team Clean Shaven



After the teams had finished their 36 hour marathon development effort we had a Showcase event in the office canteen. The rest of the Reykjavik office was invited along to try out the games people had made whilst enjoying a few beers. During the Showcase we ran some voting with each person able to vote for one project to be the Player’s Choice. Team Yellow Brick were the winners with their take on the Land of Oz. You play the Tinman desperate to get a heart in order to win over Glinda and have her accompany you to the Valentine’s Day Ball. Each stage of the game sees the Tinman attempting to steal the heart of one of the other famous characters from the Wizard of Oz as part of a bloody rampage. Between each stage the story unfolds via some rather lyrical poetry. The game was built in HTML5 using the Phaser framework.

The title screen.

The title screen.


A little bit of poetry.

A little bit of poetry.


Fighting the Scarecrow to rip out his heart.

Fighting the Scarecrow to rip out his heart.


Tomorrow I’ll wrap up with a quick look at the rest of the games.



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.


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.