Thursday, June 30, 2005

News: Chinese Government to influence MMOGs

This news item on next-gen.biz ties into my previous post. As gamers and game designers, we see MMOG as simple enjoyable games. If you are a totalitarian government such as China, you correctly identify MMOG as the following:
  • A cohesive group of well informed, technologically literate citizens that have strong ties and social beliefs that are potentially separate than your own.
  • A method of meeting, collaborating and distributing news outside of traditional government intervention
  • A powerful reward system that can be used to promote and reward specific activies amongst a large population

When the number of players start reaching into the millions and there is no government oversight, you have a potential forum for dissent. In some ways, MMOGs can serve the same purpose as a free press. In other ways, they are more powerful since they have strong organizational and collaboration mechanisms built in.

MMOGs are in their infancy as a political medium. We are witnessing a small moment of history in which a major government, China, is making the first steps to politicize these game systems as a mechanism for social control. Others will follow. The threat and the opportunity is too great.

The reality is that online communal systems mimic many of the social forces and systems found in offline governments. Expect to see the good, the bad and the ugly lessons of human governance, the same ones that have played out for thousands of years of human history, played out in a virtual form as MMOG's evolve. At the moment, I'm content to be an observer. Over time activists will emerge and starting bringing virtual struggles into the real world.

take care
Danc.

Tuesday, June 28, 2005

Out of work MMOG designers will rule the world

As I sit here contemplating business dashboards, it occurs to me (as it has occurred to many others) that game designers will ultimately rule our working lives.

Games and Business
Games are a formal system of tokens, verbs and the rules that bind all the elements together into a nested set of risks and rewards. The rules are basically a simulation, sometimes simple and sometimes complex. The tokens can represent pretty much anything, but they are usually well defined with specific and pertinent properties to the game at hand.

Business, on the other hand, is quite messy. A make or break sales opportunity might come from the fact that you sat next to a stranger on a plane. To bean counters such as myself (yes, scientific brains are merely bean counters with better pattern recognition skills), this randomness is unacceptable. A COO wants to ensure that he has a smoothly running, repeatable business process that leverages the skills of his employees in an optimal manner.

Businesses have always tended towards games-like exercises with their incentive systems, pay scales and feedback methods. This just makes a lot of sense when you are dealing with people. Games are a great way to get people to perform an arbitrary task in an optimal fashion. With the correct sequences of risks and rewards, you can teach a player to almost anything. This is the thought behind serious games, and quite honestly business folks have been applying the concept for many decades.

Digital dashboards: A big change
Over the last few years, we've seen a big change occurring on the data side of the business world. More and more of those fuzzy business events are being categorized and placed into databases. Take a CRM system like SalesForce.com. Who you talked to, when you talked to them and how that translates into the company's bottom line are all on display. Mix this with financial systems, email systems, procurement systems, inventory systems and PLM systems and almost every aspect of business is being placed in a computer.

From an end user's point of view, this giant pool of information and business rules is quite different from a game. From a developer's point of view, it all looks remarkably similar to the backend on a massively multiplayer online title. You've got your mobs in the form of customers. You have player records in the form of users. You've got your realm points in the form of business unit financial results.

Right now, the game that businesses play using the data at their finger tips is quite primitive. I liken it to the hardcore war simulations that took the game market by storm back in the 80's. The information displays are crude and focus on the simulation instead of the player psychology. The learning process for new employees tends to be sink or swim much like it was in the ancient MUD days. There's not concept of gradual level-based advancement where you only eventually gain super powers (such as the 'Call in the manager' super-strike!)

This will all change with time. Someone will mix an employee incentive program with a few existing business systems. When a pre-specified action is taken, the systems will pop out real-time alerts that give positive or negative feedback. Risk / Reward in action. Ultimately, they are going to need people who understand these concepts to design and manage the complex online community that is a next generation business.

An opportunity!
This naturally is where the out of work MMOG designers step in. Sure, your game ground to a halt after only a two-year run. The damn players hated your new weapon upgrade system and left in droves. You are bitter and tired of the game industry. An ad from Walmart catches your eye.
"Game designer wanted. Experience creating vibrant and productive communities a must Salary: Double what you are making now."
Your design, which ties together all major systems within the company will incent the minute by minute behavior of over 1 million employees. They'll have their scanners and cash registers all tied into a central system. The CEO can watch his realm points go up or down. He can stage events to encourage participation. He can experiment with rule changes on various shards of his empire.

And the best part? A game may be voluntary, but a job is not left so easily. In essence, you have the holy grail of MMOG at your finger tips: player lock-in.

All this is only reasonable considering the trends of technology. You could argue that I'm behind the times and it is happening right now. I, for one, welcome our game designer overlords. The world will be such a cleaner, more efficient, more predictable place. A formal system. And if I play my cards right, I can become one of the gods of this new glorious online universe.

Ah, sweet temptation...the root of all technological horrors.

take care
Danc.

Sunday, June 26, 2005

Confessions of a horrible game player

I'm a bad game player and I'm hoping that I'm not alone. I was just playing Kirby Cursed Canvas. The DS is one of the few hot spots of innovation in core game play mechanics, so I've been dabbling in various titles to keep myself educated on what is out there.

Kirby has some sweet gameplay ideas. The use of a touch pad to control a platform game is both enjoyable and intuitive. The reward system is solid and the use of tiered objectives lets casual gamers enjoy the title just as much as the experts. I played for a full five minutes before I turned off the DS in a fit of irritation. @#$%@# piece of...

Why I suck
This isn't Kirby's fault. It is a great game from what I've seen. I simply have some limitations as a gamer that prevents me from ever being hardcore. In an effort to present myself in the worst light possible, I will list them:

  • Poor reflexes: I couldn't Left, Right, Left, Right, Up, Down, Up, Down, A, B, Start my way out of a paper bag if my life depended on it. Complex sequences of carefully timed actions turn into gibberish when I get my club-like paws on a controller.
  • Irritated by repetition: I play games for enjoyment, not mastery. The first thing I do when I start a game is put the damn thing on "easy." The last thing I want to do is replay some section because I didn't circle strafe with pico-second timing.
  • Absent minded: I forget things. I may play a game for twenty minutes and then pick it up again two months later. If there were any skills that I had learned, there's a 80% chance I'll have forgotten them. The game typical responds with a gleeful "Gotcha! Instant death!"
  • Willingness to walk away: If a game gets too frustrating, I drop it like a rock. When I played Starfox Adventures, I had a blast noodling around with the exploration section. Then the evil designers tossed in a racing mini game. I played that thing about 15 times and got no where. At perhaps 30 minutes into the game, I put it back in the box and never touched it again.
I'd like to add impatience to this list, but I've put hundreds (sometimes thousands) of hours into games I enjoy. I could probably add basic stupidity, but somehow I managed to earn the cash necessary to purchase games. That gives me some say, despite my short bus status.

Horrible gamers unite!
Imagine that there are other non-traditional gamers like me. There are women. There are older men. There are young girls. There are even grandmothers. In a generous (and no doubt misguided) attempt to speak for all of the casual gamers in the world, here are some rules of thumb for designers out there if you want to appeal to the horrible gamers of the world:

Never kill me
Ever. Don't even think about it. Put me in second place. Tell me I could do better. Give me a smaller reward for trying as hard as I did.

