Reason

All rules need reasons for existing. If you can't pin down a good reason for a rule to exist, it should be pulled out of the game. In fact, I'd almost go as far as stating that the rules need to have a mechanical reason for existing; if a rule solely exists for a thematic reason, it probably needs to be re-thought.

And then there's another step deeper, where you have to decide if the reason itself is important enough to warrant the reason being there.

And this is one of the things I hate about chess. Just what the heck is the reason for the en passant rule there for? Remember, all pieces have their own set of moves, which are strictly followed, well except, in the one special case...

(I'm willing to give the "pawns can move 1 Space forward, EXCEPT ON THEIR FIRST MOVE THEY MAY MOVE TWO SPACES exception," given that there are a few good reasons for that to exist: It speeds up play at the start of the game, and it does offer, I think, a few more strategic choices.)

Anyway, rules without reasons just clutter the game. Rules with poor reasons should be given better reasons or removed completely if you want a tight game that flows. Rules that provide for multiple reasons are even better.

There's probably some interesting way to analyze games by looking at the reasons. Of course, reasons are pretty subjective. Here's a sampling of reasons things exist, or in some cases removed, from My Little Vineyard.

Spoilage - Originally existed as a reason to include weather/seasonally effects...was removed to due "player reset" symptoms and made the game too restrictive.
Research Books - Currently probably one of the stronger rules/reason sets as they are currently implemented. They are used as a fallback option, when there is nothing else available to do for the player. And they provide for a general "growing machine" bonus over the course of the game without directly scoring.
Fertilizers - These are thematically very strong, but on first glance, they are a weak choice. However, while they typically don't provide many points, they are very strong in removing options for competing players.
Wine Cellar - Thematically strong, provides strategic options as to score now, or hope to score better in the future decisions.
Market Place - Thematically okay, provides tactical options and some screwage against other players.
Dice Pools - Flexible way of having a group of stuff meaning one thing to one player, while meaning something else to another. Also, it's the unique feature of the game
First Round Dice Roll exception - Yeah, I'm not to happy with the first round requirement of hacing players being FORCED to roll multiple dice, as opposed to letting them decide. But the reason is very strong why it exists; the dice pool needs to be seeded somehow in a somewhat balanced fashion.

Of, course there's a lot of weaker of stuff, too. The current variety of fertilizers have pretty reasons to exist; in fact, I could probably get rid of either wood chips and volcanic ash without missing much. On the other hand, variety is always nice to have.

Thers something to be said about the potential of drafting different sets of grapevines that a player can use to spice up the variety even more, just to be sure that there isn't one clear path to victory. I'm not sure I want to add that complexity to the game at this point...and that would entail all sort of other balancing issues, I think. Which is a good enough reason to leave it alone for now.

Loose

Well, my suspicions were correct. Another playtest of My Little Vineyard with a "looser" set of rules did many things, all of which led to a better experience. Many of the rules changes weren't changes at all, but removals. Which is a good thing. Solving problems by subtraction instead of addition, or worse, addition of exceptions (as discussed a little bit later) is generally a bad place to be.

A lot of the complexity of rules centered around the removal of spoilage. During various parts of the game, most of your warehouse of supplies would be returned to the stock if you didn't use them "before winter came." Thematically, this made some amount of sense. But from a game play aspect, it really required way too much pre-planning for a player to think of, especially in a game using dice where you might not get the die roll you want. Not only did spoilage punish the player who rolled unlucky, or poorly selected a roll based on bad stategy, it resulted in a case where it "reset your world" thought various points in the game.

And that reset of the world turned out to be a problem. Early on in the design of the game, the desired reasoning was that the risk to make the better scoring wines was the potential that your supplies for it would be spoiled out of existence. As it turns out, just the fact that the higher scoring wines simply "cost more" is good enough. One of the more interesting statement on the last failed playtest which turned out to be wiser than it seemed at the time was that a game of this type should be a steamroller game...one where you start by building little things, and end with building big things. Spoilage never let you reach beyond the little stuff.

Another aspect that was changed to fit into this simpler world are the way the research books are implemented. And their change resulted in killing two birds with one stone. The research books now apply across the board to any barrel of wine you make, and you can purchase a research book at any time for yur turn for the cost of one die. Before, you only got a book when you produced a barrel...and it was only good for the type of wine you produced to earn it. Which resulted in some confusion as to when the book applied it's bonus (when you first picked it up) and tended to make player concentrate on a single wine type.

Now, with the one die pick for the book, it gives player something they can always do when there are no other actions available (the game was missing a fallback action when the was no other decent option available) as a beneficial side effect of a generalized bound-for-all book.

Anyway, I'm back to feeling good about the game again.

One other discussion about the game that we had was about defining different rounds to as doing something specific. For example, when you produce a barrel of wine, you can store it in your wine cellar, whee it will "ferment" and gain points at the end of every round, or simply ship it to score it's current value. The problem with barrels in your cellar is that they don't score for you unless you ship them out of your cellar which requires an additional action.

One of the things I liked about this system is that over the course of the four or five rounds you play, the first rounds are spent storing barrels, while the last rounds are spent shipping barrels. However, it is up to the player to decide whethat tipping point occurs. If players aren't careful, players will wind up at the end of the game with barrels stuck in their cellar scoring zero points.

Anyway, this is a choice OF THE PLAYER. There was some discussion of programming the rounds (round 1 and 2 are storing only rounds, 3 and 4 are shipping only rounds, etc). I believe that this is needless rules creep, and could prevent players from experiment with unusual strategies as they get better with the game, and falls into the category of "rules exceptions" which I don't like. Otherwise known as "the rules are this, except when..."

Chess has a few "rules exceptions" that bug the he'll out of me. Castling your king, and en passant, which are both rules that break piously discussed rules.

As it is, the game currently has one rule exception...on the first round of a season, every player must roll at least 5 (changing to 4) dice to add to the center pool. After that, it's one or more. I'm not a big fan of this exception, but it helps with first player advantage, and gets a lot of dice out in the middle of the table to start the round in a methodical manner. So, I can live with it.

I hope to have the next version of it up soon, but another, stranger project is sucking away at my time. Which I may or may not talk about depending on how that works out.

Fatigue

I fatigue easily on a design. Part of it is that I don't really have a nice continual stream of playtesting. And so, as a game gets fudged this way and that, a new design experiment comes along that captures my attention like a moth to a flame. At which point the old design gets scuttled own the shiny new design....which winds up getting scuttled for something newer.

Strangely, I do have a relatively nice stream of play testing ability more than most. But we only meet for every other week, and typically only two games get to the table. So I maybe get only one playtest a month or so out of a game in order to try and make sure everyone gets a chance to be in the spotlight.

And so, My Little Vineyard continues apace, with a new change every month or so. The link off to the right there is really old and moldy...the link on boardgamegeek is about 1.5 versions behind. But I had thought I was coming close to actually finishing it. Really close. Everyone in the group seemed to like it (which is surprising given the wide array of tastes in games). And so, I figured the last playtest would be strong with just a couple of tweaks to points and such.

And I was wrong.

Maybe because people have become familiar with the game now, they are now able to see some issues that weren't there before. Not that this is bad...just discouraging as it seemed the finish line was close. Fatigue is really settling in with this game at this point, as these probably 3 other projects I have a great desire to work on at this point, and that "1 play test per month" is valuable, indeed.

The biggest issue was where one of the players felt helpless after realizing that the action he had taken three turns ago was a poor one, and now that he had realized it, felt there was no way to rebound from it and catch up to the rest of the players. This bothered me quite a bit the more I thought about it. If you make an obvious bad play in most games, you get "penalized" for it and learn from it and move on.

It left me wondering if the obvious bad play wasn't obscured enough; I've been playing Agricola some lately, and one of the comments that comes from that game seems to be along the lines of "I lost again! And I don't know how."

Anyway, this lead to a fairly interesting discussion of fixes for the game, which would seem to complicate things further. Additionally, the fatigue that had worn on in the design of the project I could now see stretching further out down many more months. Granted, these aren't working man-months; really just an hour or so here and there in between playing. But still, the real-time length to completion is painful indeed.

As things usually happen, over the weekend I spent some time digesting the comments, and trying to come up with solutions. What I've noticed is that a lot of my project usually wind up with me adding more and more things to them, then near the end, a great purging happens; suddenly there's a realization that a lot of those things aren't needed, and removed. And that is what is happened on this next revision of the game. I think the game will be better for it, and it addresses the issues that were brought up.

And hopefully I can move on to something else soon. Strangely, while I think that this is probably my most commercial-ready design, it is also somewhat less appealing to me than other designs which are a bit more experimental. And that's what I'm missing playing around with.

Mission to Mars

Seth may appreciate this, or maybe not.

Seth has been interested in doing a "Mission to Mars" based game, with somewhat realistic-based theme-ing, based on current scientific theoretical planning. However, as he described it more, to me, it became just another in a long line of M.U.L.E. like resource generative games: put a mining unit on mars, let it mine for minerals to make more stuff, which then let's you mine different stuff, etc. etc.

The thing that struck me of being interesting about scientific-based theme is dealing with the amount of time it takes to get stuff across great distances, and the general precise of doing space travel stuff. Additionally, as President George Bush found out when he made an announcement about plans to go to Mars, it is technologically feasible to do it; but it's mostly about the political will power to be able to push through a plan of such large scope and money drain, with no obvious payback to the American public within a lifetime.

At least in the case for the race for space in the 60s, it was sold to the public partly as a race against the evil communists, as a way to prove American know-how can beat the evil empire.

Currently, I don't think that anyone is remotely close to Mars.

Anyway, so the game I proposed was not about resource management, or pick up and delivery back and forth between Earth and Mars, but primarily about controlling political clout, and the timing of various modules to Mars, based on the long term plans within the Case For Mars.

Simply enough, the game, as shown above, works like this. The sheet with the yellow pawn abstracts out the "public's interest" in the Mars program. The higher the interest, the more actions, or "political clout" you have. As most things with the public eye, interest wanes over time, giving you less clout to spend on the issue, until an important milestone is hit (say, a man walking on Mars), which increases the awareness in the program, and therefor, giving you more clout to spend.

So, the top row of cards are event cards that randomly indicate how much interest wanes on a turn. This would represent various newsworthy things that the news cycle and the public replaces their interest with. Things like scandal, wars, economy, etc.

As a country figurehead, you can control this somewhat, by spending your clout to adjust the events; "it looks like there's a war brewing, we better put a stop to that." Of course, this is clout that you can't spend towards your mission to mars.

The bottom row represents cargo ships delivering modules to Mars. Larger ships are launched with more clout; and emptier ships move faster than full ships. Eventually, the modules are dropped off on mars (to the right of the picture, where the cubes are stacked).

Certain modules don't "work" without previous modules being on Mars, and some modules eventually expire if they don't have humans, and habitat modules, powering them within a few turns after their arrival.

And so, the game pretty much plays where you are watching your clout and interest in the project dwindle, then a milestone is hit, and you got clout again.

For a first pass, it's an interesting play; but right now the game needs to be a bit tighter to be interesting I think. I'm probably being way too generous with starting clout; it really needs to feel like you are racing between hitting the next milestone and hitting rock bottom on your public interest to be fun.

Obsessed

Not that I'm obsessed or anything, but I've decided to actually finish the Shipwreck game, instead of letting it linger for other exploratory designs. Unfortunately, it's a hard game to prototype; and through various machinery of my free will and accidental programming, finishing the prototype is turning out to be a nerve racking affair, with a lot of wasted "sticky-back" printer paper.

The game includes 120 small cards which need to be on thick, chipboard-style cardboard, and I'm using illustrator board for it. These cards either contain data point clues, or cards with windows that reveal specific clues when placed over the first set of cards. Unfortunately, after mounting and cutting, it turns out that my program was "building" the cards wrong, which entailed another set of printed cards. After which, I noticed that some of my data entry was wrong, which entailed another change, reprint, and mount.


Then, when I thought I was finished, I came to another, better conclusion to how the game should be constructed, which required another set.

But I think I finally have it right now.

The next problem which I think I have solved is the way the clues are recorded for the player on the data sheet. Back when it was simply "fishin' for 'recks," I just had a data sheet with a copy of the map, and a player could mark up multiple maps for each wreck he was currently involved in hunting for. It worked, but I wasn't happy with it, and I never could come up with a better solution. However, with the new DaVinci Code-styling of the game, which involves three different "stages" of hunting and piecing together clues each with it's own slightly different approach of clue gathering, the simple map marking technique won't work.

And so I've come up with a two sheet solution. The first sheet to the left here is a data grid for each of the three stages, cross-referencing the important information that is gleaned from clues.

The top part is the ultimate goal of finding a gate. This is done by combining artifact cards (of which there are three types, A,B, and C). Each set of artifacts reveal a clue data point to the location of a gate. Two or three of these data points will reveal the gate location.

The middle part is for shipwreck searching. Shipwrecks are located by directional vectors from each of the five cities, plus a depth rating. By triangulating enough of these data points, you can find a shipwreck.

And the bottom part is for locating which shipwreck an artifact is on. Each city has a different combination of buildings. And researching an artifact in a city will reveal that shipwreck, or give you a building of the city that can reveal the shipwreck's name.

Page two over here on the left is a simple representation of the map and the important data points for triangulating the clues, and a list of actions the player can take.

By folding page two (the map page) in half inward, a player can create a "cover" in order to keep page 1 secret (also folded in half). Page 1 is folded outward, so that the data grids are on "both sides" of the half-sized page of paper, and allows for easy flip access to both halves, and easy cross-referencing of the data grid to the map. Of course, the map can also be used for taking notes.

At least, in theory, this all seems to work well. It's up to the unforgiving world of playtesting to see if actually unfolds as well as it does in my mind.

Board Game Narrative part 2

And so begins Part 2 of Board Game Narrative Stuff. Once again, I lead with the following disclaimer:

It should be noted that I’m just collecting random thoughts on this subject. Various thoughts as described herein probably have many fallacies when viewed through the lens of different types of game, and I'm sure that anyone could find a particular game that refutes any thesis that I'm providing (heck, I can do that on my own).


Part 1 can be found by clicking this link.

*******************************************


IMMERSION OF THEME
Since a main component of the narrative story is the theme, there is a need to somehow get the player immersed into the theme. Immersion can come from many areas, one core relation is that choices and performance of actions actions that seem natural within the world of the selected theme is necessary for this to happen.

Probably one of the biggest disappointments in this regard is the co-operative Lord of the Rings games. Here’s a case of a very rich theme in which the game itself seems to have very little to do with the exciting themes that surround it. It just feels like you are carefully playing cards to move your little tokens along various tracks, racing against another token on another track. There is no sense of defeating various villains or moving logically throughout a world; the players are just moving on to the next board as quickly as possible.

It’s a tricky thing. Usually, to get one immersed into a theme the design should try to hide it’s mechanics as much as possible, getting the fiddliness out of the way, trying to make sure that players are involved in the story of the game, and not the rudimentary bookkeeping actions that all games have. This would normally require that the game be kept simple in some regards. But often, that is usually not the case; the Lord of the Rings game example above is probably as easy as you can get, but since the game is reduced to merely “play XX amount of icons to move on a track” it loses almost all of the flavor that the theme represents. A game like Arkham Horror, which contains many components and reading of cards and various interlocking rules becomes much more complex, flavorful, and immersive.

Not that I’m inviting the idea that flavor text as an answer. In most cases, I hate flavor text. But if the individual rules and flavor text somehow merge as the same thing, then I’m all for that. Ideally, flavor text SHOULD be the unique rules, or at least describe the “what and why” of the unique rules given a certain representation on the card.

Additionally, I completely understand the idea to iconize all components as much as possible. This reduces the cost of a game significantly, being that the game doesn’t require multiple printings across multiple languages. But I feel that there is a cost to this; the game becomes, again, a mere shuffling of iconography around as efficiently as possible.

Again, following this thread of thought, the "tangible representation" of what is supposedly going on in the game should have some attempt at feeling like a real world representation. A game like Caylus completely fails in terms of feeling like an actual castle is being built. Additionally, as much as I like Princes of Florence, the game never really feels like fantastic works of art are being created which is what the game promises. Instead, the game is merely collecting points off of various menus.

FIGHTING THE SYSTEM
With regards to how players compete with each other, games can fit on a sliding scale with one end being competitive, while the other end being co-operative. Strangely, over the scope of most games, this result in an inverted bell curve of either-or possibilities; it is not very often that a game comes along that shares a compromise of being both competitive AND co-operative, unless you consider “traitor” games, when one of more players are secretly plotting against the rest of the players to help the system win.

While games on both ends of the spectrum can be narrative, games where the players must fight the game system tend to be more narrative, as opposed to pure competitive contests. Unless the system allows for the players to invoke thematic, creative “elements” into the game as the game goes along, pure competitive struggles focus solely on winning the game, and trying to derive the most efficient ways to do.

By adding systematic elements for the player to fight against, in addition to the players, the designer has time and creative effort to add thematic elements into the struggle. Ultimately, the game system becomes another player, who isn’t so much involved in “winning” (even though this can certainly be the case, especially in co-op games), but this virtual player is instead adding thematic flavor to the game, in the form of obstacles that are jointly being added against each player.

However balanced or unbalanced these events are, this does add randomness to game. Randomness, it can be concluded, is a prime factor for narrative, provided it is thematic and not random for random's sake. Events that are known to be coming or are scripted to happen, are things that can be planned for. Things that can be planned for then become mathematical exercises. Which reduces the thematic impact of such events.

This does not mean that things should happen completely chaotically or willy-nilly. Logic still needs to dictate these random elements. If a game’s monsoon season starts in late summer, then it shouldn’t happen in winter. But that doesn’t mean a player should know the exact date as to when the monsoon is coming. An even better approach would be including elements of foreshadowing that, yes, the monsoon is coming…the clouds are growing darker, but it’s still an unknown as to when the skies will open.


to be continued...

Multi-Card Extravaganza

In a lot of cases, I’m always more interested trying to innovate wacky new mechanics than trying to develop the game itself. In the end, the mechanic itself may not look very innovate as it essentially gets whittled down to something workable as a function of a game. Having said that, take a look at the card off to the left here. While it may look like a crudely drawn spider web, it actually has a bunch of information hidden within the web....

I'm pretty fascinated by games with hidden information, and the ways for the players to logically decode it, as these things are not very easy to create. Of course, the great example of this type of game is Clue, or Cluedo; and it still holds up pretty well after all these years. In fact, it holds up so well, that most games of the deduct-the-mystery style of game play pretty much are descendant for Clue. Not that I'm aware of many. Mystery of the Abbey uses the "figure the card that is out of play" from Clue pretty well. Wadjet uses the same puzzle amazingly poorly.

Also, my fascination of playing around with the mechanical aspects of cards continues. “Mechanical” is a strange term, I know to use to describe cards; cards can do a lot more than we are used to in relating information, I think. When refer to mechanical uses here, I am referring more to the physical actions and uses that cards be used for, or for indicating things, rather than just the pure display of indicia.

Probably the most common form of this would be based on the rotational aspect of the way the card is played. The most obvious game use, and in some game-y legal circles, of this would be that of rotating a card 90 degrees in Magic:The Gathering to indicate that it has been used in that round. Questionable patents aside, this is a fairly clean mechanism. Other game uses the rotation of cards to indicate various things; the 2 player Starship Catan card game comes to mind as a way to keep track of resources.

What I would assume to be the oldest incarnation of rotational meaning to cards most likely predates your standard playing card deck itself. The reading of Tarot cards are often read as having the opposite meanings of the particular card being studied if it has been turned on the table upside down. So while a Death card placed in its natural orientation would indicate “change” in the future, a reversed Death would indicate “statis” or no change.

Something I am not too aware of, however, are cards that have direct mechanical relationships with other cards, or cards that, when combined mechanically or spatially create some meaning or data out of the combination whereas as single cards the data shown on them is useless by itself.

There are some games that come close to the effect I’m looking at. Games such as Skallywags, where you try to build a pirate out of three different body parts. Still, to me this doesn’t equate to what I’m getting at; the game boils down to a three card set collection mechanic (get one card of each “suit”). It’s just that the suits are head, torso, and leg, aside from hearts, spades and diamonds.

I guess I’m looking for something more gimmicky. So where does this lead? Especially with the lead in to this post?

On occasion, I keep coming back to a haunted house game design that I've worked on here and there. One the things that I was fighting against was trying to come up with was a interesting hidden information system, something that wouldn't just be a bastardized Clue clone.

Basically, the game involves players surviving the night in a haunted house. There's a fairly neat "haunt" mechanism I've come up with that does a pretty good job of capturing "I think I sense something is going to happen," as opposed to your standard haunted house game draw-a-card result. Ultimately, the game revolves around trying to put the various ghosts to rest by trying to figure out what item they want, and where they want the item to be placed. For example, a ghost may want the locket placed in the study. But coming up with an interesting way of hiding this information, that wasn't easily cheat-able, was a problem.

The current system as it stands now involves a combination of cards that can reveal hidden information. In this case, the web card as shown above, and then a series of "test" cards. Each test card represents an item, a room, or an attribute that can help describe a room or item, that you are "testing" for. If half of the windows show a web intersection, then the test is true. So placing "the Pocketwatch" data card on the web above, will reveal two windows having intersections; any ghost that has this card is somehow linked to the Pocketwatch, and wants it to be placed somewhere in the house.








How this works:
Each web card is a graphical representation of a digital bar code. Each item and room can be described by two atrributes. In the case of the Pocketwatch, it is both "gold" and an "heirloom." By pairing up the digital codes for each attribute, you can create a unique code for each item.

This kind of data creation is repeated for the 8 different rooms of our haunted house. Again, there are numerous attributes that we can define in various pairs to help code up a particular room.


And then, with this data, all of the combinations of items/rooms are compressed into a single barcode number. A partial list of the data is shown below.

At which point, it becomes fairly easy to assign different areas of each card as a location for a TRUE (a crossed web graphic) or FALSE (empty space) to graphic show the digital mark of the card. So, each web card contains the “barcode” of all this information based on the web intersections. Each windowed test card, with windows based on certain attributes that a player wants to test for, simply reveals only certain barcoded elements.

So, naturally, after devising all this, my interest waned in developing the game. The haunt mechanism turned out to be a bit more finicky than I would like. But as things naturally happen, after catching glimpses of a show on TV about shipwrecks, this mechanic has been born again! This time the barcodes revealing information regarding landmarks, directions from landmarks, and water depths, of where various Shipwrecks are located.

In the Shipwreck case above, instead of trying to graphically hide the barcode into a web, the barcode information is using simple icons.

And so on, until my interest wanes on that idea…

Another aspect of meshing two cards to derive information I’ve played around with is using the edges of cards to point to information on other cards. I’ve gotten a few emails detailing using PocketCiv like mechanics in a fantasy-adventure dungeon-bash game. But a lot of these games I’ve seen leave me a little cold (which maybe is worth another post). So, I’ve decided to see if I could create one.

As I’ve noted before, when you are designing a game primarily for “print and play,” the amount of components really need to be kept to a minimum; a BARE minimum. In the current design, I’ve decided to limit myself to 20 unique cards that describe all aspects of the game, the world creation, the quest creation, the creature creation, the battle resolution, etc. Of importance to this discussion would be the battle mechanics.

In your typical slash-n-bash dungeon affair, many dice rolls are used to determine battle outcomes. Since a big goal of these print-n-play games is to make them somewhat playable on an airplane, rolling dice is not acceptable; a way to use the cards to derive random numbers for battles would have to be created.

Basically, a basic battle outcome in this game is a fairly simple and quick affair requiring only three cards. Each card along the left edge has a series of arrows, randomly distributed that indicate a combatants Level. When placed slightly offset on to another card, these arrow line up with another strip of numbers on the lower card. This set of numbers is the strength points that a combatant is given (essentially duplicating a dice roll). So, a battle simply is play a card down, then play a second card on top of it. Reference the creature’s Level, and obtain the creature battle score from the first card played based on its Level. Place a third card on the second card, and reference the player’s Level on the third card to obtain the player’s battle strength from the second card. Compare the battle scores for results.

There’s quite a bit of Excel work going on here. Even though the Level arrows bounce around from card to card, the average results are that the higher the Level that you are obtaining a Battle score for, the higher the average Battle score will be obtained. So even though the battle scores and Level numbers may look like they are randomly placed, the layout of the data on each card was particularly chosen.

And of course, as with all hack-n-slash adventure games, the scores can be further modified by special weapons and such.

One may ask “why not just have the results of a level on one card, instead of spreading it across 2 cards?” The reason is fairly straight forward. It’s simply about creating a much larger spread of results than is obtainable by using a single card solution.

Given any particular Level, if each card just has a single Level-to-Battle score ratio, the amount of results that can be obtained is solely dependent on the number of cards you have. In other words, with 20 cards, you are left with exactly 20 results for any given level.

But in this implementation, due to the fact that the Level indicators can point to any other number on a different card, for a single card, a single Level on that card can possibly point to 19 other random results (the 19 cards). Since each of the 20 cards can point to 19 different results, this results in a spread of potentially 380 different results.

I’m sure there are some additional interesting ways to building things to get a whole data point out of two halves. For even more mechanical fun, in the past, I’ve toyed around with sliding cards in paper sleeves as a way of hiding, and obtaining information. Not that slider cards are anything new, but I believe that they can be pushed further to the limits than they have been previously used for.

In response....

I've been away from the wired world for a while, waterparking with the kids at Grizzly Jacks. So, instead of responding to the comments of the last post in the comments, I figured I'll use the power of the RSS feeder to answer the questions.

The hook for PocketCiv would simply be "solitaire Civ game."

The hook for One Against the Dead would be "Solitaire Zombie game with household components." Of course, I've decided to blow away that hook, and am slowly working on a more story-driven basis for that game, while keeping the slightly strategic elements of city building/zombie creation. But that's sort of slow going at this point...creating all of the story points and arcs is turning out to be a larger time-consuming project than I have imagined.

The other project I'm working on is the resusitation of KitchenTable. The more observant may have noted that it has magically appeared in the 'Places to Play" link off in the sidebar. This is my attempt at a game prototype engine that can support multiple players, that I had given up last fall with the introduction of Gabob and Zun Tzu. However, these don't seem to appeal to a few members of BGDF, so I've gone back and started working on it again. The multiple player is currently turned off to chase down gamebox creation bugs, there's no documentation, and it's being debugged by a few BGDF chat people, but it's there for people to play with.


And, of course, there's no promise that I'll ever finish it, and give it up further along the line.



And yes, "The Hook" image was created on the DS Colors program.

The Hook

In a recent discussion on the BGDF chat forum, I’ve found that some people may, or may not, know about this little trick in the game design world known as…The Hook. Since I haven’t been feeling rather design-y recently, The Hook might be a nice little discussion point worth posting about.

The Hook is a general term that we use around the office that describes the one most singular thing that makes the game compelling to the user. This is not a game mechanic or theme, or full “pitch” sentence that describes what the game is about. In fact, it is frequently under 8 words, at most, that simply answers the question:

“So, what is the hook of this game?”

Again, it is important to realize that this is NOT really what the game is about (even though, in some cases it can overlap). This is the one simple thing that a player can grasp that “reels them in” into further play, or even the interest of playing the game. This is important because, if you cannot identify The Hook, then there is a good case to be made that the game itself is pretty bland, and there is nothing much more you can do to fix it.

Conversely, if you CAN indentify The Hook, you will understand that almost all functions and systems of the game hang off of it and support it, making a much stronger game in the process. If you feel that the game is “too heavy,” it is probably because there’s a rule or mechanism in there that doesn’t support The Hook, and can easily be removed, often improving the game.

And now, the examples.

Puerto Rico’s hook is “building the most efficient machine.” That’s it. Note that there is nothing in The Hook that describes it’s theme, or it’s somewhat unique role-selection mechanism (and yes, I know there have been role-selection games before hand).

In fact, PR's hook itself is not that innovative, as many games can be thought of as “building the most efficient machine.” But this is the thing that gets player to come back and play it again; with each play, the player picks up a better understanding of the various interplay between the buildings (and to a lesser effect, the way the worker resources energize the buildings and plantations) in determining how to avoid the inefficiencies of previous games.

Some games are often harder to find The Hook in them, or have multiple relational Hooks. The Princes of Florence, while it, too is a “efficiency builder” has an additional relational Hook, which I think is the bigger Hook for a new player in the game. The big hook for PoF players is "play Tetris in a board game". Remove this element, and while you may have a nice game there, but there'd be nothing remarkable about it. In this case, the hook defines a fairly unique application of how the game works. I suppose I should note that you aren't REALLY playing Teris, but the whole puzzle solving aspect of packing in various oddly shaped pieces matches well with that description.

It should be noted that in the two above examples, there really isn't much thought given to the theme of those games, especially with regards to their Hooks. The games, themselves are fairly themeless once you remove various typefaces and graphics. I've always found it amusing that in PoF you are supposedly attracting artisan's to your little art clubhouse and having them produce their wares, but you never actually SEE or feel an artist, and their supposed "art" they are producing is merely a card with a lot of stats on it. These are effectively themeless games, with a theme attached to them.

As an opposite example from above, I present Ticket to Ride, which has a hook that is very similar to it's game description: play sets of cards to complete tracks. The Hook here is "Building a track layout to complete city connections through simple card play." As much as I tried to keep the word count down to a minimum here, I felt that the card play aspect of the game is the thing that really carries it; there are plenty of other train games out there, but TtR is the game that I think solves the solution simply for the average player "to get," and to pick up and play often enough. And in this case, some allusion to the theme is appropriate...slapping a non-train theme on to this game is most likely inappropriate.

Of course, I've applied The Hook to three Euro Designer games, but it can be applied really to any other game. In some respect, The Hooks of various games are defined by the family in which they keep.

"Trick taking/avoiding game" all share the same hook, as described by their family trait, with maybe an additional comment with regards to what defines the trick. Wargames are somewhat all similar, given that thety can be block-styled, or card driven, or action point driven, or what have you.

The important thing, however, to take from this is that once you have found a Hook, it is important to make sure this is the heart of the game, and all other mechanics "tendril out" from it and support it. Otherwise, it gets lost, and the game will be confusing at worse, or just meandering, at the least.

The Value of Risk

It's somewhat ironic that in my last post, I bring up the Prisoner's Dilemma. To recap, my personal feeling of PD is that, while it's an interesting game theory question within itself, it doesn't play out very well in real life, in that it doesn't take into much emotion, or the value of emotion too much, derived from the situation that the "player" may be in at any given time. Additionally, I'm not sure how you can truly test the game without a value of risk involved. Sure you can play the game repeatedly in your kitchen room, deciding "guess I'm going to jail for 5 years now!" because of your choice (and of the choice of your traitorous compatriot).

But it is a different situation entirely to be locked up in a police station, presented with the same choice FOR REAL, not knowing if your buddy is blabbing in the interview room next door.

I guess I should also note here that I am not a game theorist! I don't even play one on TV.

Another aspect is that I am very hard pressed to come up with a good game that employs PD. At the root of PD is this: in general, all players moderately "share a win" if they stick together; but at what point is one player willing to break ranks to heavily "win singularily" while tossing the other players into an abyss. Of course, each player knows this option exists, but they have no idea if any other player has taken the bait.

Negotiation games such as Diplomacy don't count, since usually games like this are targeted at having only one winner; it is inevitable that someone must do some backstabbing to get ahead, and there is no real sense of a shared win. Additionally, traitor games don't count either; while players cooperate against a hidden, single foe, players are given roles, and they must perform them as expected. Now, if all players started out co-operative, but were given a choice somewhere in the game to turn secretly bad, then we might have something! But I know of no such game currently out there, not to say that it doesn't exist.

And so, here's where the irony begins.

I've been reworking Doppleganger recently. Thematically, Doppleganger is about a team of UFO believers who have broken into a deserted Area 51 outpost in the Nevada Desert. And while they have found clear evidence of alien life that has visited Earth, their vehicles and communication equipment have been sabotaged. The players must work together to escape the desert to civilization.

(I hesitate to link Doppleganger to anything at the moment...I'm not quite prepared to release Doppleganger 2.0 to the wild, and the version of Doppleganger that is currently online is missing the key trait that I am discussing here. But you can view the old version on the list of links to the right.)

At it's heart, Doppleganger is a secret traitor game; the players are working together to overcome various desert obstacles. However, there may be an alien doppleganger in their midst, trying to make sure that the team does not reach civilization. Originally, as shown in version 1.0,there are two basic win conditions: if any amount of humans makes it to civilization, the humans win. If all human players expire in the desert, the alien wins. It's simple enough.

In re-working the game, I've thought about how to create a greater sense of paranoia amongst the players. Obviously, the alien player must be careful to hide his destructive action within the team, but how can the game system "help out" the alien by naturally creating a situation where human players can find EVERYONE suspicious?

The Prisoner's Dilemma offers an interesting solution to this. It's fairly simple; let the game give secret offers to the humans to let them have a large singular win at the expense of helping out the lesser shared win.

So, not only are the humans on the lookout for suspicious behaviors from an enemy alien, but they all know that the other players will be offered potential sweet deals during the game to break ranks for the fellowship. For a player to win the game, he must rely on his partners to work together, because if they don't work as a team, it is impossible to win individually.

Here's how it works.

As the team wanders the desert (tiles that are drawn and placed, creating a desert map), when a player moves the team to a Crash Site location, that player gets to distribute XX amount of Supply Cards as shown on the tile. Distributing a Supply Card works like this, the player draws 2, discards one (face down), and then can keep the remaining card, or give it to another player.

For the most part, the Supply Deck is primarily built of supply cards that can be used to overcome obstacles. But a small amount of cards are scoring cards, cards that score points at the end of the game ONLY if that player reaches civilization safely. The question becomes:

Is a player willing to keep a scoring card which provides no help to the team to reach it's goal, or "take one for the team" and keep a supply card that can be used to help overcome an obstacle?

Of course, the Alien player could simply hand over a Scoring card to a human to cause problems in the ranks. But won't the player who received the card now realize that the ONLY reason this card was passed to him would be that the player handing the card over is the alien for the sole purpose of messing with the team? Does this player now alert the team to the alien presence, at the risk of revealing that he now has a scoring card?

A lot of these decisions fall under the category of what the Value of Risk currently is in the game. Most likely, early in the game, humans will not want to have anything to do with the scoring cards; it is in their best interest to stockpile supply cards. But the value of the risk in terms of needing supply cards change as it becomes apparent that the team is having an easy time (or not) crossing the desert. Or at least, the risky visual appearance of a player stockpiling supply cards, but never playing them, because, most likely, they are worthless scoring cards when it comes to overcoming obstacles.

So, at some point, if the team members feel that they are close to escaping, it stops becoming a team effort, and instead becomes a secret individual effort to be the sole winner. But at what point does this become prudent? Each player is assumed to have their own value of this risk, and potentially understanding what the value of risk is for each player they are playing with.

Which I think captures the Prisoner's Dilemma nicely. In theory, anyway.

There's some amount of cleverness with the scoring cards themselves, actually, as each card has a different value of risk. There are simple cards, such as awarding points for each supply card that the escaping human holds at the game. This might be worth grabbing early if everyone is holding a handful of cards.

But the more complicated cards or more interesting.

One scoring card, "The Infection," actually lets the player switch sides to the alien side. This card is interesting in terms of when it's potentially kept. It's worth keeping later in the game if it appears that the humans are a part of a lost cause.

Even better, an alien can give this card to another player to "infect" him.

But the most creative use would be this:
There is a scoring card, known as "The Hunter." This human scores points if he survives AND if an alien has been killed off (yes, players can vote off other players to kill them). So, an interesting play would be to keep the Hunter card, and then, if you draw the Infection, "infect" another player, and then persuade the group kill off the infected player.

Other scoring cards include cards that score points for the number of players that survive, and it's ying-yang, for the number of players that died.

With a little hope, this should make for an interesting experience in growing paranoia of what everyone's motives really are. After all, everyone has a little villainy in them!

("alien shadow" image blatantly stolen from www.punchstock.com)

Epic! and a little game theory, too.

There's quite a bit of lengthy commentary going on at BGDF regarding "how to make a game 'EPIC.'" Which has sort of devolved into "maybe we better define what Epic means first."

A few apple and orange comparisons are at work here. First, there's the physical camp that seems to imply that having a lot of components, chromy things, and large ruleset define an epic game. There's another line of thought that plays out on more of an emotional level, along the lines of "starting small but finishing huge." Finally, there's the third line of thought that is sort of "well, I've played games of chess that I'd consider Epic."

First of all, I think we can dispose of dealing with the third case. This is merely dealing with the concept of EPIC TALES THAT WILL BE TOLD FOR YEARS, and interesting stories about an event. Indeed, I suppose you could have an epic battle of between people playing tic-tac-toe, constantly playing to draws for hours on end, until sleep depravity (or the need to go to the bathroom) drove one player make a bad play. For the most part, these are merely legendary stories; and I don't think anyone can freely call the design of tic-tac-toe epic in any sense, even though one could, I suppose, have an epic game of it.

Which I guess leaves us at with the first two lines of thought.

In my mind, if the real goal was to answer the question of "How do I go about designing an Epic game," my answer would fall along the second line. I think that you have to start out with the notion that you are going to try to make a game, thematically, where the player has lofty, thematic goals, but they start out as a lowly peasant (or a thematic equivalent). This is the traditional epic quest, the heroes quest, if you will.

While I suppose one could study Joseph Campbell's seminal work on this subject, The Hero of a Thousand Faces, it's probably overkill for game purposes. There's a lot of stages the hero goes through, and it's pretty far beyond the scope of a typical boardgame.

However, if one COULD create a game that follows the Campbell roadmap to the letter, it would be truly EPIC!!!!! indeed.

Anyway, thematically "starting small with large goals" leads pretty much to the first line of thought anyway as a consequence. You'll be needing all those shiny, plasticy pieces to keep track of your ever-growing armies; or those well-illustrated cards indicating your new actions you've acquired or learned and can apply. Simply put, I don't think you can have huge goals while starting small WITHOUT a lot of components for keeping track of how large you've gotten, or how close to the lofty goal you've become.

The next thing to question would be, "can the theme itself somehow keep a game from being epic?" I suppose it could...but I think a sense of something being epic leads a person to looking back at the end of the game and seeing what they have accomplished. And for any game to have an epic feel, the accomplishment of starting gamewise from a lonely peasant boy to becoming the CEO of a cotton ball factory (assuming cotton ball manufacturing is, indeed, your theme), still allows you to look back and see all the little accomplishments along each step of the way.

Additionally, the amount of time spent should matter. There is very little epic-ness in completing a game in 15 minutes to start all over again. Going on an epic quest means having to spend something dearly to achieve the goal. Beyond the purchase price of a game, there is very little spent on the game aside from time.

Time seems to be a fairly good constant with regards to this. The struggles between a baseball better who constantly is fouling balls off a pitcher with two strikes against him seems to always be raising the ante; who will give in first? The above mentioned game of the theoretical tic-tac-toe game that goes on for days will have an epic quality to it; they've both spent so much in terms of time, who will win the battle after spending all that time and energy?

There's actually a good "game theory" theory about this. Sure, everyone has heard of "The Prisoner's Dilemma." But in real life, the Prisoner's Dilemma is hard to play out since the results are way too dramatic. There are very few real life examples that play out nicely in PD (well, unless you go on crime sprees, and your ONLY concern is the amount of time you do in prison).

The game theory that I suggest that is worth looking at is called "The Dollar Auction." There is a large element of epic in here, in that it deal specifically with a person's amount of willingness to press something being spent, with the possibility of getting nothing in return.

And, you can actually play it at home with a reasonable outcome, which is something PD won't let you do.

Basically, a person puts a dollar up for auction. Players can bid on it, starting at a penny. The trick is that once all players have quit, and one person has made the top bid, both the top bid AND second highest bidder pay their bids. What usually happens is this: both players wind up paying more than a dollar for the dollar. It becomes more about the money spent while gaining nothing in return than trying to make a profit.

This plays out in life all the time; how much of something are you will to pay in the hopes that you won't get nothing at all. Do you wait in a really long line for tickets that might be sold out by the time you get there? You want a Wii, but you can only go to either Best Buy or Toys R Us, because odds are, if you go to one store, the other one will be sold out. Do you spend the night waiting in line in the hopes that there will be one available? People waiting in lines for days when the iPhone came out are really pretty stupid, but epic in some sense, I suppose, in that their story became a legend of some sorts. Even though I would like to think that all that time spent on a piece of tech could've been spent better elsewhere.

Of course, you could not play at all, but that's not very epic. But spending a LOT of something for an accomplishment, however small, is pretty epic. And the something should be a tangible personal investment. Little pieces of cardboard that have no value in real life isn't much of an investment; the only thing a person playing a game can tangibly invest is time.

So, there you go! "Start small, big goals, and a fairly large chuck of time."

Next question.

Where is the "fun" function?

It's been awhile since I've bothered posting. A few things are keeping me busy. These things happen to include the Nintendo DS games Phoenix Wright: Ace Attorney, Justice For All and Puzzle Quest, which are both fairly brilliant in their own distinct ways. As far as my game designs go, I've been working on a solitaire zombie game for my games-on-the-cheap list called One Against the Dead, and a game called Sir Reginald's Fabulous Country Estate which will hopefully neatly all tie in with the rest of this article.

There always seems to be some kind of running discussions on BGDF regarding various game design theories and paradigms (as can be seen here or here, for example). They are somewhat interesting from a scholarly viewpoint, and they usually wind up including big fancy words of importance when, in my mind, there are really only a few things that are really important.

Ultimately, a game is a simply a product; and how well (or how poor) the product turns out depends on how well the goals of the product is met. Games pretty much have only one real goal: fun. Granted, they may have some other goals as well, things such as "simulation" (trying to accurately re-create an experience that one may not normally be able to do), or "educational" (trying to teach a specific skill or ability). But ultimately, fun is the usual target. A game that generally isn't fun is a game that won't get played.

But fun is sort of a nebulous goal, in addition to being a very personal thing. While most people could agree on if a game meets an educational target ("this game does a good job of teaching kids on how to count change"), or simulation ("this game accurately reflects General McBean's ill-fated attack on General Lee's non-existent forces in North Dakota with lightsabers"), each person grasps at fun with very different sized hands. And those hands can change size depending on the type of game being played.

Producing any type of game in a corporate environment really brings out the ghostliness of fun.
A case in point would be my previous job working for Williams/Bally/Midway. In the corporate world of game design, games are kept to a fairly tight schedule; you need them to be finished by a certain time to keep the factory humming, meet certain time frames for release dates to coincide with certain seasons, etc. Ultimately, there's a bean-counter guy who prepares a schedule, based on what the desired final product finished date, and works backwards from there with various targets and goals. These are things that are used for determining a final bill of material, making sure that all art assets are finished, etc. And each goal is given a certain amount of time on the list. And this time frame is given to the wacky-designer guy, at which point he shouts out the commonly heard refrain:

"Where's my time to make it fun?"

It should be noted that this isn't meant to pick on anyone of my former employer; this is just how it works when you have a system that requires deadlines because mouths need to be fed. And you can't feed the mouths without product coming off the factory line. And that doesn't happen unless the bill of materials was solidified 3 months prior in order to shop around for parts. These are all the tangible things, with known prices to them, that you can throw in the a spreadsheet, and perform mathematical equations on to get desired results.

However, fun is simply magic. If you could somehow create an excel function that would guarantee fun all the time, you'd be the richest person on earth.

But you can't.

You can put together a list, or form a path, that you think may guide you down the right path. Or conversely, create a list of "things to avoid" and try to find fun by deletion of ugly elements. These are things the that usually go on in the usual BGDF forums. Things like "what is you path to making a game?" or "Do you work on theme or mechanics first?"

But still, if you create a product that includes your desired features, that doesn't mean it's fun. It means you have a thing that does your list of features. You've created a cellphone. It doesn't mean that the features don't work or aren't useful. It's just that you aren't playing with it because it's fun; it's because it works. But no one really has a slip of a paper that they can pull out of their back pocket with the"magic rule that makes a game fun." It's completely an iterative, "try it once, make changes, did it work," kind of thing. Which could take hours. Or years. Or depending on the other goals, never. At which point maybe the goals should change.

Anyway, I guess where I'm leading towards is this; when starting a project, I think it's also worthwhile noting of what you think would make it fun. Games should be mostly about providing an entertaining way of passing the time. Some thought should be made at the very beginning as to WHY it should be entertaining.

Of course, this will mean different things to different people. But simply saying "because it takes place in the Lord of the Rings universe" or "it's a pick up and deliver game" doesn't make it fun. Lord of the Rings Checkers, anyone?

Which leads me into Sir Reginald's Fabulous Country Estate. This game is inspired by my previous rant against Pillars of the Earth. To sum it up, while I haven't played the game, I've seen pictures of it and thought that whole "build the wooden cathedral" thing in th middle of the board looked really cool. But then I glanced over the rules, and realized that the cathedral is simply a round marker; at th end of a round, add a wood piece to the cathedral. Once all the pieces are placed, the game is over.

Lame. There's no sense of a reason why you should build the Cathedral differently from one time to the next. You can place all the pieces in a random puddle of wood in the middle of the table and the game doesn't care. Or a wacky Jenga-like structure. It doesn't matter.

I was wondering how you could build something with wooden bits, where the actual building of it meant something important to the game. Some thoughts floated around for a while, back-burnered in my head. I had some discussions about it with Sedjtroll in the BGDF chat room, but never really intending to work on it.

Then Xaqery donated 200 3/4inch cubes to me to do anything. And so, with a bagful of cubes, and some light prodding by Sedj, I was off.

Ultimately, playing Sir Reginald is a lot like being a real estate agent, trying to sell a home to a picky future homeowner. He has a lot of wishes for what he wants, but every estate can't fulfill every wish, so he'll buy the one that best suits the most number of his wishes. And the agent can influence his wishes a bit, getting him to change his mind on some things.

The main aspect of this game is that every player is building a Manor, Guest House, and Servant's Quarters on a Plot of Land using the cubes, which come in various flavors, such as Doors and Windows. Sir Reginald has a list of things he wants in his house as depicted on cards. The player who best matches the cards with their buildings win.

It's fairly straight-forward. But what caught me a little off-guard is how much fun it is to build little mansions with the cubes. It's a very tactile, rewarding experience just to build things, without a game wrapped around it. It's a toy as much as it's a game.

And unlike Alhambra, where you don't really get the feeling of building a palace (even though I like the game a lot, it could just as easily lose the theme and be an abstract), Sir Reginald really does feel like you are building houses. For some reason, I always place my doors facing the road, and most of my windows overlooking the lake, because, well, that's what you'd expect in real life.

It's fun just playing with the cubes and building things. Therefore, almost all of the rules, or lack thereof, are focused solely on making the building of stuff the focus of the game. Every turn you collect cubes, and you build with them. That's pretty much it in a nutshell.

For example, I played around with only drawing one cube and placing it on your turn. That wasn't as much fun as placing multiple cubes. So the rules focus on placing 3 cubes per turn. And while Sedjtroll gently kept prodding me to try and come up with a more interesting way of collecting cubes, suggesting various routes through hiring craftsmen, getting the proper supplies, that kind of thing, I decided against it. While these are fine ideas, these really took the focus away from the simple fun of building things, and added the additional focus of material/labor management, which winds up, I think, watering down the what I felt should be the focal point of the game...the cubes themselves. So now, you just pretty much "collect cubes" from a small sample of cubes.

This is something that often gets talked about in various designing themes, such as removing "fiddliness" if possible, or "streamlining" rules. But often enough, this is almost based SOLELY on making the game work better, not making it more fun. (However, this should indirectly make things more fun in theory, as streamlining things should make the game more playable.) But very rarely are the discussions held in in terms of "what parts of the game make the game fun, and how do you bring that more in focus."

It's a question that should be asked more often in the design circles I follow. And I probably should ask it to myself more often as well.

Presentation..and Oh Yeah, System and Data

Not much to say currently as the Summer wears on, and other are pressing. The time away from design-work around the 4th of July, which included numerous family birthdays and some craziness at work, made me reposition various hobby projects. I've slowed things down around here, too, mostly for this reason.

Firstly, I've put off KitchenTable for a while. It was starting to drag me down, even though it's really close to a first free-range beta.

Secondly, I've had enough PocketCiv questions and comments that it wanted to start moving on updating that game.

Thirdly, getting KT away from me has led me into working on updating the fixes for Minsterpool for later Hippodice submission in the year.

Anyway, on with my mindless rambling on the topic.

I break games down into having three main components: Systems, Data, and Presentation. A more simpler view of this would be that the System of a game is the rules, the Data is the various elements that can be altered by the System and how they interact with each other with regards to the System, and the Presentation would be the look and feel and theming of the game. Ultimately, a game winds up being an typical Venn diagram of these three main elements.

I've never really spent that much time thinking about this really, until a BGDF post caused me to ponder it. The link to it is right here. For those who don't want to be bothered to click to it, basically someone is talking about a game idea revolving around the player being an Evil Villain, doing evil things in a Trading Card Game format.

And as I read most of his outline, I was left with the impending sense of doom that I usually get from these things. Usually, all I get out of these are Presentation and some Data (obviously a full Data set is pretty much impossible with a quick description), and no System design. Which to me means: There's really nothing new here. It's just new names and faces (Presentation) on cards (Data) that could be easily swapped out from a pre-existing game ruleset (System).

Of course, it always tough to understand the genius of someone else idea without seeing and touching what they are trying to do.

And maybe it's really not so much this game, but a lot of the game overviews on BGDF feel that way to me. Everyone wants to play and create a cool universe (again Presentation and some Data), without much regard about how the laws of the universe work (the System).

"This game is going to be cool because it's set in the Matrix universe."

And maybe that's why I don't post much to the forum anymore.

Everyone gets so hot and bothered by the Presentation and Data, that very few seem to worry about designing the System. It's EASY and FUN to design the Data, I guess. It’s a little bit tougher to design the Presentation (usually the artwork being the biggest thing, but also flavor text and background story). The real hard work for the most part is in the System. Granted, the Data needs to be balanced, so one piece of data doesn't completely overwhelm any other piece of data within the System; but early on, that isn't and shouldn't be the main issue. All that gets worked on in playtesting, or at least, it should.

Ultimately, I personally feel that the initial design flow chart pretty much works like this:

A) Develop brainstorm of the world you want to have the game in (Presentation)

B) Develop basic rules structure (System), with small amount of Data to test it.

