Engine Damage Lite: Part 1

One of the things I have wanted to do was to cover the development of a game from start to finish.  Specifically, I wanted to cover discovering the initial kernel, fleshing it out, creating the prototype, swallowing your pride as you scrap your favorite mechanic, and lots and lots of playtesting.  Luckily for me, I had an idea for a new game just after creating my website, so I am going to start a development journal for Engine Damage Lite.

Engine Damage is a game of steampunk, train on train combat.  I have been working on versions of the game for about 12 years.  It was the second game I ever created, and it will always be my special project… Mostly because it is completely unpublishable.  A massive miniatures combat game requiring special arenas and hundreds of pieces?  It will never happen.  I should probably talk about the history a little, before I get to the current version.  Feel free to skip to the line break if you don’t want to hear how Engine Damage has evolved.

1)  The first version was a futuristic train combat game, in an arena.  As much as I loved firing lasers and missiles, it just didn’t make sense to have trains in the future.  And the arena was just a giant loop, which was… underwhelming.

2)  The second version was the switch to steampunk.  It makes more sense, thematically, as planes completely invalidated the armored train, and planes don’t necessarily exist in a steampunk setting.    This version switched from an arena combat game to a race game.  A friend of mine had been testing Road Kill Rally, and like all good game designers, I wanted to improve it.  That version of Road Kill Rally was much different than the published version.  Games lasted about 2 hours, the cars were built before the race started, and players could be killed if their cars were destroyed.  I loved the heck out of it, and wanted to focus on the (to me) more interesting part:  Shooting each other.  This version focused on train construction.  Players bought an engine, cars, fitted them out with armor and weapons, purchased cargo to deliver, and tried to make it to the finish line.  Destroying other players gave you salvage rights, so there were benefits to destruction.  It worked… OK.  The rules were kind of fiddly, particularly for steam management and targeting.  I never did find a good solution to the targeting problem.  How do I stop players from spending all their energy just shooting the engine?  Random targeting was not fun, but allowing the attacker to choose wasn’t fun either.

3)  The third version was basically like the second, except I consolidated the armor for trains into a single hit point total per side.  This solved the targeting problem, but basically turned trains into cars.  The magic of the lumbering giant was lost.  And the character sheets, while smaller, were much much uglier, which definitely had an impact on enjoyability.

4)  The fourth version was an arena, again.  This kept the same basic mechanics as the third version, but players were given the objective to destroy a base, and the cargo was scrapped, because who wants to deliver cargo when you could carry another canon?  This was much more interactive, as players could focus on packing as much weaponry as possible, but it often devolved in to players just making a run at the enemy objective and not bothering to shoot each other.  Still perfectly serviceable!

5)  The fifth version was a cooperative version.  The tracks were largely abstracted, and players had to work together to defeat threats like busted tracks, enemy trains, and boarders.  The convoy concept never felt terribly cohesive, and the game suffered mechanically.

6)  The sixtIMG_1360h version went back to a race.  The tracks were abstracted out again, allowing people to pass each other with impunity (because ramming was never terribly popular).  This version used cards for damage instead of hit points.  An attack flipped damage cards up from the top of the deck and checked if they were a valid result of the attack.  If so, they were applied.  It worked well, but without hit points, there was no way to tell when a train was “destroyed” and, once again, fast trains always won.

Engine Damage:  Arena, 27)  The seventh version switched to the arena again.  This time, train cars were puzzle pieces, with tetris-like components allowing even further customization of the game.  It worked out better than the previous arena, but still suffered from the “The best defense is a good offense” problem.  The puzzle pieces were self-balancing (because the shapes prevented certain combinations) so that worked out very well.  The new dice made damage more balanced, and damage handling was more intuitive (place damage markers for each point of damage dealt, damaged tiles could not activate).  A targeting die helped the targeting problem without eliminating it.  Still little resource management tension, unfortunately.

The core tenants of the game have always focused on:

1)  Massive Armaments.  The point of the train is to have heavy armor and heavy weapons.  They are basically land battleships.

2)  Resource Management.  Setting a big fire in the engine gets you more steam but risks it overloading.  I don’t think it has been terribly well implemented in the past (most people run on full all the time) but it is always something I have tried to balance for.

3)  Cool combos.  “Oh, you mean I can use the Babbage Engine to reroll any die, even the Fat Man Cannon, which is so big it uses it’s own custom die?  Awesome!”  The first playtest of version 7 went hilariously wrong when someone realized you could charge up a lightning gun with 3 electric generators and was literally dissolving cars into sprays of superheated plasma.

Recently, I have been working on smaller games, and I wanted to try that here.  How could I strip the time and micromanagement required for train construction, without eliminating the fun of big weapons?  Randomly generated trains.  And with random generation, the ultimate balancing mechanic:  Auctions.  If a train is worse, people will pay less money for it, and it will all balance out, right?

It came together quickly.  There were 4 decks of cards.  An engine deck, a train car deck, a destination deck, and a challenge deck.  Players dealt out a number of engines equal to the number of players.  Those engines had a cargo capacity, a speed, and a power stat.  The cargo capacity was used for scoring points at the destination, the speed was used for challenges, and the power stat determined how many train cars were dealt to the engine.  The destination was revealed, which stated how much each point of cargo was worth, and how many challenges the players had to resolve to make it to the destination.  The train cars were things like steam cannons, flak cannons (for anti-air), flamethrowers (for anti-personnel), etc.  Players were essentially gambling on which would be the most versatile in resolving the challenges.

We played one round, and stopped.  What went wrong?

1)  This is partially a balance issue, but as money was both victory points and what was auctioned, the player who “won” the first destination card had the most money to bid on trains for future rounds.  The opposite of a comeback mechanic.  Having delivering cargo give you Reputation instead of money would solve this issue.

2)  The game was too random.  Not knowing which cards were coming up for the challenge meant that any specific train was a crap shoot.  In addition, the way the cards were dealt, there was generally only one “good” train, so once bidding for that was resolved, no one particularly cared about the other trains.

3)  The only interaction mechanic was bidding on the trains.  There were challenges that let players fight each other, but with no way to reliably control them, they weren’t something the players could plan on.

While this particular game had to be scrapped, the idea, in general, is a solid one.  Building a train with simplified pieces against unknown challenges allows people to specialize or generalize, and be rewarded for either.  With a more reliable set of core mechanics, it could work.  So how to fix version two?  Find out next time!

Leave a Reply

Your email address will not be published. Required fields are marked *