Math Can Be Annoying

In Lost Cities you have this wonderful scoring event that happens at the end of the game. There is nothing better after a fun game than taking a math test. It helps to have a pencil and paper handy to calculate your mess of a score. You have to sort through bases points, penalties, multipliers, and bonuses. Recounts seem to happen more often than not. All in all, this is a clunky system.

Here comes Keltis, which is sort of a reworking of Lost Cities. You still have all of the math, but it has been cleverly baked into the game. As you move your token, it magically does the math for you. At the end of the game, all you have to do is add some simple numbers together, and viola! you have your score!

Math Can Be Anti-Climatic

Ticket to Ride requires you to track your score as you lay tracks. The rules could have been written such that the players add up their score for tracks at the end of the game, since that method is equally as valid. The big difference is that the end game would be so full of addition that the finals scores would be anti-climatic. Thankfully, the current system lets the player after laying tracks to just move their score token by counting the spaces out or adding two simple numbers together.

Math Can Be Easier

Whether or not this was intentional, I like how in Through the Desert (and probably countless other games) the math is smoothed out at the end of the game. Through the game you collect all of these small valued scoring tokens. Then at the end of the game, you get bonuses for enclosed areas. Lets say you score 7 points for an enclosed area, you would take a 10 pointer and return 3 of your small tokens. After you do this several times, you are left with a lot of 10 and 5 point tokens and fewer 1,2 and 3 point tokens. When it comes time to score, it is a lot easier dealing with adding up units in 5s and 10s than it is dealing with 1s, 2s, 3s and 5s. Its a small thing, but I really like how the math feels like it has been smoothed out for me.

What Did I Learn?

In my game Venture Forth I’ve taken some actions to reduce the amount of calculation that occurs at the end of the game. The game didn’t have a ton of adding, but I wanted to add more scoring opportunities and that was limited by the current method of scoring.

Firstly, I am introducing a score track – nothing too innovative here. When you get points, you move up on the track. As simple as this is, it is one of the best ways to keep track of score and it allows players to gauge their rank.

Secondly, I am removing an equation from the game. This is not something I actively sought out to do. It just occurred because of other changes that I made. Once it was gone I noticed how smooth the scoring looked. Basically, if your adventurer had less “points” than his “power”, then you got a penalty. Now, if your adventurer has “tokens” on him, you get a penalty. What I did was took out the comparison. I know this is a simple little thing hardly worth mentioning, but it does illustrate that math can be moved around. The comparison is still there and the game plays identically, but now you just have to glance at the board to see if you have any penalties rather than to do some quick math.

What other games have math smoothed out?

Jun 262008

Dan and I met Tuesday night for play testing. We each brought a new game design to the table. Dan had a dice game based on the video game Rampart. We each had a Castle and had a stack of gold placed inside. We were able to build up the walls to our Castles, place attacking ships around our opponents Castle, blow up walls, and steal each others gold. While the game did not really have an end condition, it played very nicely. On the first round I was not very excited about the game play, but by the end of the 3 round I did not want to stop playing. While there are a lot of dice rolls in the game, there are also a lot of decisions about how to use them and in what order you need to attack the different sides of your opponents Castle. Dan indicated that this was just the core mechanics of a larger multiplayer game. Dan talked about some really cool sounding additions to it. I’m excited to see where the game goes, and I look forward to playing this again with 3 or 4 players.


My new game is essentially a light Galactic Empire Building game that has a Flicking mechanic to it. The game should scale for 2 to 4 players. Each player controls a faction of humans that have fled their own galaxy for fear of a seemingly unstoppable alien race that is bent on their destruction. After arriving in this new galaxy the refugees discovered ancient relics of 4 alien races that have long ago disappeared. The faction that develops the most new technology based on the ancient alien relics will establish the foundation of the new Human Empire. There are 24 world discs that are spread across the table. Each world disc has non slip rubber backing so they don’t move around. Players will move from planet to planet by flicking small starship discs. Also, starship combat is accomplished by a simple flicking mechanic. There are 4 different types of Technology that can be developed and each type has two different abilities (now 3). There are two different types of buildings that can be built: Research Facilities and Planetary Defenses. The game also did not have an end game condition so Dan and I played about 12 rounds. It played very well for a first prototype. There really seemed to be no reason to build Planetary Defenses, and every time I built a Research Facility Dan would take it over because it was cheaper than building his own. I focused on building up Technology while Dan focused on spreading out and Occupying Worlds. When we stopped playing Dan had about 28 points and I only had 3 points. I have tweaked the scoring a bit so it should be a bit closer next time.

Jun 112008

Last night Ian, Jon, and I met.


We started a bit differently by chatting about games on the couch. We talked about our games being published, and all of the details that go along with that.

Ian told us about his newest game idea involving dice, Chun-Li, and fireballs. We were very taken with the idea of a Street Fighter-based game, and Jon and I were spouting out ideas left and right.

The topic of designing to prevent cheating came up when Ian mentioned using dice behind a player screen. Jon said one of his biggest pet peeves was when playtesters ask: “How do you prevent the players from cheating?” He said that cheater will cheat regardless, and there’s no reason to work to stop them. I was concerned with unintentional cheating: accidentally giving the wrong answer in Mystery of the Abbey, or not following suit when you have one in you hand, or, in Ian’s example, accidentally manipulating some game state (dice, score track) that is behind a screen. Those actions can derail a game sometimes. I think we all agreed that taking the time to consider these problems is worth it, regardless of whether or not we fix them.

Haunted Destinies

Knowing that the night was slipping by, we decided to head to the table and play Jon’s game Haunted Destinies. It was a deduction game, but it lacked deduction. It was more in line with a “stab in the dark” style of detective work. The players had to determine who the bad guy was by revealing cards from the individual player’s decks. If they saw the bad guy card, then they knew how to proceed to victory. This sounded good when Jon described it, but I felt like it was a slow process. With 30 some cards to look through, a player may stumble upon the bad guy right away, or, through no fault of his own, not find the card until he sees everyone of them. Actually, that isn’t entirely true. In a three player game, the maximum amount of cards you actually need to look through is 2/3s of them because if you don’t find the bad guy card in player 1 and player 2’s decks, then it must be in player 3’s.

The revelation part of the game was, for me, the part that needed the most attention. The other parts of the game, however, were actually very clever: Eliminated ghost players, and making setup of the board into a mini-game. I hope Jon continues to refine this game to make all of the mechanics shine.

May 272008

Back in the earlier Internet days, about a dozen ago (that’s 1996-97-ish, for those of you who are either math-addled or from the future), I had fancied myself a bit of a web game developer. I had a website with couple medium-sized multiplayer online games, your standard strategic exploration and combat and tech tree stuff, one about cavemen and one about nanotech spaceship-clouds. Maybe had fifteen thousand registered users, give or take, which for the time was pretty decent. It was all old school play-by-web, with frames and javascript and database-driven Perl CGI backends and whatnot – all pretty gnarly and poorly maintained, and it all eventually collapsed under its own weight after I lost interest after a business deal fell through and I started to focus more on my day job, which was basically the same thing, only for clients who actually paid us.

I’d never try to resurrect those exact same games – the designs were clunky, the code wasn’t anything to be proud of, and the old player base is long, long gone – but I’ve still got design documents in various stages of decay sitting around for a good half dozen totally decent web-based games that could be thrown together, given a bit of care and time. A little bit of playtesting and polishing here, a chunk of content generation there, spray the Rails hose at it, and voila. Sounds reasonable enough. Unfortunately, as a freelance developer, overbooked stage performer, and relatively new father, most of my billable and non-billable hours are spoken for, and most of my game design time is directed towards the tabletop side of things. Also, the landscape is much different now than it was then – there are hundreds of browser-based games out there, many of them possessing much greater polish and love than I could ever hope to give them, unless I quit my life or something. Still, the projects are on the stack, and someday, they might get gotten to.

But, that’s not what I’m here to talk about. I’m here to talk about something that I don’t think I’ve seen yet, and if I’m not able to make it happen right now, I’d love to see someone else try it out. So, off into the collective consciousness we go: I’d like to see a set of web-based games that are totally different play-wise, theme-wise, and other-wise, but all their players operated on the same set of data that described the world, and the resources in it. So, say, you’d have one set of players flying around, mining asteroids and fighting aliens and space pirates in your typical 4x/Elite-style galactic trader game, another set of players hacking away at monsters in a fantasy world based dungeon crawl, another bunch of players fighting over city blocks and illicit businesses in a gang war game, and maybe another set doing something interesting in some stock market financial simulation thing. Or whatever.

But! When players do stuff in one of the games, it doesn’t just affect their game world, it becomes part of all the others, too – all the games work on one big database, but they all provide radically different views and available actions on that world data. So, your gangland activity in one game generates the monsters that the dungeon crawlers fight. The trading of goods in starports across the galaxy and the selling of loot in medieval towns are reflected in the stock exchange in the financial sim. The players that become leaders of the Mages’ Guild in one game are portrayed as mob bosses in another. A shrewd investor cashing in a bunch of hot commodities in one world causes a medical emergency for an outpost on the galactic rim. You could even hook generated game data into real-world sources like weather patterns, the actual stock markets, RSS feeds, twitter chatter, all kinds of fun stuff. There are so many ways to weave totally different game worlds together, and the really fun part is, you really wouldn’t have to tell anyone about it. Players on one web game are the alien menace in another, and nobody knows except the admins – until the day that the master plan leaks, which leads to all kinds of awesome.

Sure, there are some technical and design challenges involved with a scheme like this, but in my mind, totally worthwhile ones. Who knows – maybe this is already happening, and the veil hasn’t been lifted yet. And I guess I’ve blown my cover already, so if I ever do get around to doing something like this, it’ll come as no surprise. Still, potentially fun times ahead. Keep watching the skies.

May 192008

Over the weekend, I realized an important aspect of suits in game design. They restrict options and therefore increase tension.

Imagine a game of Lost Cities where all of the cards were of the same suit and they could be played on any expedition. Now instead of a 20% chance of drawing the suit you need, you have a 100% chance. The discarding aspect of the game would be pretty pointless. In short, all of the interesting decisions go out the window.

This seems pretty obvious in retrospect. In fact, I’ve added suits before to games for that very reason. I guess I was just oblivious with my perpetually undone game, Venture Forth, which was lacking suits. The game gave you lots of options, but ultimately felt flat. I added suits yesterday and all of a sudden the tension in the game started to come out! Behold the power of suits!

May 072008

Last night at our design meeting, I mentioned a game that I thought related to the topic at hand. We were discussing designing a game with a space ship control panel, when I remembered this game called Wormhole that had that very thing.

According to the entry on

‘Wormhole’ by is a tabletop space combat game which promises an affordable yet paradigm shifting gaming experience. Taking the “virtual board game” concept to the bleeding edge; instead of forcing overpriced lead miniatures on players Wormhole offers a complete fleet of high quality 3-D models that you print and build from your home printer. This feature alone gives players the opportunity to build massive fleets without breaking the bank.

Wormhole promises “cinematic” space combat with visual style and presentation not yet seen in the genre. Rules are easy to understand but offer a scaling level of depth for a variety of play styles. Wormhole also introduces an interactive damage and orders system which removes heavy book-keeping tasks and replaces it with a “control panel-like” interface (you feel absolutely in control, barking orders to your fleet). A number of unique gaming elements conspire to make Wormhole a truly immersive and completely original gaming experience.

Notice how in the top right picture how the panel is modular!

I don’t know if it is just the lighting, but this looks awesome!

And here are the ships you actually play the game with.

After a hiatus, we returned to meeting last night. One activity we partook in was to come up with lists of board game titles. We then exchanged them and tried to describe the game that came to mind. Below is the list of game titles that you may one day see at a game store near you:

  • Longest Beard
  • The Missing Pocket Protector
  • I’ve Never Eaten So Much Licorice in My Life
  • Leptoglossus
  • The Happiest Alligator
  • Drunk on Christmas
  • Whatever Ian Wrote
  • Don’t Drink the Milk!
  • Mrs. Bossman
  • Oubliette
  • Space Hemorrhoids
  • Knizia Takes a Dive
  • Emo Factory
  • Llama Race
  • Euthanasia: The Game
  • The Hand of Solitude
  • Gordon’s Waffles
  • The Land of Cyclops
  • The Bloodstorm
  • Night of 1000 Sores
  • Robot Detox
  • Omelet of Disease
  • Crossbow Cows
  • Turtle Trance
Mar 062008

My first full fledged attempt to design a game started about two years ago. It began when I read a description of a game on some webpage. The game was Light Speed by Cheapass Games. The game sounded awesome. So awesome that on my lunch break that was all I talked about. In my mind I had this image of an epic space game that took place in real time but had elements of strategy and lots of theme. There would be abilities, commanders, and many kinds of space ships that had different capabilities. The description did not talk about these things but I knew that a game this cool would have to have this stuff. I went to my local game store later that night and what I saw hanging up in a little zip lock bag shattered my dream of an epic real-time space battle game. I bought it, took it home, and played it with my wife. It was certainly not the game I wanted it to be. For what it is I think it is a cool little game. Just not the game I had imagined.

The next day at lunch I told my friend all about the true nature Light Speed. That’s when Kendrick suggested that I design the game that I had described to him. What a simple idea, design a game. I knew exactly what I wanted it to be like. I had already tinkered with one other board game design, and I had a growing collection of 3 modern board games in my collection. So how hard could it be? Well that was about two years ago and its still in development. But my game collection is now about 100.

It only took me about 3 days to get the first version of the game ready to play test. I had two very close friends that I had been playing games with for years. So I enlisted them to be my play testers. Our first play test of the game was a lot of fun. At the time I thought it went great. The game had many issues, but it worked. My two friends play tested the game with the same competitiveness reserved for tournament games of Magic where there is money on the line. I later realized that this is not the best way to play test your games.

I had the basic design for the game so I started to develop it. Of course, the more we played the game, the better we got at it. This meant the game got easier so to keep it interesting, I added more elements to the game. After about 200 plays, many revisions and tons of additions to the game I believed it to be done. My friends thought it was awesome! It was a game that required both speed and strategy to play. It was epic. It was thematic. What I failed to realize though, was that I had inadvertently designed a game that only we could play. We thought it was easy to play, and for us it was. We had over 200 games worth of practice. But it was way too much for a beginner to learn. I could teach it well enough but most people thought it had too many things going on at once, so I put the game on hold.

A few weeks ago I decided that I was going to dedicate the next 8 months to working on expansions to my game Taktika. Even with that goal, for some reason all I can think about is working on Galaxy in Flames again. My goal for the rest of this month is to finish developing GIF. Dan and I play tested the newest version of it Tuesday night and I think it went very well. I’m excited about the game again. Maybe I can even finish it this time.

Feb 262008

Tonight we will be able to continue with out weekly design meetings on our regular night and regular time. I’m stoked!


I have been playtesting Stellar Underworld at my local game store and with other gamers here and there. At one of those playings, I had one especially “thorough” playtester who offered more advice than I expected. I knew we were in for a rough game when he questioned my decision to include almost every aspect of the game. Why do we start with two of these? Why not three? Why not have an ability to do this? or that? Now keep in mind, a lot of these comments were before I was even finished explaining the rules. I was getting frustrated pretty quickly, but once the game got going, it settled down a bit. After the game, and after I had a few days to think about his comments, I realized that there were a lot of kernels of truth in what he had to say. The thing that stuck with me the most when he rolled his eyes a lot when I explained certain rules. To be more precise, it was the exceptions to those rules that were the problem. Thats when I realized that my game was full of exceptions.

For example:

  • You can use one henchman to transfer a cube into your warehouse, except for the first one each turn which is free.
  • You can use one henchman to trade a cube with the black market, except for the first one each turn which is free.
  • The starting sector is just like every other sector, except you can only take two cubes from it, it doesn’t replenish, and it starts with two cubes per player.
  • Cubes next to your ship as considered aboard your ship, except when your ship is at a sector where they are considered available for pickup.
  • Abilities can be used any number of times, except for the cantina ability which you can only do once, and certain sector abilities.

There are probably more, but these are the ones that jumped out at me. Exceptions are ok in small numbers, but in larger quantities it makes the game more difficult to follow for new players. My goal now is to weed out some of these exceptions, while retaining their original purpose. So far, I’m having luck at some of them, but others are kind of difficult. It is a three way battle between simplicity, gameplay, and theme. Hopefully, they’ll all be winners, and I know the game will be better for me having taken the time to put this problem under the microscope.

I’ve been revamping Space Port lately to fix some issues with the game. Actually, I’m revamping it to allow for more design space to fix some issues. Here are the changes:


The first change I made was to the currency system. In this universe, I used StarCreds as the money of choice. It was a name made up during one of our improv game design sessions and has been a running joke ever since. The problem with StarCreds is that is just a simple system. You gain StarCreds through certain actions, then you use them to pay for other actions. Basically, they function just like any other currency. As I was looking over ways to create more design space, I saw that the StarCred wasn’t pulling its own weight. It functioned as just a number. It was always just in a range of zero to some unbound amount. My idea spurred from the desire to inject more information into this mechanism. What if the used StarCreds didn’t go away, but just stayed there in a “used” state? What if there was a limit on the number of StarCreds you could own? Bam! That’s when it hit me.

To make sense of what I was about to do, I rethemed the StarCreds from currency to Henchman. Henchmen are just like StarCreds except they have a binary state: active or inactive. When you would gain a StarCred, you now activate a Henchman. When you would pay a StarCred, you now use (deactivate) a Henchman. New actions also have arisen such as recruiting a henchman, which is just taking a Henchman from the supply. New design space has arisen from this all over the place. There is now a limit on how many Henchmen you can have active at a time (Before there was no limit on StarCreds). You can increase that limit by recruiting (a whole new area to design with). Timing (my favorite game mechanic) comes to the limelight as now it becomes important when you gain a massive influx of “currency” because sometimes you have the room for it (a lot of inactivate henchmen), and other times you don’t (only one is inactivate). Also, the main use of StarCreds was to pay for loading goods, trading, and “borrowing” ships. Instead of paying for it, you now just have your Henchmen do the job for you!

StarCreds acted as another way to gain points at the end of the game. Each two StarCreds was worth one point. Gaining those points just happened, and there was no real thought involved. This scoring is now replaced by Henchmen which are each worth one point (active or not). To recruit a Henchman, you need you use two other Henchmen while at a Cantina. See what happened there? Using two Henchmen is the same as using two StarCreds. Instead of having two StarCreds left at the end of the game to give you points, you now have to make the decision to buy that point during the game. Of course, recruiting a Henchman has other benefits, so it all fits seamlessly together. Letting the player make the decision is what game play is all about.

Risk Management

Bad stuff can happen to you in the game and you just have to sit and take it. This was brought to my attention by Ian and Drey. We talked about the issue at length, but in the end it boiled down to risk management. I decided that by giving the player the choice to protect themselves at a cost, he can choose the level of risk he wants to take.

Shipping -The game is full of shipping. You can use your ships, neutral ships, and even other player’s ships. Other players don’t like when you use their ship even though the borrower has to pay for the privilege. The problem is that you can’t deny other players from doing this. The solution to this is to modify the cost system of borrowing. Now, the borrowing player uses a certain number of Henchmen. The ship’s owner can now deny them use of his ship by paying an equal amount of Henchmen. The ship’s owner now must manage his Henchmen so that he always has enough to thwart any attempts to hijack his ship. The hijacker must now carefully consider whether or not he wants to try and steal a ship because if his attempt is canceled, then he basically wasted Henchmen as well as a turn. Besides all that, with the new Henchmen mechanism, this oozes with theme.

Contraband - Contraband is the hot ticket item in the game. You never just want to leave it sitting on your ship or in your warehouse because someone else might play an inspection card which discards them. It was discussed that there be a way to pay for more protection for your contraband if you wanted it. So, the new system is that if you have two active Henchmen, your contraband is safe. No payment is necessary. Thematically, they just sit there and guard it. Of course, having your guys locked up to do this means that it will be difficult to pay for other things, but now at least you have a choice. I still need to playtest this a bit more, but I think it is simple enough to work.

Well, we meet tonight and I hope to test this out (and a few other changes). My preliminary testing last night made for some interesting plays, so I’m excited to see how it handles with more players.