Quicksilver: Racing and Map Design

Paul Imboden and I have followed each on Twitter for some time. He’s a designer, I’m a designer, you know how it goes. Recently, he and his partner launched Quicksilver on Kickstarter. I was intrigued and asked them to write a guest column for a few reasons. One, there aren’t that many racing games. Secondly, map design is ridiculously difficult and I wanted some of their insights into the process. Finally, their game looks neat and I thought it’d make for an interesting read!

Guest Column by: Paul Imboden

When we started working on Quicksilver, we knew the initial map had to be perfect. In order to do this, we had to nail down the mechanics for how the ships moved.  That was the first challenge.  There’s a myriad of racing games out there and most of them focus on relatively predictable vehicle performance: cars, motor boats, jet fighters, and so forth.  Zeppelins, especially if they would be the types of dirigibles suited for racing, would bring on challenges that cars would not.  They operate in an (almost) frictionless environment, they’re not well-suited for fast directional changes, they must fight momentum, and they are at the added mercy of the wind.  For a mechanic to capture the feel, it needed to be semi-chaotic, but not so chaotic as to make players feel powerless.

The first run-through played like an Excel spreadsheet! It was the opposite of fun, as the mechanics allowed players to carefully choose the exact movement patterns and velocity.  There was never a moment of risk and risk is what a racing game requires. We began to experiment with re-weighted die probability to see how it would affect movement. We found a sweet spot with a 1-2-2-3-3-4 die, which normalized movement while allowing for the occasional lucky spike. Editor’s Note: For clarity, they use a custom six-sided die with the pips modified to the numbers above.

We capped movement minimums on a triangulating scale so players who chose maximum velocity would not be cursed with horrible dice rolls. The airship’s maximum velocity should always move faster than a lucky roll at its lowest speed.  We tied movement bonuses to armor, then ditched the mechanic when it proved too cumbersome, as players would often forgot to apply the adjustments.  Finally, we gave the player just a touch of personal control over the dice, allowing them to use their cards to influence their total movement. However, to do so they had to sacrifice the card’s effects. The better the effect, the more points it granted for movement.

It was important to nail down the movement mechanic first because without it, we could only guess as to how a track would work.  The open air racing track operates as a regatta that requires planning as to where and when to stop one’s movement. This became the primary reason we went against a completely modular track.  There are ways to create a completely modular system that gives players the ability to setup their racetrack with Duel-of-Ages-style interlocking cardboard hexes that connect at six different sides.

However, the sheer math for testing those 36 combinations on TWO hexes made the early playtesting impossible.  If you add FOUR hexes together, the testing matrix increases exponentially. We anticipated a 2′ x 3′ map. The approximate dimension for our current map would require no less than TEN hexes.  We’d be playtesting these configurations for YEARS!

Therefore, we chose a static map with pre-defined checkpoint locations that players could swap and flip.  We used the playtest movement data to determine the rough placement of the major obstacles: mountains and clouds.  Mountains needed to not only look natural, but serve as blockades to the checkpoints.  There needed to be ways to cross the skies, but thoroughfares should be difficult to line up and harder to maintain.  Clouds filled in the gaps for movement delays to continue the natural leader slowdown in a similar but different way than the checkpoint turns.  We created opportunities for players to take chances on the board, such as the one-hexagon-wide canyon in the top center of the map where players can hope to shoot the moon.  Playtests confirmed some mountain segments needed pruning here, extending there.  Clouds filled the gaps where runaway leaders tended to prevail, and the players’ airships acted as additional bottlenecks.

The 48 different combinations of checkpoints and directions proved to be more than sufficient for flexibility in terms of both challenge and length of play (simpler courses are faster, naturally).  A few playtesters complained about the lack of customization — they REALLY wanted that fully modular board.  Their complaints hit their greatest pitch at the same time we realized a deal-breaking issue with two particular cards: smoke screens and flying mines, both designed to be dropped from behind a ship as it races off to the next checkpoint.  These cards became fun-killers for two reasons: They were only a benefit when you were leading and they made a runaway leader runaway even faster.  It was the elephant in the room that no one saw and no one mentioned until it became too obvious to ignore.

Man, did we not want to kill our babies.  But we needed to.  We absolutely needed to for the sake of the game. So. Mines and extra clouds. Gone.

Within 5 minutes of removing these features from the game, we brainstormed on how we could bring them back, and it all came back to a central narrative that was beginning to emerge: Give control to the players and let them make the hard choices.  Let those choices be the source of that good game tension.  Players could burn cards to aid with movement, but they’d be denying themselves greater power.  Players could take a turn slow hoping to roll high, or take a turn fast hoping to roll low.  And now, players could set the map with as many perils as they wish — but now, being in the lead wouldn’t matter.  Customize the track with a minefield here or there.  Add more clouds for extra chokepoints.  You were all in this together.  Everyone would be affected.

Editor’s Note: The player mat above is from an early prototype.

