Off to Japan!

I’ll be in Japan for the next two weeks exploring the countryside and eating delightfully squishy foods. Once a year I try to get outside of the US and I always follow the same rules of thumb. First, I try to have at least one good meal. Second, I try to sketch the local population. If you haven’t been by the galleries, there’s a good collection of past sketches from Bali, Peru, etc.

This time, I’m adding a bit of blogging to the mix. In theory I’ll have a solid internet connection and will be able to upload several bigger essays that I have halfway finished. I’m hoping that there is the equivalent of a café that I can plunk myself down at while the lovely fiancé is off gift shopping with her mother.

Here are some essays currently in queue:

• Advergames: I’ll cover some of the implications of designing a game to support a marketing campaign. There is a fun example I can use from the work we are doing on Anark Gameface that should be quite pertinent.


• Design review of Advanced Wars: Dual Strike: This is a rather classic example of traditional game design and offers a good balance to the Nintendogs review I did earlier.

I’ll be just missing the Tokyo Game Show, which is unfortunate since I’m quite curious to see if Nintendo will be announcing their new controller. Instead we’ll be taking the bullet train out to Nagoya to check out the World Expo. I am a huge sucker for robots, especially the overly cute humanoid ones that the Japanese companies seem to create in such vast numbers. This is an entire school of product design that I find quite inspirational. I’ll bring along my sketch book and see if the sensory overload sparks any fun concepts.

Take care
Danc.

News: Station Exchange deemed an early success

Here's the News.com article.

There will be people saying that paying for virtual goods is an poor practice that drives customers from the game. The reality will be that most people are willing to pay and that the revenues they generate will easily offset the lost revenues from the players who are morally outraged.

I'd be surprised if a substancial portion of the next wave of MMOGs do not have some form of non-subscription revenue model. If you can generate more profit with less people, you have a lower risk project with higher potential returns. From a business perspective, this is a no-brainer. From a customer perspective...well, they've already spoken by demonstrating massive support for the secondary markets. Now it is simply a matter of implementation and mass adoption. One big player has made the change and others will follow. Another link is formed between the virtual world and the real world...

take care
Danc.

News: China restricts MMOG playing time

You know, I'm seriously starting to love China's attitude to MMOGs. It is a precursor to how governments will attempt to influence many immersive online activities managed by a legal entity. The opportunities for abuse of civil rights is both delightfully immense and ill defined. Yet, because we are talking about virtual worlds any abuse that occurs is purely voluntary. Is this a victimless crime?

Admittedly, the owners of the MMOG have complete control over all parts of the player's online life. But because the players can leave at any point in time, it is not deemed a coercive relationship. Due to this aspect of the medium, the people I talk with seems quite comfortable with the limited civil rights available to online game players. It is just a game after all.

At some point however, rules and restrictions have real world implications. We are beginning to see online businesses spring up inside online communities. There will never be a complete virtualization of our lives, but the connections between our online worlds and the real world will growth much stronger. Some areas of potential abuse spring immediately to mind:

• Is role playing in a game an activity that falls under the category of freedom of speech?
• If real money is spent on virtual goods, can the government tax those goods?
• Can the government take the goods or delete the player's character on a whim?
• Can the government tie real world punishments into virtual activities?
• How much control does the government have when 90 - 100% of your finances are derived from virtual activities?

What I love is that China really doesn't care about any of this. An online game is social gathering spot that must be controlled like any other. They are going to do everything in their power that they can do based of the whims of the powerful minority. They'll do it out fear and out of good will at first. Many Chinese parents are honestly worried about their children. But once power is exercised, it is just a matter of time before it is used for less savory motivations.

My hope is that we'll get to see a full spectrum of greed, racial abuse, and other misuses of power. In the best of all worlds, observers in more democratic states get to witness the world's first large scale virtual human rights abuses without having to suffer the results directly.

I'm not being heartless here by any means. I'm merely trying to make predictions based off the lessons of history.

History suggests that humans are simple creatures when it comes to moral issues. We need to touch the stove to realize that it is hot. We also forget every generation or two and need to touch the stove again just to make sure. It took a couple of atomic bombs and tens of thousands of innocent deaths to realize that nuclear science thing might need to be regulated. It took dozens (hundreds)of genocidal events culminating in WWII for people in more enlightened groups to codify the eradication of racism. History suggests that people will need to be hurt badly and in large numbers for us to put limits on governmental control over online societies.

Why online worlds are at risk
Civil rights abuses occur when the group in power attempts to control a social and economic environment by harming, embarrassing and restricting individuals who do not toe the line. Online games are prime targets because they are potential forums for dissent and organization outside the government's control. Eventually some amoral (not immoral) group is going to take advantage of the easy regulation of online communities to impose real world civil rights abuses.

We are starting to see the first few steps in that direction. Initially it will be imprisonment because you broke curfew. We are there right now. Next there will be segregation and identification requirements for 'at risk' populations. It isn't that hard to implement tracking and behavioral control in an online environment. To the user, it will be just the way things are done.

As with all civil rights abuses, the abused will be voluntary participants during the early stages. It is easier to play with the time limits than it is to complain. It will be easier to provide your identification than it will be to cheat. In theory you could leave, but the social and economic penalties won't be worth paying.

In fact, the voluntary aspects of MMOG's offer no protection against abuse. No one put physical chains on post-Civil war sharecroppers. In the early days of the 3rd Reich, no one forced the majority (though certainly a minority) of Jews to wear stars for identification purposes. Yet no one will deny that these populations were coerced. Physical force is only one type of chain. When the social and economic penalties for online societies become real everything will be in place to implement strong civil controls.

There is a small ray of hope in this picture I'm painting (and I say this with no small dose of cynicism.) Online worlds put one more tool at a dictator's disposal that doesn't involve mass violence. So what if a small minority lives as slaves? At least they aren't getting shot.

I love China because their actions serve as a warning to the rest of us. Let us watch them carefully and learn.

Take care
Danc

Why you should share your game designs

Here is a conversation I’ve had many times throughout my career.

“Dude, I just thought of the greatest game design”
“Really, what is it?”
“I can’t tell you that. You could steal it.”

Remarkably quickly, the conversation comes to an abrupt dead end. This happens with professional developers, indie developers and people who happen to have picked up a game controller at some point in their sofa-bound lives and dream of breaking into the game industry. It is a cultural reaction that is pervasive throughout the game industry. The belief driving this response is simple: Game designs are unique and special, like a patentable invention. If you talk about a game design publicly, greedy buggers will implement it before you and take all your glory.

To be blunt, this attitude is completely ludicrous.

Your game design is simply a starting point
A game starts out with 1% game design and end up 100% production and polish. During the production and polish stages of the title, the game design is likely to change dramatically. For example, there was once a genre busting game design by a famous designer that involved a magic hammer and was described as an epic fantasy action RPG. Something very interesting happened along the way to creating the title. First, they did what every good team does in the early stages. They prototyped the concept and evolved what worked. The grand initial design ended up turning into an intense FPS shooter. What was this fantasy RPG? It was a little title called Quake.

When a team gets a hold of a game design, they change it in ways unique to that team. Give 5 teams the same game design document and I guarantee that you will get 5 distinctly different games. A game design ends up being closer to a movie script than it is to a blue print. The director who executes your design has a major impact on the ultimate results.

• Moral #1: The final game is not going to look anything like your initial game design because ultimately it is the game director who makes the most important decisions, not the person who writes the game design document.

Unique mechanics are almost never copied
At this point, many people claim that their design possesses a unique ‘hook’ in terms of the game mechanic. Take for example the Sims. This game had a great game design with some very unique and innovative mechanics. Holy crap, if only “I could have thought of it first” I could have made millions. Wouldn’t you love to go back in time, create a copy of the Sims and sell it before the Sims brand was established?

Yet, shortly after the Sims was released, game developers had a very similar opportunity. And they did nothing for upwards of two years. The clone masters had the blueprint for one of the most successful games of all time sitting in front of them and they did nothing. Even worse, the original Sims design was repeatedly rejected internally at Maxis because it was too risky. Ever wonder why Will Wright happily shares information about Spore multiple years before its launch?

• Moral #2: Most people like to copy successful ideas. Original ideas are far less likely to be cloned because they are seen as risky.

You can learn more by sharing than hording
Occasionally I’ll get someone to bite at this point and tell me their game design. It generally goes something like this: “So it is a fantasy game with a guy name Count Blommar who has red sword! He kills a lot of people and then fights a giant boss in the shape of a marshmallow!”

Months later, when a game comes out staring a hero bearing a red sword, the would-be designer is crestfallen that someone managed to create their idea first. Heaven forbid they actually had the gumption or clout to begin implementing their half-assed design in the meantime.

Often it is much better to talk about your game publicly so that you can gain important critical feedback from other industry experts. By discussing your ideas, you’ll learn a bit about what works and what doesn’t work. Writers do it at writing workshops. Painters do it at art critiques. These forums are harsh, open and extremely helpful. Many popular auteurs credit their current success to the constructive criticism they received from other professionals.

• Moral #3: Most people are absolutely horrible game designers. Your game design could probably be dramatically improved by talking to other skilled designers. You have dramatically more to gain by sharing than by hording.

Two copy cats doesn’t mean anyone is stealing
We operate in a cut throat industry. I’ve seen plenty of examples of similar games released at similar times and their sales suffer as a result. Two historical RTS games are released within a month of one another. Two FPS, both with triple-barreled shotguns are released nearly simultaneously. There are accusations of spying and the marketing people are lambasted for releasing screenshots too early.

Half the time, both games are merely copying from the generation that came before. If you mass enough game developers together and ask them to limit their imaginations to a narrow range of innovation, you are bound to have the same idea pop up multiple times. Suppose a publisher yells in a crowded room, “Quick, think of a color between red and blue.” How can you curse the fellow next to you who also thought of purple? This is convergent innovation, not theft.

More often than not, the ‘stolen’ idea ends up having a minor effect on the final sales of the game. One game typically has better execution and decimates the other. Perhaps if the failing company had been less focused on secrecy and more focused on building a great title, they would have done better.

• Moral #4: If your design ideas are similar to another title, there is a good chance you are both cribbing from the same cheat sheet. Relax. Your super clone isn’t going to win or lose based off the game design anyway. Brand, polish and production values are more important.

How about a little sharing?
Game designs are not patents or blue prints. They are an initial artistic sketch that is used as fodder during a very involved production process to create a final game. A great game is not derivable from the design document and an original game design is not likely to be copied. In fact, I would go so far as to say that it is impossible to steal a game design. The best you can do is create an interpretation.

When you refuse to share your game design, you are basing your decision off of indefensible paranoia. That is okay. You grew up in a culture where everyone claimed that game designs were holy. It can be hard to change. It can be hard to share.

If you do share your game design, I offer you this prediction:

• No one will steal your game design.
• By sharing your game design with other competant designers, you will receive in return invaluable feedback that improve your final game.
• You will contribute to the game development community and help others learn about game design.

You’ll find sharing game designs really isn’t such a big deal. Getting someone to listen, that is the hard part. :-) Hopefully websites like this one will be useful in promoting a reasonable discussion once you’ve made the plunge.

Take care
Danc.

What do you want to see on Lost Garden?

Hola,

I just checked my site stats and things finally seem to be settling down to normal after the spike in June of being linked to on Slashdot. Here are some numbers and a question for all those kind souls who appear to be regular readers.

• Daily unique visitors: 515 per day on the week days. 381 per day on the week ends
• Average page views per visitor: 2.1
• Monthly unique visitors: 5600

It's not a huge group of folks, but everyone who writes in seems intelligent, well spoken and remarkably insightful when it comes to game design. You rock.

I started this blog because I felt there was very little practical game design advice available on the internet. The only way we are ever going to get a large number of quality innovative games is if there is a population of game designers trained in the basics. Yet many industry members are wary about sharing their tips, tricks and proven techniques. The result is a vacuum of knowledge that encourages treating design as risky, mysterious activity.

• My hope was to create an online resource to that acted as a repository for practical design tools and processes.
• I've stayed away from technology and most 'current events'.
• I've tried to avoid (though I'm not sure how successfully) the obscure philosophical ranting that often accompanies design blogs. Instead the focus has been clear descriptions of common problems.
• Finally, I've focused on example game designs such as Space Crack and Secret Life of Aliens to ground the discussion.

There are several directions this site can go from here. I'm curious what you are interested in. Here are some ideas that have been floating about:

• Guest Designers: I could open the site up to game designers who have published a game and ask them to write on tools they find critical to their success.
• Advanced business topics: I can focus more on the money side of design. It is a fascinating topic.
• Life of a game: I can dig into the development of an actual game in more detail. This sacrifices the theory a bit, but gives you more details. Think of it as yet another game diary.
• Current events from a game design perspective: What the hell is Nintendo/Xbox 360/Hot Coffee doing and how does it effect my game design choice?
• Monkeys: I've always been a big fan. Really big.

Thoughts?

Woot,
Danc.

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.

Secret Life of Aliens: First Prototypes

Harold whipped together some sweet prototypes of SLOA this weekend. He agreed to let me post them as an educational example of how prototyping works. Think of this exercise as speed dating mixed with the post mortems that you find in the back of Game Developer magazine.

Update: I added the latest prototype. You can download it here

Version 1
The first version of SLOA sported the core game mechanic, a simple conversation system. There were two token, the drab and asexual Suburbanites and the dapper green Spies. There really isn't any game here, just a technical demonstration of a basic gameplay system.



What went right:

• Primitive graphics: I'm very proud of Harold's graphics composed entirely of cones and spheres. It took him substantially less than an hour to put these together and that is as it should be. Time spent on creating pretty graphics during the prototyping stage is time misspent.
• No UFO: Prototyping is as much about what to leave out as it is about what you build. In the design, the UFO, the main character of the entire fricking game, is really just a mouse pointer when you come right down to it. The system mouse pointer is good enough.
• Smallest possible step to feedback: Even though there is no game here, there was still enough to make some comments that dramatically improved the next version.

What went wrong:

• Getting hung up on graphics: There was in fact a prototype-0 of SLOA. Harold spent a good hour trying to get the antennae to smoothly animate out of the head of the spy. But there was a bug someplace and a few minutes turned into an hour of frustration. He was focusing on making it pretty instead of making it work.
• Colors: The green of the spies was too light and they blended into background. Even at this early stage it was possible to get feedback on the game's information design.
• Complexity: The conversation behavior was too simple. With so few characters there wasn't much interesting happening.

Version 2
Version 2 fixed a couple of problems with version 1. The colors were brighter on the spies and there were a lot more spies on the screen at once. Everything was peachy keen. Except for one little detail...
What went wrong:

• Conflict: There was a desperate need for some sort of conflict and challenge. It turns out that conversation alone is boring. This is a wonderful discovery since it shows us that we can't use the conversation mechanic as our core game mechanic. It is best to discover these things early on in a game design. :-)

Version 3
Version 3 sought to augment the basic mechanics with some classic conflict. Harold went all out and added in Agents and the detection score. The agents had sun glasses and black suits. MIB of the most classic sort, baby. They also had health meters so you couldn't just rapidly click-massacre a dozen agents in a millisecond.
What went right:

• The game was born: There was actually a challenging little game evident in this prototype. The conflict escalated, agents wandered about, your score increased. After a decent 5 minute playing session, the frantic clicking all came crashing down and the game ended. People were comparing high scores and improving their scores with each play. When people play your dismal prototype more than once, you know you are onto something.
• A recognizable setting: People grokked the alien-themed setting. The agents added the necessary burst of context that helped initial players feel like they were doing more than just clicking on random icons.

What went wrong:

• Weak connection between action and reward: The score in the game would go up and you'd kill agents, but there wasn't a clear connection between what you are doing and the rewards. A good game should be like an instrument. You swing the stick, hit the drum and it makes an enjoyable sound. Swing, boom. Simple enough. Version 3 didn't that rhythmic clearly delineated musical response. It was more like one of those little rain sticks that you turn upside down and you get a long tinkling noise. Pleasant, but not addictive.
• No focal point: Another problem was that little guys were wandering all over the place and you had literally 20 different things to worry about all at once. Successful games with lots of moving objects on the screen tend to have one or two focal points that the player can watch. In most shooters and action games, there is a central location that must be protected and then the player zones out and lets their peripheral vision take in all the various threats. Version 3 lacked this focus and the result was a game that felt more stressful than fun.
• Killing agents wasn't fun: To continue with the music analogy, when you hit a drum, there is a satisfying physicality to the action. Most decent interfaces, be they simple buttons or complex game mechanics, have this tactile element. The interface for killing agents involved a slow and steady draining of their life force. It made sense when you described it on paper, but holding down a mouse button didn't feel exciting. Combine this with bad collision detection and killing agents was another frustrating experience.

Version 4
In version 4 we finally had a robust enough system to start playing with the game balance. We added several mechanics that improved the feeling of direct control in the hopes of reducing the risk / reward cycle time.

What went right:

• Control over individual spies: We had talked about being able to drag a spy in a direction in order to reorient them. This would let the player be more tactical in their position of the spies and hopefully result in their feeling more control over the board. The implementation was a qualified success. The game immediately became more interesting and a wide variety of strategies came into existence. The 'wild spy' was born. This was a spy that ran about the screen like a lunatic at high speed, talking to every suburbanite in existence. He was hard to keep from whacking into agents, but he gathered a lot of points. Also, the 'slow spy' was born as well. This was a spy that basically was stopped in his tracks. He didn't get a lot of points, but he was much easier to defend.
• Collecting Agent bodies: When you kill lots of agents, their bodies pile up. We thought we could include a 'coin collecting' activity by letting the player click on bodies and gain points. This worked slightly, but wasn't a great addition.
• One spy at a time: This isn't either good or bad, but when players started learning to beat the game they began adopting the tactic of only having one active spy at a time. The game was too confusing to play well, so players reduced the complexity of the game until it was manageable. This demonstrated clearly the important of building focal points into the game.

What went wrong:

• Physics for the sake of physics: In the initial implementation of dragging spies in a direction, your motion took into account the spy's current momentum. On paper this was a great idea that sought to add that 'tactile' element to the verb. In practice, the dragging felt sluggish. Spies were harder to control than necessary. One possible solution was to remove the momentum factor and see if it improved the feel of the dragging action.
• No short term penalty for failure: If a spy was caught, the abstract evidence meter went up but that didn't really affect things much. Also, a spy could blast through several agents in a second making agent encounters rather hectic.
• Coin collecting had no risk element: You could leave the agent bodies on the ground forever and collect them when you got a spare moment. A better solution would be to have them fade out after a period of time so that there is some risk of not getting the points.

Version 5
With version 5, we finally are at a game where players can demonstrate mastery. It is horribly unbalanced and still need some major additional systems. However, I can sit down and happily play for 5 minutes without feeling frustrated.

What went right:

• Removing unnecessary physics improved the tactile feel of dragging: One variable tweak later, the control of the spies became much more responsive.
• New strategies that improved the focus of the game appeared: The surprising side effect of improved dragging was that the 'slow spy' technique became the dominant way to own the game. By clicking on a spy twice, you could stop it dead in its tracks. Gather enough little spies up in the corner of the screen and you had a highly defensible position against the wandering agents. Also, you ended up being able to farm major info points by clustering so many spies and suburbanites in close proximity. Finally, we were starting to get away from a series of random events towards a player created environment that had interesting strategic implications.
• Agents convert spies: When an agent runs into a spy, the spy is converted back into a suburbanite. This makes the player feel that they 'lost' a spy. We can augment this in the future by given the player a limited number of spies. The first benefit here is that there is now a more immediate result associated with the player letting a spy and an agent interact. This tightens the risk / reward cycle. The second benefit is that focus is improved. A spy that gets in trouble is lost and the player can move onto a new activity. This clearer definition of the beginning of an activity and the end of an activity helps clarify the game play.

What went wrong:
With vesion 5, the gameplay is starting to open up and we have easily a dozen different paths that we could go down to actually make the game fun. This is typical of a prototype. We add and add and add until the game becomes quite interesting. At a certain point, we need to ask 'What elements are the most fun?' and trim back the various gameplay experiments to focus on those items. A prototype should naturally grow and shrink in complexity as you try a bunch of things and then boil the gameplay down to the essentials.

• Long term level structure is non-existent: Levels never end. We need to add in some meta game mechanics that govern longer term risk / reward sequences. We can set up goals for each level and start sequencing challenges. This will give the player a feeling of progression.
• The evidence meter is bogus: Though it was in the original design, the evidence meter doesn't seem to add to the game play. Each evidence level should effect the map in some way and the player should be able to manage the evidence level.
• Obvious player tactics need to be countered: If the clustering of slow spies is a fun technique, we should make it challenging. What if agents targeted your 'base' with more intelligence?
• Support for focused gameplay: The base is a fun concept that really focuses the gameplay. However, it is one that emerges from the core mechanics. Should we build this concept into the game so that it is supported and more obvious to new players?
• The tactile feeling of the game could be improved: Dragging still doesn't feel perfect. This could be improved with some better dragging code. Also, we can't forget to improve the Agent killing mechanic.

Iterative design in action
SLOA is by no means fun quite yet, but we are getting there. Every iteration (some of which take no more than 5 minutes to create) demonstrates the same basic methodology.

• We create a theoretically enjoyable prototype.
• We play the game
• We record what works and has potential
• We record what doesn't work
• We propose some changes and implement a new prototype. Wash, rinse, repeat.

We are still only a few iterations into prototyping SLOA. We could put in a dozen more before the gameplay gels enough to start building out content. Even then, the game won't be polished until close to release. Game development is a fundamentally iterative process where the game design is just the beginning.

I'd like thank Harold for all his hard work. I like to say that a game design is like a movie script. It only shines in the hand of a great director. For SLOA, Harold is acting as the director of the game development and the real genius of the final product will be the result of his inspired implementation decisions. It is a wonderful process to observe.

take care
Danc.

User Content: Working with players to efficiently create profitable games

I recently have run across a couple of articles that have piqued my interest. The first is title 'Future Imperfect' by Jim Rossignol and discusses how user created content in games results in a deeper, more meaningful player experience. Most importantly, he coins the term 'the wikification of games', which is a money catch phrase if I have ever heard one.

The second article was in "Act of Mod: Building Sid Meier's Civilization IV for Customization" by Mustafa Thamer in the August issue of Game Developer Magazine. The article discusses how Civ IV was built from the ground up using XML, Lua and Python to make the core of the game accessible and modifiable by players.

Games are slowly emerging from the land of custom coding into the world of data driven, standards-based application development. I love this trend for a number of reasons including faster development, more artist involvement in the design process and increased opportunities for innovation. What is the future of user created content and how will it effect our profession?

Ultimately I’m interested in how user content can be leveraged to more efficiently create highly profitable games. (I’m a pirate at heart…arrh.)

The slippery slope of data-driven development
The opportunity for user created content was born due to the solely selfish activities of smart developers. Successfull games are about content, not code. They were looking at ways of speeding up their development process and began creating data-driven game engines.

The classic data-driven game starts with a small engineering team who builds out a solid infrastructure. Often the engine is based on middleware and most of the initial programming work involves ensuring the correct data driven architecture and interfaces are in place.
A hand off occurs and the designers and the scripters begin developing the game play in a modular fashion using scripts and easy to manipulate data objects. With high level scripting capabilities found in Python or Lua, teams can build interactive elements several times more quickly than if they were developing the same functionality in C or C++.

Prototyping and play balancing, both of which have historically been programming heavy activities, can now happen at a much more rapid pace. Iterative development becomes highly effective and in the best situation you end up with more polished games with shorter development schedules

Artist friendly tools
Using a standard format such as XML means that it is easier to create simple tools that give artists access to your data. At the most basic level, an artist can edit human readable text. With a bit of .NET mojo, simple editing tools can be quickly built for almost any task. Tools are certainly additional effort, but in today’s production oriented world where artists outnumber programmers 3 to 1 on many teams, the benefits are economically obvious.

The result is that game design becomes more like creating an HTML page than programming in assembly or C++. The wikification of games isn’t there quite yet, but it isn’t far off.

With these new authoring options comes a shift in the power of who can create games. Historically small games creation has been restricted to people with both a good sense of game design and the ability to program. Such creatures exist, but they are quite rare. If one out of 100 game developers is a competent designer and 1 out of 50 is a genius programmer, we’ve got a delightful 1 out of 5000 chance of stumbling across a renaissance man who can do both. These are bogus numbers, but you get the point.

I like to think of this as disqualifying 90% of potential Olympic athletes because they can’t calculate differential surfaces in their head.

By reducing the hardcore programming to an infrastructure support role and shifting the central creative capabilities into tools that can be used by almost anyone, you start to end the industry’s implicit discrimination based on technological skill. Make no mistake; you still a solid theoretical grounding that is necessary to be a competent designer. However by removing arbitrary technical barriers we increase the chances of stumbling upon that one person who was born to design great games.

Once you are able to provide tools for technically incompetent artists, it is a relatively small step to toss the tools over the wall to the consumers. A method for improving the game developer's efficiency becomes the means of empowering players to create user content.

A wonderful explosion of crap
When you reduce the cost of production and open up a highly technical creative activity to a relatively unskilled base, what happens? Let me propose a law:

If the cost of authoring traditionally highly technical creative content is reduced by an order of magnitude, there will be at least an order of magnitude increase in the amount of crap produced.

We saw it with desk top publishing. We saw it with early websites. Goodness knows we are seeing it with blogs. And we are seeing it with games. Have you honestly downloaded a game mod or flash game lately? Sewage collected from the festering depths of a bulimic convention’s septic system is often more appealing. Some of the worst manages to be both morally offensive and artistically bankrupt. Most of it simply demonstrates an utter lack of talent or imagination. And the shear amount of the bad stuff is growing at an impressive rate.

I take great delight in the early rumblings of the democratization of game design. If you can wade through the muck, there are some great designs to be experienced. The crème de la crème of this outpouring has already produced some of my favorite game play experiences (Counter Strike and More Strange Adventures in Infinite Space come to mind). In the long run, more game designs ultimately mean more good game designs even if they are just a small percentage of the total.

The good news is that the authoring tools are only going to become more friendly and the engines more conducive to modification. There are three big forces, two of which we’ve discussed that point towards the commoditization of game development technology

• Improved production efficiency
• High quality product gained from leveraging a broader population of design talent
• And last, but certainly not least, strong economic incentives

Leveraging this creative explosion for profit
Let's dig into this last force in a bit more detail. Early supporters of mod-friendly data driven games were a bit like the underpants gnomes from South Park. Their business model was the epitome of good natured benevolence but of dubious financial benefit.

1. Allow mods
2. ???
3. Profit!

History has proven many of these early pioneers correct and their apparently generous gesture to the fans resulted in substantial financial rewards. The following are some of the reasons why this tactic worked.

• Player created content equals more content. More content means that players keep playing for a longer period of time and makes the game a better value.
• In many cases, the appeal of the game was extended into market niches beyond the original intent of the designers. Even if the game developer gets their design wrong, it is likely the community will fix many of their mistakes. (Some of the balancing efforts being performed by the Age of Wonders community comes to mind)
• A strong mod community acts as a persistent word-of-mouth marketing organization for the title.
• The final result was more sales and a longer shelf life.

All this becomes justification enough for the more Machiavellian game developers out there to follow a similar path for the sake of profit. If making modable games reduces risk and increases profit, then smart developers will make modable games.

The first generation of user content
All these benefits are potential benefits dependent on quality execution. Poor implementation of a user content system results in fewer benefits to the game developer. The first generation of mods in particular suffered from many of the problems that plague current indie games:

• Poor distribution channels: Often the distribution channels were fan websites that only reached a small fraction of the primarily single player, offline player base.
• Technically demanding installation procedures: It took more than one or two clicks to use most mods. This was too much for many players.
• Lack of common filtering systems: With so many mods available, it was difficult to know which ones were worth a player’s time. The rating and review bodies were often fragmented and held little authority with the target audience.

One of the titles that I have personal interest in is Age of Wonder. They have a robust mod and mapmaking archive online, a strong community site and great tools. Recently, they polled the online users and asked if they used mods. 64% had never tried to install a mod. Only 20% successfully used mods with any frequency. This sample is heavily biased towards mod usage since we know that 80 to 90% of single player users do not participate in online community sites. This patterns exists a number of other games.

So with first generation games that support user content, a small fraction of the total user base actually takes advantage of new user content. There are better ways.

The second generation of user content
We are beginning to see the second generation of games that attempt to facilitate the financial benefits of open, data-driven engines. They are building in services that simplify access to additional user created content.

• Official stores that allow the purchase of user content: Steam allows the ability to download and purchase of commercial mods whenever you play Half Life 2 or Counter Strike: Source.
• Portals for easier trading of user content: Sims 2 includes a content portal for the download of user content.
• In game systems for managing mods: Unreal offers mini-mods called mutators, that can be easily turned on or off inside a user friendly interface.

The third generation of user content
These are wonderful steps in the right direction, but they are just the start. I suspect that we’ll see a third generation of games that promote player created content taking a hint from titles like Spore and Second Life.

In this third generation, the review system is built into the core game mechanics in the form of a standard purchasing system. Installation is transparent and happens in the background. Distribution is also transparent and automated such that you never even notice that you are getting new content. As an added bonus, the authoring of new content becomes a fundamental activity of the game play.

The third generation offers an important advantage over 1st and 2nd generation titles. In earlier attempts at promoting user content, the content was always something outside of the core game experience. The user was required to step outside the game environment, enter into a radically different user interface and context. That transition, as simple as it might sound to the tech heads of the world, is enough to prevent over 90% of users from ever partaking in user content.

The third generation of titles treats user content as an integral part of the game experience. User content isn’t an extra; it is how you play the game. With this shift, I would easily expect 100% of players to partake of user content.

Consider the benefits of this third generation of mod friendly games.

• The game developer provides an inspirational sketch of a game and a well stocked tool box.
• Then, over many months of player activity, the game becomes fleshed out with content that the players desire.
• Players build the majority of game content and the game developers monetize their results.

Go underpants gnomes, go.

The implications of third generation user content systems on game services
The more that game developers support and encourage the creation of user content, the more they play the role of a service provider and not a packaged goods producer. We need to stop thinking about a game as simply a game engine plus a fixed set of content. Instead, the developer is hosting and maintains a common game development platform that supports an ever growing library of gaming content, much of which is user generated.

The game developer sits in a unique position in the value chain. They are the only group with the power to provide proper integration between player-created content and the end user experience. A third generation design like Spore is only possible if the game developers owns, maintains and controls the financial, mechanical and social aspects of content distribution.

In fact, providing a robust service for the creation, distribution and filtering of user created content becomes an important design activity in its own right.

Creation Mechanics
Earlier I covered the concept that in order for a game to make money, the game designer must consider the financial mechanics of the title. For a developer to create a fully realized 3rd generation user content friendly game, they must also consider the creation mechanics of the title.

Creation mechanics are similar to traditional game mechanics in that they can be described using a traditional risk / reward sequence

• Action: The player creates a desirable piece of new content. The content is rated by existing filtering systems.
• Reward: The player is lavished with either social kudos or in-game rewards
• Risk: The player builds something that no one likes and their efforts are wasted.

