Designing Around The Problem

I don’t know anything about designing games. I’m making it up. That being said I know a bit about product development, and about exploring and validating ideas as cheaply as possible before you motor off in the wrong direction.

I had a tough time getting starting on the Gaslands campaign system. It seemed too big, and too important, to start. I knew it needed to be done, and soon, but I had a creative block on it.

stuck

I have never written a progression system. I have played RPGs, but none of the card, board or wargames that I have written so far have have a progression system. I have played some games with progression systems, but never analysed what makes them work.

Listening to the hosts of The Grodnard Files podcast reminiscing about the old Traveller RPG (which I owned and poured over as a kid, but never played), I was inspired to make a “space trader” themed card game, rather lamely named Oceans Of Space (all the good names have gone). The theme is obvious and sort of writes itself: mining and missions to make money, money to buy upgrades and better ships, occasional space combat; easy. In order to make it something that I could use to personally explore the up and downs and feel of a progression system, I made it a solitaire game. For speed of development, I built it upon a standard pack of playing cards.

OceansOfSpace1

Oceans Of Space was a chance to take the problem I was facing in Gaslands, namely how to construct a progression system, and make a game that was ENTIRELY about that problem. This space trading card game would basically just be a progression system and nothing else. It was a way of holding the problem up to the light, examining it without risk or fear, and learning some lessons that could apply to the Gaslands system. I was able to explore how “fast” a progression system needed to be to feel compelling, and what sort of “acceleration curve” is needed. Should you get better fast first and then should the progression slow down? Should the progression be trepidatious and staccato to start with, and then accelerate as the game plays out, like a freight train. How could the arc of this game apply to a Gaslands team across a campaign?

You can download the finished game from my website:

Oceans_Ship_Schematic

During the writing of Oceans Of Space, I hit on the idea of paying for repairs as a way of building tension and peril.  I also explored the random generation of “shop items”, which I suddenly realised was a great example of the powerful “variable reward” heuristic, and got me to thinking more about other proven “habit-forming” heuristics. (More on those in a future blog post.)

Writing Oceans Of Space also unlocked a method of testing the new post-game sequence that I don’t know would have occurred to me under different circumstances. It was now obvious that if I wanted to experience how the post-game sequence “felt” over many games, and compress the playtesting of the campaign arc over just half an hour, I could fake the games. Instead of actually playing the games, I just created some teams on the new roster sheets, and then rolled a few dice. Which team won this race (roll a die)? Who was the first car over the finish line (roll)? Which vehicles got wrecked this game (roll) and by whom (roll)? Now I could just run the post-game sequence, rolling for damage and injuries, collecting XP and rolling for new skills as if the games had really happened. Clearly, I’m not testing whether the new skills are balanced during gameplay, but I am experience the post-game sequence and getting an early feel for what seems too harsh, or too generous.

In these early campaign fake-ups it became clear that cars were going to suffer a goodly number of permanent persistance damage that slowed them down or made then less controlled. This is perfect, as it captures the ramshackle vibe of the post-apocalyptic racing team, but I immediately felt my mechanic (more on her in another post) was slacking off. Why weren’t the team able to repair some of these long-term niggles in the cars, particularly for my superstar drivers? I added a “repair” rule to simulate this.

tTmXOOX

Also clear was that my teams had too much disposable incoming. Money didn’t feel tight enough. I should be scrabbling around for enough fuel, and having to make tough decisions about selling off one of my weaker vehicles entirely to help bolster or repair one of my critical ones.

In Oceans Of Space, I had a mechanic that, if you took damage during your adventures, you would have to paid to get each hull point repaired once back in port. This provided some real tension, particularly in the early game when you don’t have much money. This idea could pretty much be moved straight across into Gaslands. Of course you need to pay each game for the refuelling and upkeep of your vehicles, of course you do. Perhaps paying for every vehicle is too harsh, and my currency system hasn’t the same amount of granularity that Oceans Of Space had, to allow players to pay to repair each hull point individually. The compromise was to force players to pay to repair lost hull points on their vehicles at the cost of 5 point for 1 can of gasoline. If your car escapes the game unharmed (or wasn’t even fielded) you have nothing to pay. If you car took damage, you are going to have to cough up to repair it, or risk going into the next game at less than full strength.

The experience of using a smaller game project to involve a larger one has been very satisfying. It appears that a valid way to overcome a design problem is to isolate that problem and start designing around just that. Take the problem space and create something as quickly as possible, without all the super-structure and weight of your “main” game. Play it and find out what doesn’t work. Learn by failing. This is likely fractal. If your experimental game still has an issue, isolate the mechanical or thematic problem and build an even smaller mini-game out of it.

Anyway, I don’t know anything about designing games. I’m making it up. “Designing around the problem” does have a nice ring to it though.  Maybe that’s my new book*…

* I’m not writing a book, but I am writing a game. If you want to be involved, please sign up as a playtester.

One thought on “Designing Around The Problem

Comments are closed.