“23 Hours to Make a 24 Hour Game”

[Parsons School of Design in New York held the Atari-sponsored Retro Redux 24-hour game design event on April 2nd-3rd 2005, challenging college students from across New York to forge games using technology comparable to the original Atari 2600. Our correspondent Matt Hawkins participated as advisor to Team SVA, and has provided a diary of his experiences at the Retro Redux event to Gamasutra.]

Saturday April 2, 2005 - 9:55am – It's another wet and dreary New York City morning, and I find myself drying off in the crowded lobby of a Parsons building. In addition to Parsons students, there are those from several other schools, including NYU, Mercy College, Rensselaer, and the School of Visual Arts where I attend. Aside from the awkwardness that comes from having to be awake early on a Saturday morning, there's a nervous energy that's pervasive throughout, which is to be expected. After all, no one there has ever made an Atari 2600 game and very few really know what lies ahead.

10:10am – Everyone has moved upstairs to the 10th floor, the computer lab for Parson's Design and Technology department, and where we will be for at least the next day. Students from all over the greater New York area have gathered for this event, being held by Parsons in conjunction with Atari; it's the first ever RetroRedux, a 24 hour game jam and the students' mission will be to create a fully functional (and hopefully fun) game.

10:35am – We gather in a room for a demonstration of the toolset where Katie Salen, the director of the graduate Design and Technology program and one of the event's lead organizers, welcomes us with a brief speech. She explains that this is all “an experiment” and that this is one of the first times that so many individuals representing different schools in New York have gathered all at once.

