Protoplay

When creating and playing prototypes, I always expect the first pass to be awful. It's second play of the game, after all of the gross adjustments have been made, that determine if the game is worth moving forward on for me.

Anyway, in the last week, I've had a chance to playtest My Little Vineyard twice. And the second playtest was very successful in this manner. Many of the really awful things from the first playtest were resolved, and it really felt like progress had been made forward, as opposed to sideways.

Obviously, the game currently is in a print-n-play format of just a scoresheet, and everyone agrees now that it should be more than that. So porbably the next version will be something much more like an art project. But at least I feel like it's worth the pursuit. The Shipwreck game, while having merits, always seems to run sideways. And the (what seems like) 25 hours of mocking up a new set of parts for that just doesn't seem like a good use of time, at least until I get the hunger to re-visit it again.

Aside from the BGG link for My Little Vineyard given above, you can go to the sideboard link which has all of the most recent files. The BGG link is kinda slow in updates due to the "moderator must check all files" thing. In the end, this is a very good policy; just not that great for quick updates.

Villains

I've been centering a lot of my prototype time on the Shipwreck game of late; as noted in this post, it has become more of an Indiana Jones-type adventure, where the game is about finding the clues through artifacts that lead the players to a final destination. And so, it continues; and I am strongly applying more thematic parts of that kind of adventure to the game.

Now, in this case, the word theme in the traditional sense of it being applied to board games would mean that I am taking characters and mythology from the movies series; well, this isn't the case. This is more about theme in the classical sense. In the sense that I am playing around with the ideas of running around the world is search of wacky magical artifacts, which have powers that can make you rich (the winner of the game), or can otherwise destroy you (put you is a losing position) due to your own moral compass.

One of the more interesting things to come out of the new direction that the game has taken is the idea of "playing the villain," which is something I haven't run across before in other games. Generally, this means you can play the "honest" way, which is full of hard work and a lot of money and actions being spent; or you can simply be the evil rogue, stealing need-to-use boats and hiring henchmen to steal artifacts. Or you can walk a fine line somewhere in between, and only play with treachery as a desperate last cause when needed. And of course, much like the Indiana Jones movies, those who take the easy, more villainous route, will most likely pay the piper when the "check comes due."

In general, the idea works like this: There's a set of rules how to obtain various important things in the game; these typically require some amount of money and actions to obtain. But, if you decide to not pay those fees in acquiring these things, you gain Villainy points.

Each artifact has a randomly (and unknown) Villainy threshold. Once a player acquires the artifact, the threshold becomes known, and if the player's Villainy is higher than the artifact, well, in true Indiana Jones fashion, the artifact turns on its owner and "bad things happen" to its owner.

From a design standpoint, I think it's an interesting concept as most games usually thematically assign a role to the player, either the good guy or bad (depending on the point of view). Then it is up to the player to win the game within the definition of that character. In this case, the player is self-defining their own character; do they see themselves as the honorable treasure hunter, or as the collector who collects through any means necessary? Are you Indiana Jones, or Rene Belloq? It's a risk/reward system where taking the low road early pays quick dividends; but the player does not know what the true risks even are (due to the random thresholds of the artifacts). So, a large part of the game is playing chicken with one's villainous self, while dealing with the race against the other players.