C) Tweak System and add more Data as various Systems are refined.

D) Finally go back and flush out the Presentation. Add mucho Data. Make sure additional Data doesn’t break the System.

It typically scares me when chatting online with the geeks on BGDF, especially cases where people have developed 500 different card types without ever testing the System yet. That just seems like a lot of wasted effort there. And, I would guess, a big “falling in love” with the theme (and the elements it brings), which is a common trap in designs.

Sometimes, the game tells you where to go. Other times, you tell the game where you want it to go. Usually, the latter is a mistake. Trying to force stuff into a game System that doesn’t want it or require it usually makes a mess of game. You are much better starting with the System first, plug holes in areas where the System needs it.

Hence, DON’T design 500 cards first before you even try to play a game.

Presentation is an interesting thing to explore, if only because it seems so obvious: Does the game look good? But it's more than that. It's part of the whole interface, and how easy it is to understand what you are supposed to do. Is the art getting in the way?

One of the more amusing things regarding this point would be the buildings in Puerto Rico, which look like this:
What happens when you effectively strip away the Presentation, and show you just the Data for each building? It looks like this:
(And, yes, it's meant to be the same picture. The buildings in PR are notably devoid of Presentation).

I know a lot of people complain about it, and others have tried to embellish the small cardboard counters with art to make the game "more immersive":



But it all seems to counter the ease of use. While the addition of the building in the upper right tile does add something without distracting from what the building tile does, the tile on the left adds nothing to the game except for some dark murky picture of a guy, who I presume, runs the indigo plant.

Forcing Presentation on to a game that doesn't need it, or worse, that really needs help in other areas simply doesn't work. It just hides the problem. Most games with a humorous bent fall prey to this trap; that their witty flavor text and absurb Data names will cover up the fact that the game has a weak System to begin with. Well, it sometimes works, until you know the jokes. And then you see what the game is really doing. The Munchkin games are a notable exception to this; while the game parts are funny, the actual game System works well, and is fairly amusing in it's own right.

For examples on the worst kind, where the humor just can't carry the game, many Cheapass Games puddle around in these waters. However, many more of the Cheapass-clone companies are much, MUCH worse.

Games where the Presentation seems to blend effortlessly within the Venn diagram; and in fact, where the Presentation is just as important as the System fairly few and far between in terms of the actual game play and how well it works. But there are exceptions, such as Wallenstein. It's cube tower being a very neat combination of Presentation and System (as opposed to the typical Presentation/Data combination). The Cube Tower IS the combat System.

Pillars of the Earth has a fairly unusual presentation element on the other end of this spectrum that bugs me. Ultimately, the game is supposedly about building a Cathedral in the middle of the board, and it sure does look cool in the pictures.

But as I read over the rules, the Cathedral really is just a simple timer. At the end of each round place a Cathedral piece on the board. I've talked to people who don't even take the Cathedral pieces out of the box.

Unlike Princes of Florence, where you are building various houses for artists in you compound, which is played with simple flat cardboard cutouts where the placement of the "houses" matter, the Cathedral is just saying "Hey, you are on round 2." The presentation of the houses in PoF matter in regards to very important elements of Data and System. The cool presentation of the Cathedral seems to be mostly a reflection of an overall boring (but important) System rule, which saddens me, instead of being more dynamic, and a true point of Data within itself.

And now, a story...

In my previous life working at Williams/Bally/Midway, I was around during the Mortal Kombat explosion. While I wasn't working in the video-game department, it was still fun to watch an enormous hit of a game steamroller itself into the public consciousness.

And with any big hit into a culture, the Fan-Boys grew. And what somewhat interesting, with the birth of the internet and widespread video game magazines, was that it was fairly easy to call up Midway, and ask for one of the designers of the game at phone central (the little old lady who sat in the booth in the plywood decorated waiting "room" (last updated in 1965) at the front door.

And she would just forward them on.
And at some point, the designer got a little fed up with wasting his time dealing with the Fan-Boys. He's a nice guy, and really tried to be nice to everyone, but he had work to do. And so he would forward these calls occasionally up to where I was at the time to a guy named Jeff. And I listened in on one of the calls.

Anyway, the caller was all set to be a co-designer on the next version of Mortal Kombat. He had all these great exciting ideas for the game; back-stories, characters, special moves, etc.

But he didn't understand how all this ties together within a system. Sure, pressing a punch button that rips of a guy head, that flies up into the air, with the "camera" following it, then it comes back down through the opening in his neck, and then explodes, is all cool I guess. But, at that time, the game system couldn't handle that kind of thing IN THE MIDDLE OF THE GAME graphically. Plus, an in-game fatality would pretty much severely un-balance the game structure that had been created at that point. Not that you couldn't add it in somehow with a balancing mechanism; but the desired structure of how the system worked was there, it worked, and didn't need a complete overhaul.

(Actually, I think there was a game where you could deliver "fatal blows" in the middle of the game; it was Time Killers.)

And of course, a lot of his presentation revolved around Animalities (where the characters would turn into animals for a fatal kill), and other "fluff" things that, while interesting and add to the package, aren't really a part of the game and how it works itself. But these were all the FUN things he had cooked up; and the design team had plenty of fun things on their own minds. All the fun Data that you want to work on while you are toiling away to figure out how to make a balanced system regarding the use of "juggles" (a feature where you can do multiple timed hits on your opponent keeping him up in the air like a hackey-sack), without having it become abusive.

Anyway, we convinced him that the next Mortal Kombat game was going to include Furnituralities, where the characters would turn into office furniture for a final blow.

"Look! I just made Johnny Cage turn into a file cabinet, and then it fell on the other guy. THAT ROCKS!"

I think that this is why people on BGDF that I talk with and have a lot of respect with, seemingly never start on their dream project: you sort of know what the final project is and the Data you want to use (that rockin' Role Playing Game in the NASCAR universe or something), but there is no thought on the system to incorporate all the Data into a useful, thoughtful process.

In other words, "Where do I begin?"

And my response to this is (as I've told some amount of designers), "Just start designing." Make a rough board layout, try to figure out your stats, whatever. But I think the important part here is that you don't go around and design 500 different car specs for that ZOMBIE NASCAR RPG. Design 1 or 2 with the stats that you want to deal with; design a rough world. Get a rough System in place that can manipulate that Data.

And then refine the System. Add a few more cars, and see if these cars break the System. Fix the Data if it doesn't work, and refine the System further.

And pretty soon you'll be at the fun part, where it's all about creating the Data and Presentation. If the System works.

It's more important that the System works without the Presentation. And this is why it's important to build a game with as little regard to things like flavor text and wacky names as possible initially. There's nothing wrong with including this kind of stuff in the design as you go to keep you interested; but don't focus on it exclusively.

Motivators

When I get the chance, I've been play-testing a basic version of Leviathan a bit, tweaking some values and such, and putting the rules into some kind of understandable form. As a recap, this is a general overview of how things currently work, based on what I've fleshed out so far.

Tales:
The object is to get as many Tales in each Port as possible. Your final score is based on the 2 Ports with the lowest Tale count.

Strength:
When a player runs out of Strength, the game is over. A player gains Strtength by taking down ships (eating the sailors). But a player also loses Strength when doing this, and due to weather events.

Game Play:
The player first decides how much Strength to apply to an "At Ready" Strength. This is the amount of Strength he expects to expend during this round. All unused At Ready Strength is discarded at the end of the round. However, if the player did not assign enough At Ready Strength to cover "losses" during the round, he must cover start sucking up his Strength reserve with a penaltly of using 3 Strength for each Strength that is required to be paid.

The player may move to a new location.

The player checks out what he has discovered at this location.

If he finds a Fleet, he Battles them, using up Strength in the process, or attempt to run away.

Strength and Tales are awarded for sunk ships.

And then round finishes, all excess At Ready Strength is discarded.

**************

Playtesting at this stage, I'm currently smoothing out the Battle system, and getting a feel for how the balance between using up Strength and awarding Tales feels.

And without the Evolution system, the game feels fairly dry. It's completely playable for sure. The game as it stands right now, is basically the player making decisions pretty much based on making decisions based on Strength/Tale conversions. And that's essentially the sole "motivator" right now.

Most motivations that move a game along are pretty simple, and they are typically all tied to "Winning the Game." Whether that means the most points, or getting rid of your cards first, or first across the finish line, or whatever, it's pretty much all tied to winning.

Usually, though, there are a lot of secondary motivations you can find in games. These things are a bit more varied, but they usually more exploratory in nature. These things are usually along the lines of finding the best strategy in order to win, but they can also be more about just trying to mess around with the game's systems and see what becomes of it if you don't follow the obvious path, like attempting to go the 100% corn producer path in Puerto Rico, or playing Princes of Florence without building ANY buildings. Or playing Tikal solely for chasing the masks and idols. A big part of the CCG allure in is this; often, it's not so much as winning the game as it is trying to get all of the cogs of some infernal machine together to come out of your deck just right.

Anyway, in my experience with PocketCiv (and really with games in general), you really need to have something more than a design that is simply "best points win." Or in the case of a solitaire game, just a running total of points. Sure, you can "beat the game," but the flexibility of the PocketCiv turned out to be much larger than I thought; there's a lot of things to explore in there.

Which leads me to Leviathan, which, in it's current form, doesn't have the same amount of flexibility. As a game design, it's pretty static, and the player has only a few real choices; these things I are Player Movement, Player Battle Decisions (which includes the At Ready/Reserve mechanic), and a player's decision to keep fighting or to run away after each sunken ship. There really isn't that much to explore.

And so, my next step is introducing the Evolution system into the mix.

Generally, the concept is this: When a player sinks a "good" ship (one that has a certain value), the player is awarded with a power-up (he Evolves). However, the fly in the ointment here is that giving the player an option of what he wants will most likely allow him to beat the game easily. PocketCiv controls this aspect by it's costing structure: more interesting or powerful technologies simply cost more, or have preresiquites before you can obtain them. Additionally, I need to have some control over the Evolution to keep the player coming back to explore new routes.

I don't really want the player to "target" a certain power-up, I would like him to discover it somehow. So if a player wants to follow a certain Evolutionary path he hasn't been down before, he can find something new.

Of course, this sort of relies on a certain amount of trust in the player in that he simply doesn't just read the entire menu before he plays the game. On my end, I sort of have to hide the power-ups as best as I can, so the player can't just happen along something cool that he isn't supposed to get.

In a nutshell, that is the design issue I'm out to solve, and here's the first pass. I think it will work out well, with the exception that I note after the description. The Evolution system requires the need for two additional grids (on one or two boards), and a book or manual for the "Captain's Log."

Ships come in two classes for the purpose of Evolving. Once a ship is sunk, the next Battle Card is turned over, and based on the Ship Type (of the defeated ship), the player can determine if the ship is "Named" (a cool ship, one worthy of songs to be sung by sailors), or "Unnamed". If a ship is Named, you are awarded a icon; there will only be 4 different icons a player can collect. Additionally, a player can only have one of a particular icon at a given time; so if a player collects a "spyglass," and he already has a spyglass, then too bad, he doesn't get an additional one.

I would've liked there to be more of a theme to "naming ships," but at this point, I'm going to attempt a simple route to keep the current, overly large component count down a bit.

Anyway, evolving is based essentially on a probability tree. A player starts a pawn on the bottom of the tree, he may spend on icon to move on a branch to the next space up on a branch, provided he has the current icon to move there. At the new space, there will be an entry number of a Captain's Log that the player will be required to read.

The Captain's Log contains two types of articles. First, a Captain's graphic description of the sea monster that attacked his ship, which will end with another pointer to entry somewhere else in the book. This entry contains the power-up rules description; the new rules that appply to the player now that he has Evolved.

Ultimately, the Captain's description is fluff, but important fluff it is! It is the link that hides the misdirection between the entry number on the Evolution Tree (which can be seen by the player) and the eventual reward of the power-up (the entry that the Captain's description points to). So while a player may glance and read about a potential rules change; he will most likely not know how to get there, short of scanning and remembering other Captain's descriptions.

So, let's break this down a little bit more, in terms of a player's choice.

The player now has fairly limited control over exactly how he will evolve. He has enough control where he can decide to wait and spend his icon (in this example, the "spyglass") on whatever the next "spyglass" Evolution will be. Now, if he has played the game enough times, and decides that he has seen the "spyglass" Evolution choice enough at the start of the game, he may wait and use it further up the tree in the hopes of exploring a new branch on the tree, and finding a new "spyglass" Evolution that he hasn't played yet.

However, this comes at a possible price, as getting another "spyglass" is essentially a useless endeavor, since you can't carry spares. "Collecting" a second "spyglass" is giving up one Evolution. So, there's a bit of fun risk/reward in this. You can collect the known Evolution now, or you can wait, and try for a different one, in the hopes of spending it on a new, unplayed Evolution later.

While conceptually, I think the basic design is strong, the hard part on my end is this: I need to somehow come up with a rather large list off power-ups to make this a useful and interesting feature. And they need to be fairly unique, especially the ones further up the tree, as these will not be seen very often. They need to have a certain "hey that's cool!" about them, so the first time a player experiences something neat 5 levels into the tree, he'll want to come back and try a different branching route in the tree to see what else is at level 5.

I'm somewhat concerned that the "base game" isn't robust enough to really pull this off. Or at least, pull it off to the point of making the player's choice meaningful with the Evolution Tree. Here are the current "systems" I can power-up:

• Player movement
• strength/healing
• Battle options
  
• Awarding of Tales
• Weather effects

And so, that's the plan of the moment. We'll have to see how it all comes out.