Players already plan on using the controller to overcome in-game challenges.

While most of the industry heaps pop-up on top of overlay in search of the perfect tutorial to help your mother/grandfather/spouse play their latest game, I’d like to step in with a reminder.  The person who is most likely to be playing your game doesn’t need your shoehorned tutorial, and you’re just pissing them off.

How concerned are you that I won’t be able to figure out to press A to activate something?  And if I need to hit something, don’t you think I’ll figure out in a hurry if it’s A, X, Y, B, or trigger?  And– this is by far the worst offender– do you really need to stick a pop-up in my face to tell me that the right stick moves the camera?  Look: I figured out the nearest game store, I heard about your game from someone, I dropped 60 bucks in addition to the entrance fee for the console of my choice.  Do you think I’ve done all this without ever having played a game before?

Let me guess: you picked up some guy off the street and ran him through your focus test.  After he figured out that the controller wasn’t a necklace, he made some comment like, “Hmm… I can’t figure out what the attack button is.  Crap… oh, wait, it’s X!  Awesome!  Die, rat!”  Your take-home from this was that you need to have a bunch of text (or even voice-acted dialog) telling the player about the attack button.  (Your other take-home?  Rats are AWESOME introductory enemies.)

Fun may involve learning, but learning isn’t sufficient.  (Raph Koster elaborated on this recently, in a post discussing fun in games, class, and sex.)  The fun doesn’t kick in until you’re using the tools the game gives you, pushing your boundaries, learning the new patterns the game is throwing your way.  If that’s when the fun starts, don’t you want to get each player to that point as quickly as possible?  And since players may be coming into your game with different levels of skill, doesn’t the beginning of the game need to be self-paced?

Halo 3’s tutorials are a pretty good example of how to do things properly.  Early in the game, you’re presented with a ledge you need to jump over.  If you jump over it– fantastic! You’ve already figured out the jump button.  If not, pretty soon the game will display a text overlay telling you that A is the jump button.  This is far less obtrusive than most games and, tellingly, more likely to be helpful– Halo’s much more likely to be someone’s first FPS than a lower-selling niche title.

Why all this antipathy towards tutorials?  I’m knee-deep in Fable 2 right now, and loving it.  Yet the first hour or so almost put me to sleep, even though, as far as tutorials go, it was really more elaborate and well-done than most I’ve seen.  They tried to hide everything under backstory exposition, but look– I just bought the game, I want to get in the action now.  And now that I’ve turned tutorials off in the menu, my screen’s still covered with tons of UI hints.  I know you want your game to be accessible, but who’s the audience that doesn’t understand the A button 10 hours into the game?

If you’re interested in gold farming, MMO economies, RMT (real-money trading), and microtransaction models in virtual worlds, these are a few recent blog posts by prominent MMO developers that go into awesome depth on their own systems.  Free information this good isn’t easy to come by, so check it out.  Shockingly, even the comments on the posts are good.

Matt Mihaly (created some popular microtransaction MUDs; is working on a browser-playable MMO) started off the discussion in February by talking about the dual-currency system they use successfully in Iron Realms’ text-based games. In short, the dual-currency system allows your non-paying users to indirectly drive demand for your for-pay virtual goods (while not pissing off either paying or non-paying users).

Scott Jennings (Lum the Mad; recently worked on a canceled MMO at NCSoft and is now also working on a browser-playable MMO) recently wrote a response with a very similar system he developed independently. His goal was the sharp reduction of unauthorized gold selling (since that’s money you, the developer, could be getting by selling the gold yourself).

Finally, Matt responded with his plan for another dual-currency system in the upcoming Earth Eternal.  He walks through some theorizing about what will happen when gold farmers try to sell to the Earth Eternal audience.  (Iron Realms is small enough that it hasn’t had to deal with the problem.)  It all sounds good, but it’ll be fun to see what happens when theory meets practice.

My in-development web game is pretty board gamey, so I decided to save myself some time and money and prototype it on paper.  The past couple nights, I’ve been playing the first pass.  The testing is pretty fun, even though I can tell the game is far from it.

The good news: the core concept feels compelling.  Some of the mechanics feel really great and intuitive, and they leave a lot of room for thematic development.  I think players will really feel ownership of their pieces and their creations.

On the mechanics side, however, things are quite a mess.  The game takes way too long to ramp up: I was aiming for sub-hour games, and it takes an hour just to get to the interesting bits.  There are a couple of resources in the game, but one is totally dwarfed in importance by the other.  One “key” mechanic didn’t even get used in the several hours of testing!