There's a rationale behind this. If you look at play patterns, people tend to stop playing when they die. Very few people quit when they are doing well. If one of our goals is to encourage playing, then ending every session with a big dose of negative reinforcement is generally a bad idea. This encourage extended play only in masochists who get amped by pain and failure. Everyone else leaves the building.

Luckily, little boys tend to be masochists and so we've built an industry around them. Now we have to come to grips with the fact that in order to grow our industry, we need game play mechanics that appeal to normal folks, not just the masochists.

Never force me to repeat a section
I know you are proud of your lovely level design. I know I screwed up by getting too close to those spikes. But I was happy to have killed those first five monsters and the maneuver I did to get past the swirly dude was very impressive. Now I have to do it all over again?

When a player is thrown back at the start of the level you've tossed away all his hardwork and told him it was meaningless. This is the equivalent of telling a school child to write a report. Then when they miss a period at the end of the last sentence, you rip the entire report up and tell them to write it over again.

Always maintain my progress even if it makes the game shorter. Kirby would be an even more appealing game if I could just meander around through the levels in a sandbox mode. Keep the objectives, certainly. Most of the game can remain the same. At the end of the level, tell me how I've done. Couch it in terms of progress, not in terms of abject failure. "Hey, there's some cool stuff you could get if you wanted to try the level again." Many racing games where you race against time do this with great success.

Who knows, if the first time was fun enough, I might give it another go. The psychology of such a reward system is very different than a traditional console title.

Reward me for deigning to play your game again.
If I do pick up your game again after two months, let me know you care. Track the time I was away. It isn't hard with most modern machines. Welcome me back and give me the option for a refresher course if I need it. If I'm in the middle of a big fight and seem to be a bit clunky, go easy on me. Double my bonuses and make me feel like I'm the best damned player ever. Make me want to play.

Don't leave me with the feeling "Huh, I guess I suck at this game more than I remember." I don't have time to build up my skills again. And chances are that if the design forces me to reinvest in maintaining my skills, I'm just going to walk away.

Conclusion
In the world of casual games and MMOG, players give you money after they play the game. The demographics are different. The expectations are different. The underlying psychology of a reward is different. If, as designers, we don't understand these differences, if we don't question the traditional game mechanics that designers have relied upon for decades, then we will fail to capture the non-traditional gamer's dollars.

More importantly, I want more fun games to play. I'm selfish like that. :-)

take care
Danc.

Space Crack: Using Planets to Build Territories

Introduction
This part 7 of an ongoing game design document written as a blog. Be sure to catch up on previous posts. In the last installment, we described the Planet token and its use in player-created environments. This time we'll extend the concept of player-created environments with the notion of territories.


In order to create fully realized player-created environments, we need to define some rules that lead to interesting large scale structures within the environment. Remember that one of our requirements for a successful player-created environment is that it does not converge on a small set of strategies. By introducing larger patterns of environment evolution that emerge from a simple set of rules, we can help ensure that this rule is met.

Territories: A theoretical underpinning
Again, I’m going to steal a concept from Go that I’ll call ‘capturing a territory’. You see this same concept in the old arcade game Qix. The idea is simple. Given a large board of tokens, you can create a perimeter that encapsulates a certain number of tokens. Any tokens within the closed perimeter are captured.

I could wax philosophical about the beauty of this system for a long while. Larger areas are more valuable, but end up being more risky. Players spend much of their time jockeying for position on the board in an attempt to break the other player’s perimeter. A deftly positioned token can turn the tide of the battle by capturing a large number of tokens instantly. With the addition of a relatively simple rule set, we get loads of game play.

Increasing player involvement through historical context
Let’s compare the player-created environments of territories to a typical real-time strategy game. In an RTS, many major strategic elements are determined ahead of time by the designer. A few obvious static elements include the location of the most valuable resources, the positioning of various choke points on the map, and in many single player levels, the ebb and flow of the battle with the scripted introduction of enemies.

With territories, the player builds the major strategic landmarks in the environment one move at a time. These maps are more engrossing than many designer-created maps or randomly generated maps because they have historical context. A particular territory is not important just because of its location on the map.

  • It is important because it was built with sweat, blood and intent of the player.
  • They remember building it.
  • They remember defending it.
  • They are emotionally involved as the creator of that little sliver of the map.
Heaven forbid that another player try to alter another player’s little bit of paradise.

Implementing Territories using Planets
Imagine an array of planets, perhaps 50 or 60 on a 2D plane. When a ship travels from a conquered planet to an unconquered planet, a line is created joining the two planets. This line is the perimeter. Planets that are part of the perimeter are called perimeter worlds.

When the perimeter completely encloses a set of planets, those planets are captured and they become core planets. The perimeter, the perimeter worlds, and the core worlds contained inside the perimeter make up a territory.

So using the simple verbs of building a ship and moving the ship, we’ve created a new complex verb called ‘capturing a territory’. Here is an illustrated example of how capturing works.












The reward you get from capturing a territory
Document note: Every new action must have a meaningful reward. Games are made by layering action / reward pairs. Break this rule and you no longer have a game.

Once you capture a territory, what do you get?
  • Each ship on the perimeter worlds are immediately given an attack bonus based off the number of core worlds. Bigger territories are worth exponentially more than smaller territories.
  • You also get a production bonus each turn with bonus Crack flowing into your coffers.
Territories become like M&M’s; a hard candy shell with a tasty inside. Everyone wants to build them since owning a nice territory creates vast wealth for the player. Everyone wants to destroy them since not only do they take away the enemy’s advantage, but if you can break through the perimeter worlds, you can wreak havoc in the interior.

Balancing a new game mechanic
Each time you add a new game mechanic, there are inevitably unpleasant effects that ruin the game. It is worth ‘playing the game in your head’ or in a prototype and seeing what major problems occur.

With territories and simultaneous turns, I want to be careful of situations that involve ‘tit for tat’ tactics. Ray captures a planet needed to complete his perimeter and five minutes later, George recaptures it. This encourages micromanagement. Each turn should be decisive and not involve micromanaging your perimeter.

One possible fix:
  • Temporary immunity for recently captured planets: If a planet was captured in the current turn, it cannot be recaptured.
Conclusion
The combination of planets and territories gives our players a wonderfully rich and varied gaming environment. We’ve also described our a major risk / reward sequence.
  • Action: Conquer a loop of planets.
  • Reward: There are several.
    - Production bonus: You gain more resources to spend on expanding your capabilities.
    - Territory: By creating an easy to defend perimeter, you capture territory and reduce the other player’s options.
  • Failure:
    - Since Command Points are scarce, there is a large opportunity cost associated with attempting to create a perimeter.
    - Also, when you expand without closing off the perimeter, you spread out your forces and make your planets ripe for attack.

Next we need to discuss how planets are captured. This leads us first to Ships, the most kick ass token in the SpaceCrack world.

The next post is up Read it now!

take care
Danc.

Paper Nintendo characters

Here's another example of the neo-retro art style that is downright delightful. Someone recreated a wide range of Nintendo characters with foldable paper cutouts. It is not overly surprising that a close variation of this style is used in Paper Mario. Kudos to 4colorrebellion for linking to this.



Check it out:
http://gotorion.com/orion/singles3.php?t1=Nintendo%20Paper%20Models&f1=miscfunny/papercraft.txt

take care
Danc.

Saturday, June 25, 2005

SpaceCrack: Planet Basics

Introduction
This part 6 of an ongoing game design document written as a blog. Be sure to catch up on previous posts. In the last post we talked about using expressive verbs as the model for player actions. This time we'll talk about the need for a game environment that provides a large set of unique and interesting context for each player action.

I’m going to pull another design technique called ‘Player Created Environments” out of the hat o’ tricks that will help us get this with the minimum amount of effort.

Game Environments: A theoretical underpinning.
The verbs we’ve discussed let the player act on a single token. In isolation, such an action is pretty damned boring. If you merely say “I moved a ship,” the typical response is “So what?”

The context and implication of the action depend on what is happening in the game environment. When you can say “I moved a ship that is going to attack the center of the empire that he is forming as a forward attack base on my home planet” then you start to have an interesting context that engages the player.

Game environment: The current state of all non-player tokens in play at a given moment in time.

Most game environments are largely static and pre-planned by the game designer. This takes a lot of work and is typically done by level designers. They build elaborate set pieces with monsters ready to bash through doors and traps poised to spring on unsuspecting player avatars. This can be fun (usually only once), but to be blunt, as an independent designer, I can’t afford it. Every second of game play takes hours of custom molding of the experience and level designers are damned expensive.

Player-created Environments
This is where Player-created environments come in.

Player-created environment: A player-created environment is a game environment where the current state of non-player tokens in play is determined primarily by the intentional and meaningful historical actions of the players and not the designer.

Go sports the classic player-created environment. You start with a small set of tokens and simple rules for how the tokens interact. Over the course of the game, one move at a time, a complex environment emerges whose game play possibilities confound even the most potent supercomputer on the planet.

What is even better is that this environment is unique. The next time someone plays, they’ll be in the middle of a completely different environment full of new strategic implications. With a few tokens and a simple set of rules, the player creates an astronomical number of ‘levels’ at zero cost to the developer.

There are some basic requirements for interesting player created environments

  • The changes that a player makes to the game world have meaningful short-term tactical implications.
  • Incremental changes build on top of one another such that the environment diverges rapidly from its base state. The cumulative effect of player changes has major strategic implications for the game play.
  • The environment does not converge on a few readily identifiable configurations of tokens. Instead each game builds a unique playing environment.

The distinction between Level Editors and Player-created environments
Inevitably when I talk about player-created environments, someone brings up level editors and mod tool. These tools let someone who was not on the original development team create original, typically static, game environments. Since the editing isn’t happening as part of the game during actually gameplay, these are not classified as player-created environments.

Planets
The core building blocks of SpaceCrack’s player-created environments are planets. Planets form the physical landscape of the game and serve as the hubs for all player activity.

  • Planets produce ships, the only movable tokens in the game. Based on player choices, there are a huge range of ships that can be produced at each planet.
  • Planets produce upgrades and automatically apply those upgrades to ships.
  • Players capture planets to forms a unique topography of nodes that must traversed in order to conquer the universe.
  • Planets produce resources in the form of Crack.

Attributes of a Planet
They have the following attributes

  • Ownership: A planet is marked by it’s owner. Planets can belong to a specific player, be independent.
  • Military Status: A planet can be being attacked, recently conquered, a conquered perimeter world, or a conquered core world.
  • Class: This is used to determine size of ships that are built and modifies the time it takes to build ships. The bigger the class of planet, the larger the planet on the screen.
  • Number of Upgrade slots: The more upgrade slots, the more upgrades can be built on a planet. Upgrades give your planet and ships special powers.
  • Existing Upgrades: Some planets are randomly generated with existing upgrades already built.

Planet GUI
The planet is the center of the graphical user interface of SpaceCrack Classic. This section describes the icons that exist. Other sections describe how these gizmos are used.

  • Player Ownership: The base texture and color of the planet changes based off which empire owns it. All planets owned by a player have the same texture.
  • Ship Platform: A space station exists for building ships. This is attached to the planet.
  • Upgrade platform: Each planet has a fixed number of upgrade platforms. These are floating disks that also rotate around the planet. By clicking on an empty Upgrade Platform, a menu appears that lets you build a specific upgrade.
  • Upgrades: An upgrade gives special powers to the planet or any ship built on the planet. Once an upgrade is built, it is no longer interactive. Rolling over the upgrade gives a tool tip describing what the upgrade does.
  • Planet rotation: If the player wants to see what upgrades a specific planet has, they can grab the planet or existing upgrades and spin it. Planets spin with momentum.
  • Planet tool tip: Rolling over a planet gives basic stats including Planet Class, # of open upgrade slots, # of total upgrade slots.

Changing Planet Ownership
Each player owns one planet at the beginning of the game. All other planets are independent.

  • Conquering independent planets: The first player’s ship to land on an independent planet takes ownership of that planet. The first player to land on an independent planet gets a Crack bonus.
  • Conquering enemy planets: When a player ship wins a battle at a player against a defending ship, the winning player take ownership of the planet.

Conclusion
We’ve just nicked the surface of Planets and how they contribute to the gameplay. However, at this stage, we’ve described the basic building block of our player environment. Each planet has a number of attributes, each of which has a major impact on the gameplay. The player can manipulate almost any attribute with the basic verbs that we described earlier.

This is a very important design concept. Tokens in player-created environments tend to sport attributes that are player-defined, not designer-defined. If games are all about the player making meaningful choices, why spend time adding attributes that only present meaningful choices to the designer? Remember: we are building this game for Ray, not ourselves. Truly embracing this design philosophy can have a major impact on your game design.

Next we need to figure out a player-driven mechanism for organizing our planet tokens into strategically interesting environments.



The next post is up! Read it now.

take care
Danc.


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.

Thursday, June 23, 2005

Vistech 2005: Thoughts on the military industrial game complex

I gave a talk at a tradeshow called Vistech earlier this week. With all the traveling and attending talks my posts have been coming slower than I would like. Thanks to everyone who keeps visiting the site even after the Nintendogs story dropped off Slashdot and Kotaku. :-)

Vistech is a brand new show by Halldale that I would classify as 'Serious Games for the Military'. The military talks are always intriguing because they are solving problems with game technology in ways that are quite different than your typical game developer.

There is also some weird freaky shit out there. If you ever get invited to a real talk about improving the 'kill chain', run and hide. I didn't know this, but a kill chain is very much like a supply chain in business. Except where a supply chain delivers boxes of shoes to Walmart, the kill chain delivers enemy bodies...Efficiently and with the least amount of thinking required. Applying the scientific process to war activities is a long standing tradition, but it still gives me the shivers.

Here are some fun technology trends...