(I guess I should mention that there are not enough artifacts to go around for all players, so there NEED to be at least a little villainous streak in everybody. Let's face it, Dr. Jones was never one to shy against a little chicanery when times called for it.)

It also adds another layer of choice to the game. It's not just a racing logic puzzle anymore, where you choices were determined simply by trying to figure out the most efficient way to get the next part of the puzzle that you need. Now it's more about how you go about chasing down your clues long term, as decisions to use Villiany may or may not come back to bite you later on.

The closest that can find to this mechanism would be in Cleopatra and the Society of Architects, where you gain corruption tokens for using sub-standard building materials. I've never played it; I assume it's pretty close to what I'm talking about. And I guess that there must be other games out there that do this kind of thing.

How did this come about; like most elements of Eureka moments, it's about solving problems with the design. In the last playtest, I really wanted a strategy to exist where a player could simply spend all their time collecting money, while other players are doing the hard work. Then the money rich player could simply hire more goons and steal the artifacts away from the other players. However, even though no one attempted that strategy, it seemed pretty clear that it was the optimal one.

While suggestions came in about limiting what a player could do with regards to the money-rich strategy, I preferred to still let the player decide to take it or not, as opposed to the game limiting the collection of funds or steals in some way. The player SHOULD be able to take the role of the extremely wealthy collector if he wanted to, instead of the down-and-dirty tomb raider.

And hence the Villainy count was born, where every time the player tried to steal an artifact, he get dinged for a Villainy. Then it became second nature just to apply this concept to all of the other aspects of the game, and make it a prominent feature of the game.

**After all, the concept of tomb robbing, regardless of reasons for the robbing, is a little villainous no mater how you look at it.

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.

Focus

So, I've been busy. That's my excuse. For not bothering to post in a while.

I've been re-working the Shipwreck game a bit lately. It's now on version 4.

It's been a sort of troubling game. The core mechanics are fun and everyone who has played it seems to enjoy that part of the game, but the surrounding structure of it has never seemed to gel very well.

The core structure is finding clues to find locations of shipwrecks, which players salvage for points. There was always an intended structure for the points allotted, based on various things, such as the class of the ship, the quality of the salvage crew you've hired, and how deep the shipwreck was in the lake.

And ultimately, most of that stuff never really mattered.

So much time and effort was spent on finding enough clues on a particular a shipwreck, that if you did realize that it was a low point salvage operation, you never really cared. You had completely "adopted" that wreck at that point, so it was in your best interest to salvage it anyway, low points be damned.

And so, in the end, it felt like the wrecks were just handing out random points, even though there was a lot of effort built in to the game to make it not random.

Therefore, the game was just running around, finding wrecks, and getting random points. Pretty much like what I imagine real shipwreck hunting and salvaging is sort of like. I've gone through 3 different versions of this, with handling the point system in different ways. With all the same results; while the clue hunting is fun and sound, the game around that aspect isn't.

Recently, I decided that what was wrong with the game is the focus of it; the ultimate goal of how to win at it. The ride was fun, but the destination wasn't. As it was, I had still not developed a good way to end the game, aside from "after 12 shipwrecks have been found." I've never liked this kind of arbitrary kind of ending in a game to begin with. I'd much have a more organic way to end the game (whatever that means), than some simply stated fact. There's nothing really building towards that finish. It's not like players are building an empire from some small cogs. Your salvage operation is always the same operation throughout the game. Puerto Rico doesn't end after XX rounds,there are hard component limitations that end the game, things that the players can control, or at least feel like they can. Or at least point to how it happened.

Not, "just because the rules said so."

So I've turned the game much more into an Indiana Jones/DaVinci Code affair. Which has brought a lot of the mechanical concepts of how the game works into a much more sharper focus, and has even brought the theme out some more. And it has gotten rid of the entire pesky points awarding system. It goes like this now:

The game is the first player to discover one of the 3 Gates of Atlantis at the bottom of the bay. To do this, players combine artifacts together which reveal clues as to where those gates are. However, those artifacts are also lost in the bay, hidden amongst the many shipwrecks. So, the player first travel from city to city, finding the clues that eventually lead the players to discover which shipwreck each artifact is hidden on, then the players must discover the locations of those shipwrecks, dive down to recover the artifacts and then use the artifacts to discover the location of one gate.

This is a much stronger narrative theme to impose on the players, as it gives them a call to action. The game now has a drive behind all of it's clue-hunting mechanical nonsense. And like any good "race for the artifact story," the game no thematically allows for stealing things from other players, leading to more direct confrontations, which I think should play out well.

//Well, of course, until it doesn't play out well, then back to the drawing board. The life of a prototype game is never complete.

Hippodice Entry Guide

So, the entry deadline for Hippodice fast approaches. I won't be entering this year.

The few interesting projects I've worked on this year are Dark Water Salvage, and Reading Railroad. DWS still needs a bit of work to fix some timing issues (which should only require one more playtest, whenever that is) before I can balance the game out. And RR is a hybrid word/train game that probably would need some alterations due to language. Plus Seth has sort of taken that game over, and corrupted its soul into a different game (somewhat). But hey, at least he's taking it to BGG con for playtesting, which is more that I can do.

However, since I did make the initial cut last year, I thought I'd put up my entry from last year for those who are interested in entering. This way, interested parties can see how I laid out my initial entry, based on the way way I parsed out the English translations.

You can download the .zip file for my entry at this location.

The leash

Occasionally, I try to write up a post that focuses in on a design aspect, using examples with something I'm currently working on. This is one of those posts. However, it feels like it came out a little more jumbled than it should have, and for that, I apologize.

Anyway, on with the show...

Early game prototyping can be thought of like walking an insanely active dog; you want it to be happy and go about following it's desired course, but you need to keep it under some amount of restraint, otherwise it gets away from you.

While I have no concrete evidence of this, my personal experience is that good games (like most creative processes) develop "on their own" fairly naturally with only gentle shoves and yanks of "the leash" as guides. It's a careful balancing act, games left to run by themselves become a mess pretty quickly, and require quite a bit of leashing mid-way in the design. And games that are under the heavy hand of the designer leash, with no intentions of wavering away from the original plan. Well, they don't go any where much at all. Every game project that I've been involved with professionally was never, ever considered to be "done" by the creators; just "finished enough" given the tightrope walk between the various constraints of schedules and finances on one side, and creative design work on the other. They are never perfect, but close enough to almost be happy with the final the output, as there is always at least one more bit of polish to clean up, or one more feature to add that the game absolutely requires, but at some point, as a designer, you have to stop, and move on.

The development process usually works like this (of course, your mileage may differ). Early on, after settling in on one or two "gimmicks" that the game is going to based around, I let the game go, adding features, or doing whatever the game feels like it needs. Ultimately, the gimmicks are the leash; these are the things that will guide the decisions made for the rest of the design process. But I allow the game to go off and explore other possibilities. Until, of course, the game has now become so bloated, or confusing, or misguided, that now is the time to yank the leash, and get the game back on a course. Editing out extra rules, or components, or things that don't seem to affect the original gimmicks, etc.

In most cases, letting the game "roam free" doesn't happen and develop in a vacuum. They require the ability to bounce off walls, knocking into other people, and going through various filters that other people have, through your usual playtesting experiences. In fact, the first few playtesting sessions of a game probably should mostly focus on the main gimmicks, making sure that they even work, without much attention to the side effects generated by the game running it's own course. These additions (and subtractions) should naturally come and go as they please.

Recently, I've been playing around with the Shipwrecks game (the current version can be downloaded off in the "Things To Play" section in the sidebar, listed as "Dark Water Salvage"). There's been a nice progression of the main gimmick, along with various levels of fluctuating game-defining rules.

Luckily, I'm a member of the Board Gamer Designers Workshop, which is a small group of geekiness dedicated to just playing game prototypes of our own creation. A sort of a bi-weekly Protospiel. So, there's no need to torture real players who might not understand the concept of how prototypes work.

As is usual of my designs, the game went through a few revisions even before the first playtest. As I've noted in a previous post regarding the use of windowed cards for hidden data, the main gimmick of the game is hunting for shipwrecks that are "hidden" in a lake. This hidden information system was originally being developed as a haunted house game; but things "weren't meshing" well at that point. This system initially was testing for directions using simple binary coding (Y or N). The binary "bar code" worked with deducing items back when it was a haunted house game, but now the game involved searching for a location, and the game cried out for a modified version of the system that more closely relates to that action.




And so, while the gimmick was kept the same, the data was reversed. By testing from various locations on the game board, you can get directional information regarding where a location is in relationship to the testing location. In this case to the left, the location is Southwest of the city of Missaukee (when Missaukee is stacked on top of the location card). So, while "the leash" of the stacked cards revealing hidden information is kept, the game was still allowed to form naturally around it.

During the first playtest, one of the main focal points was watching to see if this mechanic would actually work (it did). Other elements of the game around it did not, but that's fine. As the core interest point of this game is based on the the searching and locating function of this mechanic, those are adjusted or removed, and tested again.

At this point, I'd like to point out that there's almost no sense of trying to balance scoring, or creating a more "interesting" map, or any kind of fine tuning. It's an early prototype, and the basic functions of the game are still being fleshed out. In fact, after finding a major rules break in the second playtest, it became obvious what some fixes were required, and what was still broken...there was no need to finish.

As an additional aside...

One of the games we played was very much of a loosey goosey party game, whose main goal was seemingly guessing random numbers. The only information that you had to go on was that the current number to guess is less than the previous number on a card. Basically, no strategy or skill, just wild guesses for the most part. And while the designer was happy with what he implemented, this IS a group dedicated to board game geekery, and simple random guessing games don't cut it.

The results that came out of the discussion at least sounds like an interesting game. At least playing the game mentally. It still keeps it's party game roots, but has some elements of a mind game. For the most part, it was an idea that was "let loose" to see where it would go. As is typical of a brainstorming session, no leashes are attached.

For the fun of it, I've dubbed the name of the "Vezzini," in honor of the greatest mental skills battle ever filmed, the Battle of Wits from "The Princess Bride."



I imagine that the game winds up being played in a "well, I picked this because I think you picked that because I figured you'll think I'll pick this" kind of manner. I also imagine that the game could be potentially be terrible, too. Of course, this is solely what I consider to be the best version discussed, I'm sure other would have different opinions.


Vezzini
A (potentially irritating) battle of wits for any group of players

Give every player a pad of paper and a pencil.
Someone will also need to keep track of a running point total for each player on a separate sheet of paper.
Agree to a Target Score that determines the winner.

THE GAME:
The game is player in rounds. In each round, the players will first determine who the Host is. Once a Host is determined, all players then battle the Host.

DETERMINE THE HOST:
All players write down a number secretly on their pad of paper.
All player's reveal their number.
The player who wrote down the LOWEST value number, that is not tied with another player's selection, becomes the Host. All other players become Active Opponents.


The Host scores points equal to the number he wrote down.

BATTLE THE HOST:
A Battle consists of three rounds, in each round the host secretly writes down a number that MUST be lower than the number he previously wrote down. In the case of the first round of the battle, the number he writes down must be lower than the number he wrote down to become the Host.

All Active Opponents now write down their guess. Opponents can ask questions; the Host can lie or bluff, or refuse to answer.

Once finished, Active Opponents reveal their guesses, and the Host reveals his number.

If an Active Opponent guesses correctly, they stay Active; an incorrect guess renders them Inactive, and out of the remaining battle rounds.

The Battle ends when all Opponents have become Inactive, or after three rounds of Battle have been played. All Opponents that are still Active after three rounds (they have successfully guessed the Host's number three times), win points equal to 2 times the amount of the initial number the Host selected to become the Host.

THE GAME IS OVER:
...when a player has earned points equal to or greater than the target score.

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.