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.