Good trends that I found interesting
  • Hybrid systems (aka Augmented reality): The ultimate goal of many folks is get to the point where the virtual simulated world is placed on top of what the pilot is seeing out the aircraft window. In a normal aircraft, the pilot would look out and see trees. In a hybrid aircraft, the pilot would look out the window and see a tank blinking in the trees. The tank is completely virtual and is based on a momentary sighting 5 minutes ago by a drone. Its current position is extrapolated from an AI algorithm that is used to plot its potential course.

    Combine the data from hundreds of aircraft, infantry, sensors, etc with satellite data and that little window out the cockpit becomes a highly illuminated, data rich environment. In twenty years, this technology will start making its way into the commercial world. Software tends towards commodity pricing so the only thing keeping this back in the long term will be hardware and display costs.
  • Ladar scanning: The single biggest problem facing the use of 3D in serious applications is the cost of producing meaningful 3D information. At Anark, we rely primarily on CAD data because of the huge repositories deep inside manufacturing companies. Other folks are looking at ways to rapidly scan large scenes with a laser system (or photographs). Drive down a street and get a multi-terabyte point cloud model complete with color and all the little details.

    In 10 years or so, this will turn into 3D photography. You won't model anything from scratch. Instead, you'll whip out your special 3D camera and capture a massively high resolution model that is then post processed to run on 3D hardware. The part that excites me is the inevitable creation of "3D photoshop". That will be sweet.
Bad trends
  • Recycling game engines: We are at such an early stage of transferring game technology over to other sectors, that the primary method evident is outright theft. Grab the Unreal engine, slap a new mod on it, and call it an Army game. This works for a small set of problems. It doesn't work for many other problems (for example, ones that don't involve shooting people)

    The 'stealing phase' of technology adoption is common and inevitable. My worry is that this becomes the primary mode of dealing with game technology. We need to open our eyes to the broader possibilities. Rip out all the guns, and look at a physics system, a 3D engine and all that lovely networking code as a tool kit. Find a problem and apply the tool kit. I suspect that if you do your job well, you'll come up with an application that is very effective, but looks nothing like a FPS.
  • Small size of events: Games have been around for a while. The problems that game technology helps solve has been around for a while. Yet there were only a page full of names attending this conference. They are the forward thinkers, the visionaries. Very cool, but the industry cannot grow with visionaries alone. I look forward to the day when the accountants, middle managers and people on the front line come to conferences such as Vistech because it is pertinent to their jobs.

    I have hope. The Serious Games Summit keeps doubling in size each year. New shows like Vistech and the Synergy Summit are popping up. With any new industry, it is simply a matter of time and momentum. We have the later, but I'm an impatient fellow.
take care
Danc.

Thursday, June 16, 2005

SpaceCrack: Verbs

Introduction
This part 5 of an ongoing game design document written as a blog. Be sure to catch up on previous posts. In the last installment, we made a quick inventory of all the pieces in the game. This time we'll dig into the part of the game that matters most to first time players, the things they can do.

Expressive Verbs: A theoretical underpinning
The immediate question that comes to mind is "what can the player do!?" If I'm remembering my game design history correctly, Chris Crawford came up with the concept of measuring the interactivity of a game by the number of "verbs" that a player can choose from. These verbs represent meaningful choices that affect the playerÂ’s traversal of the simulation/interactive story/system of psychological rewards (Feel free to insert your current favorite theoretical foundation for games)

SpaceCrack is a simple game that relies on design method I call "expressive verbs". These are simple verbs with complex environmental connotations. The result is the player can only perform a few actions, but the impact of these actions vary dramatically in effect depending on when and where you perform them.

The classic example of an expressive verb is found in Go. The player can place a single piece on the board. However, the environment within which the piece is placed provides a rich set of contextual meaning for the move. With one simple action you could win the game, lose the game or do anything in-between. In fact, the shades of meaning associated with placing a piece in Go are infinite and can take on hues of rivalry, respect, submission, deceit and more.

When designing game verbs, it is better to go with a small number of expressive verbs than to overwhelm the player with a truckload of shallow verbs. This is a fundamental requirement for creating a game that is easy to learn but difficult to master.

SpaceCrack Commands
I'm calling the verbs in SpaceCrack 'Commands' since they use up Command Points as a primary resource. Below is the complete list of Commands that can be given in the game:

Required

  • Build a ship.
  • Move a ship to a planet.

Optional

  • Build an upgrade on a specific planet
  • Send a message to another user.
  • End the turn

All players will need to learn the required verbs in order to play a basic game. If they want to become experts, the optional verbs will help them play better. Having a hierarchy of verbs helps new users pick up the game quickly.

This is streamlined vocabulary that lets the player can place a new token, modify a token, move an existing token or do nothing. Messages add a strong social context to all these actions. Novices can learn this list quickly, but the scope of the verbs also enough room for expert player to explore a universe of game play.

Resources required to perform a Command
There are two key resources required to perform an action.

  • Crack: The first is the name sake of SpaceCrack, a miraculous nanotechnological substance known as "Crack". With this currency you buy ships and upgrades. The economics of the crack trade in the game will be discussed in a future entry.
  • Command Points: The second resource is Command Points, which I mentioned in the previous post. Most Commands takes a set number of Command Points to enact. When you perform a Command, the appropriate number of Command Points are removed from your supply. We will be adjusting the number of Command points required for each action in order to balance the game.

Time required to perform a Command
Some commands also take an integer number of turns to complete. Items that take 1 turn are enacted immediately. Once you have used all of your Command Points, you can click the "end turn" button.

Let's say you are moving a ship to another planet. This going to take you three turns. The ship will travel 1/3 of the way there and stop. That is as far as the ship can move in that turn. If it is firing its weapons, it will fire for 1/3rd of it's path and then stop. Think of the ship as being on a personal timeline that is played 1/3rd of the way through and paused.

Command and massively multiplayer games
Because turns are executed in a simultaneous fashion using a single game world clock you can have lots and lots of players and no slow down of game play. This excites me.

  • You can have a game with 2 players.
  • You can have a game with 50 players.

Cool technology that needs to be built
Commands are calculated on a central server and the results are sent back to the client for rendering.

  • Players does a command which submits the command to the central server.
  • The central server contains a copy of the game world. It simulates the results of the various orders. The server contains basic error checking to ensure that no one submits impossible commands with a hacked client.
  • A new game world state is generated.
  • The set of changes necessary to generate this new game world state is sent to each player.
  • The player sees the result of their command and may perform a new command if they have points remaining.

Conclusion
So far you have an idea of what the player can do, but to really make this meaningful, we need to start talking about tokens. What the heck are these planets and ships I keep talking about?

Be assured that they are more exciting than your wildest dreams. And I'm pretty sure that your dreams are wild. (I have inside information)



The next post is up! Read it now.

take care
Danc.

Tuesday, June 14, 2005

The Neo-Retro Art Style: Savior of the game industry?

This summary is not available. Please click here to view the post.

Sunday, June 12, 2005

Space Crack: Building a gameplay parts list

Document Note: Games are complicated. This ‘small’ design
will be 20+ pages by the time I’m done and most designs run into the
hundreds of pages. This post compresses the entire design into a single
page. Game design can become horribly abstract and it helps to have a
complete (if simplified) vision of the gameplay in your head before delving
to each area.
Introduction
This part 4 of an ongoing game design document written as a blog. Be sure to catch up on previous posts. In the last installment, we described how to reinvent the TBS game genre. This time we'll give a short list of the parts we'll need before we can put together the complete game design.

How to summarize a game in 1 page
We need to write down an inventory of the mechanical pieces of the game design. Much like a car is made of wheels, engines, seats etc, you can break down most games into the following parts categories:
  • Tokens and Resources
  • Verbs
  • Rules

