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.

GameDevMap is just that: a map of game developers and publishers, searchable and sortable by various criteria.  I wasn’t sure it would catch on– but I was quite wrong, as you can see if you swing by.  It’s quite comprehensive, and pretty dang current.

It’s run by Gaurav Mathur, who I worked with a little at Double Fine, and who’s now at Factor 5.   Looking for a game job?  Just curious?  Prepping to invade your favorite game developer’s office and steal an advance copy of their game?  Check out GameDevMap!

I’m implementing yet another XML-based object creation architecture, and wondering if I’m reinventing (reimplementing, really) the wheel one time too many.  I’m looking for the basics: tweak object attributes in XML; reload on the fly; easily add new object types.  Basically, I want a pretty standard data-driven engine that pulls pretty much everything from level data to player info and quest/mission/plot progression from a bunch of XML files.

It may seem like it’s not that much– there are a million free XML parsers out there– but there’s always more to it than you’d think.  What information goes in attributes vs. children?  How do you handle reloads of changed data?  How much control do the objects being created have over parsing?  What about saving data out?

Do you know of anything that fits the bill?  C++ source code is best, but even a well-written, modern article describing a game-relevant architecture would be great.  I’m definitely noticing the paucity of game development writing compared to other sectors: I dug up a couple tiny game-related bits from 2002 that basically told me I should try using XML, while I also dug up many highly detailed case studies of XML-based GUI app creation.

Classic 2-D space games such as Star Control were keyboard-centric: WASD for turning and thrust, plus other buttons to shoot, dock, and so on.

It’s been a decade or so, and it’s time to update 2-D spaceship controls: it’s time to use the mouse.  Here are some requirements:

• Navigate anywhere.
• Control speed.  I don’t mean reverse thrust: maybe you have to turn around and thrust in the other direction.  With enough skill, though, I should be able to stop near that planet, or go faster, or slow down.
• Communicate and dock with other objects.  Land on a planet, hail a ship.
• Inertia.  I should be able to rotate in a particular direction without affecting my current thrust.
• Shoot.  What’s a game without shooting?

Some options, in case that’s too easy:

• Turreted fire.  While pointed in one direction, I can shoot whatever turreted weaponry I have at my command in any arbitrary direction.
• Location-targeted secondary abilities.  This may be a dupe of turreted fire.  Think Diablo 2, with the ability to place a trap anywhere on the screen.
• Targeted abilities.  I want to launch my tracking missile at that ship over there.
• Multiple types of fire.  As mentioned above, I’ve got some regular guns, and perhaps some turreted guns, and missiles.  And mines and shields and boosters and all sorts of goodies.

The goal is to accommodate all of the required features and enough cool optional ones, while making an interface that’s comfortable and easy to learn.

Disclaimer 1: I’ve been thinking about this for a while, and I don’t believe there’s an easy solution.  Some compromises in requirements or ease of use may be required.

Disclaimer 2: If anyone proposes an awesome solution, anyone who reads this is free to use it in any space game they may or may not be working on.