Our first game jam: Ludum Dare 33

Last weekend David and I took part in our first ‘game jam’ event. As part of Ludum Dare 33 we had 72 hours in which to make a game from scratch (or as close to that as possible) following a prescribed theme. You can find our live-updates that David was posting throughout the weekend on our Ludum Dare page (start from the bottom) but I’ll give a summary here.

If you would like to play the game it’s available from our Ludum Dare page or directly from our website. You can also download the project source.

The weekend


David arrived at my house on Friday and while waiting on the official start and theme announcement (not until 2:00 Saturday morning) we had to decide on the technology we would use. It came down to a choice between something simple in 2D using HTML5 or Python or making use of Cubiquity in a full 3D game engine like Unity3D or Unreal Engine. While I was apprehensive about the production-readiness of Cubiquity for Unreal Engine we decided that it was worth giving it chance, even just as a test of the system. Also we really wanted to have destructible scenery worked into the game somehow!


Saturday morning we woke up to find out the theme this time was ‘you are the monster’. After working through some ideas (hunting Pac-Man as a ghost or a moving-maze labyrinth game) we settled on a simple fantasy-style twin-stick shooter where you kill villagers with fireballs. Choosing the game to make was one of the hardest parts as it’s very easy to get carried away and it’s difficult to have a sense up-front as to the difficulty of some part of the design. Deciding to start from as simple a concept as possible with plenty of scope for adding features along the way definitely turned out to be the right decision as we were able to get a first draft working quickly, knowing that we would have something to ship.

Since we were using Unreal Engine we decided that I would do the programming and David would develop the artwork. I set to work playing with the twin-stick template provided by Unreal Engine and tried to get a handle on how AI and navigation works in UE4 (something I’d never worked with before). The documentation on this was very good though and within a few hours I had a working prototype with enemies moving towards the player, firing arrows.

Meanwhile David had been hard at work getting some assets ready, primarily a first draft of the game level and some character art. All the artwork was done using MagicaVoxel which David had never used before now either.

The monster

The monster in MagicaVoxel about 16:00 on Saturday

By the end of Saturday David had most of the in-game props made (including towers and trees) and was starting to get more artistic with the design of the level itself. I however, having got Cubiquity integrated was having a lot of trouble getting it to play along with Unreal’s navigation mesh creation. In the case that we weren’t able to get the two to play nicely within the time limit we devised a potential hack of making the Cubiquity terrain simply visual but non-blocking and recreating the basic collision shapes with Unreal primitives for the navigation system to use.

We went to bed exhausted from a fraught day, not quite as far along as we would have liked but happy with the progress nonetheless.


I started Sunday with the aim of getting a complete working first version with as much of the art in as possible and all of the basic features. It was helpful for David to see the art in-game so that he could start iterating and make sure that everything looked correctly scaled against each-other. By mid-afternoon we had a first complete version of the map in the game and an early version of the complete combat process between the peasants and the monster.

First version of the models and scenery in-game

First version of the models and scenery in-game about 16:00 on Sunday

From this point on it was ‘simply’ a very large polishing process and working through our feature wishlist, hoping to get as far as destructible terrain. Throughout Sunday afternoon and evening we really found our flow and were both making very good progress. By the end of the day David had mostly finished the game map and I had a working game which, if necessary, we would have been ready to ship.

The full map at the end of the day on Sunday

The full map at the end of the day on Sunday

While we hadn’t got as far on Saturday as I would have liked, I felt that by the end of Sunday we were further along than I had expected. Luckily this gave us a whole day to iterate and tweak and make the game feel less like a tech demo.


On our last day we were starting to feel the crunch. When you’re counting down the hours you have to start prioritising and so we each started working against a to-do list. David spent a lot of time fleshing out the map and trying to make sure that there’s always something interesting on screen as well as paths to encourage the player to explore. I was working hard to make sure that we had everything in there that made it a polished game such as a HUD, help text, depth-of-field, sound effects and powerups.

Until this point we hadn’t created a full build so I spent an hour or so getting that working and testing it on David’s computer so that he could iterate on the artwork and have it appear directly in-game.

Almost final version of game about 16:00 on Monday

Almost final version of game about 16:00 on Monday

We still didn’t have voxel destruction in-game but soon after lunch David convinced me that I should see if it’s possible to get it to work easily. I’d been putting it off due to potential problems with collision and navigation mesh updates but I decided that to first order I would just do the voxel destruction under an explosion and make collision and navigation ignore it. In the end Cubiquity made this easy and very quickly we had the effect you see in the game. I’m glad David encouraged me to try to get this working as I think it makes a big difference to the feel of the game.

With about an hour to go I realised that while we were recording the player’s score to the screen during the game it was hard to pay attention to it while playing so often you didn’t know what highscore you’d achieved. With less than an hour to go until we would stop development I threw together a highscore system which ended up working very well.

David spent the last hour or two doing things like writing a readme, looking into the submission process, setting up hosting for the game download and making some artwork. In the end we submitted at about 19:00 on Monday.

Final thoughts


Since I was alone doing the programming there was a lot of pressure to get something working at the beginning. However as soon as we were underway I got into the flow of it and really enjoyed it. I think we were realistic with our scheduling over the weekend with

  • Day 1: Prototype of game
  • Day 2: Make it into a real game that is theoretically submittable
  • Day 3: Polish

Unreal Engine really did make things very easy and it’s great to still be using the engine which I first played with 17 years ago. Making real use of Cubiquity with UE4 showed me the areas where I should focus next, particularly the packaging pipeline and asset management.

The things I’m most proud of are the voxel destruction and the highscore system. They were both very late additions but they’re the main things that have been mentioned on the Ludum Dare review page. They both could have easily been left out but the game would have definitely been worse off without them. This really demonstrates to me the importance of polish in a game and helps justify that final ‘10%’.


This Ludum Dare was a really interesting experience for me. Despite being a programmer, I was keen to try my hand at doing art because being a Jack-of-all-trades is very valuable in indie game development. I’ve also been really impressed by some of the things I’ve seen made with MagicaVoxel, so was curious how well I could do, and I’m pretty happy with the result considering my previous voxel art experience was limited to making the enemies in Voxeliens (about 50 voxels each!).

One quadrant of the map loaded in  MagicaVoxel

One quadrant of the map loaded in MagicaVoxel

MagicaVoxel is a very cool program and I’d definitely recommend budding voxel artists play around with it for a few hours. There isn’t a lot of documentation though, and most things had to be discovered by trial and error. There are alternatives such as VoxelShop and Qubicle Constructor so I hope to play with those in the future to see how they compare (the main reason for using MagicaVoxel was that we already had a rudimentary importer for it).

Overall I really enjoyed doing voxel art and hope to do more in the future. In the past I have purchased small pieces of voxel art but I don’t think I’ll be doing that again when I can make it myself! This should open up many more options for making future demos in Cubiquity.

This entry was posted in Uncategorized by Matt Williams. Bookmark the permalink.

About Matt Williams

Matt is Computer Officer at the University of Birmingham in the UK, providing support and management of computing resources for Particle Physics research. For Volumes of Fun he manages the website as well as looking after the build system, Linux porting and continuous integration for PolyVox. Follow him on Google+.

2 thoughts on “Our first game jam: Ludum Dare 33

Leave a Reply

Your email address will not be published.