Potemkin Empire Designer Dairy #3

I assure you this building is thoroughly and completely real. *ahem*

I finished a round of edits and cleanup on the Potemkin Empire rules last night — it’s still testing really well; every group to play it ends up getting into the sarcastic tone, and preposterousness of the theme, though I must say, when I first put pen to paper for this, it wasn’t intended to look so timely with current geopolitics. Hopefully that won’t be a turnoff when pitching, or selling to customers, if there’s a feeling that it’s just chasing some soon-to-pass cultural zeitgeist. But! The theme is too strongly baked into the mechanics to worry much about that now.

One test group at Protospiel was made up of several hardcore “card game”-type players; folks who seek out “drafting” games as a genre, or have committed to memory their entire Magic:TG and Shadowfist decks because they play those games competitively. This group was unanimous in suggesting that Potemkin Empire needed a little more ‘meat’ to the strategy; suggesting that instead of only having cards which caused buildings to be “fake” or “real”, giving those cards alternative unique non-standard actions to make the Drafting Phase more interesting. I was nervous this might be too many moving pieces for a more casual audience (I think a big swath of my target audience for this has never encountered “drafting” as a mechanic), plus… if I’m honest, designing and implementing something like that scared me. It seemed like a lot of work to make sure I had created “balance” among them, and how would I decide whether an action like “Recover a killed spy” should be attached to a card that, if used to build, would be a fake building, or a real building? Continue reading

“Award Winning” Game Designer

Once, in a group of other game designers working to get our first designs signed by publishers (i.e.: unpublished designers), someone asked “what do you all call yourselves, since you’re not published? I’m struggling with what to call myself when people ask.”

Ever the smartass, I quipped “I think all of us who design games should go with ‘Game Designer’. But once I’m published, I’ll transition to ‘Published Game Designer’, and hopefully soon after to ‘Prolific Game Designer’ ;)”

In that vein, I’m excited to belatedly announce, with tongue firmly in cheek, that I’m officially an “Award Winning Game Designer”

A while back, Atlas Games ran a design contest for games that used their Letter Head deck. It’s a quite clever deck of alphabet cards, with a cryptographic (English) frequency distribution of letter counts of cards and their point values. The effect of this is that almost any 5- or 7- card hand is almost guaranteed to have an English word in it. It’s a pretty fun effect when dealing out test hands. So I did some brainstorming and threw my hat in the ring.

I came up with a little ditty about Shakespearean wordplay, which I called Draw! Beat Down Their Weapons! And it turns out the contest judges liked it! I was one of the winners, and D! BDTW! is included in the downloadable content for customers who have bought Letter Head decks!


You can read about the contest, Letter Head, and access the PDF with all the winning designs here!

“Hidden Mechanics” in Video Games — and in Tabletop Games?

Last week, a video game designer I’ve been following on Twitter for a while now, Jennifer Scheurle posted asking game developers to post tricks they use to optimize for fun, versus coding a perfect simulation of an environment:

The responses were great, and the thread is being picked up by all kinds of video game press. Kinda makes me wish I’d chimed in when I saw the tweet come by amidst the political dumpster fire I generally consume on Twitter, though I don’t specifically have my of my own inventions to post about, so maybe just as well I didn’t. Though I have written about a couple related topics here previously.

The thread kicked off a discussion in a FlightlessCo Slack channel as well — my Terraformist collaborator who is taking the lead on game design for that project found it on Polygon and wanted to discuss; this being his first foray into this type of design.

I love these tricks, both as a designer and a player, but I think it’s telling that many of the responses are about single-player games; in a multiplayer PvP situation there are humans trying to have fun on both ends of the equation — and in a direct head-to-head, thumbing the scale for one of them might have a negative impact on the other. For instance, in Terraformist, a player sending a swarm of combat units against another can’t necessarily just result in warning shots ‘across the bow’ to get their attention, because then the attacking player may feel disadvantaged. Continue reading

Potemkin Empire Designer Diary #2

Opening gambit of an unassailable lead.

Potemkin Empire was one of the designs I took with me to Protospiel Ann Arbor earlier this summer; one of my newer designs. It’s been on the table a few times in a previous iteration that crashed and burned spectacularly. After rebuilding essentially from the ground up, I felt it was good-to-go for Ann Arbor. I’m trying the Joshua Buergel / Grant Rodiek method of iterating in public on this design; in case you missed rules google doc come through my Twitter feed, here it is.

The suits remain the same as the first iteration: Government, Espionage, Science, Culture, and Industry, and their relative impacts on the in-game economy also remain largely similar; government is for ‘first player’ and final points, espionage is for attacking, science is for advantaging building, culture is for protection from attack, and industry is a secondary avenue to victory.

