Interview

I guess I'm a little late posting this up, but Matt Worden asked me a few questions about the development of PocketCiv, and here are the answers.

And the people shall speak...

I had always hoped that, somehow, PocketCiv would wind up taking a life of it's own somewhat. And that somewhere along the line, that some small community somehow would come along and support it, add to it, and let it grow naturally.

In a lot of regards, this did not happen. While the general response has been overwhelmingly more enthusiastic than I could have dreamed ( ranked as the 720th best game on BGG), it's been a disappointment in the "virus" category so far.

Some part of this is that I really haven't "marketed" the game at all. One, I've got other things I want to do in my limited free time, and two, again, I really wanted to see what would happen to it, so I wanted it to have a life of it's own with me pushing it.

Most notably in my eternal sadness, even though there have been various calls for someone to turn it into a multi-player game, no one has apparently even tried the 2 player variant I have listed in the rules.

However, in other cases, things are brighter. I have received numerous emails for various people who have been inspired by PocketCiv to create their own solitaire game, using system elements from the game. So that's pretty satisfying. Most notably in this case is Zombie in My Pocket, the tiniest zombie game ever. And even though ZIMP leaves me a little flat due to the game lacking some interesting decisions (in my opinion), it does get props for the sheer size (or lack of size) of it, and still feeling like a game. Plus, it's been picked up by a publisher (Cambridge Games Factory), so it can't be all bad. And again, in this case Jeremiah (ZIMP's designer) has gone to pretty good lengths as far as marketing the game on BGG.

Anyway, this leads me to this point, in that I've agreed to let a fan of PocketCiv create an errata sheet, at which point I'll go back and fix all the bugaboos that the Geeks have found. And so, the call has gone out on BGG, at a thread that can be read here.

I assume this will give the geeks a little ownership of the game. And maybe a little pause for some creative sparks on their own beyond just rules fixes. And maybe, just maybe *sniff* my dream will be realized.



Well, if not, that's ok, too. As long as people still have fun with the game.

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 internet is a big place

So, how do I know that the internet is a big place?

On Friday, I spent some time cleaning up the PocketCiv website, finally purging it of all version #1 data, and FINALLY updating the scenarios. But it turns out that I had missed a link (to the rules sheet, of course).

And how do I know this? I come into work on Monday, and find that I have 8 emails from people informing me about bad link.

Which probably doesn't seem like a lot, given the whole entire scope of things. But, in a lot of ways it's quite amazing. I don't track traffic on the site, so I have no idea how often it gets visited. Really, the only "marketing" there is in terms of pointing out where the game is at boardgamegeek, and it's only occasionally mentioned here or there in a forum. In fact, there hasn't really been a large jump in it's ratings for quite some time now; I had assumed everyone has just moved on to "the next big thing." Well, that's assuming if PocketCiv was ever a anything larger that a small thing to begin with.

The game is such a niche-within-a-niche-within-a-niche kind of thing. First, you need to find that group of players that are "enlightened" board gamers (as opposed to the vast amount of people who only know of Scrabble and Monopoly, and whatever is sitting on the shelves at Target). And then with in that group, you need to find the people who are interested in a solitaire non-wargame experience, followed by people who are willing to take the time to print-and-play within THAT group. I imagine that the the pickings at this is is quite small.

But dedicated.

I guess that this leaves me wondering how constant the flow of traffic is, even though I'll probably just leave it as a mystery. After watching for various forum posts about the game, I'm always quite surprised how quickly catch an update to the website and mention it. So there must be some kind of small following for it.

As a side note, I've been toying around with a game tentatively named "Conjunction Junction" (named by Darkehorse of bgdf.com fame) with Seth over at sedjtroll. It's a sort of wacky idea I've had combining train/rail connections with Scrabble-like word play, that Seth has prodded me to investigate further with a few good ideas of his own. I can't imagine what the Venn diagram looks like for the crossover between those type of players!

When it rains, it pours.

So, I'm gone for about a week to a trade show, the holidays are coming up, and in general I was in the mood to just take a break from all this designing stuff.

So, naturally, Sir Reginald is accepted to Hippodice.

And I've suddenly got a whole list of PocketCiv questions appearing.

And I've got to get a copy (which hasn't really been built yet) to Germany by Dec. 5th.

I would've had a lot more to talk about, but I'm too busy right sticking stickers on 100 wood cubes right now...

PocketCiv ranks!

PocketCiv finally hit the 30 ratings mark on BGG to finally be given a rank. While it has a true rating of 7.6, it's biased rating is 5.86 (biased due to the fact it has so few ratings), ranking in currently as the 1583rd best game ever invented.

For the record, the worst ranked games with at least 30 ratings (again biased), are:

#3701 Snakes and Ladders
#3702 Bingo
#3703 Tic Tac Toe

And in other news, PocketCiv was subjected to an audio podcast review, which is a strange experience. It's one thing reading someone's comments about your game on a website; it's another thing to hear a voice talk about it. It all sounds so...official. Maybe it's the accent.

Anyway, comments and rules clarifications keep tricklling in on PocketCiv, and I've been meaning to get back and clean that game up a bit. Unfortunately, KitchenTable has been keeping me quite busy of late, and I've hit the "man, I'm so tired of working on this" part of the project.

The other side of KitchenTable is that I think I'm pretty close to having a releasable beta (after a complete re-write of some elements). Aside from a few issues I need to pick up, I'm currently dealing some higher conceptual issues in regards to how the multi-user aspects work.

Unlike a typical online game server where all the objects and graphics are known, KitchenTable relies completely on user-created content. And for a true multi-user game session to take place over the internet, each user must "point" KT to the correct file structure on their local hard-drive, and make sure that they are both pointing to the same image folder and files. This is all trickier than it should be; but since KT knows nothing about the content it is going to use, it just can't simply go to the folder structure "games/carcassonne/images."

What's on your Kitchen Table?

Work on KitchenTable continues during my lunch breaks. It's an interesting project in terms of trying to create something that allows a user to have as much freedom as he wants, while still maintaining a nice, easily understood interface without letting the user break things because f his own whims. And by nice, easily understood interface, I really want none at all.

But I'm going to be needing some buttons, whether I like it or not. These are going to be more global in nature, than actual gameplay kind of stuff. Think "load game" and "save game" vesus, "move a token."

Actually, it appears that Thoth does this very well.

It's working out fairly well at this point. Left-clicking on an object lets you drag it around. Right-clicking pops up a menu of special actions that's specific for that component type. Well, I have to convert the right-clicking to double-clicking due to a new"feature" the latest version of Director/Shockwave added where right-clicking an executable Shockwave will randomly shut the program down on a PC, but I don't need to discuss the gory details of that.






Something I've never contemplated up to now is that on the outside, thinking about all the different type of components there are, and how they are used can be somewhat mind boggling to try and define. But ultimately since KT is dumb about the uses of objects, the organization of component types is fairly straight-forward, with just a few differences across types. Ultimately, every object has an image, or a list of images that it could be, it has a location and a rotation. And that's sort of it. For the most part, every object allows you to select an image from it's list. Dice have an additional "pick a random image" action. Cards can be rotated (you can set the rotation increments if you are using hexes as cards, or something that requires strange rotations), and only have 2 images: card face and card backs. Now that I've got a lot of the backbone of how the world works, it's been fairly easy to add new component types.

Initially, when I was thinking about the structure of how this would all work, I really looked at something like a DECK OF CARDS, and saw a nightmare. How does one define that? Is it really a list of CARD objects? How do I go about manipulating that if I want to shuffle only the cards in the discard pile or a subset of cards? Is the DISCARD PILE a different object, or somehow tied to a DECK? What if the game doesn't have a discard pile for some reason, and is using some card-like kind of thing, like cardboard tiles or hexes?

Along those same lines would be this question: how would I go about creating a simple version of Yahtzee? Rolling one die is simple enough with a special "roll" action, but how do I handle multiple dice? Do I somehow create a way to "hold" dice (ala video poker) that I don't want to roll again? Is there a ROLL DICE button that affects all dice that aren't "held?" Or do I leave it up to the user to simply roll each die individually?

It turns out that a lot of these questions got aswered when I finished up my parenting method for moving objects. I use the term "parenting" not in the OOP sense, but in the animation sense. What this means is this: for any given object, it can be "parented" to one other object. This creates a relationship between the "child" and the parent where the child can follow instructions from the parent.

The easiest way to imagine this would be a stack of two cards. While each card is a seperate object, the top card is parented to the card directly below it, and if you move the bottom card, the top card will follow maintaining it's relationship in regards it's placement on the second card. At any point you can remove the top card from the bottom card, breaking it's parenting relationship, or place it back on top, re-connecting that relationship. Or swap the cards, reversing the parenting relationship.

This is, in fact, what KitchenTable is doing now with all of it's objects. Pick up and move an object, and all of that object's children will follow. Once an object is "dropped," KT checks to see if it has landed on another object; if so, it creates a parental relationship with those objects. You want to stack chess pieces on top of each other, you can do that. Move the bottom piece, and all the others on top of it follow along, and you never have to worry about them dropping!

This took some time to work out all of the kinks, but it works pretty well. You can stack components to your hearts content, break apart those stacks, and re-stack things in any different order. They are all just generic objects to KT.