We gave our first playtest group complete freedom. When the first minefield token dropped right in front of the starting line we knew we needed to rein in that freedom. Players need to be able to make it out of the blocks and through the checkpoints. Playtests determined that a distance of at least four spaces from the start-finish line and three spaces from any checkpoint provided just enough opportunity for interference. Any closer and safety depended too much on luck.  Not surprisingly, the canyon became a prime location for a turret.  Minefields popped up like mushrooms on the straightaways, which prompted players to ask if minefield explosions set off chain reactions.  (Our answer: No, once is enough.)  Cloud patterns expanded, prompting players to ask if clouds nested inside of clouds halved movement a second time.  (Our answer: No.  Once is enough.  You people are MEAN.)  Those two challenges led us to put a limit on these player-placed obstacles and after various tests we settled on one per block.

The feedback from this dynamic reaffirmed our suspicions: Players loved that control and they blamed themselves for their own cursed nature rather than the dice or the elements.  Once we set limits on the distance from critical game elements, there was nowhere on the course where another obstacle (or combination of obstacles) broke gameplay.  It could certainly make the game take longer if people wanted to avoid that final minefield placed between the final checkpoint and the finish line, but that would be an active choice made by a willing player.

Feeling like you’re piloting an airship.  Freedom to create the race you’d like.  Sandboxed control over a static board.  Hard choices.  We did what we set out to do in Quicksilver and we’re proud of the two years of development (and generous playtest audiences) that created it.

We’re currently working hard on another static map, this time with less open space and more “mountains” (actually, skyscrapers serving the same purpose as a mountain for an urban regatta).  We’re enjoying the tests and we think players will like the contrasting feel of this course.  They’ll still be able to customize the track and it should have the same effect on gameplay; the protective mechanics prove universal.  If we reach $40k on our Kickstarter campaign, this second map will become part of the base game.  Thanks for reading.  Risk more of yourself.

If you’re interested in Quicksilver, take a look at the KS campaign here. 

6 thoughts on “Quicksilver: Racing and Map Design

  1. Thanks for the opportunity, Grant!

    I’ll be checking in regularly — readers, feel free to ask me anything.

    Reply
  2. Paul, this sounds like an elegantly exciting racing game.

    How much playtesting with kids did you do? I’m curious about your target minimum player age.

    Also, is altitude a factor, or do leave that out as an unnecessary complication?

    Grant, thanks for bringing Paul’s game to your audience.

    Reply
    • He noted that it was in the works for 2 years. I’m sure he’ll have something more specific.

      I really liked the premise and I thought it’d make for a good read. I became a backer myself this morning!

      Also, here are the rules: https://dl.dropbox.com/u/22273337/Quicksilver_Rulebook.pdf

      Reply
    • Thanks for the questions, Paul!

      A) We did a fair amount of playtesting with kids, especially families, and we worked with teachers to determine an appropriate age range. Our decision on age ranking ties in with the Piaget scale of development. This game requires the ability to think and plan a few moves ahead, as well as understanding the consequences of using resources for different purposes. That level of abstract thinking usually happens at Level 4 on the Piaget scale, which starts appearing at age 12-13 or higher. We played it safe and chose 13-and-up.

      Kids aged 7-10 and up enjoyed the game… but for many of them the game was more of a toy, if that makes sense. They understood what they could do on their turn, but they didn’t quite understand why certain choices were better than others. They didn’t grasp the problems with consistent take-that play; they’d go too fast into turns; they couldn’t see the value in sacrificing cards for speed. They couldn’t think abstractly enough. (More advanced kids were able to ‘grok’ the strategy, so that age limit is not etched in stone, goodness knows. But as a general rule, they hadn’t made the transition to Level 4.)

      And now you’ve got me thinking about what it would take to make “The Kids of Quicksilver”…

      B) We initially played with altitude — the card now titled “Pardon Me, Chap”, which grants a player immunity to attacks for one turn, was initially called “Upper Altitudes” — but we quickly decided to omit it. If Quicksilver finds an audience we might include altitude rules in the future, either through a download or a full-on expansion.

      Reply
    • Also, important to note: The US has some pretty strict guidelines as to how toys and games are labeled age-appropriate. We have to stay within given parameters for any toys or games marketed/sold to children 12 and under. Many of those parameters relate to Piaget, but not all. Other countries have similar guidelines.

      And that’s not even counting US safety requirements. Those stickers on the back of nearly every game that say “This is not meant for children under 3 years of age. Small parts may be swallowed by infants and can cause a choking hazard”? We’ll have one of those stickers on Quicksilver as well. It’s the price of business.

      Reply
  3. What board-game had these dice in it?: http://hyperbolegames.com/files/2012/06/photo.jpg

    You’d take turns rolling dice to go around the board, collecting armor and other equipment from four beings to finally try taking out the ultimate baddie in the center of the board. I think one of the guardians(?) might have been a cyclops or centaur.. I’m thinking an 1980s to 1990s game. Not HeroQuest but eh…Recognized the die and post. hm.

    Reply

Leave a Reply

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

You may use these HTML tags and attributes: