As January draws to a close, the annual Global Game Jam returns to keep me up for the greater part of 48 hours jammed packed with learning, playing, creating, and perhaps a little developing. If you have read my previous posts about game jams, you will know that me and my team try something new at every jam we attend. Sometimes this leads us to success (see our work on shaders on Tripwire), and sometimes this leads us nowhere (see our failed attempt at a networked Javascript game at GGJ 2014). This year we turned our eyes to the challenge of an entirely new development engine, the light-weight and incredibly popular Unity engine.
Fortunately my work in C# over the last few years means that the script writing, the crux of Unity’s component based architecture, is already second nature to me. The difficult part has been learning the many standards and practises that form Unity’s underlying framework: how to access objects from scripts, how to create objects in the scene view, how interaction between objects works etc. I will talk more about learning Unity in my next post, but for this post I want to impart some knowledge I have learnt over the course of the last 48 hours.
Firstly, dream big, but plan small. It is all well and good designing a game with procedural level generation and multiple sprawling methods of traversing the world, but that doesn’t mean you’ll make it in time to show it off at the end of the jam. Lock down the core concept and create something that can show it off in 3 – 5 minutes. That will mean that you feel like you developed the game you set out to, but also mean your final game is not lost in a myriad of features and half implemented functions.
Secondly, at the end of the jam one of my lecturers, the famous Rob Miles, gave us this piece of advice: it is best to always have a working version of the game at every stage of development. We suffered massively this year from a massive schedule change near the end of the game jam (with two and a half hours until the judging began we were informed the an hour and a half were being cut from the schedule), which resulted in several elements of our game not being at their best (and sadly meant our audio was missing). In the future I will make sure to always have a working version of the game on one machine, as it will mean not only do we always have something to show, but it will also mean that everyone’s features and elements are in place the moment they are complete.
Hopefully this advice will help you in your next endeavour and help to mitigate any problems you face. If you find yourself with a spare minute, check out the game I helped to make on the Global Game Jam website (http://globalgamejam.org/2015/games/event). My specific contributions were the level design and building and the global effects, such as the underlying level time and lighting effects.
Happy developing,
Adam
Adam Boyne 
Leave a Reply