This article is part of a series documenting the development of a new tabletop game from inception all the way to… well, all the way to wherever it gets in development, I suppose. To pick up the thread from an earlier installment, go to THIS PAGE and scroll down as far as you need to.
Early on, it helps to start writing down the rules you come up with—not because they’re going to stay that way, but so you can be methodical about what rule(s) you’re actually testing. Obviously, you will change some of these rules (perhaps all of them), but you need to do so systematically, and you should have some sort of record of what rules are “in” and what rules are “out.” It’s very much like a science experiment in which you’re changing variables from trial to trial.
When you’re playtesting a game design in this way, and each time you play, the game lasts a little bit longer and gets a little more dynamic before it breaks, you know you’re headed in the right direction. But that doesn’t mean you should rush into adding new elements before perfecting the foundational layers. In fact, sometimes you have to go backwards one step in order to go forward two steps. That was the case with the latest rounds of testing and tweaking for Engine Engine.
Having had almost two weeks of distance from it, I came back to the carpet and, after one test round, resolved once and for all that the “contracts” rule was just too complicated for the target audience. Furthermore, it was creating additional complications, such how much space needed to be left when placing city tiles down—stuff that wasn’t intuitive or easy to remember. So I canned it. I went back to playing out round after round with just tile placement and goods movement—no money or scoring or anything else—just to look for more roadblocks and brainstorm new possible solutions.
I was back to the problem of players “dead-ending” themselves once they built a second city. However, it occurred to me that only the player placing the city go dead-ended, while all the other players could automatically be granted new lines off the new city. As long as multiple players built cities—which they should be motivated to do in order to gain access to new goods—no player would forever be dead-ended. However, I did reduce the number of city tiles in the mix so that there wouldn’t be quite such a ridiculous number of new “stations.” I converted these unwanted city tiles into more “T-splits,” so that there’d be an even higher chance that a player would have more possible expansion routes. It’s also worth noting that I added BACK into the mix the cross-over tracks, because it just kept happening too often that players could easily cut each other off and ruin an opponent’s chances pretty early on. I may need to add back the “double-corner” tiles as well.
The one negative consequence of reducing the city tiles was a lack of viable destinations for goods to be delivered. This is where the best development so far came in. You might remember from Design Diary #3 that I couldn’t decide whether to call the city tiles “cities” or “towns.” You might also have noticed that in this article, I’ve consistently called them cities. That’s because “towns” are something else entirely now.
In order to have more viable destinations, I thought the players could place tokens representing “towns” on track tiles already in play. This would solve the destinations problem, as well as make the playing field more dynamic and more visually appealing. For balance and equalization, the current rule is that, upon the appearance of a new city, the other players, in reverse order, build one new rail off it, and place one new town—along someone else’s track. This should encourage towns to appear (1) near cities (keeping distances short), which will also mimic how suburbs evolve in real life, and (2) more frequently for players who are furthest behind in scoring, helping to keep “last place” competitive with the other players.
It was an easy thing to find some tokens to use: Monopoly houses. In my cache, I have a whole sandwich bag filled with Monopoly houses, each hollow house filled with a ball bearing and some putty to give it some weight. These were all left over from a wargame design I had been working on a decade ago that never really came to fruition. (Pro tip: never throw away your components or your ideas. Even the “failed” ones can be recycled into something new and great down the line. I may even come back to that wargame one of these years.) So, I “scientifically” picked a number of houses which seemed to make sense, spray-painted them according to the primary colors representing the goods in the game, and now they are called “towns.” And because towns are where goods GO, and now cities are simply where goods come FROM (goods don’t go to cities anymore), even a player who is temporarily blocked up still has play options and the ability to score.
With the corrections to city and rail tile placement, and the addition of towns, subsequent rounds saw the tiles beginning to sprawl over a relatively wide area of my carpet, and this layer of the game didn’t seem to be breaking anymore. The last problem of the weekend was that, as the board grew and new cities appeared, the players eventually had little to no reason to work with the lines they had built early on. Old parts of the board were stagnant, and only new parts were active. The natural solution to this was a concept I’ve had in mind since the inception: “passengers.” In addition to delivering goods, the players could score/earn money by transporting imaginary passengers along their lines. The differences would be thus: goods go from cities to the NEAREST color-coordinated town, encouraging town growth around cities. Conversely, passengers go from towns to ANY city, encouraging players to build longer rails and to try and connect newer tiles back to older ones, keeping the whole, expanding board active. When I sit down again, I’ll try it this way, and I’ll keep track of generic “points” for both goods and passengers. I hope to get a sense of how much game money these things should yield. With any luck, I’ll get to introduce the “bandit” as well. After all, what’s a train game without a train robber?