And it turns out that this naturally and elegantly solves my questions above. There is no "physical" DECK object; a deck after all is just a stack of cards. But what there is turns out to handle deck functions (mostly shuffling) is a DECK TRAY, and dragging selected stacks of cards into deck tray allows the deck tray, as a special action, shuffle all the cards that have been parented in the tray. Much like collecting cards to shuffle.










For the dice, there's a DICE CUP. Put all the dice you want to roll into the dice cup, and those are the only dice that will roll.

It all feels very natural and very similar to playing with components on a table. And for prototyping purposes, I imagine this works wonders as it's pretty darn flexible since things aren't "hard-coded" for lists of components. There is no defined list for a given deck, one can fine tune the deck components easily by just not placing those cards on the deck tray, and instead dragging them "off the board." Same thing with rolling the dice. Ever wonder what Risk would be like throwing 8-sided dice for defense, and 6-sided for offense, well, just put the dice you want to use in the cup and find out.

And so, the project continues. This has put some of the things I wanted to work on for PocketCiv in the back burner. Which is sort of sad, now that PocketCiv has had a bit of awakening on BoardGameGeek (9 new ratings in the past week and a half. WOO!), it would be nice to keep that train going. Heck, a guy even made a nice little tech tree graphic for the game!

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.

He Died for Your Mounted Soldiers

What I learned from an email about a PocketCiv misspelling...

When I want to refer to something that are "warriors who fight on horseback in combat," I should spell the word "Cavalry".

When I want to refer to something that is "hill in which Jesus was crucified," I should spell the word "Calvary". Which explains why Word didn't catch the misspelling.

That is all.

Giant Gilded Statues of Yourself

I had someone email me recently asking a few questions about PocketCiv. In general, I find such questions pretty interesting, no matter how insignificant. If someone is willing to take the time to pose a few questions about a game to me, that pretty much means that something about the game has hit a nerve, and that they enjoyed the game.

Ultimately, noone cares about any background or balancing issues on games they hate. Thankfully, I've been somewhat surprised about the amount of email I've gotten, including one from someone who wanted to translate the rules to spanish (YES! PLEASE!).

Anyway, here's the gist of one question that I thought was interesting, mostly from an aspect of where my mind was at the time of a design decision.

"When comparing the costs between a Giant Gilded Statue of Yourself (4 Tribes, 20 Gold, and requires Art, for 15 VP) and Huge Monolith of Impressiveness (4 Tribes, 10 Gold, no requirements, for 12 VP), why would you even bother to build the GGSoY - it requires Art and 10 extra Gold to build."

Well, you know what, he was right. From a pure game design and rules standpoint, there is no good reason to build a GGSoY compared to the Monolith.

But from a esoteric mental image of what's going on in the game world, to me, I'm ALWAYS going to be building GGSoY. Heck, if I'm leading my people around, teaching them such simple things as Irrigation, Engineering, and Law, they better be building statues in my honor! Sure the Monolith may be impressive, but it's not me!

To be honest, I never really have spent much time on balancing the VPs in the game. I was more concerned with if the game played fun, and was hard, but still possible to play through 8 Eras. That was the driving goal of the game to me: to beat the game through 8 Eras and to experiment with differently shaped worlds and figure out the puzzles of which Advances best suited the terrain I decided to play against.



Scoring VP was pretty much secondary. Scoring really only came about because Advanced Civilization had it. I quickly did my best to think out some of the balance for VP to each thing as an after thought.

But I forgot that a lot of other people play games for different reasons. And score is a main fuel for the fire for many people who play.

Instead of seeing GGSoY as the abstract thing that it is (some little chit with text on it that scores 15VP when built), I see it conceptually as an entertaining motivator to canvass your Empire with giant gold likenesses of myself, lording over my little Tribes. Not that I'm this ego driven madman, mind you. I saw it more as a little side quest to do out of pure entertainment, just to be able to say "Look, I've got a little Easter island over here and they al look like me"

I guess you could do the same thing, plopping down Monoliths willy-nilly everywhere. But conceptually, that a series of overblown black bricks just isn't the same a bunch of muscle-rippling, heroically-posed, 50-foot high Scotts littering the view of the ocean.

Of course, the author of the email is correct. While the concept is amusing, that really shouldn't be the thrust of the game. And changing the stats to better reflect the cost of the things doesn't change my mental concept; but the concept itself shouldn't be driving the balance issues. The equations should not include "because you will find it amusing to build this."

I suppose this is why humor-based games fail. Once the joke is told, you usually find that the game behind the jokes is not very good. The equations to often include "you should do THIS because it is funny," and not "you should do THIS because it is a good play for you to make within the confines of the rules."

