Directory of All Essays

Saturday, December 06, 2008

Post-it note design docs


I happen to fall into the artist-designer skill set, so I often find myself trying to prototype ideas on teams rich with programmers. As such, I'm always looking for better game development techniques that work well for this particular team mix.

Here is a very lightweight prototyping process using Post-it notes that I quite enjoy.

  1. Initial idea: I sit down with an available programmer (and artist/UI designer depending on the system) and we chat about how to test out a new bit of gameplay. Usually this is an idea that has been bubbling about since the night or week before.
  2. Post-it note design: I jot down a quick bulleted list summarizing our discussion on a single post-it note. We go over it one last time so there everything is clear. The list isn't very detailed. Mostly it serves as something to jog our memories if we forget what we were talking about.
  3. Build it: The programmer and artist go off and build the items on the list. It might take 2 hours or two days. They are encouraged to solve problems creatively and they can always just give me a shout if something doesn't make sense.
  4. Play test: When most of the items on the Post-it note are playable, I get called over and we play test it the experiment together. If the results are comprehensible by mere humans, we pull in some play testers for 3-4 minutes to observe some real players interacting with the mechanic for the first time.
  5. Review: Afterwards, we discuss our observations and write up another Post-it note worth of improvements.
  6. Repeat or Stop?: The process repeats until we run out of time or give up. Sometimes we give ourselves a day per experiment, sometimes two days. In the land of Scrum, we treat the experiment like a time boxed task.
  7. Rate: At the end, the gameplay experiment is rated according the scale below.
  8. Save: The code is saved off, a few choice notes are recorded in a doc containing our 'list of experiments' and we move on. Bits of code, even from failed prototypes, are often reused in future gameplay experiments.
Rating system
The rating system is delightfully crude. The goal is to triage experiments quickly.
  1. "A": These experiments were obviously fun. Players laughed, smiled and generally exhibited the emotions we were looking for. If in doubt, ask "Was this fun? How so?"
  2. "B": These experiments showed a hint of fun if you knew what you were looking for. However, it is going to take more effort to expose the fun in a manner that is visible to the players.
  3. "C": There wasn't any fun. The experiment fails.
A portfolio of fun
One of my favorite aspects of this method is that you end up with a mini-portfolio of game design ideas. Instead of putting all the design risk in a project on one or two unproven mechanic, the team now has a half dozen or more proven bits of fun to build upon. If some don't fit into the game or get abandoned for other reasons, that's alright. You can afford to lose a few and the end product will still be fun. Think of it as designing from a position of plenty.

Contrast this with a prescriptive 'design doc' approach where you are forced to pick, without much evidence, a main mechanics for production. Even for the most experienced designer, 50% to 80% of your 'educated' selections are going to be complete dogs. Every unproven mechanic you polish ends up being a massive drain on your budget and your reputation as a designer. You might hear gentle comments like, "We spent 3 months of dev time on this lump of an idea and it isn't fun?"

It doesn't take very many expensive failures for the project's perceived 'design risk' to blossom to the point where conservative minds seek to kill the project. I think of this as designing from a position of sudden death.

Some basic observations
Here's a quick list of things I've observed when prototyping.
  • Failed experiments happen a lot. Don't be surprised if C-rated experiments occur 50% to 80% of the time. Everyone on the team has to be aware that not every experiment is going to be a success, but the learning process is still worthwhile.
  • Designing on your feet is a critical skill: Each consultation and analysis might last only 10 to 20 minutes and you need to leave folks with that all important sticky note filled with impactful, yet inexpensive changes. It pays to have lots of ideas and a deep understanding of game mechanics so you can quickly pull together a list of incisive comments. If you can't, you likely are not suited to be performing the designer role.
  • Listening matters. The designer doesn't need to come up with all the solutions. Everyone on the team is bright and has great ideas. As a designer, your role is to herd all ideas (yours and others) into something that serves the next step in the prototype.
  • You need programmers: If there aren't programmers dedicated to prototyping, the prototyping isn't going to happen. You can drop down to paper prototyping, but it usually doesn't prove out many types of mechanics (especially ones involving timing and interfaces.)
