Guest Post by Chris Holly - Narrative in Games: A Love Story

As I wrote earlier, Other Suns has the advantage of not being designed solely by me. This will certainly make it better.

Chris got involved with the project as soon as I realized that I didn’t want to have to write all those paragraphs myself. Since that time, on top of being our sole paragraph-writer, he’s also become instrumental to the design and testing of all aspects of the game. We’ve generally worked on different areas of the design, so I thought it’d be a good idea to get a window into Other Suns from Chris’ point of view. Luckily he was up for it.

—-

Ever since I picked up my first gamebook around the tender age of 9 or 10 – if memory serves, it was either Fighting Fantasy’s “Starship Traveller” or one of the lesser known series “You Are An Interplanetary Spy” – I’ve been enthralled with the combination of reading a well-told story and interacting with the story via gameplay. And I can tell you with 100% certainty that one of the things on my bucket list since I was a kid was to write my own gamebook.

I made a few halfhearted stabs at that early age, spurred on by such cultural touchstones as a ridiculous treasure hunt featured on the back of Cap’n Crunch cereal boxes (no, really). I got as far as writing some choose-your-own-adventure type chapters, but nothing featuring actual gameplay, outside of something incredibly fair like asking the reader to answer a trivia question about arachnid biochemistry before being otherwise entombed in a pyramid.

I then discovered the wonders of interactive fiction, and devoured every title in the Infocom catalogue (praise be to the Implementors). Although less narratively dense than a gamebook, the thrill of A) typing instead of writing and B) solving puzzles that required lateral thinking kicked me into high gear. And I can tell you with 100% certainty that one of the things on my bucket list since I was a kid was to write my own interactive fiction.

I made a few halfhearted stabs at that age, learning a scripting language well enough to construct a few rooms in a science-fiction noir setting, with what I thought at the time was a catchy opening, and which I now see as irredeemably stupid: “A private eye. A corpse in the skimmer. 36 hours to make sure one doesn’t become the other.”

(Side Note: Yes, this was shamelessly ripped off from the slogan for Deadline, Infocom’s first mystery adventure. Also, though I thought I was inferring that the private eye (you) might die, it never occurred to me that the corpse might BECOME THE PRIVATE EYE. Which probably would have made for the better story, in all honesty. Anyway.)

(Additional Side Note: I also thought I was SUPER FUTURE-Y with the use of “skimmer,” which, although I was CLEARLY referencing the flying cars from Blade Runner, to the uninitiated may have implied that there was a dead body in some sort of cheese-making facility. Again, probably a better story than the one I had planned. And so it goes.)

Then I got into board games, mainly solo-playing ones. And the crown jewel for me was Ambush!. I could (and probably will) write novels about how much I love this game. Brilliantly designed by John Butterfield, who I should probably be writing poems to, it combined the squad-level tactical strategy of WWII hex-and-counter play with a progressive campaign where your soldiers increased their skills (or, more often, died). Best of all, it had a book full of paragraphs! The German AI jerks were controlled by cards, and combining those cards with a die roll and the overall situation on the board directed you to a paragraph book that told you what the German jerk in question did that turn – moving, shooting, changing stance, etc. The paragraphs also provided a narrative of sorts, describing random events, controlling the flow of the scenario as things happened, moving the story along. The real genius of the game though, was in never sacrificing player agency in the interest of telling its story.

It was (and is) a wonderful blending of dice, narrative, and player engagement. And I can tell you with 100% certainty that one of the things on my bucket list since I first rolled up a squad was to write my own paragraph game.

I made a few halfhearted stabs, mostly revolving (again) around a sci-fi noir concept and one about a serial killing minotaur inspired by a David Bowie album (I am not making that up), but I found out two things: 1) I had no idea how to design the actual gameplay elements, and 2) writing paragraphs is hard. Like, really hard. Like, super duper hard.

“Sure,” you think, “It’s a couple sentences, throw in a die check or something, and be on your way.” Which actually works for the first, oh, 20 paragraphs or so. Then somewhere around paragraph 40 you start to wonder if you’re just rewriting the same one over and over again. Then somewhere about graf 60 you think that you’ve got a cool idea and realize it makes no sense. By paragraph 80 you wish you’d never come up with that one mechanic that seemed so awesome, and at paragraph 100 you’re ready to burn it all and take up something less complicated, like quantum mechanics.

All this is to say that I’ve long been in love with the idea of narrative gameplay in a lot of different forms. So when Corvid Games asked me to be a part of (be still my heart) a sci-fi paragraph game with honest to god gameplay and dice and everything, I jumped at the chance. It is most certainly a work in progress, but it’s been an incredible learning experience so far. Next time, I’ll share some of the things I’ve learned to date about while working on Other Suns, the unique challenges the game itself presents with regards to writing and world building, and some of the joys and difficulties of doing it the way we’re doing it.