Creation mechanics, like financial mechanics, are optional. Only a small percentage of the player community will take advantage of the design tools that are available. The majority of what is created will be derivative and will add approximately zero to overall addiction level of the game. A much smaller percentage of the user content will transform the basic game set forth by the game developer into a more widely appealing experience.

One of my favorite stories is Stone Soup. In this tale, a starving soldier arrives at a small town in the middle of a famine. No one will give him food, so he pulls out a large kettle, fills it with boiling water and drops in a magical stone. The villagers, being quite curious, ask him what he is doing. He is making a delectable meal of “Stone Soup”, he replies confidently and mentions that it tastes best with a carrot of two. A carrot is found and one by one the other villagers add their hidden food to the pot. By the end of the evening, the pot contains a rich stew that provides the entire village (and the wily soldier) with a sumptuous meal.

The creation mechanics for a creation oriented game are the initial kettle, the water and the magic stone from the tale. They are the incentives that get the community of strangers to contribute and build something great that can be shared by all. The game designer is the soldier, the charming and crafty persuader who sets the system in motion.

More than just tools!
It is worth mentioning that 3rd generation creation mechanics are not merely tools. This is a common mistake made by many mod-crazed designers. They provide a set of verbs and call it good. The content needs to be filtered, made available to other players in a painless fashion and finally good efforts need to be rewarded.

When a game developer merely supplies the tools, they are abdicating their position as the leader of their game’s creative community. They are saying “Look, we let you experience our creative vision and we gave you a few tools. Now figure it out. We have more important things to do.”

I’m convinced that this path leads to investing 80% of the effort and only getting 20% of the benefit. Developers that properly service their creative game players have a greater chance of achieving a longer sales life. It is really that simple.

Rewarding the creative class
The ultimate drivers of a 3rd generation user content system are the mod makers, map makers, and other creative folks that play your game. They deserve special attention. Suppose that only 1% of your players are actually contributing interesting new content to your game. The main fellow is a chap by the name of Willy S. and he has single handedly produced a mod that is played avidly by 20% of your player population. You could A) Do nothing or B) Give him a reward and publicly shout his success from the highest rooftop.

I’m all for intrinsic rewards, but a making a welcoming environment that encourages artistic experimentation in is always a good thing. I’m willing to lavish in-game currency on the 5% of players who make the 80% of new content that drives the continued subscriptions. I’m willing to make them in-game rock stars. Game design naturally blends into designing systems that promote a desired social structure.

Sure, the creative class will be a bunch of whiney bastards when the fame goes to their heads, but that’s okay as long as they keep producing hit content. Yes, there is indeed a certain irony here. In the new world of user content, game developers are meta-publishers and the creative users are the new game designers.

Some thoughts on making money through user content
So we have a great user content system in place. The content is making its way to the vast majority of players and adding substantial value to the title. The creative class is cooking up new content and feels happy and well rewarded for their efforts. Wonderful, now how the heck do we make money?

There are two distinct scenarios that come to mind

• Retail Titles
• Online Titles

Making money off user content in retail
The goal of retail titles is to sell more titles. You only make money from selling boxes, so every tactic relates to this goal.

• Word of mouth: Have a strong community (an outgrowth of a strong user content strategy) will often cause players to promote the title to their friends. Developer support for the community can enhance this marketing force.
• Perceived value: A large archive of user content can increase the perceive value for money of a title. Campaigns can use this as a benefit point.
• Repackaging user content: A common technique is to bundle user content together into an expansion pack and sell it as a new SKU. This extends the shelf life of the title at a much lower production cost than if the game developer was required to create the expansion pack content from scratch.

Ultimately, user content ends up being a ‘nice to have’ in the retail world due to several factors.
First is that fact that users generally only purchase once. At a certain point in the game’s life cycle, the market for a particular game becomes saturated. When everyone has the game that might buy it, all the additional content in the world does little to effect sales. You end up with a lot of happy players who can now play their favorite game for years. This is great for the players, but it doesn’t put any more money in the pockets of the game developers.

The exception to this rule are titles like the Sims. They have a broad enough demographic that it is unlikely that they will ever saturate the market.

Second, in the retail world word of mouth is a smaller sales driver than things like brand, reviews and advertisements. When the official buzz starts to die down, the community can only maintain a trickle of additional sales.

The exception to this rule are titles like Counter Strike. The multiplayer aspects of the title end up creating a magnified word of mouth effect that are quite useful in driving additional sales.

Making money off user content online
Online games are once again a different beast. The goal of online titles is to keep your current customers for as long as possible. Selling boxes is nice, but the real money comes from keeping customers. The lifetime value of a customer in a service-based business is dramatically higher than the value of a customer who only purchases once.

Let’s look at a game like World of Warcraft and compare it to Doom 3. Suppose that a customer buys Doom 3 for $50. The developer might get $10 of revenue from this sale if they are very lucky. With WoW, the customer pays $14 a month. Let’s say Blizzard gets to keep $10 of this with the rest going to various publishing obligations. If the average life of a customer is 2 years, they’ll spend $220 on WoW.

In this scenario, keeping a customer for an extra month in an online game is worth just as much as selling one copy of a purely retail game like Doom 3. In addition, since you already have an existing relationship with an online customer, your cost of keeping them happy should be less than your cost of acquiring a new customer.

This changes the dynamics of the business model quite dramatically. In retail, you only care about making existing customers happy so that they will act as a marketing effort to pull in new users. In online games, you care about keeping customers happy so they will play your game for all eternity.

An infinite, evergreen source of high quality user content becomes a major strategic tool in keeping customers. Here are some ideas:

• Create a source of free content that is distributed to long time users.
• Create a system where players can purchase content created by other users. The game developer gets a cut of the proceeds
• Create contests that set forth a theme and prizes. The community judges the content and the winning package is then collected into themed expansion packs

The most appropriate system will be dependent on the online game’s revenue model. For example, the subscription-based services may be happy with providing an archive of free content. A service that makes money by selling avatars may be best served by reselling user content. The sky is really the limit here. Over the next decade, I predict that we will see some innovative and highly successful business models built around user content.

Conclusion
Once again, I’ve meandered to the end of another essay. We’ve covered some rather important topics:

• The basic benefits of data-driven development and how it leads naturally to mod friendly games
• The potential market benefits of encouraging user content.
• The various generations of user content system and the challenges with creation, distribution, filtering
• The advent of 3rd generation user content systems in which the act of playing the game results in content generation.
• A conceptual design tool known as “creation mechanics” for seamlessly integrating a user content system into the game design.
• The importance of seeing a game as both a development platform and a community service, not just a fixed bundle of developer created content.
• The importance of cultivating a game’s creative class
• Business models for both retail and online games that take advantage of user content.

In the end, I’m most interested in production efficiency and making money. User content is a natural answer to both of these topics. Game developers can leverage their investment in data-driven development systems to empower their game player’s creative class. The end result is games with a much longer shelf life and only a marginally more expensive development cost.

Ultimately, this process will yield new genres of games that look distinctly different than those you find today. A game like Spore may superficially resemble Diablo or a RTS. However the compromises necessary to embed a robust user content system into the title produces game play that feels radically different than previous games based off the same core game mechanics.

Properly done, user content is a win for the developer and a win for the game players. (Arrr…and the pirates are happy too)

Take care
Danc.

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.

Space Crack: Graphics and UI Test

This weekend I had a chance to put together a little test rig for a revised interface I'm trying out. I had two goals. First I wanted to rectify some of the complaints about my first interface. Second, I was playing with some of the artistic bits based on the comments folks had in the earlier art thread.

Click here to download PlanetTest8-7-2005.zip (2.62 MB)

The Test Rig
I'm following the list laid out in my component bible. You quickly end up with lots of objects that all can be in any of a half dozen different states. Rather confusing to be honest. To keep everything straight, I whipped together a primitive menu that lets me sort through the components as I finish them.

• Left and right arrows switch between components. The large text tells you the name of the component.
• Clicking on the down arrow in the center cycles through the states of the selected component. (You can get things in some odd states if you switch between components when you are in the middle of the cycle. Click enough times and it all seems to come back to normal. It's a test rig, not a polished application. :-)

Fixing the UI: The second pass
I had several issues with my first UI attempt.

• Remove unnecessary hierarchy: First, I tried a pie menu for selecting between multiple upgrades, but it was a pain to use. This time I made the rule that ever powerup gets one button. If you can see it, you can click on it and something wonderful will happen immediately. Sometimes I wish all UI's followed that philosophy. :-)
• Restrict the UI to the tasks at hand: Early on I thought it would be fun to have a planet that could be spun around. Unfortunately, allowing dragging in multiple directions was too much freedom. Half the time, the planet ended up at some odd unusable angle and the rest of the time the 3D rotation algorithm reversed up and down. There's no point in requiring users to master crazy 3D rotation concepts just to play the game. This time I constrained the planet rotation to a single axis. I also placed the powerup buttons above the equator so that players can always see them. Much simpler and it is still viscerally enjoyable to spin the earth like a top.

The Art Style
The art should look at lot like the previous test exe. Really the only new model is the space ship. I tried to make something a bit sleeker than the Space Cute design, but still having a prominent character element that I felt was lacking in the 50's iPod style.

I'm rather excited about the ability to use simple texture maps to change the look of the ships quite easily. There are two images, one for the helmet and one for the ship. By swapping these out, players should be able to get a huge range of different 'team flags'. I need to spend some time cranking out some skins.

take care
Danc.

Space Crack: An artistic dilemma

Cute or Hardcore?
I'm a relatively decent artist. This poses a problem. I have the unholy power to skin Space Crack with an acceptable facsimile of almost any popular art style out there. The result is too many choices. So here's a question for everyone who has been kind enough to read this blog: What art style should Space Crack use? I've got a couple of seed ideas that I've been playing with.

• The first is Fifties iPod. This one is very white, with simple retro shapes that harkens back to glory days of early sci-fi. Other than sporting a classic 50's pin-up girl, the designs tend towards more abstract and geometric shapes
• The second is Space Cute: Another rather white design, but this one has cartoony characters and highly symbolic graphics. Red hearts, yellow stars, and people with space helmets make an appearance. Think of it as Mario in Space.

Fifties iPod

Space Cute



Worms shows the way?
Someone mentioned how Worms made an incredibly violent game palatable to a wide variety of players. I'd love to do the same thing with the art direction on this game design. I'm not sure if my 50's pinup (as enjoyable as she was to paint) does the trick here. At the same time, I'm curious if the Space Cute style is too generic. Thoughts, opinions and critiques are welcome.

take care
Danc.