Advanced observations
These are some notes that are a bit geekier, but can save you large amounts of pain.
  • Meta game mechanics are harder to prototype: The systems that link together the various gameplay experiments are harder to playtest. They operate on longer time spans (hours instead of minutes) and often require that the core gameplay is already fun.
  • Build a meta-game architecture that allows for loose coupling of gameplay experiments: Most successful games have an architecture that allows the team to plug in new bits of fun as they are found. The linear 'level-story-level' pattern used by most FPS is one example. The 'hub with many sub levels" used by Mario 64 is another. Any of these allow you to plug in a new experiment independently of the other gameplay experiments. If you don't have a modular architecture, you run into situations where a fun new system breaks many of the other bits of fun you've already discovered.
  • Integrating tightly coupled gameplay experiments is a pain: If I independently find a fun new type of weapon and an interesting enemy AI, the combination of the two is often a non-trivial issue. The new weapon many work with an old AI, but be completely useless with the new one. Integration yields a whole new set of experiments. Plan for time to rediscover the fun all over again.
Benefits
There are some interesting benefits to the Post-it note design method:
  • Scales nicely to large prototyping efforts: One designer can serve multiple programmers. This works nicely on teams where there are more programmers than designers and you need to get a lot of prototyping done quickly.
  • Failing quickly is fun and educational. You learn a lot with each failure and can move onto the next experiment with a much better idea of what doesn't work.
  • Provides a quick death for bad pet ideas. It is much harder to resurrect pet ideas when you have concrete, playable proof that it won't work. Finding out early which one of my favorite ideas is idiotic saves me a lot of political pain.
  • Fun prototypes are quite convincing: A fun, playable crazy idea works a lot better for winning over other team members than any amount of hand waving or documentation.
  • An easier team to assemble: Finding a competent game designer and a competent programmer can often be easier than finding a competent programmer-designer. Well developed hybrid skill sets are very valuable, but can be quite rare. A side benefit of having a team is that you end up cross training your designers and programmers. You create designers who can speak to programmers and programmers who can riff on some of the design.
The value of dime-a-dozen designs (A brief aside)
One often hears the negative comment that game designs are a dime-a-dozen. And in a waterfall design process, an incessant stream of ideas is indeed a problem. If you attempt to squeeze all those ideas into a typical waterfall development process, you end up with an immense amount of waste. Each designs need documentation, concepting, implementation, testing and bug fixes. In response, project owners will often ask for just one good idea.

There is another path. A lightweight prototyping method takes your flurry of crazy ideas and converts them at moderate cost into a well sorted portfolio of working designs. All those ideas are not, in fact, worthless or wasteful; they are the essential fuel that feeds a good prototyping process. Each idea either teaches you something or provides you with a success.

The way to make the process work without getting gunked up is to make prototyping incredibly lightweight. Other than our focused conversations, I spend my time on a total of two design docs: The first is the brief list of rated prototypes and the second is a set of discardable, temporary Post-it notes. Design waste in the form of unnecessary artifacts is minimal. Most of the 'programming waste' is better classified as low cost learning.

Those wild flocks of churning, swirling ideas end up not being worthless at all. They simply need to be funneled into the project with the right process for their value to be realized.


Conclusion
The "Post-it note design process" has likely been reinvented in one form or another hundreds of times across the history of game development. It is so basic that it feels odd to even write it up in any sort of formal fashion.

If you have a designer and a programmer, give it a shot. It is certainly a good functional alternative to the popular process of sticking a lone programmer-designer in a room and asking them to 'find the fun'. Both can produce great games. Pick the one that works best for your current team composition.

This process does have an cost since you need to devote at least two people to finding the fun instead of putting all decisions on the head of the designer. However, the end result is well worth it. After all, it is far smarter to spend team time uncovering a portfolio of the right mechanics than it is to 'save your programmers' so they can be off running really fast in the wrong direction.

In the end it really isn't about programmers, designers, design documents or features. It is about the team working together to make the right product. Everything else is just ego and waste. And for some reason, it is quite difficult to invest much ego or waste in a little disposable Post-it note.

take care
Danc,
Post-it note fanboy

Labels: , , ,


Read more!

Sunday, October 14, 2007

Lessons about failure


I happened across a wonderful nugget of design philosophy, while reading an interview with Clinton Keith, the head of High Moon Studios' technical department. It bundles up lessons from Miyamoto, the joy of failing fast and the benefits of using Stage Gate-type processes in one delightfully juicy quote.

"If you want someone to fail, you want them to fail fast, before they spend a lot of money. That's how Nintendo was. When I was working on the Dream Team [at Angel Studios], they wanted us to do this DNA-based driving game called Buggy Boogie. You had these vehicles that would eat other vehicles and adopt their powers and morph. It was really cool. But they would sign three month contracts, and Miyamoto himself would say that he did not want any documents. He would just say, "Find the fun, and I'll be back in three months to take a look at what you have."

We went through about three iterations of that. We busted our hump trying different things, but at the end of it, he kept coming back and saying that it wasn't there, and it wasn't fun. We were a new company that didn't know how to make games. After about six or nine months, he came back and said, "You guys have really worked hard, and we see the progress, but we're not seeing the product. But another opportunity has come up for a fantasy golf game, so why don't you guys work on that? In three months, we'll be back. Show us a golf game."

So rather than getting pissed off at us and canceling the contract after two years and millions of dollars, they spent just a tiny fraction of that with a small team and said, "Well, it was just a bad idea." It maintained the relationship with them, so we could go off and do something else.
The Lessons
Here are the tidbits I squeezed out:
  • Give yourself a short period of time to 'find the fun' in a design. Give a small team for a few months to iterate on a new design idea. Your goal is come up with the enjoyable core game mechanics. Toss the lengthy design docs. That can come later. If you don't have the fun core of your game, all the design docs in the world won't help your title.
  • If the fun isn't there, move on. Many ideas are bad ideas. You didn't know until you tried. Luckily game designs are a dime a dozen, so perhaps another one will be more fruitful.
  • If you do fail, it isn't the end of the world. Failure is a reasonable and obvious part of the process of creating games.
Much of how creative people see the world is marred by the success bias. We are constantly surrounded by successful, beautiful creations. It is natural to assume that somewhere out there are people who can just create an amazing game at the snap of their fingers. We look at our lump of an attempt and the comparison can be soul shattering.

What we don't see are the failures, those thousands of experiments that never made the final cut. There is a thread over at TIGsource where they are posting incomplete projects. This is the reality, the secret underbelly of both the marvelous IGD competition entries and many commercial successes. You will fail many times before you creating something amazing.

The multitude of playtests that arise from the plethora of exploratory project will inevitably give you more failures than successes. The smart folks use failures to learn and improve. Failing quickly and cheaply means you'll get to really good ideas faster. The path to success is intentionally strewn with failure. Embracing failure is a fundamental lesson of good design and one that is not taught nearly enough.

So when you look at your feeble, twitching prototype and compare it to the latest vibrant screens of some Miyamoto masterpiece, don't give up hope. He likely went down that path as well. Pick yourself up. Is there are spark of fun in your idea? Can your coax it into a bright flame? If not, you should have no regrets. For there is always the next glorious idea waiting to be explored.

take care
Danc

Labels: , ,


Read more!

Monday, May 15, 2006

Cheap custom whiteboards for rapid game prototyping


I started doodling with the Comicall prototype this weekend, but I needed a large number of custom shapes that I could draw on multiple times. I found some Post-It notes that were covered with a whiteboard-like material, but they cost $5 for a pack of four. That gets expensive rather quickly.

Instead, I found a tip online that said you can use glossing contact paper, the sort typically used for covering drawers, to make anything into a dry-erase surface. I picked up 15 feet worth of some glossy clear contact paper from the local store for $4.95.

I applied it to some blank white cards and cut them into the shapes I desired. It works like a charm. The dry erase markers come off easily, without a trace. I grabbed some multi-color pens that have the erasers built into the cap so it is remarkably easy to make small changes on the fly as you evolve your prototype.

The downside
The marks do rub off easily with very little handling. I’d use this technique in the following situations:
  • Early rapid prototyping where you are changing tokens very fluidly and can’t be bothered to be constantly cutting out new tokens every time you make a change.
  • Board design: If you have a custom board for your game, this allows you to lay out the board quickly and rapidly as well as make quick changes. Any whiteboard will do.
  • Games that allow user modification of the board: This is a pretty inexpensive way of letting users draw all over things. I bet that there are all sorts of core mechanics that have yet to be tapped that use this ‘advanced collaborative user content driven’ technology. ;-)
You can always make certain marks permanent by using a permanent marker instead of a dry erase marker.

Any other fun prototyping tricks that you've come up with? One of my favorites comes from Chris. He puts his prototype cards into baseball card holders to give them instant protection and 'heft'. Very useful.

Take care
Danc.

Labels: ,


Read more!

Friday, October 28, 2005

Article: "How to prototype a game in under 7 days" on Gamasutra

Here's a great little article on prototyping. It is rare that you see such a dedicated prototyping effort described in such detail. At times I feel like those who write about game design are anthropologists wandering deep in the Amazon looking for signs of some highly elusive tribe. Most activities are done in secret, under the cover of darkness. and when you actually get a chance to a design ritual in action, you should whip out your notebook and frantically take as many notes as possible. :-)

Toys
One of the suggestions that came up was to make a 'toy' first and then add goals like scoring. This concept of toys has come up repeatedly. Chris mentioned it in his book and numerous other authors have attempted to make the distinction between toys and games. Each is describing a different slice of the same basic puzzle.

A toy has been described as a simple fun activity that 'feels good'. It also has been described more formally as an environment that allows players to create their own goals. Both of these can be categorized as low level core game mechanics that do not have higher level meta mechanics.

A toy is really a simple risk / reward system. Do A and reward B occurs. The risk is often minimal and can be described in terms of opportunity cost or irrevocable decisions. Rewards do not need to be numbers increasing or stars. A little animation, a new graphic or a sound effect are all simple rewards. The article describes this as 'juiciness', which is a delightful term that speaks to the inherent reward in many tactile activities.

We often forget that mechanics like score are meta game mechanics layered ontop of simple tactile mechanics. The coin collecting in Mario is a layer on top of the simple activity of jumping. The score in asteroids is a layer on top of the highly rewarding act of shooting asteroids and watching them explode.

In games like that Sims that are described as toys, there is a simple risk / reward to watching your Sim perform an order. There almost always is an existing core game mechanic. Where many people get confused the nature of such a game is that they expect a plethora of higher level goals to direct their actions. They look for things like a score or a mission or other familiar mechanics that have been used in their favorite games.

None of these elements are needed really. All they do is explicitly reward and enhance a particular play strategy that emerges from the players interactions with the existing game mechanics. Here's a thought experiment. Imagine playing Space Invaders. A particular player enjoys sitting in the right hand side of the screen as a method of controlling the space around their character. He has a series of implicit goals about not moving too far out of his zone.

This player is creating his own rules, punishing himself when he breaks his rules and feeling satisfaction when he executes them well. This emergent goal creation is evident in almost every game that I can imagine. The mere fact that you have choice means that you must choose a play style and build up internal goals.

So the boundary between games and toys is remarkably fuzzy. All games have emergent goals. Most games that are described as 'toys' have risk / reward sequences at their core. At best, I see the term 'toy' as being useful to describe the general flavor of the gameplay to an existing experianced gamer. More often than not, it gets you very little practical information for further refining your design.

I lean towards a term like 'highly layered' when I judge a prototype. A title like Civilization is has a large number of concretely defined strategies that are explicitly rewarded and expanded upon with complex layers of meta mechanics. A new game prototype will have one or two of these risk / reward layers and the player will be forced to make strategic leaps without much guidance.

Measure the player strategies
Here is a useful method for adding additional layers to your game prototype that the article touches on very briefly. Start by building up a game is to create a core game mechanic with a focus on an enjoyable 'juicy' activity. Then watch what the player does. What activities are repeated? Which goals does the player set for themselves? Often this takes the designer's touch at the early stages since it can be difficult to get players to explain their momentary urges.

Once you've identified these primitive strategies, try to create risk / reward sequences around them. When you are popping bubbles, perhaps popping three in a row gives you points. When you are jumping on something and yelling 'Gotcha!', wouldn't it be nice if the thing you were jumping on broke and maybe gave you something for your efforts.

take care
Danc.

Labels: ,


Read more!

Sunday, August 21, 2005

Common Game Prototyping Pitfalls

I’ve spent some time in previous posts describing the benefits and process of game prototyping. You’ll create more innovative game mechanics, weed out bad concepts early, and help ensure that your final product is highly addictive. As with any good technique, there are several notable pitfalls and drawbacks to prototyping that a savvy practitioner should be mindful of.

How can you prototype successfully when…
  • Your programmer tells you that he needs 8 months to implement the cool DX 9 engine you need and another 4 months to build out the game’s architecture. Only then can he start the prototype.
  • People keep getting pulled off the prototype to work on other high priority projects
  • Your prototypes end up being stupid mini-games that no one cares about
  • You create games that are fun for you to play, but everyone else seems to hate them.
  • Your idea for the next greatest FPS MMOG Adventure game seems far too big to prototype.
Read on to find out how solve these common prototyping dilemmas.

