Between the 11-12th of June, I went up with a friend and fellow Windows Games Ambassador Aaron Smith, along with a games design student Nathan Holding to the University of Hull for ThreeThingGame, the University’s 24 hour games jam. The premise is that each team was provided three words, and were tasked with making a game that incorporated them. The games would be judged on how well they fit the three things, and the quality of the game overall and the winning teams would get prizes.

This was going to be an interesting event for all three of us, as despite being used to travelling around several campuses for events, Hull was way far out for us. We were also aware that the majority of students there had been at ThreeThingGame before and new how it all worked. However Aaron and I were a bit more confident in what we could pull off together since we went through a games jam one week prior, where we learned to have a proper functioning version control system that the tools can work with, as well as having an actual artist working with us this time. Our three words were Room, Moon and Lune, and from that we made a Lunar Lander style space game where you avoided asteroids and landed on moon bases.

We also had an additional tool to work with, my Ricoh2DFramework. I don’t think I’ve mentioned it before on this site, but the Ricoh2DFramework is a framework for MonoGame. The purpose of the framework is to provide classes to assist with graphics, collision, input and audio among other functions. I was actually quite eager to use Ricoh2D in a game development project to see how well it works practically.

Game Development went rather well, and while there were some small issues found in the Ricoh2DFramework, they were easily fixed and all of those changes have been uploaded to the Ricoh2DFramework’s repository. There were also some performance issues that required some work arounds in order to avoid (slow downs, glitches and crashes galore), but in the end we finished the game.

What went right:

• Proper source control: Using C# and MonoGame with Github is much better than the last games jam at Stafford, where we tried to use Unity with Git. Overall it was a nightmare back then to merge all the changes and ensure the project work. Using a system that is completely text based and readable made the process much more easier.
• More prepared: Using the Ricoh2DFramework definitely saved some time in developing the game, and even though the framework had issues they were much quicker to deal with instead of having to build everything up from scratch.
• Having an artist: Definitely enables the team to work on the game while assets are being created, instead of having to be made during or after development where issues can arise.

What went wrong:

• Didn’t sleep enough: All three of us, me especially, thought we could spend the entire night working on the game. We didn’t. I could barely stay awake after literally staying awake for 24 hours, even with an abundance of food, drink and snacks to help us keep our energy.
• Technical issues: While some performance issues were most likely due to some of the original code that was developed for the game, we also had numerous unexplained crashes from Microsoft and SharpDX libraries. This was especially bad when the game crashed unexpectedly with an unhandled exception while judges were looking at our game. This could’ve been one of the reasons why we didn’t get a place in the rankings, but since we were still using the Technical preview, hopefully issues would be ironed out afterwards.

Overall, I rather enjoyed ThreeThingGame. It’s a neat idea for a games jam and everyone at the University of Hull was very enthusiastic and eager to make games, which makes it even more impressive as the University doesn’t have a specialist games course unlike Staffordshire University.

Now it’s back to the Procedural Level Editor and my newest game project Gem Finder, where I’ve already started on new features…