The Problems We Faced In Forty Eight Hours and How To Tackle Them

Part and parcel of any project involving games development is the fact that you will encounter problems. In fact, it’s more than likely you will encounter the same problems that almost every game developer faces on every project they are a part of. When my team and I attempted to create a game within 48 hours at Global Game Jam 2015, we certainly encountered all of these problems, but in an incredibly short space of time. This meant that some of these issues had a much more detrimental effect to our final product than had we known how to deal with these problems before hand. As such, this post looks to examine the problems we faced and talk about what I wish we had known beforehand.

Coming Up With an Idea

Ideas are a malevolent group of beings. When you need them the least, such as when you’re trying to sleep, they flood your brain. However when you desperately need one, they are nowhere to be found. So it was at the start of GGJ15, the moment the theme was announced our brains began to fill up with a million shiny plans, but when we got to our laptops we couldn’t nail down a single idea between us. You could sit for hours as a team, discussing a hundred possible details before beginning to develop, but by that point it is two in the morning and you’re already tired. Alternatively, consider obtaining a whiteboard and pen (post-it notes and a wall are a good alternative) and writing every single one word idea that you can come up with as a team. What this does is two things: firstly, it means each member of your team feels part of the creative process as the board/wall fills with the team’s thoughts. Secondly, as the small ideas fill up the board minds become alight with how they could be combined, leading to people not only coming up with fully fledged ideas, but other people getting on board with those because they can see how the idea has formed based and are probably on a similar train of thought. While this method can take some time, it means everyone feels like they had their say on the final idea, which means they’ll feel as though they have a responsibility to see it actualised.

Planning to Develop On Time

At the start of a game jam, particularly a forty eight hour one, the end seems a very long way off. Certainly, a lot can be accomplished in forty eight hours, but if you take a look at the GGJ15 website the difference between the games that look good but lack polish and the games that seem all but complete is usually due to planning. Taking ten minutes or so to draw up a simple scrum board (with a backlog of features, a list of features being worked on currently, and a list of completed features), and stopping every three or so hours to discuss where you are at can make all the difference. For example, in my team there were a lot of problems when people finished what they were working on and trying to figure out what was the next best thing to develop. Had we had a plan of any description then we would have known what to work on, when it would be needed by etc., and would have therefore had a better game as a result. Even if you don’t end up sticking rigorously to the plan having one there makes everything feel more organised and gives you a sense of direction and achievement as you go through the process, which can help keep you going when things seem a bit bleak at four in the morning.

Not Knowing How to Make X

A lot of time can be lost attempting to solve problems single-handedly. The issue is often not the problem itself, but the person trying to solve it believing they can do so on their own. This leads to too many hours being lost due to several desperate attempts to develop complex methods which will return the right output failing miserably. There are two ways of preventing/dealing with these issues to make sure the amount of time lost to a single problem is kept to a minimum.

One method is pair programming, whether it is sporadic or constant. Having two people look at a problem means that not only do you have twice as many people looking at an issue, but also that the individuals in the pair are less likely to feel ownership over the problem and are therefore more likely to ask for help, whether that is from another team member, a professional, or from the good old internet. Certainly in our team towards the end of the jam we were pair programming many issues that we had given too much time to at the start of the jam, which cost us dearly in the end.

The other method requires the planning that I outlined in the previous section. With a plan in place these problems can be picked up when the team comes together to discuss their progress. When a person is stuck on an issue, taking time to discuss progress between team mates will mean the team is more likely to spot when a person is struggling, which means they are more likely to be offered help or alternative methods of tackling the issue. This in turn means that issues get resolved or at least dealt with much faster than without having the opportunity to routinely check up on each other.

Bringing it All Together

It may seem logical to take your idea, break into as many pieces as there are developers, and work on it separately, bringing it all together at the end. While this can work, it opens you up to several major problems. If one piece is unfinished or missing, it can bring the whole game down or even prevent the game from existing. Finding that out at the end of the jam means you don’t have enough time to truly fix the issue; you either have to cover it over or forgo that piece altogether, resulting in a poorer game as a result. If something dramatic happens beyond your control (for example in our jam with two and a half hours to go the organisers slashed an hour and a half off our development time), it can mean the pieces are rushed together, again resulting in a poorer product as a result. To give you an example, one member of our team had been working on audio for the most part of the forty five hours up to that point, but because we lost so much time we didn’t get a chance to add any of the audio to game the judges saw. Having a device with a working version of your game built and running on it early as possible in the jam means that you always have something to show, no matter what occurs. It also means that when someone develops a new feature or, in our case, creates the audio, they have somewhere to implement it immediately, without having to wait until the last minute collation to assemble the pieces.

Demonstrating your game

Often the final thing to be considered is how you’re actually going to show the judges your game. Will it be a run through of a level, a team member giving an interpretive dance, or just demonstrating the concepts behind the epic storyline you developed? The thing that is often not considered is the fact that this demo, usually between three and five minutes long, is the difference between you winning and losing a game jam. There is no point having a fantastic boss fight if it takes thirty minutes to get there (though if you managed to make a thirty plus minute game in the time limit, good job). From the beginning, consider what parts of your big overarching idea you actually need to make to get the idea across. The game we came up with had procedural levels and multiple endings, which are massively time consuming to develop and almost impossible to demonstrate in five minutes. Think about what you want the judges to see, and what you can explain as they play. This will help to focus your team to only the most important of features. It will also mean that, when the time comes, your game is ready to be shown at its best, with all the particles and lights and set pieces you worked on right there in the first three or so minutes, not hidden behind a hundred locked doors.

If you keep these five elements in mind as you go into a game jam it will mean that, not only do you avoid the numerous issues that we encountered during our game jam, but your final game will be all the better because of your preparation and mindfulness throughout the jam. I hope this will come of use to you in your next jam and will save you from one of the judges saying “Very nice … I have no idea what’s going on though” as they did to us!

Happy coding,

Adam