The need for fundamental engine systems
Of all the pitfalls, the need for infrastructure is the most difficult to overcome. Most games need substantial game engine system in place before they can be prototyped. The list ranges from graphics engines to networking support. It is nearly impossible to prototype a game like Doom if you don’t have a 3D engine. It is also difficult to prototype an online game when your engine had not networking support.

In the worst case situations, you’ll need to build these items before you can begin exploring your game mechanics. This is costly, time consuming and gets in the way of the real task at hand: rapidly exploring a series of game mechanics. In many cases, I’ve seen momentum for the project completely extinguished. In others, the spirit of prototyping is lost. There ends up being so much effort invested in the infrastructure necessary to support a particular game idea that it becomes politically unreasonable to radically transform (or even kill) the concept.

Solution - Use an existing engine: My recommendation is to use off the shelf or preexisting engines that have most major systems in place. Ideally, you can work at a higher level by manipulating pre-existing blocks of functionality and focus on roughing out the game mechanics. I’ve seen great success with multimedia tools like Flash (2D) and Anark (3D). Those with a bit more of a programming background can do amazing things with Torque or other off the shelf engines.

When selecting an engine for prototyping, be sure that it is more than just a rendering engine. Having preexisting systems for handling simple physics, collision detection, player movement, path finding, and input device support can make your life much easier.

The misplaced urge to create sound architecture
The spirit of prototyping is one that is best suited to off the cuff hackers and geniuses. In mere hours, the prototype needs to be playable such that the feedback cycle can begin. Hackers, though deadly in the long run, will cobble a prototype together by hook or by crook. The code will stink, but it will work. Geniuses will get the prototyping up and running just as quickly, but they’ll have enough experience to give themselves room in the code to build a competent architecture.

There is a third group that believes deeply in good architecture above all else. This group will spend 3 weeks creating the most beautiful data structures the world has ever seen. “If we don’t *insert engineering speak here*, we will be screwed.” To which, I reply “Bullshit.”

Unless you are talking about engine systems, most prototypes do not need to be overly robust architectures to test the basic game play. In fact, it can be quite damaging.

Consider the downside of perfectionism at the prototyping stage. In the prototype The Secret Lives of Aliens I had proposed a core game mechanic based on a conversation simulation. Building that out is a good chunk of work. Instead, we went with the stupidest mechanic possible and within a couple of hours discovered that the entire system was simply not fun from a game play perspective. If we had spent the time to build a robust conversation system, the project would have been delayed by weeks and major momentum would be lost.

Solution – Set strict time limits on architectural work: The goal is to create a prototype that can be critiqued, trashed and thrown away. The goal is not to create a finished product. There is a time and a place for spending copious time on your architecture and the prototyping phase is not it. Depending on the personality of your team, this can be your biggest project management challenges.

Importance of project momentum
I’m going to harp on the importance of project momentum when it comes to prototyping. Very few prototypes have any sort of official buy off and are generally seen as throw away activities. Prototypes are one small step removed from game design ideas and everyone knows that game design ideas aren’t worth a hoot in this industry. Everyone has a dozen in their pocket and 99.99% will never turn into anything. In the grand pecking order, prototypes are almost always projects of low individual value.

If a prototype is not showing results, team members will begin to focus on other ideas or project management will move team members to higher priority activities. There is almost always something higher priority than a prototype that isn’t going anywhere.

A prototype becomes something more valuable when it is an enjoyable mini-game that shows great promise. At this point, people begin to get excited about the project. They’ll put in the extra time if needed and it becomes more difficult for the project to have its resources taken away. A project with momentum can go through a dozen iterations in a short period of time. A project without this momentum might hit two or three iterations in the same amount of time. Both projects can have killer game design ideas at their core, but poor execution of the prototyping phase will kill off the low momentum project before it even has a chance.

Solution – Prototype early and prototype often: Focus on early results and do everything you can to keep the momentum going. Promote your early successes and outline the immediate short term steps you are taking towards success.

A roadmap with clearly defined, visible chunks of meaningful functionality can be a great help in organizing your work effort. By making each chunk of work small enough to easily build, you ensure that there is always a constant stream of interesting results coming from the prototyping project. Avoid long gaps between prototypes at all cost.

Locking in mechanics too early and reducing the scope of the game.
When you get the first prototype up and running, there is an urge to immediately perfect the game play in all ways. Common critiques tend to be very detail oriented:
  • Is the text readable?
  • Does clicking on the character have a satisfying feel?
  • Is the timing on the respawn too fast?