I’m hard at work on the mechanics again, and pretty happy about things.  You can throw together all the concepts, themes, and mechanics you like, you can try to satisfy the Koster theory of fun, you can just include the most bad-ass (yet not too foreign!) stuff you can think of, but there’s still a big concern if any of it will actually feel fun.  Maybe it goes away with a few more games, but I go through peaks and valleys of excitement and despair about any new game idea.  Now that I’ve gotten past the first real prototype, though, I’m confident in the core.  Now I just have to fix a few minor things, like totally broken gameplay.

I recently ran into a problem where an exporter I’d written was creating output that wasn’t what the artists were expecting.  In particular, the output from the automated tool looked brighter than the by-hand process they’d been performing.

The mismatch originated from use of the single channel view.  When you view a single channel of an RGB image in Photoshop, it uses its grayscale working space (working space being gamma, more or less) to display the channel.  This can cause problems if you weren’t expecting to author anything in grayscale, and hadn’t bothered to set that working space to something compatible with your output.  In this case, the color space was set to Dot Gain 20%, which is a calculation explicitly intended for print work!  It was very noticeable: if you selected a single channel to view, even the white areas would appear much different than the RGB view.

Copying data from this single channel view into an RGB image, or vice versa, causes a conversion between your RGB color space and your Gray color space, which in this case were sRGB and Dot Gain 20%, respectively.  That means that Photoshop will actually change the color values to maintain something that looks visually identical– remember, they’re displaying at different gammas.  So you’re inadvertently changing your image.  In this case, it caused different than intended behavior in a variety of single channel applications (specular term, emissive term, etc.).

The problem, fortunately, is quite simple to fix: if you’re going to be taking image data back and forth between RGB and grayscale color spaces, just make sure your color spaces are compatible.  In this case, we wanted to work with sRGB– it’s a logical choice for game development– so we picked sGray to go with it.

I didn’t see sGray documented anywhere, but it turns out my guess was correct: it’s simply sRGB’s gamma calculation, but for a grayscale working space.  sRGB’s gamma calculation is already well-documented, so I won’t go into it here.

Proper respawn system design requires a depth of understanding of your game and your goals that is difficult to accomplish. (I believe “respawn system” is more accurate and “save system”, because it addresses how the user gets back into the game after death, whether it’s through loading or continuing. Maybe it should be called reentry system?)

Escape Velocity’s system on certain tricky edge cases. Bioshock’s system broke frequently because of incompatibilities with the game’s carefully-balanced inventory model: it made the resource of health infinite, while not replenishing gameplay items, resulting in non-strategic and anti-immersive zerging tactics. Mass Effect’s system functioned as a perpetual annoyance because of a lack of consideration for where players might spend their time, encouraging compulsive saving. Halo’s system, on the other hand, succeeded in almost all areas, revealing the obsessive lengths the designers went to to understand every last minute of a player’s experience.

It’s a surprise that respawn systems are as good as they are. Aside from designer masochism (“They should thank me for a save point every hour!”), there’s the simple problem that you can’t really understand your game until it’s almost complete– at which point you’re crunching, addressing critical bugs while you try to get the damned title out the door. The more ambitious your game, the worse the complexity and deadline factors become.

Conversely, the simpler your game… well, here’s a one-minute game that demonstrated a thorough understanding of the user’s play-through behavior, including the crucial out-of-game portion of the experience.

A couple of the Spacetime Studios guys have put together a fantastic series of blog entries describing their rapid gameplay prototyping process, which they call Greyworlding. Give ‘em a look: though studios are constantly trying new development techniques, it’s rare to get this level of insight into a studio’s new methodologies, even at a conference or other large gathering of developers.

In some ways, “Grayworlding” is a logical, and almost obvious, implementation of the idea of prototyping first to “find the fun”. Anyone who’s actually tried that with a large and complex game knows, though, that the details are far from trivial.

I’m doing a bit of a survey of tile placement games, and asking: how do they restrict tile placement? What purpose or interactivity do those tiles have after they’re placed? Here are a few, though there are many more:

