My name is Steve Williams, and I am a MMO gamer and also a casual gamer. Give me an MMO, and I’ll play it. Give me a simple Flash game and I’ll play it. Wouldn’t it be fun if someone could mix the two flavors together and make a peanut butter cup of gameplay that would satisfy both MMO fun and casual fun?

So let’s talk about what mini-games are doing in a self-respecting MMO like Stargate Worlds - let’s talk about putting the peanut butter into the chocolate and making something tasty.

Since time immemorial, or at least the past few years, MMOs have focused upon two things: Killing stuff (and getting their loot) and making stuff for people to go kill stuff (and get their loot). As building games goes, that’s a pretty good spread of features, and it’s not too hard to make that work.

Recently, however, the thought struck the minds of some developers out in the deserts of Arizona that a lot of fiction is built not around killing things (and getting their loot), but in solving problems, thinking up solutions, and generally interacting with the world in some manner.

If you watch almost any episode of Stargate SG-1 (or Atlantis), you’ll see that the basic plot revolves around getting into big trouble, and then solving a puzzle or working a gizmo or device to get out of big trouble. That’s what we call good TV.

Enter mini-games for Stargate Worlds. In SGW, we will present situations in which you can solve a puzzle, can work a gizmo or device, and get out of big trouble. Instead of walking into a room and shooting a big, flashing-red Jaffa until he dies and rifling through his bloody clothes for goodies, you will do all the above in order to get to the real goal: hacking into a reactor control to save a civilization from a disatrous meltdown.

So enter my job. As a systems designer, I get to take the basic concepts like “hack into a reactor and save the world” and turn it into a fun game you can solve in a few short seconds. The process behind this is what we’ll talk about here.

The first step to designing a mini-game for SGW is to identify what the player will be doing, what we call the “verb” of the mini-game. To continue our reactor reprogramming example above, the verb would be “hack.”

What does “hack” mean? For inspiration we go to two sources: movies/TV, and computer/console/board/card games. In movies and TV, we have many role models for “hackers” - Indiana Jones, Corporal Hicks, Axel Foley… and of course Sam Carter. In computer gaming, there are many, many examples, like Paradroid.

So at this point you have a lot of cool characters in your head, and you have lots of fun games in your head - a primary skill for a designer is to have a massive database of references in your head - and you distill those things that are most interesting to you.

For a hack-type game, we have two important role models in Corporal Hicks and Axel Foley, and a number of hack-type games like Pipe Dream, or Paradroid. Hicks had a lot of problems, but when it came to hacking into locks and computers, he was competent, confident, and cool. Axel Foley is the same way - no matter how dangerous the situation, Foley would whip out a MacGyveresque solution, like using a chewing gum wrapper to break into a secure building. We want that vibe. In Paradroid, you hack robots and take them over by manipulating the power flow to their circuits. We want that vibe too.

So now we have a basic idea to work with, and we have some mental references to try and match. There’s two ways to proceed from here - one is define the parameters of the game, and the other is to define the look and feel of the game. For Hack, I started with the feel - “find and cut the red wire.” The closest type of game that corresponds to that are what are known as hidden object games, like 5 Differences. As I was designing a hidden object game that emulates a tense situation, I worked a little more on the feel - I wanted visual noise, a logical but confusing timer ticking down fast, sound feedback that was both ambiguous but useful (you can solve this game with your eyes closed), and lots of red herrings to work through.

It was at this point I had an epiphany - one of my absolute favorite movies is Sneakers, starring everyone cool. In Sneakers, there is a scene in which the blind hacker “Whistler” is using sound signals from a probe attached to various phone trunk lines to hack into the phone switch box for a building.

This became my holy grail - working with Nick LaMartina, I devised a series of sounds that are derived from phone phreaker lore - the Red Box tone, a dial tone, 2600 hz - the sorts of sounds Whistler in Sneakers would be interested in…

So now I had a game - using sounds and your eyes, you need to find a wire hidden in a bundle of wires and clip it.

Thus, we moved to parameters. This is where math and the psychology of “fun” collide. Did we want to cut only one wire? Was the timer constant? Were there “green wires” that if you cut them caused bad things to happen? What about other clues than sound (the player may have their sound turned off!)… and we’re off to the races.

You get a lot of numbers on paper, you get a lot of ideas specced out in design, and you stop.

Stopping is always the hard part - especially with a mini-game!

Over-design is a tough beast to slay. You always want one more feature, one more bell or whistle. Hack only needed a few features: confusing timer, bundle of wires, visually noisy design, and the tones that play when you interact with the wires.

In other mini-games, paper prototyping would occur, but with Hack it was apparent what few features were needed, and which ones (sadly, with a heavy, heavy heart) needed to be cut.

The second to last hurdle: explaining your design to the coders, artists, sound folks, and other designers who would be building, integrating, and incorporating your game. If an encylopedic knowledge of culture and gaming is a primary tool for a designer, a secondary tool is simply this: the ability to explain a design to an artist and a coder, both of which normally have mindsets that are downright alien to your sane, normal mindset.

Building any game is like watching the ocean. Progress on a feature advances and recedes like waves - you get the prototype, you test it, and then it goes away for another pass, it comes back, you test it - you give feedback, you balance, and you send it back…

And so we come to the last part of building a mini-game, “polish.”

Unlike large systems or single games with no hooks, the mini-game in Stargate Worlds is linked in many, many ways to other parts of the game. You get experience for completing a mini-game. You get loot. You can register and have NPCs call you to do mini-games for them… all of these are fraught with peril as balance issues. Do we want players kicking back with a cup of tea and play mini-games to level up? What does it mean when you get uber loot from clipping a wire in less than 12 seconds? Questions, discussions, compromises - the game industry is based on collaborative effort of a lot of passionate, creative people, and an MMO is possibly the razor’s edge of this aspect of game design.

In the end though, you get to send out the mini-game to a bunch of testers, listen as the sounds you helped create are beeping and booping from dozens of speakers, listen as aggravation at loss and the joy of victory comes from what started as a simple verb written on a sheet of paper: “hack.”

That’s the point you reach over to the others who worked on the mini-game and shake hands. And since we have a game to ship, you wipe your brow and grab the next verb from the list…

Check out the original entry from Steve Williams, complete with additonal links here.