Posted by Jack on Thu, 18 May 2017
tags:

Design Toolbox

Around age ten, I designed my first game. A couple sheets of printer paper haphazardly taped together, a few dozen connected squares snaking across them, and effects like “giant boulder, move back 3 spaces” scrawled next to arrows pointing at the spaces affected by them. A die stolen from Monopoly and pawns stolen from the gravel driveway, and my Indiana Jones game was complete.

Flash forward a few years and Until Dawn was put together in pretty much the same way; old L5R cards marked up with a Sharpie and components Frankensteined together from parts of dead Euro games. Harbinger was even fancier: a printed Excel sheet.

I’ve always appreciated the low barrier to entry of boardgame design. It allows me to focus on the design of the game rather than the medium used to create it. The path from idea to alpha prototype can be incredibly quick, which allows you to playtest early as well as easily try out new ideas, implement changes, or sometimes make sweeping overhauls with very little effort.

There are, however, a few programs and systems that over the years I’ve become dependent on, and wouldn’t work on games without. These are those:

1) Vassal

I am not a crafty person. I can’t put stickers on straight, I can’t color inside the lines, I can’t cut along a straight edge. I can’t read my own handwriting. Not only am I bad at these things, I actively don’t enjoy them. Many a game idea is stopped dead at the point where making a prototype is the next step.

Vassal is basically a virtual table that allows you to take a pile of images and give them some rules and definitions. So a big board image is put in the back and can’t move. A deck of card images is piled face down in the corner and randomized. You can make tokens, player boards, hidden stashes, and even automate some of these things (though generally Vassal games do not “know” the rules or enforce anything).

Learning Vassal and building a module for a game can definitely be slower than MacGyvering together a physical prototype, but it has some additional benefits beyond avoiding the trip to the craft store.

One, you avoid the trip to the craft store. This can’t be understated.

Two, ease of storage and no components. A Vassal mod is a single zip file, so no shelf space required. You don’t have to scrounge unplayed games for pieces, or buy a pack of card sleeves so your miscut index cards can actually be shuffled.

Three, accessibility. With two spawn running around, gaming time is limited and leaving a game out is a myth. If you have five minutes you can load up a playtest game, move some pieces around, leave yourself notes in the chat about things to look at or fix, and save your place when someone inevitably throws up on your foot or runs their head into the piano bench again. If you save your game as a log, you can go back at any time and click through every move you made and note you left.

Four, playtesters that don’t hate you (as much). I’ve found it much easier to find and keep playtesters when all they have to do is download a 10 meg file and they’re ready to play. On top of that, they can do the same thing: save plays as logs, write notes, and you can click through every game they play and dissect to your heart’s content.

Five, you end up with a Vassal mod. If you keep your mod maintained, then the mod and your game are playtested and advance together toward completion. When you’re done, you’ve got a tested Vassal mod for your game, ready to go. I’ll write something in the future about whether having a mod for your game is a good idea, but yes it’s a good idea.

2) GIMP

If you’re going to use Vassal, then you’re going to be spending some time making image files. They don’t have to be pretty, but they do have to exist in order for Vassal to use them.

GIMP is a free raster graphics editor. For someone who knows what they’re doing, there are probably better options out there, but for throwing together quick ugly prototype images, I’ve yet to run into a problem GIMP couldn’t solve. Including the problem of having no money to buy software.

Plus, when you Google questions about using it, you always get some fun results.

3) All Things Google

This may be an obvious one, but Corvid Games exists almost entirely on Google’s servers. Rules are Google text documents, card lists are Google spreadsheets, playtest questions are Google forms.

This means I can work on any file from any device or computer. I can share individual files or entire folders with team members. Documents can be commented on by multiple readers and editors, and everything’s kept organized and clean. You can upload any file you want, so I’ll save the newest version of the Vassal mod to the playtest folder and now everyone has access to it.

And though I’ve only just started doing this on one new game, I’ve been involved in many playtests that use Google groups as a means of organizing playtesters. It gives a quick snapshot of who your playtesters are, gives an easy way to communicate to everyone, and gives playtesters and designers a forum to discuss the game without clogging people’s e-mails.

With these tools I’ll do 90% of the work on a game, from the initial idea to minor corrections on a well-tested prototype. Having tools that you feel comfortable using means you’re more likely to use them. Being burdened by the medium of your work takes energy and concentration away from the work itself. If I had to schlep it out to the driveway to quest for quartz pawns for every prototype, Indiana Jones would have been my opus.

Posted by Jack on Sun, 7 May 2017
tags: