Friday
Video games are computer programs, made up of the same 1s and 0s as every other piece of software. Putting those 1s and 0s in their right order is, in essence, a technical exercise requiring technical skills.
Yet the best games also involve the best storytelling, character development, sounds, graphics, and cut scenes. They are complex forms of art. No one person can create all of these elements alone: games must be made collaboratively, which is why big-budget productions are team efforts. Aspiring video game makers must know how to work with other members of a large group, usually under time pressure.
It’s hard to grok that sort of skill from a book, or a how-to course on the web. But you can learn it at a “game jam”: a weekend-long event where game designers, artists, editors, programmers, and assorted other tech heads come together for ad hoc, start-to-finish game-development projects. This January, I went to my first, Toronto Global Game Jam 2015 at George Brown College.
I’m twenty-three years old: young by professional game-design standards, but right around the sweet spot for a game jam. At TGGJ, the crowd is a mix of university students, long-time hobbyists, and established industry veterans. There are plenty of teenagers, but also a good number of middle-agers.
As I mingle, I learn that many jammers have published games on their resumés. When asked what I do, I say I’m a gaming generalist, before admitting that my only real skills are self-taught, mostly involving Java and Unity. (Early games were typically programmed from scratch. Most modern games are created and edited on an existing “engine,” such as Unity, that automates common video game elements. Engines handle the nitty-gritty details of simulating physics when characters and objects bounce around the screen: detecting collisions, loading new levels, rendering 2-D and 3-D graphics on screen, and more.)
The opening ceremony happens at 8:30 p.m. The organizers lay down the rules and code of conduct—basically, don’t be a jerk—and assign us to various rooms. I am sent to 516, the destination for unaffiliated floaters like myself. By the end of the night, it is expected that we will assemble into teams, pick concepts, and figure out ways to generate playable games before the Sunday 3 p.m. deadline.
The process that follows is decidedly low tech. People mill around looking for groups to join, with a few self-appointed leaders passing around ideas on Post-it Notes. Teams form organically; I end up embedded in a group of six that is brainstorming concepts on a whiteboard. Someone suggests an idea called “choose your doom,” and ears perk up. As it’s explained to us, the game would place its protagonist inside a dark room with half a dozen objects. You pick up an object, get led down a path, make a few quick choices, watch an animated vignette, and then die. It’s weird and morbid, but original.
Adam, a 3-D artist and TGGJ veteran, steps up and leads the meeting. The group talks about scope, and takes stock of everyone’s role. Adam and another artist agree to start drawing the CGI models we will need to bring the game to life visually. A coder wanders into the circle, and is immediately conscripted as our lead programmer. I and another first-timer, Neal, are put down as “jacks of all trades”; the two of us agree to begin sketching out the structure of the game.
As we start, I worry that I might be a bad fit for this: I have no experience with 3-D, and don’t see how a game this ambitious can reach a playable state in less than two days. Creating simple 3-D shapes isn’t difficult, but the choose-your-doom concept rests on the idea that characters will have detailed, distinctive, plot-critical objects to play with. I could probably lose a day just learning the tools required to handle this sort of game design. I politely indicate that I’d like to walk around and see what the other groups are working on before I commit.
I luck out almost immediately by meeting Bryan, an energetic, fast talker who is studying advanced game development at Toronto’s Seneca College. He wears square glasses and a Super Mario T-shirt under a red plaid button up; if we had known each other in high school, he would probably have been one of the guys I hung out with at the local Internet café at lunch. Unprompted, he lays out the new idea that will become our game.
A lone pilot is travelling through space. His ship is damaged. Every attempt to repair something leads to unpredictable side effects and a loss of resources. Eventually, the damage becomes unfixable and the spacecraft crashes. The player is scored on his or her performance. In my mind, I picture the indie game FTL: Faster Than Light, a critical and commercial success that came out in 2012. I make a quick sketch in my notebook of how our game will look to the player; this becomes the basis for our prototype.
So far, Bryan has teamed up with a 2-D artist named Caio, an illustrator from Brazil who is trying to break into the game industry. Since my own art skills are limited to editing basic shapes and characters in Photoshop, I’m happy to have a real artist on board. (As the weekend progresses, our team will grow to include Nick, an audio engineer who creates our game’s music. A floating 2-D animator named Ryan said he’d try to help out, but never found the time.)
The two of them tell me they’re looking for me to be the game designer—the one who will keep the project on track, coordinate its various components, and build a demonstration level in time for the deadline.
After I agree to their offer (and inform the choose-your-doom group about my choice), an intense brainstorming session follows. Bryan, Caio, and I start to sketch out the major game elements. The spaceship theme stays; the player will have direct control over a single character. The camera will be fixed: positioned so that the whole ship is visible, as though its ceiling has been ripped away so the player can stare straight down into the control room. We briefly consider having multiple controllable crew members, but decide it’s too much work to draw, animate, and program artificial intelligence for them. (The crew eventually make it in, but only as passive entities. The player must keep as many of them alive as possible as life support shuts down.)
I furiously scribble down everything the team throws out. Concept art; gauges; buttons for the user interface; a loose flowchart of the script. Near the end of the meeting, we realize we need a name. At some point, I write down Space Panic!, which seems to stick.
After 11 p.m., I walk away for half an hour to process everything I’ve written on my pad. I pace the halls, observe the other teams, watch some FTL gameplay on my laptop, and stare at my notes until I can fully picture Space Panic! in my head.
I quickly sketch out a revised blueprint to show my team. I remove the complicated resource-management system that Bryan described, and replace it with simpler gameplay. Now, the player just has to worry about just one resource: power.
To make the plot more exciting, we establish a concrete goal—to get the spaceship to a home planet before its reactor runs dry. To accomplish this, the player must reroute power from non-essential systems in order to keep the engines going. Bryan seems disappointed by my retreat from his original vision for the game, but concedes it’s probably the only way we’ll complete a prototype by Sunday.
We make a task list. Bryan will start programming the power-management system that forms the core of our game. Caio will use my rough sketches to draw the environment and props. I sit down to set up the main project, and download some temporary concept art so I can test our progress first thing tomorrow morning.
By 1:30 a.m., I’m too tired to go on. Bryan intends to stay all night to keep working—not an unusual choice at a game jam. Caio plans to do a bit more, but says he will leave to sleep at some point. I say my goodbyes and catch the bus home.
Saturday
I wake up at 8 a.m., full of energy and eager to get back to TGGJ. I pack my bag with a toothbrush, my laptop, and some snacks. I scarf down a sandwich on my way out the door, and head back to the campus.
I find Bryan where I left him at his computer. He shows me the multi-pronged resource-management system he has created overnight. It shows great promise, but is far more complex than what we’d discussed. I feel both impressed and frustrated. I wonder if my partner might be a little too good for the type of game we are trying to make. I explain that we will need a simplified version by this afternoon so I can begin testing.
Caio has completed a mock-up of the ship. The overall look is great, but he has fully drawn out the level layout, something we hadn’t talked about. Rather, what I wanted was a set of modular components, like Lego blocks, that I could put into whatever configuration works best for the design of the game. I try to channel my inner manager, saying that while this is a collaborative effort, it’s not the artist’s job to determine how the level should be precisely mapped. I try to avoid sounding mean or patronizing, but worry that control of the project is slipping away.
I tell myself these frustrations are part of the jam experience. There will always be creative differences among team members. That is equally true at the professional level, which is why learning how to deal with these situations now is important.
After our team breaks for lunch, I quickly build a start menu and game-over screen so we won’t forget them later. I also do some writing and basic programming to get a game tutorial ready. I make the narrator a snarky AI that ridicules and taunts players who mistakenly kill crew members. (It’s a rip-off of Portal’s famous antagonist, GLaDOS, but I can’t resist.) This works fairly well in the end, adding flavour to the game. I have ambitions for voicing the character, but am running out of time.
With Bryan and Caio still working on their components, I go see what some of the other groups are up to. Although Unity seems to be the engine of choice for many teams, it’s not universal. Sitting near us, for instance, a solo jammer is writing his game in Java, which means it will be playable on an ordinary web browser.
Another team in our neighbourhood features a pair of women, Amanda and Marika, making a text adventure. Amanda is a web developer who once worked in video game publishing; Marika has no game-industry experience, having worked in TV and theatre. She is writing the text for their game, and Amanda is building a web app to run it. People learn fast at game jams: by the end of this weekend, Marika will take on some of the coding.
Around 5:30 p.m.—with less than twenty-four hours before the deadline—I ask Bryan to send over the files he has been writing all afternoon. As I get the code imported, and survey where our project stands, I feel overwhelmed with everything I have to do. We still have no functioning game level, and only about a fifth of the fully formed art we will need. I’m not sure if the game mechanics will even work as intended. I step outside for a quick walk around the neighbourhood to calm myself down.
Then I go back to work, fixing the “scripts”—instructions provided to the game engine—line by line. I am telling the software what I want it to do whenever the player performs a game action. As a skilled programmer, Bryan has written his code in a way such that even a noob like me can change how it works by adjusting different values in Unity’s interface.
At 7 p.m., we eat a pizza dinner provided by the organizers. The hours that follow are a blur: I work continuously, pausing only when I need to call Bryan over to solve a programming issue, ask Caio for a new drawing, or go online to look up a tutorial for Unity. I’m not alone, as most other participants seem to be on round-the-clock benders of their own.
By 3:30 a.m., I’ve become stuck on a problem I just can’t seem to solve. I glance over at Bryan, but alas, he is passed out in his chair. I make a backup of our project on a USB drive, toss it in my bag, gather my coat, and quietly leave the room.
There are no bunks, cots, or couches in the building, only an empty classroom that jam organizers have converted into a makeshift sleeping room. Unfortunately, I didn’t think to bring a sleeping bag or pillow. Instead, I wrap myself in my winter coat, put my gloves and hat beneath my head, and pass out perfectly flat on my back for two hours. It’s one of the best sleeps I’ve ever had.
Sunday
When I return to my desk, Amanda asks if I want to go to McDonald’s for breakfast with a few other folks. Sounds like a good idea. I quickly wolf down a Sausage McGriddle as we chat about the game industry. Amanda, a veteran of several publishing houses and mobile development companies, gives me some career advice. Go independent, she says, because the big publishing houses don’t care about art, only profit.
From a consumer perspective, I agree. Many of the highest-profile gaming franchises, such as Call of Duty, have become like Transformers movies: flashy and fun, but also uninteresting. (I should say that the most recent instalment, Call of Duty: Advanced Warfare, shows some signs of creative life.) Meanwhile, titles by smaller game makers are growing more popular, with online platforms such as Steam and gog.com—think of them like iTunes Stores for games—allow designers to self-publish. There’s also crowdfunding to consider. Double Fine, an independent game company based in San Francisco, has enjoyed massive success on Kickstarter by offering to revive a genre that had almost completely disappeared from mainstream gaming: the point-and-click adventure.
The local scene I am experiencing this weekend reflects that shift. For those who want to make big, expensive console games, there is pretty much only Ubisoft Toronto. However, for those aiming smaller, there’s a plethora of studios often looking to hire—such as DrinkBox Studios, makers of the critically acclaimed Guacamelee! And Super Time Force, a game made in Toronto by Capybara Games, was featured on stage at a Playstation Experience global press conference last December.
By 2 p.m., following four or five hours of intense collaboration, Space Panic! is in halfway playable shape. Our team spends its last hour testing the game and ironing out its bugs. With minutes to spare, I upload the game’s executable file and source code to globalgamejam.org, where anyone can see and download it.
We perform the obligatory high-five. It has been a group effort, but I feel a personal flush of pride too. I now can tell people I’m a game designer who has actually produced a finished, playable project.
After the closing ceremonies, the jam makes way for an evening open house, where members of the public are invited to come and play the newly created games. I seize the opportunity to take the grand tour as well.
Some games are straightforward and clearly basic, if well-made, first efforts. Others are highly experimental, and take me by surprise. One team—composed of an artist and programmer from Ubisoft—has combined an Oculus Rift virtual reality headset and DK Bongos peripheral controllers for a Nintendo Wii to create a busking simulator. (As you hit the bongo drums in time to music, 3-D subway passengers on their way to work either toss money at your feet or frown and storm away, depending on your performance.)
Why do people come to a game jam at all, I find myself wondering. Why not just work with collaborators over Skype, email, or something like that? Because, I think, creative people usually require some degree of social stimulation to do their best work: there’s a reason, after all, why so many writers so often work in cafés.
During this weekend, I was constantly surrounded by fellow geeks who share my passion and interests. The fact that I could use them to crowdsource my technical questions was an added bonus; someone with whatever skill I needed at the time was usually sitting just a few desks away. There is a pay-it-forward attitude that emerges when everyone is open and ready to be helpful. At a game jam, I’ve learned, there is no such thing as a trade secret.