However, I do think an exception can be made. Maybe it should slightly fit in the equation in a game where you really ARE placing giant, oversized plastic pieces on a board. Because, part of the fun is in actually playing with the giant bits. A lot of the draw to the collectible figurine games have this element. Playing with the pieces is a huge part of the fun. I'm not sure if HeroScape is much fun in a cardboard chit on played on a paper hex map. But man, a large set with a bunch of figurines running around sure looks like a lot of fun.

Alas, PocketCiv has little colored chits that say "Monolith" and "Statue." The math will have to be fixed until otherwise.

Off the Checklist

And so, instead of getting back into Leviathan which I sorely need to do, I’m still busy cleaning up some other items off my design list.

Item number one of my “Things to Do List” is finished and shipped. Minsterpool is off to GCOM contest. Recently, I got an email detailing some information about the contest, indicating when each of the games will be played, and a short description of each game (there are 10).

Of interest is that one of the names of the designers sounded familiar. A quick google search for “Andrew Parks” did, indeed, pop up a BoardGameGeek entry for him, with a few published games. I’m assuming he’s also demonstrating his game as it does not have an official “demonstrator” tag attached to it.

Item two was tweaking PocketCiv a little bit. There’s a two-fold reason for this.

One, from a game design standpoint, There’s been enough comments on the game about it’s ability to beat up players in the early Eras. So I’ve tweaked and scaled a few of the Events down a bit early on.

The second issue is more of a marketing kind of thing. By updating the game, it gives me a really good excuse to keep the game “fresh” on BoardGameGeek, by bringing it up to the top of a forum list for a day or two. Like most things that go unheard, games on the Geek that don’t get much attention pretty much die a silent death. Conversely, every time PocketCiv gets a mention on a forum, it gets two or three more ratings. So, instead of just a blantant ad for the game, updating it periodically gives me a reason to re-introduce it.

Occasional updates also indicate a certain level of “customer support” I’m willing to give, as opposed to just letting complaints and comments rot away into the ether. I hoping that this should make the geeks who are on the fence about the game have a little more interest in trying it out.

And as item 2.5, I’m also experimenting with additional scenarios with PocketCiv based on a few comments. Also, I can’t say that I’m not influenced at least a little bit by my recent Nintendo DS games I’ve been playing.

I’ll probably go in depth a little more on this project at some point. But in general, it works like this: unlike the first 10 scenarios, which were just a random collection of various setups and goals, this next set will follow a story line, building a mythology as the scenarios are played out. This is pretty much following the videogame model, where every little mode plays similarly, but advances an overall story. This makes the game somewhat more compelling, as the “story mode” pushes you along in the world. Unraveling hints about a greater world, and gives it a little “just one more page” addiction. Notably, this is a moderately small experiment for a board game format (even though I believe it has to have been done before; probably at the very least HeroQuest did something similar). And so, as the story progresses, new rules are added and abilities are learned.

And, oh yeah, I’m adding magic to the mix using some new mechanics. So while I could just easily make the Advance Tree larger, or add a few new resource types (the easiest way to expand the rules), I am actively expanding the world instead, and trying out a different way to drive a solitaire game.

Fun stuff to play with. Until I get annoyed.

Success!

After watching the viral-ness of the internet take it's time, PocketCiv has made it on to boardgamegeek by itself (well, somebody other than me). I've seen a few comments about it in various threads, and have gotten a few email links to some session reports, so I've been kind of looking around for it. Of course, it's spelled "Pocket Civ" with a space, so it was kind of tough for me to find. Looks like I'll have to update the game name to include the space for completeness sake. And it's also listed as a "2005" game. I didn't start messing around with it until...checking blog archives...July 27, 2006.

It's nice to see such a high rating for it, even though there's only 6 votes for it. Heck! Those could be 2's and 3's. So I'm glad that people are enjoying it. What is particularily engrossing about the ratings is that I was able to develop a game that people like within the fairly tight contraints of the PocketCiv goal of "a solitaire sprawling epic in the tiny space of an airplane tray." I think that just pulling off a working game within those limitations is a tough cookie to crack (Lord knows that Leviathan isn't going to be going anywhere near that), but the fact that it's also fun to it's target niche audience is encouraging. The component list for initial entry into the game is fairly small (16 cards and rules) compared to other Print-n-Play games most likely helps. Just another hurdle for Leviathan to cross. Or fall down on it's face on.

I hope that at some point, there will be some amount of critical mass that gets hit where people will start submitting their own scenarios for it. Or better multi-player rules. Or something else to keep it fresh and engaging.

Anyway, for those who might have played it, and don't know about it's entry, here is the link to it: Pocket Civ at BGG. And if you have the ability and an inclination, feel free to give it a rating. A nice rating would be good, but a honest one would be better.