Tokens
Every game is made up of tokens. A token is an object in the game that is manipulated by the game rules and the player. All the tokens in play at any one time form the game environment.
SpaceCrack has a rather small set of tokens:

  • Planets: Thing of these as the chess spaces on the board. They provide resources to those who own them. They can build ships.
  • Ships: Ships are tokens can be sent to conquer enemy planets and can defend against enemy attacks.
  • Planet Upgrades: These are additional abilities that enhance a planet.
  • Ship Upgrades: These are additional abilities that enhance any ship built on a planet.
  • The Sun: The sun provides extra resources and goes super nova if the game goes too long. Think of it as the referee.

Resources
There are also two resources. These are really a specialized form of token, but I’m not going to quibble with definitions.

  • Crack: These are also used to perform Commands.
  • Command Points: These are used to perform Commands.

Verbs
Verbs are the actions that the player can perform. In this case there are a handful:

  • Move a ship to a planet.
  • Build an upgrade.
  • Build a ship.
  • Send a message to another user.
  • End the turn

Rules
Rules are how all these tokens and verbs play nicely together. The following rules govern the game:

  • Players build ships and upgrades using crack and command points.
  • Players move ships onto enemy planets to conquer them.
  • Ships battle one another and the winner gets the planet.
  • The person with the most planets in the end wins.

Any questions? I'll dig into each one of these in more depth in upcoming posts.

The next post is up! Read it now.

take care
Danc.

Space Crack: Graphics Mockup


Click here to download the presentation (2.5 megs)

Just download the zip file, unzip the exe onto your drive and run the file.

Some things to try:

  • Building a ship
  • Launching a ship
  • Wasting command points
  • Building an upgrade
  • Spinning the planet

This particular test isn't intended to be very functional. The goal is to create the graphics and put them together in context so I can see if this art style works. The theme of the game is 'white space'.

Expect a bit more 'glitz' as I flesh the rest of the game tokens out.

take care
Danc.

Space Crack: Fixing the Turn-based Strategy genre

A discussion of simultaneous turns

Document Note: Each feature in a game design must address a need or solve a problem that occurs with the design.

Introduction
This part 3 of an ongoing game design document written as a blog. Be sure to catch up on previous posts. In the last installment, we described a typical person who would play SpaceCrack and some of the requirements the must be fullfilled in order for the game to succeed.. This time we'll look at how to reinvent the TBS game genre.

But TBS games suck!
There are good reasons why TBS games are dying as a genre. The fanboy in me hates to face the music, but as a designer I realize that there are fundamental flaws with the reward schedules in a typical TBS game. Here are some common ones:

  • Multiplayer games take forever: In the typical “I go, you go” turn structure you are waiting to play most of the time. Play for 5 minutes and wait for twenty results in lots of bored players.
  • More players results in longer games: As you add players, the wait gets longer. Boring.
  • The first turn is boring: Inevitably nothing happens in the first turn. Then you end your turn and wait for the other player’s results. Often, it is not until you are four or five turns into the game does it get anywhere close to interesting.
  • Complexity rules: As an old genre, there are lots of genre conventions. Most TBS games have loads of statistics and complex game systems. This is comfortable for some advanced players, but acts as a huge entry barrier for newer players.

It is no wonder that people dismiss TBS games. If you are looking for a quick gaming fix, this is the last genre in the world you’d want to play. Luckily, we have a lovely solution to all these issues.

New and improved multiplayer TBS
The genre has been evolving. My friend Lennart Sas created a TBS game called Age of Wonders. It had an original multiplayer turn structure called “simultaneous turns.” SpaceCrack steals his idea because, quite frankly, it is ingenious. Some benefits include:

  • The first few minutes of the game actually exciting.
  • Game play moves faster compared to traditional turn-based games.
  • It works great with both multiplayer and single player.
  • You can have fast games that are similar to an RTS. You can have slow games that are similar to play-by-email. All with the same basic game mechanics.

Real-time…
The turn structure is a variation on real-time networked game play. As far as the player is concerned the universe is always ‘live’ with the state of the playing field maintained on the server.

When the player logs on, they start getting real-time updates on the state of the game world. If another player attacks a planet, the player can watch this happen. No more waiting, no more convoluted phases.

But not real-time…
The game is divided into turns, during which the players can accomplish a fixed number of tasks using a limited number of Command points.

Players spend Command points in order to perform actions ranging from building a new ship to attacking an enemy planet. When the command points are spent, the player’s turn is over.
The turn structure and command points keep the playing field even. You can’t perform twice as many actions as your enemy. You can’t use your twitch skills to pummel an enemy that stepped away from their computer.

Turn Structure Variations

  • New command points every X time period: The player gets new command points every X period of time. For a short game, this could be every 2 minutes. For a long game this could be once a day. If a player does not spend his command points with the turn time limit, the points roll over to the next turn.
  • New command points when all turns are ended: When every player has hit ‘end turn’ or has exhausted their command points, the server gives out new command points. This means games can last forever if there is a laggard.
  • Mixed: If either the time limit or all players have ended their turn, command points are renewed.

Cool technology that needs to be built

  • Server: There is a server that tracks the state of each game. All calculations of world state are performed on the server.
  • Client: There is a client that can display updates from the server when the world state changes. The client must also be able to submit action that change the world state.
  • Command Management System: There is a system that manages command points and the end of turns.

Example

Document Note: Features are often difficult to visualize without a diagram and a game play example. If you want your design to convince, you need to include clear, emotionally exciting examples of each feature in action.

“Ray logs into his latest SpaceCrack game with his regular playing buddies. He got the new turn notification last night in his email, but didn’t get a chance to play since it was date night.
He has 10 command points available. Looks like Porter is online as well and the other guys have already finished their turns. Ray does a quick glance over the map and the news log to see what has occurred.

He moves a few of his ships towards an enemy planet. The missles fly and he destroys the defending ship. Within a minute of playing, he has launched 4 attacks and taken over 1 planet. He spends a couple more points building upgrades on his new planet and another couple of Command points moving some ships in as reinforcements.

A message blinks and Porter sends him a message ‘Hey, check the Troglis system.’ Ray zooms over to the Troglis system just in time to see Porter’s battle ships knock the planet flying. Daniel, the planet’s owner, is asleep in Sweden but that’s okay. The way the command points work, this isn’t like a RTS where he could have mounted some twitch response. Daniel will see the report in the morning.

Ray decides to save his remaining Command points and hits the End Turn button. Once everyone has finished, there’ll be a new round with a batch of fresh Command points waiting him tomorrow. “

Conclusion
I wanted to get the concept of simultaneous turns up front since it has a major impact on the rest of the design. In the next post I'll cover the basic elements of the game design: Token, Verbs, and Rules.

In other news, I've also been mocking up the graphic style of the game and some of the basic interface systems. I'm doing my mockups in Anark Studio and though I'm biased (I designed the damn tool), it is truely a joy to whip up this sort of thing. I banged out a working pie menu in a couple of hours and I didn't need a programmer. As a game designer who can't code my way out of a paper bag, this is truely an empowering experience.



The next post is up! Read it now.

take care
Danc.


Saturday, June 11, 2005

Nintendogs: The case of the non-game that barked like a game

A game design review of an innovative game

My beautiful lass recently borrowed a copy of Nintendogs from a friend (Thank you Porter!). This title has been burning up the charts in Japan and managed to get a perfect score in Famitsu magazine, a feat matched by only 4 other games in history. Why is it so successful and what can we learn from it as game designers?

