In Global Game Jam 2012, I came up with…12, no 13 different game ideas.

Yeah, I had a lot of ideas. But how? Coming up with a game idea in a short time might seem difficult at first. But believe it or not, it isn’t: understanding the context of the situation, and letting your gut reaction go wild generates a whole slew of creative game ideas.

The Perspective
In Global Game Jam, you have to recognize the scope and effort your team can put in in 48 hours. That’s a very short time with very little people. Even worse, you’re dealing with a lot of competitors, so to get the attention of the crowd, you want your game to be easy and immediately accessible.

Therefore, your game must be simple, small, and short. It shouldn’t take more than a minute to explain how to play the game. If you can finish the game within five minutes, you can present everything in a timely manner. And if it’s small, that means less time necessary to play-test and squash bugs. Despite the general urgency budding game designers have to create an epic, a Wii Sports angle for Global Game Jam will garner more attention and more points.

The Idea
Now that we have the context out of the way, which ideas tend to succeed more at generating an actual game?

One word: gameplay. Yes, the sooner you establish how to play the game, the better. It’s important to stress how much easier it is to come up with a gameplay first, then create a story and artworks for the game later, than it is the other way around.

As an example, here at the George Mason University this year, we were given an hour to come up and present a game idea.  There were many people who admitted that their ideas were merely gameplay looking for a game. You guys were doing it right. On the other hand, there was a team in Universities at Shady Grove last year who tried to come up with the story of the game first.  They struggled to write anything on paper for nearly 3 hours.  Clearly, they were doing it wrong.

Frequently, a team will change its mind about the artwork, the story, and even the end goal halfway through development. This is fine, and in fact, encouraged. You should keep an open mind about how you want to present your game. But you still want to retain the backbone of your game: the gameplay.

The Theme
When the theme is presented, I see many people attempt to analyze and evaluate what the heck the theme means.

Stop right there. You only have 48 hours. Don’t waste the first hour determining what the heck the theme is, especially when your event coordinator is nice enough to reserve this brainstorming session for you.

Instead, let your guts handle this. Whatever your first impression was when you saw that theme, write it down. Or if you’re talented enough, draw a picture. The latter is much more favorable.

Now look up. What’s your second impression? Does it remind you of another game? Write it down.

Look again. Does it remind you of a song, a book, or a movie? Write it down.

Keep at this. It doesn’t matter how much you dislike the idea; it matters that you have any. After all, you want to keep your games simple, small, and short. Your impulse reactions are good at that. Your logical mind, on the other hand, isn’t. Don’t worry about the details. Gameplay first; presentation later.

Putting it Into Practice
So what were the ideas that I came up with? What were my impulses?

This year’s theme was an image of an Ouroboros. Thanks to Harry Potter, I knew the image meant the cyclical nature of things, and my immediate reaction was, “Awesome! I can use that idea that was nagging in my mind during the hour-long drive to this college campus!” This eventually became our game, Susie’s Summer Home.

OK, I admit, that was cheating. But I did have more.

Second, I notice the circular shape the snake was making. My mind went immediately to gears, and I wrote down, “something to do with gears.”

Looked back up again. I noticed the head was at the bottom. It made the picture feel heavier at the bottom than at the top. I wrote down, “gears with gravity: the bottom of the gear is heavier than the top.”

Up again. I see three colors in this photo. I wrote down, “graphics: white, gray, and black.”

Rinse and repeat. Snake eating tail. I wrote, “make the snake eat its tail. P.S. yes, everyone else must have thought of this!” I can’t emphasize enough to write down ideas, even if it isn’t original or unique. Maybe everybody else thought it was so obvious, they dismissed the idea. Just as likely, maybe nobody thought of it. It doesn’t hurt to take the risk

I’m on a roll here! Lets see…that circular negative space is interesting! I wrote, “level where the character navigates the white space. See: Echochrome.”

And so on and so forth.

Last Words
That’s how to do it, boys and girls! It doesn’t matter too much whether the game idea applies strongly to the theme or not. After all, the people will be judging by the end product, not by how much it relates to the theme. Instead, it’s most important to keep in mind that the game must be simple, small, and short. Also remember, that it’s easier to build game off of gameplay than the story, artwork, music, or even presentation.

In both cases, your impulses are insanely good at those. Use it wisely!
[social_share/]

Leave a Comment on Coming Up With a Game in Global Game Jam | Categories: Game Development

I know this is very, very late, but here’s a look back at how our Global Game Jam 2011 game went. Rather than focusing the advantages and the disadvantages in our final product (which I describe on another webpage, anyways), I’ll be evaluating how we went through the development process for this game.

The Team

To me, the most important part of any software development process is how well the team works together. Frequently, the smallest things causes development to halt, such as miscommunication between two members, the lack of trust, perfectionism, or straight-out laziness. All too frequently, I’ve worked with teams that were heavily demoralized by a single team member, who refused to cooperate. As such, I strongly value a team who’s communicative, ambitious, friendly, but also self-critical.

In this sense, the team I worked with–Ruben Brown, Carrington Dennis, Damion Jackson, and Marcus Whitfield–was excellent. Everyone was ambitious, but at the same time, understanding. The artists, Damion and Marcus, were right there when I needed them. Although we’ve had a few arguments here and there, rarely did I feel that our team was uncooperative or lazy. I have no regret with working with you guys, and I definitely look forward in teaming up in the near-future.

The Process

A good team, however, is nothing without a plan or a process. Unfortunately, this was where I think we started faltering.

The first problem we had was the plan. Ruben began by outlining several meanings of our theme, extinction, on our white board. From there, we’ve pondered for about 3 hours on how to make any of the written keywords into a game. My first red flag.

In most game jams I’ve went to, I found it easier to come up with a gameplay mechanic first, then eventually cover it with theme-related story, artwork, and music. This proved itself once again when, out of impatience, I pitched an idea about a game that initially used an entire keyboard, but gradually reduced the number of usable keys. Within an hour, we were able to agree upon an intriguing idea to develop on: a tower-defense game where each defense, the limited-use ground mines, was detonated by a key on the keyboard.

To be fair, I was the only one in the team that went to game jams before. And four of them were eight hours long.

For the process, we tried to get immediately started. Sadly, the majority of us didn’t know how to use Unity 3D, the game engine we decided to use. While I was able to get started immediately, both Ruben and Carrington had to go through a number of tutorials to get themselves oriented with the tool. While this wasn’t detrimental in the beginning, it certainly had an impact towards the end, where weird bugs started cropping up.

On the good side, we did get a prototype working within the middle of the second day. It wasn’t a particularly fun game, however, and Ruben pitched a different idea: a game where you drop a ball onto the keyboard.

Towards the end, where we started working on this idea, weird bugs started happening. Certain folders didn’t appear to be committed in subversion, despite adding them at least twice. The explosion assets that made the first prototype visually entertaining stopped working entirely on our shift. Perhaps the worst moment was when the operating system boot-loader GRUB suddenly stopped working on my computer, and I had to ask another kind person burn an Ubuntu image to fix it.

The Presentation

Given a small presentation window we were given, I think we’ve largely succeeded in selling our idea. Many people were intrigued about our unique control scheme, and within the casual audience, I think we’ve garnered the most attention. That said, it wasn’t without faults. For whatever reason, the game was unusually unresponsive on Carringtons laptop, and we had to switch to Ruben’s instead. Some people also were cautious about how they dropped the ball.

Despite this, things did turn out for the better in the end. While I admit our game is in desperate need of re-analysis and re-exploring, the controls was enough a selling to catch attention.

Also, Ruben, please don’t make up a story at the top of your head. That wasn’t necessary.
[social_share/]

Leave a Comment on Boomshakalaka Postmortem | Categories: Game Development