All sorts of little details that make your prototype an awkward player experience shout for attention and you really want to polish the heck out of the prototype immediately.

If you create your list of ‘Things that suck” and then fix all these little details, you’ll end up with a short, trivial mini-game that isn’t really all that fun to play. You’ve locked in the game play too early.

Solution – Focus on the design on the big picture: A better tactic is to look at the game from the standpoint of its future potential.
  • Can the player make meaningful decisions?
  • Is the player getting the feedback they require to make good decisions?
  • Are the major risk / reward schedules in place?
  • What is the pacing of the experience?
  • Is there enough meat here to hang the rest of the game on?
These higher level questions will reveal fundamental problems with your game play and point to additional systems that must be added. Often by thinking big and then paring the design down to its core elements, you’ll end up with a prototype that has the foundation for some major game play elements.

Getting feedback from the wrong users
Game developers are sometimes the worst testers. They are expert gamers with intimate knowledge of the system. Their natural bias is to make game play more difficult and less intuitive.

Let me tell you a classic tale of a title called Galapagos. It was roughly an ‘action puzzle’ game that involved manipulating the 3D environment such that a little creature could find his way through to the level exit. Watching a developer play the game was a delightful experience. The camera would swoop dramatically around your little character with Star Wars-like platforms zooming about, arriving at their location at the very last second. It looked fun!

As a first time player, Galapagos was easily one of the most frustrating games I have ever played in my entire life. The camera angles were nearly unmanageable. The little creature never went where you wanted him to go and you had no idea how you were supposed to manipulate the environment. The only way to beat the game was super natural reflexes and lots and lots of trial and error.

The major feedback on each round of prototypes came from the same people who had played early prototypes. As the game grew, so did the skill level of the people testing the title. The end result was game that was enjoyable for expert Galapagos players, but not by the general public.

Solution – Gather new user feedback: The way around this is to use lots of ‘Kleenex Testers’ to balance the useful testing done by the development team. These are ‘throw away’ testers that try the game for the first time and then are never used again. Setting up such a system ensures that you are constantly having your expert opinion challenged by a fresh, unpolluted crop of new users.

Content heavy games
Prototypes tend to be algorithmic in nature. There isn’t a lot of animation, the graphics are primitive and even level design is unlikely. Most modern games can be prototyped despite these inherent limitations. Some cannot.

Content heavy games like RPG’s, Adventure games, some MMOGs and heavily scripted FPSs are difficult to prototype. The problem here is that these titles are actually highly evolved versions of a core game mechanic.

A RPG or MMOG is generally a single or multiplayer turn-based combat system with a whole bunch of content and meta-game systems layered on top. You can prototype the combat system, but the game’s competitive advantage is often “everything else.”

Adventure games are really just a series of puzzle oriented mini-games tied together with a bunch of story. Again, you can prototype the mini-games, but the reason people play is to experience the story-based rewards. The same basic concept applies to modern single player FPSs.

Solution – Know when to prototype and when to start production: Prototyping still has a place in established, content heavy genres. I suspect the various weapons in Half Life 2 were heavily prototyped before they made it into the game. I’ll bet money that Blizzard spent ages testing the WoW combat system at very early stages in the project’s development. However, ultimately 99% of the work that will go into such games will be custom crafted content. When the conversation turns to custom content, it is time for the prototyping phase to hand over the reigns to the production team.

Prototypes can’t do everything. However, done correctly they can provide a strong foundation to build the rest of the game upon.

Conclusion
Prototyping is a high value development activity. By paying attention to the common execution pitfalls you can increase its effectiveness.

One last pitfall is worth mentioning. It is almost too obvious to talk about, but is important for artist / designers like myself. Prototypes are algorithmic creations. In general, you need some programming skills to create a prototype. Better programming skills make a wider palette of game mechanics available to your prototype in a shorter period of time. But the trick is to at least have some programming skills.

I have a friend named Charles who makes award winning casual games. He is a great artist, but only has moderate scripting skills. Due to his current scripting abilities, it is unlikely that he will ever create the next great MMOG on his own. However, even the basic level of scripting that he has mastered allows him to create wonderful platformers, shooters and racing games. The inspiration I take from Charles is that as long as you have a great knowledge of game design, entry level programming and art skills are all you need to produce great games.