This is a game design review, not a game review. A game review typically is written for the consumer and is intended to help them decide if they want to purchase the title. A game design review is written for other game developers and is intended to highlight successes and failures of the various layers of the game design. The hope is that we learn from the successful design practices and apply them in an intelligent fashion to our future titles.

Not a game?
The first thing that arises whenever someone talks about Nintendogs is the claim that it is not a game. "Dude, it is just a stupid Tamagotchi clone with dogs!" Such a vehement response is indicative of a larger trend in both the designer and gaming community. Unfortunately, it is a trend that has its roots in a fundamental misunderstanding of game design.

To generalize, there are two camps of designers in the world

  • Craftsman designers: Craftsman designers look at existing titles on the market and build up these to create improved titles. Craftsman designers are always hardcore game players with intimate knowledge of their preferred genre. Craftsmen know details, but fail to see deeper patterns.
  • Theoretical designers: Theoretical designers looks for common elements across all game genres and builds their designs from these fundamental parts. Where a craftsman designer might say "My FPS (First Person Shooter) needs a double shot gun to replace the single shotgun", a theoretical designer might say "Player enjoyment is dropping at this point, so we need to add a new risk/reward schedule."

The craftsman definition of a game.
Each of these two groups looks at a title like Nintendogs in very different ways. A craftsman designer classifies a title as a game if it fits into a pre-existing category. Is it a RTS game, a FPS, an adventure game, etc?

  • Is the game title part of a pre-existing genre?
  • If so how does that title compare to my personal enjoyment of other games in that genre?

This method works well when you operate within well defined genres (as is the case with most hard core gamers.) It breaks down when a title doesn't fit into a pre-existing genre. They'll still apply the same analysis, but generally end up shoe horning the title into a genre that is a poor fit.

There is nothing on that market that compares to Nintendogs. If you dig into the game mechanics at an abstract level, it has surprisingly more in common with a RPG than most virtual pet games. Yet hardcore gamers make a snap judgment and instantly assume it must be a Tamagotchi-style game. This is an unfortunate mistake that limits our understanding of the game design.

The theoretical definition of a game
The other way of looking at it is to look for the key elements that make up any game.

  • Are there psychological risk / reward systems?
  • Are there overlapping reward cycles on different timescales?
  • Can the game design be classified into standard game design elements such as tokens, verbs and rules?
  • Can the various layers of the game design be separated out so that the title can be examined in terms of core mechanics, metamechanics, contextualized tokens, plot, etc?

Nintendogs has clear game mechanism in each of these areas. There are clearly specific elements throughout the game that match existing game system that have been used throughout the history of game design. The theoretical designer realizes that a powerup is a powerup whether you call it a 'Quad Damage' or a 'Doggy Brush'.

To get this point across, let's look at Nintendogs by identifying the various game play elements that make it such an addictive experience and then compare those to the same mechanics used in other genres.

Overall Structure
Nintendogs follows the path of many successful titles. You start out with a novice character and through a variety of challenges and adventures, you grow the character in strength and power. Along the way, you gather treasure, gain new abilities and discover far away places.

In Nintendogs, it just happens that your character is a puppy and the world you are exploring is the city around your house. The battle sequences where you gain experience are dogshows. The powerups you get a hair care products and doggy snacks. Strip away the setting and plot of Nintendogs and you are still left with an innovative title, but it is one that bears more than a passing resemblance in structure to many other games.

This big structure is composed of smaller elements

  • Core mechanics: Layers of risk / reward activities
  • Meta Mechanics: Additional activities that tie together groups of core game mechanics.

Core Mechanics: Learning tricks
The primary activity you do with your dog is tell it commands and pet it. The first level of risk / reward cycle goes something like this:

  • Action: Say a phrase in a clear concise manner.
  • Reward: The dog responds with an attractive animation.
  • Example: Say "Lucky!" and the dog comes up to you. Say "Sit" and the dog sits.
  • Comparisons to other titles: In a fighting game, you hit a button with specific timing and it kills an enemy. The enemy crumples to the ground in an attractive animation. For Nintendogs, voice is certainly a fun new control mechanism, but in many ways it is no different than hitting the attack button in the fighting game. From a game mechanics viewpoint, pressing a button that means 'sit' is identical to saying 'sit' and having a voice recognition sub-system return the value 'sit' to the game.

The second level of risk / reward cycle builds on the first.

  • Action: Once you have gotten the character to perform a 'success' animation, you can now rub your stylus on the dog.
  • Reward: The dog plays an additional success animation, and gains 'happiness'
  • Example: After the dog sits, you can pet the dog and he arches his back contentedly. Pet long enough a sparkle appears that states you have improved your dog's happiness.
  • Comparisons to other games: In our fighting game, the dead enemy drops a heart. You need to run up to the coin and collect it, thus improving your 'health'. The meter that records your dog's happiness and the meter that rewards your character's health serve nearly identical purposes despite their very different names.

The third level of risk / reward cycle adds an additional layer.

  • Action: Periodically, the dog will perform a new action. You can enter into a minigame in which you must say a particular phase associated with that action over and over again.
  • Reward: The dog plays an additional success animation, and gains a new ability that will let you take on additional metagame challenges.
  • Example: During petting the dog rolls over on it's back you are presented with the option to train it to do the 'rollover' command. You say 'rollover' repeatedly until the dog understand what you are saying. Music plays and your dog learns a new trick. As a higher level reward, this is immensely satisfying.
  • Comparisons to other games: In our fighting game, the character fights their way past a boss enemy (think Megaman). At the end battle, an animation plays and you gain the 'Ice attack." Woot!

Metagame: Competitions
Once you've gained a few skills, you can participate in dogshows. Think of this as a game of Simon. You must perform certain actions within certain time limits. If you succeed, you win money that can be spent on additional goodies and powerups.

There are a variety of other competitions ranging from agility contests to Frisbee tossing events. These events help put your skills to use and provide a clearly defined set of challenges for goal oriented players. The 'win challenge stage, get money' is a system found in most games. Just because it involves a puppy doesn't mean you aren't dealing with old school proven game mechanics.

Metagame: Walking your dog
Walking your dog is very similar to the overworld in a typical RPG. This how you discover new places such as training courses and special encounters.

One innovation that Nintendogs adds here is that the distance you can travel is dependent on the strength of your character. This creates a challenging mini-game. Given a limited amount of energy, what path exists through the city that lets your dog hit the maximum number of bonus points and special areas? This is a minor variation on the Traveling Salesman problem that most computer science students run into in their undergraduate courses. There is no easy solution to this class of problem, which makes it a constant challenge.

The special points on the map are randomly generated so the player is required to come up with new routes each time. This helps prevent burn out. Also, there is an explicit 30 minute timer in place that reduces the rewards if you play this section too often.

Other game systems
There are numerous other common systems involved in Nintendogs.

  • Random reward schedules: When your dog brings you a present, it can be something good or something useless. By having intermittent reinforcement, the designer maintains the enjoyable addictive nature of the reward for a longer period of time.
  • Sandbox Levels: The interior area that you start out in acts as a sandbox area for introducing new actions (like the Frisbee). When the goal oriented challenges appear, the player is already trained in the basic use of their character's abilities.
  • Time penalties: When you don't play for very long, your character loses some of it's powerups. The dog gets dirty, hungry and thirsty.

Everywhere you look are standard game design techniques. The initial structure of the game, how skill are introduced and then used in challenges, the entire broader meta-game that drives the player forward...all these can be found in great games going back decades. Nintendogs is a good game because it has a solid game design, not just because older Japanese women like dogs.

However, the reason Nintendogs is a great game is because older Japanese women like dogs. Nintendogs is also a glorious example of game anthropology at work.

The game anthropology of Nintendogs
A solid game design is one piece of a successful game. However, a successful break out design needs to also identify an unmet need in the society at large.

Game Anthropology: Game anthropology is about watching how ordinary consumers go about their lives; what sort of things do they do, what do they want to do, how do they use the things they have? Amidst all this, what opportunities exist to play games?

It turns out that Japanese folks love dogs, but due to their cramped apartments they are rarely able to own them. Every child dreams about owning a dog, yet very few ever will. There are actually dog renting services that let you walk a dog just for a little while so you can capture the thrill of pet ownership.

The designers of Nintendogs recognized that if you can build a game that lets people experience the joys of owning a dog you can tap into a market rarely touched by traditional games. This is a very different thought process than "Let's make a game like X except better". Instead, it requires game designers to go out in the field and understand how games an be applied to broader trends in their culture. The designer of Nintendogs asked the simple question "How do games apply to the world outside of me?"

Such big picture thinking that is utterly alien to people who think of games as the sole domain of elite geeky guys. The good news is that people who successfully apply the techniques of game anthropology are rewarded beyond their wildest dreams.

Conclusion
Nintendogs is a game that get two key elements right:

  • It addresses a niche need within the broader culture that is highly underserved.
  • It understands game design theory well enough to build an original new game experience out of proven game design techniques.

Kudos to the theoretical developers behind Nintendogs and their mastery of the game design process. Anyone who calls themselves a game designer should pick up the title when it comes out in English. It is a perfect case study of how to build a highly innovative game that achieves impressive market success.

Ignore the fools who claim that it isn't a game and dismiss it's success as a random chance. The myth that game designers must be derivative to be successful is fundamentally false. Creating successful innovative games like Nintendogs is wholely a matter of hard work and a deep understanding of the game design process. The phenomenon of Nintendogs is completely reproducible if we heed its design lessons.

take care
Danc.

PS: There is one poor design choice in Nintendogs that I wanted to call out. Time penalties for not playing are a horrible way to encourage people to start playing. The person may feels obligated to play but games should not be a guilty activity. I much prefer systems like those found in World of Warcraft that give the player bonuses if they return after not playing for a while. The player feels "I haven't played in a while, but if I play now I'll get something good!"

Time penalties can backfire on the designer. Often, the player assumes that their work has decayed so far (the dog has forgotten words, etc) that it is simply not worth playing again. The player who has fallen off the wagon feels "I am so far behind now, why try?"



Wednesday, June 8, 2005

Space Crack: Why Space Crack?

Document Note: A game design must justify its existence. If you are going to
spend thousands of hours on a title, there should be a good reason behind what
you are building. “Because I want to” is not good enough. “Like Title X, but
better” is not good enough. What is the unique need does your game title fill?
Why would anyone play this game instead of other games?

Introduction
This is an ongoing game design document written as a blog. Be sure to catch up on previous posts. In the last installment, we described the basic gameplay in a brief story. This time we'll lay out the guiding requirements for the game design.

We need to build a casual TBS game
I have a friend named Ray. He is quite a bit over 30, has a wife and some kids. He grew up in the glory days of PC games, but the market has changed and so has his life. He still wants to play games, but there is very little on the market that fits his needs.

He has a craving for a simple turn-based strategy (TBS) game that he can play against his friends. Unfortunately, the number of polished strategy titles on the market is A) depressingly slim and B) targeted at people who have far more spare time than Ray does. For Ray’s sake and all the millions of people just like him, let’s create a casual internet game that brings back the ‘sitting around the table’ beer and pretzel game experience.

  • Requirement #1: The play time is less than 20 minutes for a quick match or we can have a multi-day match over email. SpaceCrack is the Counterstrike of TBS games.
  • Requirement #2: If you happen to consume a fine alcoholic beverage or three, the game is still completely playable. Much like Mario Party or other social games, SpaceCrack can be enjoyed by drunk monkeys. (Ray doesn’t drink, but his friends do)

A game for old people
Twenty year olds think Ray is eccentric when he talks about the joys of TBS games. Teenagers don’t even recognize the genre. Instead they flaunt their mad RTS game skillz and snipes Ray in the head as he hobbles around corners in Quake.

Ray wants a game that is impervious to youthful reflexes. He dreams of plotting out his moves, scheming over delightful tactics and chortling to himself in the time honored fashion of a master strategist. When he dies a miserable death (and he will) at least he’ll know why.

  • Requirement #3: This is a TBS game. We can twist genre conventions like crazy with the design, but a turn-based structure will still be the primary mechanism used to balance the game. If there are young whipper-snappers present, the old drunk monkeys can still win.

Easy entry
The game must be easy to pick up or else none of Ray’s equally ancient friends will ever play. Ever recommend a game to someone, watch them glance at it for a minute or two and then give up? Many games require a good 15-30 minutes to really grok. New players tend to bail.

  • Requirement #4: In less than 2 minutes, the game needs to teach you how to take over the universe. In five minutes, you should be kicking enemy butt.
  • Requirement #5: In the first 60 seconds, first time gamers should have a smile on their face.

Social focus
Ray wants a game that forces him to hang out with his friends. Amidst all the working, running errands, etc he needs an easy way to carve out a chunk of dedicated gaming time with people he knows. And the game needs to remind everyone to play since goodness knows some of his friends are incredibly absent minded.

  • Requirement #6: There needs to be a way to schedule a gaming session with friends quickly and easily. (Not with anonymous fanbois, please.)
  • Requirement #7: If we set a gaming date for a Friday night, then people need to be reminded to tune in. If they fail to show, they will be abused in a fashion befitting their lameness. Think eVite.

Promotes long distance relationships
Modern America is anti-community. Jobs entice us to leave our home towns, colleges and social networks behind. In your lifetime, the friends that you make end up strewn across a dozen states and several countries. Many folks like Ray live in suburbs an hour away from even minor acquaintances. The simple act of say “Hey, let’s meet over at my house” presents a surprisingly difficult and costly challenge to most friends.

This game is going to change all that. Honest.

  • Requirement #8: The game is playable over the internet. Anyone in the world can participate, not matter what the timezone.
  • Requirement #9: There is a chat system and forums so that people can reaffirm old bonds and reminisce about past and future battles.

Now we've described a bit of who this game is for. Creating a rich target persona and setting core requirements helps us keep the design focused. If the design is spinning out of control, we can always play the game "What would Ray like?" to help make those hard decisions.

Time to dig into the core game mechanics in the next post! (I always get excited about this next step :-)



The next post is up! Read it now.

take care
Danc.

Space Crack: Introduction

Your email box has a message. “9pm tonight. Time for some SpaceCrack. – Ray
At 8:55, the baby is asleep and you log onto the computer and double click on the SpaceCrack icon. You grin: Everyone is here, even Daniel over in Sweden. The familiar friendly jabber starts immediately. You get down to the task of taking over the universe.