The first tabling at Protospiel revealed a large “runaway leader” problem involving combos with the Culture suit. Shannon McDowell identified the value of Culture’s unlimited protection from spying, and built an unassailable lead in that suit. This also proved that “exceed the current leader by 1” is too drastic a hurdle for a second-ranked player to ever overcome a current leader in any suit. With the shield firmly in place, she bluffed her way into an Science lead as well (for an additional card draw / building opportunity each round!), then went on a building spree of point-scoring Government buildings with total impunity as the other players spied each other to death. Continue reading


What’s the ideal number of designs to be working on at a time? There’s a lot of wisdom in focusing on one single thing at a time, making it amazing, completing it, then using the completed project as a pillar to step to the next thing. Creative pursuits though, don’t always progress cleanly in a straight line from start to conclusion, so it often (for me) feels valuable to have additional ‘active’ projects waiting in the wings so if I ever run into designer’s block, or get frustrated trying to work through an issue, there’s something else to context switch to and at least make some progress, even when the primary project is in a bit of a furlough.

Splitting focus comes with all sorts of disadvantages — there’s an additional cognitive load even choosing which design to work on, given a free block of design time. Then each design is only progressing at 1/n the pace that could be possible with only one design as a focus. The marketing side also becomes more challenging — which do you talk about? Which do you blog, and send people updates about? The complexity compounds like a network effect with each added design in flight.

For many years, knowing my inclination to scattershot on a thousand different shiny things, I made a deliberate choice and clung tightly to the first approach — I only worked on Valour, anything else was a distraction, and went directly into the catch sheet, not into the brain cycles. It largely went well, though with some periods of extreme productivity, and others of frustration. And once I started shopping it around to publishers, I found myself in a strange spot; I would make new contacts at other publishers, and I didn’t have anything to pitch them, since I didn’t want to double-dip with the evaluations and risk burning bridges if one ended up signing it out from someone else reviewing.

So in one of these lulls, I started grabbing some other (smaller!) designs and making bits of progress on them as well, eventually getting one and then a second working prototype together. An awesome thing started happening, where I always had a prototype ready for a test when in an opportunity arose, and there was something to pitch while waiting on word about Valour.

Do these advantages counteract the negatives of a split focus?

I’m not sure, but I’m starting to feel like 3-4 is a good number of designs for me to have actively circling. How many designs do you have in flight? Do you find yourself more productive with more or fewer? Have you experimented to find an optimum? I’m really interested to hear the process other designers follow in this regard.

Protospiel Ann Arbor 2017

Take out that Storm Generator at all costs!

Protospiel Ann Arbor, the testing event that launched a thousand other testing events, is an easy stop on the annual circuit for me, (though I sometimes end up missing the anniversary party for one of my favorite Colorado breweries 😟), since I can combine with a visit to my hometown and the fam.

I’ve written about it before (maybe thrice), and got in a great set of tests this year as well — I got Valour tested, got a not-yet-public project I’m working on with Josh Sprung beat to hell, and got my new card drafting/bluffing game Potemkin Empire to the table twice: the second test was a great opportunity to shore up some issues that presented strongly in the first test. Fixed a runaway leader problem, and doubled down on the parts of the game players said were the most fun.

It really feels like Valour is rounding a final corner; the game only overstayed it’s welcome by one single Gaul turn this time, and a two hour playtest (Yay! Hit my target duration!) prompted a full hour of discussion among the players. Felt really good.

Josh and I also got some good news about an externality we were waiting on for our not-yet-public project, which I’ll either be talking about soon, or continuing not to talk about… So cloak & dagger🕵️🗡!

Now that we’re over a hundred words into this post, what I really wanted to discuss was the Protospiel “Karma” system, which, as you might imagine from a gathering of game designers, is a set of casual game mechanics governing how the event itself run. How meta!

The crux of the system (the primary resource, if you will…) is time; The economy of time is how it’s spent on your designs, and how your time is spent on others’ designs. Since that’s zero-sum on its own, there’s a little bit of give in the system, and it’s overall purpose is to prevent people from being total moochers, rather than landing in an exactly perfect balance by the end of the weekend.

An all-truthful build strategy in Potemkin Empire v2 is no match for a wildly imbalanced protection mechanic.

If you test a one hour, five player game first thing in the morning, (a total of five person-hours) you ought to sit in on other players’ games for the next five hours. Pretty rad system. And if you’re doing the math on  above and wondering how I possibly got all that in in a three-day event, and still came anywhere close to achieving a karmic balance, a secondary part of designer registration is that you can bring along free “tester” attendees — one day my dad came by to check it out, and play a few games, so his time in-game helps push the needle to balance out my scale.

It’s pretty cool, and seems quite equitable if everyone is honoring the rules. I’m working on gathering a critical mass of designers for a playtesting ring in Boulder, and if I get a group together, I’ll definitely be using a system like this to keep it fair.

Origins 2017 Roundup

I got back from Columbus (a tough destination for a Wolverine alumnus…) last week from the Origins Game Fair. Earlier in 2016, I set some ambitious goals for Origins with regards to ‘designs ready to pitch’. I didn’t hit every goal, but aiming for the ambitious targets ended up landing me in a good spot, further than I probably would have been without them.

Some highlights of this year’s Con:

First and foremost was meeting long-time blog reader become internet friend Conor McGoey and getting to play his debut game Summit — for sure the black sheep hit of Origins; every time I wandered by his table to get to the UnPub room, he was running another session with another crowd of engaged players. The production quality is top notch, the gameplay is great, and the whole thing has that je ne se quoi we’re all looking for as designers. The mountain is savage, without being disheartening, and the take-that is well tempered. Continue reading

“COVER ME!”: Convenient covers for things you don’t know how to do

This is a second little anecdote about game design I absorbed during undergrad, while studying video games, which I think have some crossover consideration with board game design. See the entry Bonus! for the first.

My takeaway from “Bonus!” was that even if you can’t make something work, or there’s a technical hurdle between you and your exact design objective, sometimes a little wallpapering over it with theme or dopamine can make for an even better experience for players.

The story related below is third hand, and so may be apocryphal. If anyone involved in the design choices described ever reads this, please reach out so I can correct my memory and set the record straight here 🙂

When the Quake series of games came out, they were a technical marvel. When the code was open-sourced years later, things were discovered in it that were still considered remarkable at that time. However, for all it brought, “bots” were still an incredibly hard feat to accomplish in first person shooters – there wasn’t a whole lot of “I” in the AI.

The Quake designers wanted to make it appear as if the computer-controlled AI bots were actually communicating with each other in coordinated attacks on player. Which, at this point in game development, was pretty impossible. At least by any standard we’d expect today. True, they were built into the game, thus they had an edge on the player, and could actually read perfect information about each other directly from the game engine. Their algorithms also had access to other shared information about game state, stored in system variables or registers. Continue reading

Socializing with a purpose

A few weeks ago, Andrea and I were sitting at a brewery discussing the ‘why’ of various things — when she asked:

“Well, how often do you stop to think about why you like the things you like?” and she threw out board games as an example. Luckily for the conversational repartee, this is a topic I have spent at least a modest amount of time thinking about.

To me, board games provide a framework for socializing, in a way that we don’t often get in our modern lives. Sure, it’s easy to have friends over for dinner, discuss the meal, catch up on each other’s jobs, or any of the usual idle chatter, but at the end of the day, I think we all feel, at least subconsciously, a little bit hollow in it, as the Eleanor Roosevelt quote goes: “Great minds discuss ideas; average minds discuss events; small minds discuss people.” And, I’m going to posit, orthogonal to this to create a space to analyze, is the idea that creativity is born of constraints. These types of gatherings don’t provide constraints, which can lead to a lack of creativity in the interactions. Continue reading

“BONUS!”: Clever game deceptions

I’m going to talk a little about video game design today, but think there’s a lesson in it for board game design as well.

3D animation frame.

A poorly-textured Josh plays cards… in an animation project for a different class. [1]

An anecdote that I think about at least once a month:

It’s my senior year at UMich, and I’m one of the apex classes of the computer science program “EECS 494: Computer Game Design & Development”. This was the class I’d been champing at the bit to get into all four years, because this is what I was hoping to do professionally after I graduated. I’d convinced a few of my nerd housemates to take the class with me.

One of our assignments was to develop an “arcade-style” game — simple user interactions, on the level of complexity of 80’s classics like Missile Command, Space Invaders, etc., to get a handle on concepts like ‘event loops’, ‘collision bounds checking’ and all that good stuff. I embarked on a JezzBall clone, and my roommate Josh set about building in the Bust-a-Move/Snood style.

Josh had built some data structure atop an C++ STL container, which he was using to keep track of all the “balloons” in the playfield. It implemented a clever formula for determining when three or more balloons were adjacent and should “pop” to score points for the player. There was just one problem. The code would occasionally glitch, and the data structure would “forget” about some of the balloons on the field. He’d narrowed down the bug such that his code could consistently determine that it had happened, after the fact, and it didn’t seem to cause a crash, or break anything else. Continue reading