From Concept to Game in 48 hours: Global Game Jam 2011

This past weekend I participated in Global Game Jam 2011, an international event in which small groups of game development enthusiasts attempt to build a game in 48 hours. It provides an opportunity for people who love games to share in their passion of making games. This year the event was a huge success, with 6500 participants resulting in over 1500 games. I was part of the game jam at UC Santa Cruz, which included over 50 jammers. While building a game in 48 hours was a highly rewarding experience, it provided several interesting challenges. 

Day 1: Design

The game  jam at UC Santa Cruz began on Friday at 4:30 pm. The kickoff event included several motivational talks from Brenda Brathwaite, Graeme Devine, and Tom Lehmann. The event also provided participants with this years theme: Extinction. 

The first challenge of the jam was to split the participants into small teams of 3 to 6 participants. The organizers handled team construction by having participants list their desired roles and then assigning captains for assembling teams. I had already decided to work with another participant before the event, which helped streamline this process. The result of team building was that I was assigned to a team consisting of three game design undergraduate students and a lead programmer (me). 

The next task was to decide on an idea for our game. We began this process by looking through a dictionary for definitions of the term "extinction". One thing that caught our attention was the use of the term extinction for the act of extinguishing. We entertained the idea of extinguishing light in a game that involved lurking in the darkness. While we did not immediately agree on this concept, it ended up being the focus of our game.

We then formed a consensus about the concept of our game: you control a character that is lurking in the darkness and must avoid contact with light sources. The character can extinguish light sources as well as place additional objects that interact with light. We had now formed an idea of what we wanted to build (the fun part), and all that was left was to build our game (the hard part). 

Next up was deciding on how to build our game. While the game design curriculum at UC Santa Cruz focuses on C# and XNA, we decided to go with Processing instead. We choose this option because it provides an environment which enables prototyping with minimal code, and also because the team I was working with was enthusiastic about learning another platform. Processing turned out to be an excellent language for our game, because it enables projects to be exported as applets playable via the web.

The next challenge we faced was deciding how to implement our game design. We wanted to have a game that enabled the player to interact with light sources, but due to time constraints we limited ourselves to a 2D game. To implement light sources in a 2D space, we decide to implement a particle based system for lights. However, we did not know going into the project if we would be able to build convincing light sources given our target platform and design.  

During the remainder of the evening, into the early hours of the morning, we starting building a prototype of our ideas. We had an idea about the game we wanted to build, but felt that we needed to really get something implemented before we could determine if the design decisions we had made were going to be fruitful. Therefore, Friday night we started building our system, even though we did not decide on the mechanics for our game. We were able to quickly throw some functionality together and by the end of day, we were able to move our character around, and put light sources on the screen. We now had enough structure in place for our two level designers to work on levels independent of the main code push.

The title screen from Within the Darkness.

Day 2: Mechanics

I started the second day of the jam quite early, and I found that this was a good time to start introducing several new mechanics into our game. When the rest of the team joined up with me on the second day, we were able to start discussing the level design for our game. In contrast to several other games at the jam, we focused on building a game with multiple levels. Therefore, I focused on setting up our game for dealing with multiple levels and split up the code base to deal with concurrent developers building levels. As a lead programmer, my goal was to provide as much functionality as possible to the designers, enabling them to work on levels for the game, independent of the main game code base.  

However, there was still a huge concurrency issue. In addition to my role as the lead programmer, we had another member that was heavily invested in coding. Typically, this issue of multiple programmers would not be a problem, because of a source control system. But due to the tight constraints of the jam and internet speed issues, we did not want to spend time on setting up a proper repository for source control. We decided to use DropBox to share files across multiple team members. This required a great deal of communication that would not be feasible for a lengthier project. 

Day two of the game jam was mostly a huge code push. Processing helped to keep the amount of code manageable and our code base was less than 5000 lines of code. At the end of the day we had enough code in place for dealing with different levels, but our game had a lack of polish and a lack of content. Until this point I had been acting as the team lead, but at the end of the second day I relinquished control and let the rest of the team take over. I ended the second day relatively early, but had provided enough structure for the rest of the team to implement a wide variety of levels. 

Placing shadow walls.

Day 3: Polish

During the third day of the jam I was pretty exhausted, but my team had really stepped up. Given the framework I had provided, they were able to put together over a dozen levels. We had the unique experience of throwing together a game with enough infrastructure to really start looking into future projects. With some polish, the game we threw together in a weekend could be applicable to several platforms.

One of the main things added in the third day of the game project was animation. We started with place holder graphics (colored rectangles), which were later replaced by sprites. It was great to see our monochrome art transformed into a higher fidelity game experience, and it was quite rewarding for the content creators to see their assets used in the game. Plugging team assets into the game really strengthened ties between members of our team. 

The final challenge we faced during the 48 hour gauntlet was the ability to have new users play our game. This can be stated as follows: if somebody brings their children in to play our game, will they be able to pick up the controls and understand the interactions in our game? We addressed this problem by introducing several tutorial levels in which the mechanics of the game are progressively introduced. But due to team communication issues, the controls provided in the tutorial did not initially match the controls in the game.

This made playtesting difficult, because we had to walk every tester through the controls and mechanics of our game. Ideally, players should be able to play and perfect our game with no outside influence. Given our constrained timeline, we decided to skip a complete in-game tutorial and instead provide help instructions on the website containing the game. We felt this was the right tradeoff for the 48 hour constraint, but would have really liked to explore how to gently introduce game mechanics and complexity like Portal.

We are proud of our game!

Postmortem  

And here is the result of our effort: Within the Darkness. I am quite proud of what our small team accomplished in 48 hours, but looking back I have some recommendations for myself and possibly others embarking on a game jamming quest.

First, design is key. There is no need to computationally prototype a design until it has been physically tested. We completely ignored this step when we could have easily put together a test environment using a handful of flashlights and construction paper. By physically prototyping our game, we could have more quickly ruled out unnecessary features. For example, in our game the repulsion and attractor abilities serve the same purpose, but act differently.  

Next, I would have liked to have included a more diverse set of abilities in my team. My team included a senior programmer and several designer/programmers. This limited our options to procedurally generated content for the most part. If I had embraced a wider pool of abilities, we could potentially have produced a game with more vibrant graphics. 

Another regret I have is the lack of levels present in our game. While Within the Darkness includes a dozen levels, it barely explores the idea of resource scarcity. Some of the same levels could be re-utilized where the same level is presented, but new resource constraints are provided to the player. 

And finally, audio. Our game lacks sound, be it music or effects. This was partially due to our use of Processing, which enables audio through only third party libraries. However, this was a skill set lacked by our team, and therefore lacked from our game. This is a facet of games I would like to fully embrace in the future.

Acknowledgements

The Global Game Jam is a product of the IGDA. The jam at UC Santa Cruz was made possible by  Foaad Khosmood and Teale Fristoe.