ALERT! A vote has been added since I started this post! Can't stop this train now, baby!

The Natural Migration of Sea Monsters

My definition of a game is broader than the typical game geek. It is, simply, "a set of rules the paticipants agree to follow for primarily their enjoyment." This pretty much encasulates things like Chutes and Ladders and slot machines, which the geeks would disallow since there is no control over the game, and things like Rubik's Cubes and The Sims, which geeks would argue are toys.

Anyway, games are pretty much rules with parts. It is up to the other players in the game to provide the competition. The game, itself, usually doesn't provide any competition, aside from getting screwed by a bad random event. The standard bearer for this seems to be the "Settlers of Catan bad dice roll syndrome." But even that, I don't really consider to be "competition," the game is just doing it's thing; it's not out to get you. That's the odds.

To make a long analysis short, since board games really can't do the artificial intelligence (coming up with a battle plan or strategy based on player actions) like a computer game, it's generally hard to pull off any some of semblance of "Game versus Player." But they can do something that I have termed, for lack of something better, "Automatic Intelligence" (or a.I. for short). This is basically where a game is pre-programmed, or in the case of a board game, somehow designed, to get harder or more challenging as the players progresses. Since the game can't do much in terms of creating alternate stratagems to whatever the player is doing, all it (and it's designer) can do is make educated guesses that at certain points in the game, the player will be at a strength of X and therefore the game needs to somehow combat this at some level.