The flip side of this is that a game designer without access to programming talent is at best a windbag (a label I happily accept :-). A song writer alone makes a poor band and the same is true for a game design. If you can’t program, you need to hook up with someone who can. Of course, the opposite is also true. If you are a programmer that can’t design, you need to hook up with someone who can.

I’m personally (and no doubt for selfish reasons) a fan of a small prototyping teams that include 2 to 3 people. Being able to bounce ideas off of one another results in a better final project. There is less tunnel vision and the team is more likely to notice the obvious solutions.

So the minimum prototyping team includes some dash of game design talent and another dash of programming talent. With that mix, the sky is the limit. You can build an enjoyable prototype, get enough momentum to recruit an artist, build some initial levels and start to wow people who matter (be they early customers, producers, etc.). Sweet.

Take care
Danc.

Labels: ,


Read more!

Tuesday, August 09, 2005

The Secret Life of Aliens: A Redesign

How to make the stupidest game possible
Several years ago I designed a casual game called The Secret Life of Aliens (SLOA). The player starred as an alien UFO whose job it was to explore earth and return with news about the natives. You could implant various alien probes and turn happy suburban dads into alien spies. Evil trench coat wearing Agents (modeled after Scully from the X-Files) were constantly snooping about trying to gather evidence of a diabolical alien conspiracy.

The longer you went undetected, the more delightful information you could gather about the natives. This made your overlords back at the university on Sigma Prime very happy. On the other hand, if the Agents gathered enough evidence of your existence, they nuked the entire town from orbit in order to 'cleanse' the alien invasion. Think of this as having a high Grand Theft Auto alert level except the cops are armed with nuclear armaments.

SLOA was intended to be casual action RTS set on a single screen. I drew some test graphics and a friend of mine (Phil Carlisle of Worms fame) took the design and made a prototype.

And it sucked. Here is why.

What went wrong
I was playing with fire in the original SLOA design. The core mechanic of the game was a highly experimental gossip simulation system. The little AI characters wandered merrily about and stopped to chat with anyone who wandered by. They would exchange information about various topics and then go and chat about their freshly collected news with the next person that wandered by. Agents collected evidence by talking to people who had talked to someone who had seen an alien.

It was all quite elegant and very original. I had come across the idea talking to a professor from MIT and was convinced that it was dying to be made into a game design. After all, if a game managed to model a fully working social ecosystem, it must be fun. Sometimes I imagine that a similar thought process led to such glorious experiments as Sim Earth.

Here are some reasons why it wasn't fun:
  • The cause and effect mechanics were not transparent to the user: The little people talked, but you never really knew the internal state of their minds. They might have two or three topics in their heads and as the player, you had no idea. You did something and then something random happened. This is distinctly not fun.
  • The core risk reward schedule was too long: In many games you click a button for 2 or 3 seconds and you get a cool result. In the original version of SLOA, you clicked on something and 20 seconds later some number would change. There was no steady drip of candy treats to hook the player.

The lesson I got from all this is that being original and intellectually satisfying does not guarantee that you will create an enjoyable game. A worthy thought, but one that I'm sure to ignore in the future.

Another attempt: The Stupidest Game Possible
Most failed game designs are worth tossing at this point and I did indeed shelf SLOA for quite some time. However, I love the setting and am convinced that there is a fun game lurking someplace in my original design. Other than the recent "Destroy all Humans" there is a remarkable dearth of casual alien probing games on the market.

I have a bag of tricks that I pull out in cases such as this. One of my favorites is an exercise called the"Stupidest Game Possible." Inevitably a game designers will be presented at some point in their career with a sketch of a monstrously complex game design. My eyes tend to glaze over and images of slogging away on the same game for decades fill my brain.

"Wait!" I cry, "What is the stupidest game possible that captures the essence of your idea? Reduce this superbly detailed MMORPG with excellent public housing algorithms to something can be completed by an average programmer in a day or two."

Done correctly, this is a great exercise that really helps boil a concept down to its essentials. The goal is to identify the 10 seconds of enjoyable gameplay that serves as the core of your title. Admittedly, I've seen two distinct responses. The first is absolute disgust in my obviously simple minded dismissal of the wonderfully detailed work of art that has been laid before me. The second response is a gleeful smile that comes from the realization that they can complete their dream game in a mere 2 days. :-)

The real win here is that in a month of creating stupid games, you'll kill 9 prototypes that suck and find 1 worth pursuing. This is far better than spending a year or more on 1 prototype that has a 90% chance of sucking. I performed this magical shrinking exercise on SLOA with some very interesting results.

The Secret Life of Aliens: The Stupid Version
I reduced the game design to my three components: tokens, rules, and verbs. First I defined a minimal number of tokens (3 tokens and 2 resources):

  • Suburbanite: The standard person. Usually there's 10 to 20 of these folks wandering on the screen.
  • Agent: The classic MIB character. These pop onto the screen at a steady rate.
  • Spy: The player can convert Suburbanites into Spys.
  • UFO: This is really just a mouse cursor.
  • Evidence meter: This tracks how much evidence the Agents have collected against you.
  • Info Score: This tracks how much information you have collected.
Rules:
The next thing that went was the original gossip system. It wasn't enjoyable and needed to be dramatically simplified. In the new version, people bounce around the map slowly like billiard balls and only talk when they get within range of one another. There is no complex AI or meme-based conversations. Instead, you have the following clearly defined cause and effects rules:
  • If a Normal Person gets near a Normal Person, nothing happens.
  • If an Alien Spy gets near a Normal Person, your Info score goes up.
  • If an Agent gets near a Normal Person, nother happens
  • If an Agent gets near an Alien Spy, the evidence alert level goes up.

Verbs: Adding short term risk rewards sequences
You can convert a normal person into a spy by click on them with your UFO beam. They stay converted for 20 seconds and then change back into a normal person.
  • Action: Click on a Suburbanite and they turn into a Spy
  • Reward: Spys talk to Suburbanites and increase your Info score.
  • Risk: If you turn too many Suburbanites into Spies, you won't have enough Suburbanites to talk to and your score will increase only slowly. If you don't convert enough, you also won't increase your score fast enough. The player needs to constantly manage the correct ratio of Spies to Suburbanites to get the highest score.
The next verb I added was a more direct method of interacting with the world Clicking on an Agent for a second or two burns them into ash. Probes are nice and all, but everyone knows that Death Rays are where it is at.
  • Action: Click on an Agent to burn them into ash.
  • Reward: Frying agents lets you collect information with less hassle.
  • Risk: As evidence mounts, more agents start spewing out of predefined emitter locations. You need to make a simple guns and butter choice. Should you kill the rapidly approaching agents or should you build more spys to boost your score?

I'm rather happy with how basic this game design has become. The original design was 13 pages long. This is a little over a page. It still captures the spirit of the original gameplay and might solve some of the basic problems that plagued the last prototype.

Another less obvious benefit is that with fewer moving parts, it is less likely that the design will be unsalvagable. If the first prototype fails to be fun, we can make dramatic changes with relatively little effort. Once the infrastructure is in place with a prototype, a simple design can go through a half dozen major changes in an afternoon. Simple game designs can be rapidly evolved at a much lower cost than complex game designs. Again, the benefit is that you are far more likely to end up with an enjoyable set of core mechanics.

Next Steps
I've been chatting with a charming and talented fellow (Harold Hausman of Whack-a-Ninja fame) who it going to attempt to create the entire SLOA prototype in a weekend using Anark Studio. The graphics will be simple primitives, but the core gameplay should all be there. If the end result is enjoyable, then steps can be taken to add additional layers of game mechanics in order to hone the addictive experiance even further. If it isn't enjoyable, c'est la vie. :-) Very little time was lost and many lessons will no doubt be learned.

There is a freedom in creating small prototypes that is quite joyful. Most games still rely on a perfected core that spans a mere 10 seconds of gameplay. Get the right core game mechanics and you've captured 80% of the magic that makes a classic game. Once you've captured that magic in a prototype, you have the freedom to make the next great epic or the next elegant haiku. Doom, Splintercell, Mario 64, Civilization, etc all started out as small test beds, where judged as successes, and only then were evolved into the great games we know and love. Their originality and core gameplay were baked in while they were barely more than an implementation of the 1-page design you are reading today. I firmly believe that a successful prototyping process holds the key to original engaging gameplay.

With this in mind, may we all go forth and make the stupidest games possible. ;-)

take care
Danc.

Labels: , , ,


Read more!

Friday, June 24, 2005

Article: Usability Testing

Gamasutra has a link up to an article on usability testing in games. This is a subject near and dear to my heart since major elements of games are basically "interfaces". If you assume that games are made up of token, verbs and rules, the first two speak directly to the 'interface' of the game and have a major impact on the title's playability.

Registration is required, but who isn't registered to Gamasutra? :-)

Click here to read the article

take care
Danc.

Labels: , ,


Read more!