Some info that we already know or was assumed is also run down; it is hoped that working in a 2600-based environment, with its extremely rudimentary graphical, aural, and control capabilities will allow people to focus on design. And Game Maker, the toolset that everyone will be using, should make the process of making a game for the 2600 (it's a WYSIWYG interface, far easier to manage than actual assembly). Plus no one in attendance is at all familiar with it, making the playing field even.

Salen also notes that it's a rather odd coincidence that such an auspicious occasion in which time is such an important factor is falling on Daylight Savings. So “there will be 23 hours to make a 24 hour game”.

11:45am – The demo went well, and everyone has the basic gist of the program, which seemed relatively easy to use. By now, everyone from the SVA team has arrived. There are six members, with two people allotted to two specific tasks. One by one: there's Nelson Ramirez, a senior whose thesis for graduation focuses on mobile game technology and who organized the SVA team. There's Samuel Roldan, whose senior thesis is a side-scroller game. Both Nelson and Sam will handle the sound duties. Then there's Travis Griggs, an animator who's interested in working for a game company, and Brea Taylor-Munro, the only female and junior in the group. She too will be designing a game come senior year. The two of them are handling graphics. Finally, there's Andres Hernandez, yet another senior working on a game for his thesis, and Mason Staugler, who has created several games on his own for various clients; they make up the programming crew.

They're an interesting mix of students who clearly love video games and making them, yet are all from a school where games have no real focus. Everyone hails from the Computer Art Department where animation, dynamics, and storytelling are emphasized. There's only one game design class and I teach it, which is why I'm in attendance as the official advisor to the group for the next 24 hours. I'm there to help them with whatever design issues or problems that may arise, and to simply help them stay on track.

12:00pm – It's the time that everyone's been waiting for: the official start of competition. Salen calls for everyone's attention and hands out small envelopes. Inside is the design constraint that every game must follow, which keeps everyone on a level field by preventing folks from thinking of game concepts ahead of time.

We take our envelope back to our corner of the lab, open it up, read it out loud… and are immediately confused. When our team met up a few weeks beforehand, we knew it was pointless to come up with ideas, but we did theorize what the constraint might be. Considering that the top game chosen might appear in a future iteration of the Atari Flashback console, one of those popular mini consoles that has games pre-soldered into the unit and which directly plugs into the TV, it had to be assumed that no one could create any parody games, at least not those that directly reference another property.

So what was now being asked of our game? “Your game must use a character, setting, or story from an existing videogame, but in a new way.” We were totally confused.

It didn't take long for Salen to stop by each group to clarify what was given, and the theme was then changed on the spot to simply putting something, anything, into unfamiliar territory, or at least that's how we interpreted it, and that's what we went with. We begin brainstorming for ideas.

1:00pm – In the aforementioned meeting, I told the students that the task of making a game for the 2600 was unbelievably difficult, and that a good game took many months to conceive and create, so to do the same in 24 hours would be a Herculean task. But the toolset demo gave everyone confidence that making more than one game in the time allotted was actually possible. So it was decided to start on one game, and then, once the time was right, to begin work on another. A heavy debate began on which game we should start on… the strongest in concept? Or the secondary concept moving on to the best idea once everyone became more comfortable with Game Maker?

By now, there were a few game ideas that everyone liked that were on the board:

1:45pm – Now came the process of fleshing out and elimination.

The bull game was something everyone immediately liked, but again, everyone had their own take of it without a consensus. The same with the puzzle game, but it seemed that no one else wanted to do a puzzler so it quietly slid off the list. The shark game started off as simply fun, but became extremely absurd and complicated as everyone tried justifying the relationship between the sharks and humans. There was this constant debate between “It has to make sense!” and the “It's a 2600 game, for Christ's sake!” As for the siege idea, no one, save the person behind it, could envision such complex mechanics on such a rudimentary scale - one person stated plainly, “We only have one button,” and that was the end of that.

This was the first real instance in which I myself felt torn. My job was to simply guide the team; I could only question their decisions in a manner to help point out possible flaws or show a different approach. I pushed hard for the puzzle game since it seemed to be a comfortable fit on the 2600, with its abstract qualities along with the fact that very few straightforward puzzle games existed on the system proper. But at a certain point, I felt I was pushing too hard and overstepping boundaries. It would be something I would be hyper-sensitive to during the next day. At least I was comfortable with the bull game since its qualities were straightforward and would be theoretically easy to playtest.

2:30pm – After the concept had been refined, production begins. While everyone is doing their thing, I offer to help come up with possible control and scoring guidelines. I also emphasize the need to set up milestones, so it is agreed that a working demo should be ready by 6 pm.

3:40pm – Things become busy and intense. The press is everywhere, with reporters from the New York Times and Game Informer making the rounds and asking questions. There are even little kids, the children of the faculty on hand, who run around asking things. The questioning is beneficial, if only to help the students clarify to themselves what they are doing.

The room is noisy, as the sounds of semi-familiar bleeps and bloops fill the room. Its music to certain people's ears, at least those who can appreciate it.

4:00pm – Problems with the documentation begin to rear its head. Since the technical specifications are inconsistent, due to the fact that it's geared for game production on the Flashback, which itself supports both 2600 and 7800 games (and even crazier is the fact that the chip that emulates both is a NES clone). So everyone has been working on either 2600 numbers or 7800, and even those aren't entirely accurate. The program was created by a homebrew enthusiast who didn't have direct access to the original system's tech specs, and today's standards when it comes to crunching the numbers do not even match with from those back then - everyone must go by assumptions and best reasoning. There is no baseline maximum of what can be done; it's simply asked that everyone creates a game that could be done on the 2600 within reason.

5:00pm – We finally have sound. The group is very pleased.

5:30pm – Despite numerous attempts at clarification, our group is still fighting with the numbers, so Katie has us all meet to discuss a possible solution. At the heart of the debate is whether pixels in the 2600 are true squares or rectangles. In the background, Ms. Pac-Man is running on a stock 2600, and it doesn't help that it's on a widescreen plasma display that distorts the image due to its width. In the end, it's agreed that each pixel will be 4 x 2, and the resolution is 640 x 480, which is significantly scaled back from previously established numbers. I get the sense that a good amount of work has been lost due to readjusting to the new numbers.

6:00pm – The first milestone arrives and is not met. Instead, there are still disagreements with the controls and even the perspective of the action. But a quick sketch from one of the guys makes everything clear. It's the first time that the idea that the game does not have to make perfect visual sense hits home and everyone's faith is renewed.

6:30pm – There are further disagreements over the visuals. This time, it's more of the classic butting of the heads between artists and coders than anything else. It is then suggested by one of the programmers that the team should have one designated leader, who has the final word on all decisions… This never happens.

Dinner arrives and everyone eats hurriedly. The next milestone is set at 9:00pm.

7:00pm – We finally see the bull animated, and the team instantly goes nuts. Confidence goes up again as we are all enamored by the very simple, yet exquisite two-frame animation.

Meanwhile, the two programmers, who are waiting for art to input, are working on the AI by running tests. Even at an early stage, Game Maker is proving to be a tricky program, requiring frequent visits to the developer's forum.

8:00pm – The title screen music is finalized, but then comes the realization that we need a name for the game. After plenty of debate, some heated, "Bull Run!" is decided upon.

8:30pm – It is at this point that I had assumed that people from all the other teams would be lowering their defenses and everyone would be chatting with each other. This doesn't happen; everyone is in their corners, far too engrossed in the task at hand. I wasn't so much concerned with making new friends as I was in sharing possible solutions to everyone's individual problems with the program. At least, I assumed that everyone is having the same problems, since there is no way to tell.

It's also clear at this point that making a second game will, as originally thought, be impossible.

9:00pm – The second milestone passes, and again, there is no playable demo. For the first time, the mood is grim and tension is mounting. As stated before, there is no way to gauge how much progress our team has made compared to the others, but the feeling is that we are behind.

But we can see across the way what another team has on their screen. As expected, the unofficial “anything goes” attitude that we sensed from the others at the end of the second meeting has produced what we were afraid of: people just doing as they saw fit, regardless of it being technically possible on the 2600. It was suggested by at least one team member that we may have to do the same, but everyone ultimately agreed to stay the course and hoping that sticking to the original rules will be acknowledged come judgment time.

11:30pm – Assets are finally being brought together. We talk about taking a break at midnight to play some games and break the ice.

Sunday April 3, 2005 - 1:00am , which is now 2:00am – The game break never happens. Fatigue is setting in, which means certain folk are more emotional. We all laugh extra heartily at jokes, and small, instant arguments break out far more frequently. It's like a dysfunctional family trying to get through the holiday meal without major incident, but some just won't let certain things lie.

And like the mom that tries her best to keep the peace but not able to do a particularly good job about it, I keep myself occupied by storyboarding the sequence of different screens and play a quick game on the Game Informer reporter's PSP.

5:00am - It's now early morning, and tensions are especially high, especially amongst the programmers. A combination of caffeinated drinks, a bug in the program that cannot be fixed, and the fact that they cannot both work on the same file at the same time, leads to a brief war of words. And at this point, I know that there will not be enough time for proper playtesting, which is something I pressed hard for.

6:00am – As new glitches appear, there comes the need to itemize what needs to be fixed and what needs to changed to compensate the lack of time to properly address them. Despite tensions running high, the programmers know it's entirely up to them now to make it all happen; the rest of the team can only sit back and watch. They could have gone off to surf the web, play some games, or get some well deserved (and much needed) rest, but everyone just sits and watches.

9:00am – Things are down to wire, but the game is coming together and is playable. Everyone takes a turn playing the game and is happy that it's finally “for real”. A graphical glitch, one of two big glitches, is finally fixed much to everyone's relief.

10:00am – With just two hours away from the final deadline, and after four or so hours of concerted effort to eliminate the other major glitch, which as to do with the game's scoring and level progression, one of the techs decides to call it a day and go home. And no one had the heart to stop him or give him grief.

We notice all around the some are finally done with their games, with relief on their faces. Others are still diligently coding away. It is only then clear that we were all pretty much in the same exact boat the whole time.

10:15am – It is then decided to chance the scoring mechanism to work around the unfixable glitch. After some quick coding, the back-up plan that was conceived many hours ago as… a back-up plan… is implemented… and works! The game is seemingly done… but not just yet.

10:45am – Everyone has had a chance to playtest the game and everything seems fine. During one play through, it took a bit too much time and effort to reach the end so some numbers are changed making it a bit easier. When we feel finally ready, Katie is called to play the game. To everyone's relief, she enjoys it and the mission feels accomplished.

Folks from other teams finally step forward, curious about “that bull game” they overheard us talking about (like all dysfunctional families, we were quite loud), and took it for a spin. There's nothing more gratify than when your competition plays your game and says “it's fun! I found it sort of boring at first, but really got into it.”

Every member of the team had their concerns at first, but that's to be expected, especially when it's your very first game, as was the case with some on the team. And obviously, this dwelling on the details, and the subsequent “too many chefs in the kitchen” ordeals, ended up putting the game in a less than ideal spot for the most part. But by the end, you could tell that it didn't matter. Whether it was the sense of accomplishment… or fatigue… everyone was satisfied and extremely pleased. We had done it… created a 24-hour game in 23 hours, a damn good looking one, might I add, that was not too shabby in the gameplay department either.

And best of all, in a little over 24 hours after we began, our game, "Bull Run!", took the award for Best Visual Design.