:strip_icc()/pic954814.jpg)
/pic699168.jpg)
Like 95% of American gamers at Essen, I missed out on Hansa Teutonica at Spiel 2009. It looked like run-of-the-mill area control, and the artwork was uninspiring. I don't believe I gave it a second look at the publisher's booth, and absolutely no one at the show told me to check it out. When BGG.con rolled around a month later, there was some buzz, and I had an opportunity to play the game. When I did, I immediately snatched up a copy, and over the next few months HT become one of the most-played games in my collection.
Except that it just wasn't very good (relatively speaking) at lower numbers. With four and five players, it was excellent. But three had some issues, and two felt very tacked on. Other folks thought it was too long and over complicated. I still liked it immensely, however.
I was quite fond of other skill tree games like Goa and Pirate's Cove (well, the skill tree aspect of it, at least), and had several games of my own developed and shelved that had skill trees. Inspired by HT, I broke one of them out for review, tweaked it a bit, and sat down to play a few games with a small set of playtesters. It was a space-themed game with a complex resource management tree where the resources were used in combination to increase your faction's speed, cargo area, weapons, range, etc. But it still wasn't something I felt had immediate potential, so it was shelved again.
Recycling
/pic289188.jpg)
The most obvious re-usable piece from the game was a 52-card deck of cards, which had custom suits designed to be a turn-of-the-20th-Century style to fit the Victorian theme of Rapscallion. Inspiration hit as I was going through my game shelves and stumbled across an old favorite: Havoc: The Hundred Years War, a game where players use poker hands from a significantly expanded deck of cards (more suits and more cards in each suit) to "wage battles" against each other, with the victor of each battle getting more VPs than the next highest hand, etc.
Initial Designs and Modifications
The thought I had was "What if each time you played a hand of cards, you could increase your ability to get better cards into your hand?" I started with the ability to increase your hand size, then added the ability to draw additional cards into your hand each turn. Tracking your new skills was done with cubes, kind of the reverse way that HT was doing it, in an almost upside-down version of the Goa skill tree. Each time you increased a skill, you moved a counter forward one space to increase your score.
That was okay, and it certainly was moderately compelling, but it felt a little dry and was way too dependent on which cards you drew sight unseen. I changed the card selection mechanism so that players could select a card (or cards, if their skill was high enough) from a set of four face-up cards instead of a face-down draw deck. That provided some more interesting options.
Very quickly I added an additional skill that allowed the player to pick from the face-down deck as well, giving them the choice of either some of the visible cards or if there was nothing displayed that they were interested in, a shot at something better from the deck.
I then added irregular skill tree advances, in that some of the increases on the skill tree took more than one cube, allowing your score to rise more quickly as you increased each of the skills to its maximum.
Finally, I decided to limit the number of cubes the player had available to him at any one time by allowing the player to "run the machine", instead of taking/playing cards, by taking cubes from the general pile (at this time, all players had equal access to a pool of cubes) and placing them in a personal pile. This personal pile is where the cubes came to place them on the board. The number of cubes taken was dependent on the player's score. (The number of cubes to be taken was the score divided by five.) To make things more interesting, another skill was added that increased a number of "bonus" cubes that could be taken.
Playtesting
At this point the first playtesting began. Most of it was two-player because in my mind I wanted to ensure that this game was clearly playable by two players. The game supported up to five players and an occasional test was done this way.
A word about how I do playtesting: First, before anyone plays one of my games, I do pretty exhaustive self-testing. This is the first step of the playtesting process, and for me this is the point where about 50% of games fail outright, and I realize that I had made some sort of grievous oversight in the design, and that the game just didn't work. Forty percent of the time the game needs serious tweaking, and about 10% of the time I realize that there's something really intriguing about the design and I make minor modifications quite often in the middle of these self-testing sessions.
The way I do self-testing is to play as two or more people, all by myself. In the case of PMM, I dealt cards to each "player" face up and took turns for each player. The one thing that's missing in the case of PMM is that each player doesn't know what the other players' cards are, which hampered testing a bit, but still allowed me to work through the mechanisms and get a feel for the length and scope of the game as it's being played.
As the game was being tweaked, I started playtesting the game with other people, and the game quickly evolved.
Development
Publishing your own games is kind of tricky. As a game designer, you rarely think about the costs and complexities of game publication. For the games I've submitted to other publishers, I've focused on the game play and rules, and made the assumption that the publisher would figure out all the publication details. That's rarely the case, however, as the games other publishers have published tend to have an enormous amount of input from me on what they actually contain.
But when you're publishing your own game, you're constantly thinking about costs, weight, sizes, printing issues, artwork, and all the other issues surrounding creating a game. So with Perpetual-Motion Machine, since one of the goals of the game was to figure out a use for all those extra Rapscallion card decks and to publish it myself, this was a constant thought.
In the case of Perpetual-Motion Machine, the fiscal issues had an impact on the game play in a very positive way...when it came to how the cubes that tracked the skills and score were being used. In order to make the game work as originally designed, I would have had to have about 160 cubes in each box, as the cubes were virtually unlimited, and each player could fill up most of the spaces on his game board before the end. That's a lot of cubes, and it got me thinking about how I could reduce that to a reasonable number. (I ended up with 80 per box.)
Because of that thinking, I streamlined the cube placing, transferring and even the scoring process, reducing the need for all of those extra cubes.
:strip_icc()/pic954813.jpg)
Perpetual-Motion Machine – player mat and cards
The player mats were another consideration. I (and retailers) really liked the size of the Rapscallion and Ultimate Werewolf boxes – just big enough to comfortably contain the components of the game, while small enough to easily fit several on a retailer's shelf. Players liked the small boxes, too. When I developed Beer & Pretzels in 2009, I ended up with a bigger box so that I could economically print the coasters on a certain size board. (You'll notice that when you punch the coasters out, you can almost fit all the game components into an Ultimate Werewolf box.) So my goal with PMM was to again use the smaller box size. This defined the maximum size of the player mats.
Because the player mats were smaller than the original playtest sizes, the skill trees and scoring track really didn't fit well on them anymore. That led to removing the scoring track, and changing the goal (slightly) from a certain score to "getting rid of all of your cubes," which was much more clear and obvious from the players' standpoint.
Of course, getting rid of the score track required a change to the "running the machine" mechanism because it was now much more difficult to count up your points and divide by five, so that was simplified along with its corresponding skill tree. The end result was a simple "trade a card for a cube" which each increasing skill level allowing you to trade one additional card for a cube, thus making the player more efficient.
Final Tweaking and Publishing
Several months of playtesting changed the number of cubes each player had to place, the configuration and order of the skill trees, and even, at the very end, the initial setup.
Finally, the game was done and ready to be printed. I ordered a bunch of cubes wholesale from Germany, added Perpetual-Motion Machine boxes to an Ultimate Werewolf reprint being done overseas, and had the player mats and rules printed locally.
Big honking pile of cubage
By the time everything came in, I had already disassembled most of the Rapscallion copies in order to take the decks out, so I had all the components ready to go. It took a solid day of bagging cubes (by weight, which is while you'll see the rules say "at least" 80 cubes...most people will get 82 or 83), another few days of assembling boxes, and then a few afternoons of shrink wrapping to get the boxes all ready to ship.
The end result is much better than I could have hoped, and it's a game I'm quite proud of. The choices are interesting throughout the game, there's a reasonable amount of chance and luck. Playtesters who are good at the game win fairly consistently, which is pretty important to me: It's frustrating to have luck be so dominant in any game where experienced players often lose to newbies. It's mostly about you, the player, making the right decisions about what cards to add to your hand, when to play your cards, and when to increase your personal supply of cubes.
Ted Alspach
(This designer diary was first published on BoardgameNews.com in October 2010. —WEM)
/pic915054.jpg)
:strip_icc()/pic951869.jpg)
/pic950998.jpg)
/pic951795.jpg)
:strip_icc()/pic939626.jpg)