• Dominoes: very simple. Placement is restricted by requiring matching numbers on each tile. Only end dominoes are interactive; pieces in the middle are unimportant for placement restrictions or scoring.
• Scrabble: placement is restricted by a grid, as well as the English language (or, more accurately, a giant Scrabble dictionary). Most tiles remain in play throughout the game, though scoring is fixed at the time the tiles are placed. The game board itself adds bonus scoring to some placement positions.
• Go: placement is fairly unrestricted, limited to uninhabited locations on a game grid. Because adjacent tiles work together to chain, much of the board remains interactive throughout the game. Many non-interactive situations actually cause the game pieces to be removed from the board, resulting in a highly complex and dynamic game.
• Tangrams: tile placement is technically not restricted aside from the board’s boundaries. The pieces have no purpose beyond their shape, resulting in a fairly simple geometric puzzle game.
• Zombies!!!: tiles must be adjacent, and essentially within a grid. Furthermore, roads may not be blocked by tile placement. Placing a tile causes a certain number of zombie, bullet, and life tokens to come into existence on the tile. Players and zombies roll dice and move about this player-created board. The tile placement portion of the game is fairly simple, but since it defines the geography for the rest of the game’s action, most tiles remain interactive throughout the game.  Players use event cards to further spice up gameplay.
• Carcassonne: Tile placement is somewhat similar to Zombies!!!, in that terrain types must be respected. Carcassonne has more types, with grass, road, and city edges.  When a player places a tile, the player may choose to place another type of game piece (a follower) onto the tile, sometimes with multiple options as to where.  Some areas of the board become completed as the game progresses, though some adjacency chaining (fields) causes large amounts of the board to remain in play for the duration.  Unlike Zombies!!!, pieces do not move around the game board, and tile information is only used to restrict placement of tiles and followers, and for scoring.

Wikipedia has some more (such as the tile placement version of Diceland), though it lists tile-based games, not just tile placement games.

I find tile placement games exciting for several reasons.  Their rules tend to be intuitive, but lend themselves to depth.  Tiles can provide layers of gameplay: their edges, shapes, or other characteristics can restrict placement; their attributes (such as color, terrain type, printed rules, etc.) can influence gameplay or scoring in other ways.  On a visceral level, the simple action of placing a tile is satisfying.

Do you have any tile placement games you’ve enjoyed?  What is it you like about them?  Do you like the difficult process of deciding which tiles to place and where, such as Go or Scrabble?  Do you prefer playing on a game board of your own construction, such as Zombies!!!?  What about the loose diplomacy and planning behind a game of Carcassonne?

As I mentioned recently, I’m looking for a collaborative, online design tool. I’ve decided to try out TWiki, a wiki with so many plugins it looks like you can do anything. For example, I’d talked about wanting the ability to draw, and there’s a diagramming tool. It’s a long way from a notebook and a pen, but maybe it’ll have its advantages.

So far, the results aren’t terribly encouraging. It took several hours to get TWiki up and running with the appropriate plugins and security settings, and I had to have my host install a module (which they did promptly, and for free!). Now that it’s up, the idea of fighting the Wiki language or the WYSIWYG plugin’s quirks just makes me want to retreat back to the notebook. I fight that inclination long enough to mess with the wiki for a few minutes, and then I give up design work altogether.

Maybe the payoff is down the line, when I’ve figured out the wiki and I’ve opened it up to friends. Hopefully I can get to that point.

My design up to this point has been in notebooks.  There are a few qualities I really like about them:

• Diagramming is easy.  I don’t have to conform all of my thoughts to paragraph structure.
• They don’t require a computer (my laptop is heavy).
•  It’s easy to peruse old entries (I date all of them), so I can see what I was thinking a couple years ago.

There are also some shortcomings to my pen and notebook system, the bolded ones being the most important:

• They’re disorganized and unsearchable.  If I’m designing several things, either all the designs get mixed up in the same notebook, or I have to keep a stack of different project notebooks on hand.
• They’re not backed up.  I’d better not lose those notebooks.
• They’re difficult to discuss.   If I want to get feedback, I have to gather some friends together and discuss the ideas, or write up some ideas all over again in email format.
• They’re not collaborative.  If other people come up with great ideas during those discussions, they don’t end up in the notebook, and I’m likely to forget them.

I’ve decided I should probably move to software design tools, even if I have to give up some of the positives such as easy diagramming.  My first thought was a wiki: they’re easy to set up, and collaborative.  (I’d only be giving a few trusted people access.)  Is there something better out there?  Something more tuned towards design, perhaps?  I know there are tons of teamwork tools out there, but I’m not sure where to start looking.