Planets like giant billiard balls strewn across a solar system. Using terraforming technology and powerful worldtugs, you gather planetoids and asteroids together into an interplanetary empire. Your enlightened rule leads to a golden age of technology and economic prosperity.

Along comes the Enemy with a massive empire-busting warship the size of Mars. He slips through your defenses and plows directly into the heart of your empire at full speed.

Mayhem. Planets scatter and fragment. The combined might of Mike and Daniel’s attack force mops up your remaining ships. Bummer. Only 20 minutes have passed, the wife is still happy, and you have a grin on your face for the rest of the night.

SpaceCrack is an interstellar strategy game without all the numbers, playable in a web browser. Learn it in two minutes. Challenge your friends over email and kick their ass. Simple. Easy to learn. Playable by drunk monkeys.

The next post is up! Read it now

take care
Danc.

Thursday, June 2, 2005

Using a blog as a game design document

I've written lots of design documents...Hundreds and hundreds of pages of design documentation that occasionally gets turned into a nifty product. It goes without saying that the vast majority don't get read unless they are essential to the final implementation. That is a start, but I'm always looking for better ways to convey ideas and get people on board.

What is the goal of a design document?
Not all design documents are created for the same purpose. The two most common ones I run into are as follows:
  • Convey implementation requirements: "Put this feature C at (X3, Y4) and hook it up to widget B!"
  • Convince: "Let me tell you a tale about widget B and how cool it would be to implement!"
The first is the traditional use of a design document and tends to focus on lists of implementational details. If it isn't specified in the design document, it isn't going to get done. So people tend to overdo the exhaustive detail. Honestly, it is no wonder that people avoid reading such literary monstrosities unless forced to by whip cracking managers.

The second is quite common, but rarely acknowledged as part of the development process. Teams don't always get to meet communally on every feature and usually one or two people have a strong understanding of a particular feature's benefits. These feature champions often write the design documents, the one touch point that is available to all team members.

Problem: No one reads it.
Here's the problem. If you write the first draft of a feature design in the highly specified fashion promoted as a 'good design doc', no one will read it and it becomes hard to build any sort of excitement around the idea. I've seen hundreds of great design ideas wither on the vine because highly technical design docs are tossed over the fence and no one ever really grasps the full picture about why the feature matters.

Problem: Too expensive to create
Documents intended to convince are usually created in the early stages of development. Ideas are rough and speed is essential. Often you'll need to bang out a feature concept in a spare 30 minutes and then submit it to the team. If the authoring medium is too difficult to use (raw HTML comes to mind) no one will take the time to put their design thoughts down.

How do we write a design document that convinces? (And isn't horrendously boring to read or expensive to create)

A blog as a narrative design document
One of the things I like about blogs is that they have an inherently linear narrative built into the structure. "Monday, 8:42am: Today, I ate bacon." followed by "Tuesday, 8:15am: This sounds like a bacon day too" Each post gives a sequential snapshot of a person's life.

What if a blog could tell a reader friendly narrative story about a product design? Blogs are easy to write and generally reader friendly. The text doesn't have to be structured like a novel (few blogs are). But like a story, you can mention relationships between items coming up in the future. You can use more casual engaging language. You can lead the reader through the beginning of the project all the way to the end.

How iterative development maps onto a blog
Iterative software development lends itself quite well to a story where each iteration is a chapter. In iterative development, you typically follow a standard pattern
  • Identify the big story
  • Identify the most important things that need to be done first from the customer's perspective.
  • Build it.
  • Ask what needs to be done next based off your current project status and customer needs.
  • Repeat with a new iteration.
What you end up with is a rich explanation of the rational behind each feature. As you add features, your are building a narrative leading towards a final goal or product state.

The role of comments
A post in a blog is an authoritative statement of reality. A page of a design must also be authoritative. However, a design intended to convince others must also have a feedback mechanism to address concerns, worries and other ideas. The comment section of a blog is perfect for this. Each 'chapter' of the design is up for public discussion. When changes must be made, the author of the post can go back in and make the revisions.

Specifying the Blog-based Game Design
What are the elements of a blog-based game design?
  • Introduction: The big picture on why this product matters. Who does it serve? Why should they care? Why should the developers care?
  • Walkthrough: A simple story illustrating how the game plays. This is an example illustrating the big story.
  • Core Systems: What are the core game mechanics that the player will be engaging in. What systems are required to build this core game mechanics?
  • Release: This post describes a minimum bundle of features necessary to create a truly playable game. The game can be broken, but everyone on the team needs to feel the vision and understand what happens next.
  • Feature: What is the first feature that will make this game come alive? Include descriptive example text. No lists please.
  • Next Release: Celebrate the previous Release and do a virtual post mortem. Discuss what needs to happen in the next release and the features necessary. Tie it all back into the big vision. Repeat!
  • Conclusion: What happens at the end of the project? What is the result? Sell the reader on the fact that all this effort was well worthwhile.

All these posts are kept to a manageable size and have a narrative writing style. If the post is too long, chances are slim someone will implement it without losing sight of the big vision of the product.

Benefits of Blogs as Design documents
  • Easy to author: No fancy formating, just bang out the text. Sweet.
  • Searchable: Looking for something? Just search the blog and you'll find it.
  • Linkable: Want to send someone just a single feature. Forward the link.
  • Comment Friendly: Nuff said.
  • Speaks with one voice: The posts are the authority. Everything else is just noise.
Problems with Blogs as Design documents
  • No Autolinking: Typically a designer will build up a unique vocabulary as the design develops. It can be useful for the reader to be able to access these words. Wiki-style autolinking would alleviate this issue.
  • Linear structure limits non sequiteurs: Traditional narrative plays with this issue constantly. Thankfully most readers can deal with a brief side jaunt over to a different story thread before coming back to the main story line of the design.
  • Lack of index: As documents get super long, a blog can become hard to navigate without an index or tagging system of some sort. Some blogs solve this, but Blogger doesn't. :-)

A Test Case: Putting theory into action.
I have a short (13 page) design document for a casual strategy game called SpaceCrack that I'll be posting on LostGarden.com over the next couple of months. I'm going to 'blog the design' and see how some of my theoretical structures work in practice. My hope is to hone in on a 'readable' game design document that can be easily shared with a wide group of people.

As part of the bigger picture, I've noticed that professional complete game design documents are a rare thing on the web. This whole exercise is a stab at shedding some light on a traditionally black art of game development.

take care
Danc.

PS: A side note on Wikis
I've used Wikis for design documentation recently and like them a lot. The change tracking, communal commentary, and auto-linking are wonderful. Right now we are using them as our design document method at the office. They are the best thing I've seen so far for writing design documents. The two topics that are painful
  • Poor at convincing: Wiki's lack narrative structure that makes them difficult navigate and read. Instead of one argument the flows from beginning to end, there are multiple ways of reading the same document. Nothing 'builds'. Instead the reader is left with a spattering of discrete information.
  • Lack of a single voice: Wiki's nature is that they are quite chaotic at times with people jumping in at random points and offering a wide variety of comments, ideas, etc. This is mentally invigorating but can be difficult to parse. Often developers are left scratching their heads and thinking "So, what are we supposed to do?" A good gardener can help, but this generally results in the loss of the original comments (even when you have versioning, no one reads the old versions)