To be honest, I can't think of too many competitive games that actively work against the player(s) using some sort of a.I. mechanism. The few examples that I can think of would be the co-operative Lord of the Rings game and it's sister Beowolf (with it's funky 3 paneled folding board), and strangely enough Prince of Florence. I'm sure there are others, and people who are much more versed in many more games than I can come up with them. Again, since most games are designed to be player versus player, there's really not much reason to spend time and effort on a.I.

In the PoF case, the a.I. mechanism is the ever increasing minimum value that a work of art must need to be completed in that round. One of the things that strike me most about this part of the game is this: I can't fathom a reason as to why it's there. Winning games of PoF HAVE to include creating art well above these minimums. I assume this fixes something that was found to be broken in the playtesting at some point. Since you have a limited amount of actions to use to create artwork anyway, just whipping out a bunch of crummy 5 VP creations is a path to failure. I'm left to ponder what happens to the game if you just don't follow that rule.

Beowulf does a really good job of implementing the LotR mechanic of collecting and playing cards along a definite path, but turning original game on it's ear by making it competitive auction game. It uses a.I. well, as various auctions get more interesting as time goes on, leaving players with a lot of decisions regarding "Do I play these cards now, or get bloodied now while holding on for future rewards."

I have trouble including LotR in this list, as it is co-operative, and strangely enough, it usually becomes somewhat of a solitaire affair, with one player making all the decisions for everyone. As a solitaire game (which again, it often turns out to be a solitaire game with three friends helping hold cards for you), it is a pretty fascinating usage of a.I.

Which leads me to this...

Solitaire games, I feel, need some semblance of a.I. to make them have any kind of fun. Just doing something and then rolling dice for some random event doesn't seem to cut it, as a player can't really plan against pure randomness. The player needs to have some feel that he can control his destiny against the game with some amount of strategy. Something logical.

A lot of the design in PocketCiv went towards the Event Cards to make it seem like there was something evolving in the world around the player, that within the randomness of the card draws, there was some logical plan to the chaos. Looking at an excel sheet of all the cards, one can see a progression to the events.


Early Eras have fewer Events, hopefully allowing the player to get a foothold into the game. Later on, Events come nearly every turn; hopefully, the player has built up the resources to protect him from them.

Additionally, the types of Events change over time. Early Era Events are mostly natural disasters, with a few Visitations thrown in for good measure. As the game progresses, so do the Events, in their complexity, the damage they can cause, and within some amount of relationship to where the player should in his civilization at the time. Additionally, the scaling of the scalable Events also helps the game keep up with the player as he grows more powerful, but that's a more obvious effect.

Just throwing dice and looking up Event XX wouldn't be the same. Getting dumped with a Civil War before you have a chance to actually HAVE civility doesn't make much sense.

Actually, the whole Event concept, as originally created in (and, I admit, borrowed from) the grand-daddy Civilization is a nice example of "a.I.-lite," in that it does a good job of throwing out the desired calamities into the mix as the players advance. The rule about secretly trading the calamities to other players somewhat lessens it's a.I. usage, however. Even though I think that themewise it works; as a civilization trades more with other civilizations, foreign ideas can pollute the nirvana that was once a well planned group. But isolation is hardly a good answer as outside ideas and trade also can help foster ideas and speed along civilizations in many ways. So, you take your chances, I guess.

Which brings us to Leviathan. The game as it stands now, in it's simplest terms, move to a sea area, and then see if there are any ships that you can attack. It would be reasonable to simply just roll some dice and look up some ship data in table.

But I want the game to have some intelligence. It needs to have some a.I.

I want the player to have to reason to move about the board, to move to different areas. In order to make this work, I need to have the Fleets change their locations during different parts of the game. Weather and seasonal changes give me a logical reason to do this; during the Winter, ships travelling across the Altantic (especially in the north) will be few and far between, and ships will most likely follow the coast lines; in the Summer, voyages crossing the Atlantic become more plentiful.

I want the game to start being more aggressive as the player become more powerful, and if enough Tales reach land about the fearsome beast that lurks in ocean blue, I want the game to be actively searching for the player.

And, at least for now, here is how I am doing it. Of course, at any point I can change this, but this is my first pass at making this all work.

The Discovery Phase

The Discovery Phase is derived from a small deck of Discovery cards. Each card of the Discovery deck shows all 7 areas of the Atlantic Ocean that the player can occupy. Each card has a different psuedo-random order to the ocean areas. In order for me to better "control the randomness" of the game, ocean areas that are more northernly tend to hang out at the top of the list on the card; southernly areas tend to be on the bottom.










Additionally, there is a Discovery Board (labelled by Years) that Discovery cards will be placed on, one per turn. The placement of the card moves one notch over for every turn. When a card is placed, a player can look up data from the board that is directly to the left and right of the ocean area the player currently occupies. As the player progresses through the board, the type of data changes, simulating the changes that the "world" would be experiencing during those seasonal changes.






The data itself is two codes (a letter and a number) which is derived from referencing the current ocean area that the player is in. The letters determine a Weather Event, or a fleet's Port of Origin and Destination, and the numbers determine the size and strength of the fleets that the player will interact with. Much like the Discovery card and their "sorted-randomness," the data on the board points to Ports that roughly correlate to Northern-to-Southern Ports.

A lot of this organization of Northern-to-Southern stuff has to do with trying to make sure that there are no goofy weather conditions, such as snowstorms in the Carribean, and to make sure that Port Destinations and Origins also make some reliable sense, such that a fleet wouldn't be travelling in the North Atlantic while going on a route from Port Royale to Sierra Leone (a typical southernly route). However, there is enough random slop in the system to keep it from being too predictable.

So, if a player is desperately trying to get more Tales (Tales are the main point system of the game, which are awarded when you take down ships) in Halifax, he can make some informed decisions as to when, and where he should be for his most likely chance of success; but there is no guarantee.

While it's a confusing system from a design standpoint (and involved a lot of excel charts to figure out "the math" behind the numbers), to the player it should play fairly straightforward:

1. Draw a card, place it in the "slot" of the current turn.
2. Based on his current location, look up the letter that is to the left of the card in the Ports Chart to determine the ports of Origin and Destination for a Fleet (I'll describe the importance of ports of Origin and Destination in a later post). Place the appropriate Origin and Destination markers on the map as a reminder. Or play out the Weather event.
3. If he has found a Fleet, look up the number on the right side of the card (again, based on the player ocean location) in the Fleet Chart, which will reveal the composition and strength of the Fleet, and then the battle may or may not begin.
   

But what does this really mean to the player?

Since the main point system is based on getting Tales "told" in Ports. A player's score is, right now, derived from the port with the LOWEST amount of Tales told. So players will want to naturally target fleets that come and go from all Ports equally, as getting a lot of Tales in one Port is worthless if another Port has zero. However, all Ports are not treated equally due to seasonal adjustments (and, well, map locations). Hopefully, the player can latch on to this, and learn to best adapt to the a.I. of the Seasons to help him focus on the Ports where he needs more Tales. He will need to learn to naturally migrate with the seasons.

At least it is my hope he will.

Catching up, Part 2

Well, I finally managed to update PocketCiv with the new "scalable event" Event cards and rules. Sadly, this completely breaks the walkthrough scenarios; I'm not sure if I want to go through that pain again (which is the right thing to do) or just blow them off and forever remove them from the server. I just don't have the time to update those with my other plans for my short hobby hours.

And I've finally caught up posting all of my scans for My Budding Artist, my blog for my 3.5 year old daughter and some of her drawings. I thought this would be interesting to track her progression from completely random scribbles to, well, less random scribbles. However, if she keeps up her interest in drawing stuff, it might actually have a real nice progression over many years. And I'm starting to fall behind on the scans again...sigh.

Finally, my whole priority list has changed again in terms of design projects. Once again, I'm going forward with Restless, only because I now have a pretty solid foundation for how I want to test it out.

Restless started out originally as a complicated "choose your own adventure book" kind of thing. You move pawns around on a map, you looked up a chart that cross-referenced what turn it was with where you were, which then got you to a list of book entries which you had to choose from based on how many players were in that room. Those entries were FURTHER expanded to other entries based on various player stats.

It became quite the headache to keep this entry chart staight with all these cross-referenced numbers, affectionately called "the database."

This has been an off again/on again project for a few years now, I've had about 30 "beats," or major elements to the story outlined out. Not to mention my various false starts with it. At one point, I've gotten about 40% through the game over a few months, took a break, then came back to it,and had no idea where to continue it from. It's a game that really needs a strong focus to wrap one's head around the creation of, apparently. Mostly, due to where I was in the database, and how far I had gotten on the various story threads, things got quickly off-track.

Well, some friends of mine have been big on goofy "tear away a page caladars" recently, where each day gives you a new factoid, or questions to answer. Which got me to thinking that this might be a way to go with Restless by make each turn calandar based. But it still had a lot of database issues regarding entry numbers and such. I've just changed the mechanism for what a turn is.

But then I got to thinking about trying to create a weblog game [edited to nando's liking, and the correct terminology], where each day you could go to a blog, and then get your instructions, or game state changes. Html becomes a perfect replacement for the database. Sure you need to keep your links straight, but I don't have to deal with hundreds and hundreds of entry numbers scattered around in a book.

Also, the blog format lets the people I know who I chat with everyday on IRC play together (well, I hope they try it out), without having to create physical books for everyone.

Anyway, I'm currently building this, getting my feet wet in terms of formatting room descriptions and such. I'll probably turn it on after I've got 8 or 10 turns linked up, just to see how feasible the game is, and then determine if I want to continue it from there.

Anyway, I've got a starting point now, and a pretty good direction. You can check out the eventual home page here (now with rules!).

Poor, forgotten Smoking Barrels...

Catching up

Now that the holidays are over, I'm starting to catch up on a lot of things; hopefully I can get back to designing things soon.

One of the things that has slowed me down is the "art game" known as Exquisite Corpse. Basically, someone draws a 460X200 pixel image, sends it in, and then the Corpse Engine sends out the bottom 15 pixels of that image to the next artist, who must continue the picture only with the information provided in that little 15 pixel strip. And then, he turns in his 200 pixel high image, and the process repeats.

It plays very much like an online party game. Which, makes sense since it pretty much is an old party game.

Aside from the occasionally amusing and/or shocking reveal of the entire image at the end when all the absurdities come to light, it is a rather simple exploration of the collective unconscious. This basically states that there is a shared psychology amongst all humans in all cultures. A part of the game is trying to understand what the previous artist was doing given only that 15 pixel sliver of information, as the best Corpses seem to be the ones that carry a similiar theme through each artists' panels. Therefore, there is some sense that all of the artists shared a common psychology on a particular piece. Recent examples that seemed to fall into place like this would be this one (regarding theme) and this one (regarding color usage).

Of course, you get the opposite results more frequently. Especially with some artists who don't quite get the concept of trying to match the seams with the previous players. And even still, this image comes across as a sort of cool, movie poster image.

And looking at a group of these pictures in an archive format is pretty dazzling, with all the crazy uses of color and images and just general looniness.

Anyway, my most pressing game design goals right now are to get the updated PocketCiv rules and Event cards done, followed by finishing a prototype of the newly-named Lumina Dark (I've got a half-baked rule set stsuck in my head). Finally, I really, REALLY want to work on a Leviathan themed solo game next, spurred on by this BGDF discussion.

Man, that's a lot of links up there. YAY! for hypertext.

And the Results are in...

Well, there really aren't any results, or anything. After getting enough feedback from people who've played PocketCiv, and my experiences, I'm going to have to do some tweaking on the Events cards. Most noticably, making things scale a little better.

Currently, all the Events have "set in stone" look up numbers. That is, an attack from a visiting Empire will always have an Attacking Force equal to the value of blue hex on the next card time 2. These numbers need to start off smaller in the earlier Eras, and be a bit larger in the later Eras, as I'm beginning to find out, as I've always suspected, that usually the first Era or two are are pretty tight struggles, but when you get your machinery going, and survive the first Era, life gets a lot easier.

This isn't a bad thing really, on the short cusp of it. As I'm sure this is how civilizations developed naturally; it took a lot of luck for a fledgling group of people to build up something from nothing. However, it does suck that drawing the last card for the first Era simply nets you an invasion force so overwhelming at that stage of the game, that you have no real chance of recovering from it.

So, I've pretty much decided that Visitations will scale up as the game goes along. And I've got a pretty simple way of doing it with more symbology on the cards, so that's not an issue. But then, I start thinking, "why can't I scale up all of the Events that make sense?"

Well, there's no reason not to, so i might as well go that route. Aside from all the little trickle down changes that this will change.

Anyway, this will take a little bit of time in Excel to mess around with numbers I'm happy with. Thankfully, this doesn't change any of the work I've done on the main scenarios I've worked on. But it does change the walkthru scenarios greatly. I'm not looking forward to re-writing those. And the Event cards will naturally have to change.

Not particularily fun, but hopefully something better comes from it.

Interfaces

Even though I don't think many people consider board games to have user interfaces, technically they do. It's the components themselves. The parts are the things that the connects the players to the rules. When games are considered to be "too fiddly," that's just another way of saying that there's too much stuff on the interface. However, whether that's because there's too much needless stuff, or too many rules, is another issue, one that's primarily left up to a player's taste, for the most part.

I'm pretty amazed at some of the awful interfaces people have designed for various uses. I've seen gas pumps with a START button nowhere near the rest of the button panel, for example. Not very intuitive. There's quite a few websites that deal with bad/good interfaces which are fairly interesting to read.

In boardgame design, however, I think that most interface issues seem to fall into place fairly quickly during playtesting. You see very few games with insanely stupid interface decisions. You are more likely to see some bad interface designs brought on buy cost considerations more than true design thinking (or non-thinking). Such as using non-language dependant symbology for cards. It might look cooler, but having readable text that you understand sure helps a lot; however, if you can bring your cost down by only having to do one print run for the whole world of components, so much the better.

Anyway, where all this is going, is this: Someone emailed me about PocketCiv (which is becoming a lot less pocket-ful as I go, due to the work I'm putting in on the deluxe version), and wondered about the counters I had made for the City Advances (the red and blule counters in here). Basically, the question amounted to why i decided that each counter is a +1 AV counter that needs to be stacked, as opposed to simply having counters that get swapped out that said 1AV, 2AV, 3AV and 4AV.

I had considered this at one point. But when playtesting, I found that I sort of enjoyed the stacking aspects when a city gets built up. Aside from being visually pleasing, I didn't need to have to go searching for a specific tile with the right number on it, just grab another AV chit and stick it on top. And if an AV got reduced, simply pull one off the top and throw it in the pile.

Swapping of chits os sort of messy, since you have to search for the right chit that you need, and then remove the old one, and place the new one i the right place. The old chit being removed would presumably have to be placed in an area that you would have to remember where it was in case you needed to swap them out again. Not that this is REALLY a brain-bursting or Operation! twitchy physical action or anything.

In addition, anytime a player changes the state of a board, you are always prone to the player somehow accidentally whacking something that was not meant to be moved. Swapping tiles seems to complicate these issues a fraction more, since you are moving things at the board level. Stacking and unstacking tiles are slightly above board level, and is only one action, reducing possible whacking time.

Of course, there's always the condition that you now have stacked stuff that can fall down while you are moving other pieces around. So it's not THAT foolproof. But, hey, you go with your gut.

The Living Document

I've been sort of surprised by the amount of time PocketCiv is taking. But then again, not really. Maybe, due to that fact that it's more of a system than a standalone game, it's sort of taken on a life of it's own. And therefore sucking out a lot more than I thought I it would from my spare time.

One thing seems to just lead to another. While I am fairly happy with the way the basic PocketCiv works (even though I think I've failed to make it truly work while ON a plane), the game itself WORKS pretty nicely as a pasttime. I've actually managed to survive all 8 Eras while waiting for a delayed plane.

Anyway, I start working on making graphics for the Deluxe version (the boardgame version), and then I get to fooling around with creating specific scenarios. So, now, all my playtesting time has been taken up with Scenario creation, and graphics creation.

One of the nice features of the Scenarios, however, is the ability to lead a player through the game initailly without having them read the book (ala the first few round of a video game that introduces features as it goes along). These took quite a bit of time. The regular scenarios are easy. Too bad THEY need testing.

And now that I've got solid, mechanical, boards and peices, I'm mentally puting together a 2 player version...

There's not enough time to feed the Beast.

Anyway, if there is ANYONE out there reading this, feel free to at least playtest the basic version. You might have fun. Honest.

PocketCiv Event Card: Visitation

The Visitation card for PocketCiv:


The event gives you the name of the Empire that is visiting you. From there, there is a small amount of "follow the tree" down to get to your ultimate results, which is either doing a Trade Actioin, or an Attack Action. Visitors can either come in peace naturally, or come to pillage, however, if you have Diplomacy, and enough of a donation of gold, you can turn them into a Trade Partner, forever making a visit from this Empire an opportunity to do a Trade Action and avoid the nastiness of having your villages and damsels pillaged.