Welcome to Mostly Tryin’, a blog series where I, Rick, a UK-based board game and RPG designer, face my fear of failure by failing repeatedly and learn how to make good games by making bad ones. In every post, I’ll be reflecting on a different game, and sharing what went well, what didn’t, and how I’ve taken each experience forward with me in order to get better at creating and running games.
The first time I ever invented a game for other people, I was in Primary school (for non-Scottish folks, it’s the school you attend between the ages of 5-12). My friends and I were fans of Simon the Sorcerer, the old point-and-click adventure game. We’d use Multilink, a building and counting toy, to create fantastical scenes. Then we’d make up puzzles for each other, like the kinds we’d find in those old games. We had great fun reacting to one another’s outlandish suggestions and trying to find ways to move forward with the ever-falling-apart story we were telling.
It turns out I’ve enjoyed making and running games for friends since I was around about 8 years old. So why am I so nervous to do it now?
As I grew older, I became more aware of taking up space in the world—my actions impacting others, both positively and negatively. I think of myself as a fairly meek person—conflict-averse, for good and for ill. I’ve concluded that my biggest fear isn’t failure per se, rather it’s of being seen as a disappointment, or not good enough. It’s disappointing other people.
It’s something that still sits with me whenever I feel responsible for other people, particularly when running games. It still gets me now, a small flutter in the stomach in the minutes and hours before, but it was nearly debilitating back when I first started running RPGs for my friends. It led to an initial reluctance to stray into the unknown, so the first I time I created my own game, I leaned heavily on something I knew very well indeed.
Fallout: Vault Raid (aka the first TTRPG I ever designed)
The first time I ever invented an RPG for friends, I was in my mid-twenties. My friends and I were fans of the 1997 video game Fallout, where you play the Vault Dweller, the survivor of a global nuclear war living underground in a shelter. The game is an RPG—your character has attributes and skills that level up as you play, you fight bad guys in turn-based combat, and NPCs give you quests.
In an effort to translate this to a tabletop RPG I had assembled a complicated, math-y translation of the game’s huge list of skills and made up a few generic characters for a two-hour one-shot about a bunch of folks raiding an old nuclear Fallout shelter (or “Vault”) for some goodies. Simple stuff.
It’s worth noting this was many years before Modiphius released their licensed Fallout games, and not long after Bethesda released the excellent Fallout: New Vegas—I was ahead of the curve. Sure, I’d never actually *made* an RPG from scratch before but, I thought, it can’t be that hard, can it?
It turns out it is very easy to make an RPG system. What it is not easy to do is make that system in any way engaging, interesting, or easy for players to parse. My biggest mistake was handing each player a character sheet with around 20 stats on it. The scenario they would be playing would require, at most, eight of those skills.
So began the slog of trying to explain how this game would work (“You’ve all played Fallout 1 or 2, right? No? Oh. Well, this is designed to play kinda like those…”), what the objective was (“Go get the thing that’s on level 3”), and why they should care (“Uh…”). And then they were let loose, but because of the way I designed the game, they ended up making the most predictable decisions that would lead them directly to the quick resolution of their main quest.
Unfortunately, what this RPG was missing were the opportunities for roleplay—it played like a mostly competent, if very slow, dungeon-crawling board game, complete with carefully counting spaces every time anyone moved anywhere, and losing an entire turn thanks to an unlucky die roll. It was also very boring—and I say this as the designer, creator, and GM of the game’s one and only outing. Although the players dutifully played through it, I could tell it was a bit flat.
The reason that game never saw the light of day after that was simply because it was too fiddly and therefore a boring chore to get through—even for me! Trying to recreate in an RPG what a video game can do very quickly was, ultimately, the wrong approach. It was also, tellingly, one of the last times I ever ran a game so heavily focused on combat. It turns out I like my RPGs the same way I did back when I was eight: explorative, story-driven, and reactive to the players that inhabit the world.
For me, games are ultimately about embracing that inner child, so who better to turn to when I want to create?
Lessons Learned
Despite this game being played exactly once, I think it’s still worth looking at, to understand what didn’t work, and learn how to avoid these situations in the future. A lot of the lessons I’ve learned are still relevant to the games I make today!
So then, the game itself: as I said, a reimagining of the Fallout video games, condensed into a two-hour one shot. The system itself ran on a d100 basis; any roll under the skill value was a success.
There were also additional modifiers for things like weapon range and the opponent’s armor class, as well as situational, GM-imposed bonuses/penalties (most commonly “oh no, the players are too powerful” fudging). As you can see below, the character sheets are fairly faithful to the original two games, which is why it’s near-unworkable as a two-hour game.
I also made a ton of cards to represent the various kinds of equipment a player may pick up, each card designed to be physically placed over an inventory slot on the character sheet. The text on these cards themselves was actually relatively succinct, but when coupled with everything else, added so much to the page as to be information overload.
The system itself, though unwieldy, was relatively solid—as you might expect considering I’d mostly ripped off a well-loved video game from the mid-90s (which itself was originally meant to be based on GURPS until licensing issues got in the way).
Unfortunately there’s no way this could be anything other than a dungeon crawler, as there is so little framework outside of the combat engine. It may be worth exploring now that I'm older and wiser, though.
Lesson Learned: Be inspired by things you love, but don’t just copy them.
It’s great to be inspired by the things you love, especially if those things help you to get creative! But simply remaking what is already out there will probably only lead to unfavorable comparisons. Instead, try to think about what you enjoy most about your source (be it settings, mood, mechanics, or whatever), and then build on the feelings that those things evoke for you.
Next time I’m looking back at the first time I ran games for people I didn’t already know, and working out how to get past the fear that comes with putting something you’ve made on the table for new people.
Rick is a UK-based board game and RPG designer, and forever GM. He enjoys football (aka soccer), kobolds (the thinking person's goblin) and trying to convince his cats to come lay on his lap.
Cloud Curio is not associated with any companies mentioned in the blog series Mostly Tryin'. We don't earn any money if you purchase any of the games, programs, or products mentioned. We'll always disclose if we're being sponsored in any way for what we write.
Comentarios