A couple of weekends ago, I participated in the Game/Play Jam at Melbourne's NGV Studio, where local game developers were tasked with creating a game from a collection of drawings that had been made a day earlier, by participants who had visited the space.
gameplayjam11_drawings
It was inspired by Adam Saltsman's Idea Bucket event, although luckily for us the collating and scanning process was undertaken by the Jam's organizer, that indomitable champion of gaming Paul Callaghan. It was an interesting day, and the first Jam of any kind that either I or my co-conspirator Russell Dilley had taken part in. While initially I was somewhat apprehensive due to my disbelief that anything could be made within such a short amount of time, I now feel it was a great experience, and one that I'd recommend to anyone interested in holistic game development. Here's a breakdown of the day from my perspective: 10:00 AM Russell and I arrived, set up our laptops, and started working. We'd done a bit of preparation the previous day - creating a subversion repository for the project and making sure we could do some simple things in Flixel/AS3, such as rendering a sprite and loading+reading an XML file - but other than that, we were starting from scratch. While we chatted about what ideas we should pursue with the game, I began to convert the art to usable formats/sizes using the IrfanView batch utility, while Russell started working on the game states. 11:00 AM 
bbqattack_11am
After an hour we had the drawings rendering on the screen at the correct scale. When looking into scaling images in Flixel, we found that doing a dynamic scale (versus pre-scaling the image) was up to 10x slower. Even though we knew our game would probably not be an intensive program, we still decided to make sure everything was pre-scaled to the size we wanted. We had decided to go with the idea of putting the characters in a bubble, and then having spiky things come at them from the side of the screen. Russell suggested we make it two player, and that a good way to use as many of the hand-drawn images as possible would be to allow the players to select their characters. This sounded good to me, so he began work on the character select screen state while I followed this tutorial and made a quick bubble in Inkscape. 12:00 PM 
bubble
At this point Russell had added the intro screen and was partway into character select, while I had split the database into "hero" drawings and "enemy" drawings. As mid-day passed us by, we started to worry that we hadn't started on the gameplay functionality yet, so that became my next focus. 1:00 PM 
Ab1YDakCQAAOhnJ
Nearing the halfway point, Russell had finished the first pass of character select and was moving on to the end-game states, while I got the player's selected character and the bubble loading into the "play" state. During this time, I noticed that I'd incorrectly batched the images and they all had transparency issues, so I quickly went back, fixed the issue in the batch process and re-exported. 2:00 PM 
bbqattack_2pm
After having ironed out the transparency issue, I grabbed Russell's input code from the character select screen and got the player characters moving around in the play state. My next task was to get the bubble-like physics working and smoother character movement, while Russell implemented the second player and some game-specific input functionality. 3:00 PM 
bbqattack_3pm
We now had input working and the players moving around in a bubble-y fashion, and bouncing off the edges of the playfield. With only two hours left, I began to look into getting the enemies in and working, while Russell started picking some sound effects out of Sound Librarian. 4:00 PM 
Ab2lA7MCAAAa3QP
After getting the first enemy in and flying across the screen, my next key task was to define a "collision area" for each enemy - we couldn't simply use a big centre-oriented radius for the enemies like we had for the characters in the bubbles. I ended up doing this by defining a radius and offset for the collision within the XML files for each creature. Having spent the previous hour preparing some great sound effects, Russell got to the point of putting them into the game and realised they weren't in a format that Flixel/AS3 would play. We had a quick discussion about this, and decided his last hour would be better spent improving the 1-player win, 2-player win and intro screens, instead of hunting down a solution for the format issue. 5:00 PM 
bbqattack_5pm
The last hour was a crazy rush of getting the rest of the enemies in, improving the timing for the enemy spawn speed and setting up the timing regarding when more difficult types of enemies would be spawned. At the last moment we decided to make the players collide, and to create a "bounce" effect that occurs when they touch - making the multi-player mode decidedly competitive, as players could now bounce each other into oncoming enemies. Russell got the win states working for the single-player and multi-player states, and in a stroke of random luck found that he could place the characters on the win screen such that they look like they're standing on the hill in the scene. We packed up and were ushered out before merging our final changes, but the game worked - we'd made a game in seven hours. You can play a final version of BBQ Attack! here - it has had a couple of extra hours of work put in as we merged those last changes, tweaked the screens a little more and added a preloader, but we've made no fundamental changes to the build that we had at the end of the day. As we travelled home that evening, revelling in the fact that we'd created a game in a day, we came up with three reasons why it was a worthwhile experience: Possibility All things considered, what we were able to achieve within those seven hours far exceeded our expectations. We now know that a prototype for any kind of (fairly simple) game should be no further than a few hours out of reach, and that knowledge is incredibly empowering for a game developer. Cutting the Chaff As a game programmer, especially when working on projects where you're in charge, you can easily get caught up with developing the game how it "ought" to be developed, making sure each system you're creating is modular, easily extensible and fully featured. This focus on excellence can be a great thing when working on projects for extended periods of time, but needs to be thrown out the window when prototyping. We came a lot closer to distilling the process of game development down to exactly what is necessary, and realised that developing quick prototypes in an environment suited to it (such as Flixel or perhaps Unity) makes much more sense than developing them in other environments, particularly when you're not familiar with that environment. Bad Game Count ++ In any creative field, whether it be writing, painting, film-making or game development, there is a common mantra that is repeated as advice to aspiring creators - your first creations will be bad, but you have to push through and keep creating, and eventually you will have the experience and ability to make something good. Regardless of your evaluation of BBQ Attack!, it's probably not going to win any awards at the IGF (and not just because we didn't submit it). But through making it we gained some measure of experience that will contribute to our next creation, and when we eventually do make something awesome, the experience of creating BBQ Attack! will have somehow informed that game's development. Thanks to Paul for organizing the event and inviting us to participate, our fellow Jammers, who were great to hang out with during the event, and the people of Melbourne who drew those sweet pictures that fill our game.
