Friday, August 4, 2017

The Psi-Wars Process

Creativity as a loop
Christopher Rice (of Ravens'n'Pennies) recently asked me to outline the process by which I've created Psi-Wars.  I believe I've discussed it before, but not really in specific detail, or all in one easy-to-find place.  So, I thought I'd take the opportunity to break it all down, at least as I see it right now (processes, of course, evolve).

Up front, this is a process I've learned as a computer programmer, but I believe it applies to all creative work where possible: most artists sketch before drawing, most writers make multiple drafts and so on.  But this is also informed by years of working on RPGs and struggling with the amount of work a really detailed campaign or session needs, and the amount of time I have to get work done paired with the big X factor that is the amount of learning I need to do, or the hidden complexities of my project, all of which should be familiar to any programmer.  As such, I've learned a few things that have informed Psi-Wars, and my session design (as seen in the minimum viable session).  The process is, at its core, this:


  1. Identify and articulate what it is you want to do.
  2. Do the minimum work necessary to achieve what the goal you want to do in step one
  3. Test the resulting work to see if it accomplishes the goal you set out to do
  4. Reflect on the work, and see what went well and see what you could Refine.
  5. Release the result
  6. Repeat until satisfied or your players bang down your door.


Like many things, this seems simple but I find it helpful to offer a more concrete scenario.  In particular, when creating a GURPS campaign framework, I find that we can get very specific, as certain results tend to come up again and again, and you need to have a certain, very specific mind-set.

Building a GURPS Campaign Framework, Cycle 1

Step 1: Identify

So, you have a campaign idea, huh?  What is it?  In the very least, you need to articulate that. Sometimes, that's even enough: "I want a monster hunters campaign where the players need to ponder the morality of killing zombies given that a cure is possible," but often, especially when designing a campaign framework, we should define the core activity of the campaign.

The core activity of a campaign is the default gameplay scenario.  If your group sits down to a generic session in your campaign framework, what do they do?  All Campaign Frameworks have this.
  • In Dungeon Fantasy: They find out about a dungeon, travel to it, then go in, kill monsters (dodge traps) and take their stuff.
  • In Action: The receive a mission, investigate the mission, prep the mission, argue for hours about the plan, go in, have their plan fall apart in seconds, run around shooting everything, achieve the objective, get out and get yelled at by their superiors.
  • In Monster Hunters: They find out about some monster, usually through a gruesome murder, investigate, encounter the monster, freak out because they had it all wrong, escape, investigate again as bodies begin to pile up, figure it all out, go into the monster's den, have a horrific encounter, kill the thing, burn the thing, salt the thing, bury the thing, then cover up that any of it ever happened.  Brood.
  • In After the End: Some calamity pushes the survivor's uncertain situation over the brink and now they face extinction unless X, which usually involves travelling into even more dangerous territory to achieve X (which usually involves acquiring some thing).  They go on a trip, survive the wilds, get into the place, survive the inhabitants, find the thing, survive getting the thing (usually traps or some disastrous thing), return triumphant, and then return to the status quo of "barely surviving."
Most of these also have a broader story associated with them.  Each action scenario might bring the heroes closer to uncovering some underlying conspiracy, while Monster Hunters might grasp that some monster is driving all the other monsters out into the open, and survivors in After the End might come closer in each scenario to uncovering why the world ended.

Each scenario also has associated gameplay elements.  For example, DF typically requires some means of learning of dungeons, surviving the trip to the dungeon, fighting the monsters, avoiding traps, identifying and collecting loot, and then selling said loot.  Note, however, that "just having the right skills" is not enough.  What you want to do here is create gameplay, which is a topic I'd like to discuss at great length at some point, but essentially boils down to: Give your players interesting choices.  For example, finding the dungeon is rarely interesting.  It's not like you need some skill to pick out what dungeon you're going to, because you're only ever going to go to one dungeon, the one your GM has planned.  So you just kick around until the GM announces that you've found some mysterious stranger who knows of a dungeon, nod along to the backstory and then off you go.  However, fighting the monsters or navigating the dungeon does involve interesting choices.  You might need to choose how you make your way through the dungeon, choosing between paths, or even approaching your dungeon holistically.  When you fight, you need to decide what sort of maneuvers you should use, what monsters to focus on, what tactics to use, etc.  Often, the "interesting choices" offered aren't simple "A vs B" to an entire plethora of options, like the "choices" presented to a player during a first person shooter or a complex wargame.

We don't need to worry so much about gameplay in the first iteration, but it's good to keep in mind.

So, we have a basic outline of what our campaign is like and what our core activity is.  If we don't, grab the most similar GURPS book you can and dig through it's campaign information.  For example, if we wanted a fantasy game utterly unlike dungeon fantasy, we might dig through GURPS Fantasy and find some ideas (such as a wainscot fantasy: what would it be like to play an "urban fantasy" game where violence wasn't the solution?)

Step 2: The Minimum Viable Product

Okay, so we have our basic idea.  Now, what's the minimum necessary work we can do to achieve what we've set out to do?

Ideally, at the end of each cycle, you can stop and run your game.  This is critical.  Games die on the planning floor because they're "not ready," so our first priority is to make them ready.  This, I think, is the point where I get more conscious or unconscious pushback.  "But I want to spend days working out a distinct language" or "But the magic system has to be perfect!"  These things are good and nice, but your first priority should be getting the game off the ground.  First, the whole point of this is to build a game that players can experience, and if you're not building towards this goal then what are you doing?  There's nothing wrong with coming up with a language or a magic system for its own sake, but if you're doing that, be honest with yourself about it.  Second, by creating a specific game, you'll see what you need and what you don't.

Programmers have a saying called "You're Not Gonna Need It" or YNGNI.  That is, programmers (and gamers both) plan for things they think they need, but don't actually need.  Take that complex language you had in mind.  Are players going to use it?  What purpose does it serve?  If you have a complete, finished game and you put it before the players and it quickly becomes obvious that language is irrelevant background information, then YNGNI.  But what if it becomes obvious that the game turns on language? For example, this is a game about first contact and language is one of the key elements?  Then you definitely need it.

So, to get our game up and off the ground as quickly as possible, I suggest turning to what GURPS already has.  What do you need for your game?
  • A list of appropriate traits that players can choose from
  • Or better, templates that give the players an idea of what sorts of characters they can play as.
  • The core rules you want to use to run your game.
  • Any interesting subsystems (magic, martial arts, vehicles, philosophical shenanigans) that the game requires
  • A catalog of items that the players can get
  • Opposition the characters might face
And so on. If you're really not sure what you need, again, dive into an existing book.  GURPS Fantasy will tell you a lot about Fantasy, Space and Ultra-Tech will tell you about sci-fi, and so on.  If you're not sure if you'll need it, if it isn't vital to your core premise skip it.  Maybe psionic powers would be cool for your wainscot, but it's not vital as Magic will work for the most part, so just use magic, at least for now!

Then take what already exists and patch it together.  You want that wainscot fantasy?  Just use the fantasy templates in GURPS Fantasy, unless those are wholly inappropriate, in which case maybe GURPS Horror Templates (sounds weird, but they're good "normal people" templates).  For your fantasy races, you can definitely use GURPS Fantasy.  For magic, you can use GURPS Magic, or GURPS Ritual Path Magic.  For monsters, again, we can dive into Fantasy or Horror.

What will result from this will likely be an unsatisfying patchwork mess, but it will work.  Your "core system" here is GURPS.  That already works with your templates and your subsystems and offers you catalogs.  You now have something that you can play.  That's vital, because it means you can test it, and if your players beat down your door demanding to play the campaign right now, you could do it.

Step 3: Test the Result

Okay, now you have your working campaign.  Run it.

You don't have to literally run it.  You can run it "in your head."  Walk through some of those core activities.  If your game is about fighting, run a test fight.  If we're doing a wainscot game, do a typical mechanical experience (how do your characters encounter the supernatural?  What generally happens when they do?  Is it typically investigation followed by diplomacy? Run a test version of that then). You can also run it for a small, select group of "testers."  Your family, a friend, just some people who will push at the work and challenge it.  Or, if you're bold, you can run it for a full group.

Expect this to fail, but perhaps not in the way you expect.  Do the player characters have access to all the tools they need to interact with the core scenario?  Do they have sufficient interesting choices?  Do your mechanics play out more or less like you expect?  Where does the game fail and where doesn't it fail?  It may well be that some of the stuff you introduce at this stage are good enough.  For example, in psi-wars, I've had to make no meaningful changes to force swords or force bucklers.  They're pretty good as written, and Psionic Powers work fine out of the box (only Psychokinesis really needs changes, and that's more thematic than mechanical).

By actually running it, you force yourself to encounter things you might not just by pondering it.  Many people skip this step, assuming they already know, but don't.  Systems like RPGs tend to be very complex, and even if you're sure you have it down pat, you're going to forget something, or not understand how certain gameplay elements emerge from the rules you've put into place.


Step 4: Refine

So you've seen what's gone wrong.  Is there anything you can do right now to fix that result?  This should be a short, quick fix.  If it seems like it's a really big thing to fix ("The magic system doesn't work at all!  I'll need to start from scratch!") then don't worry about it at this point.  It'll get its own cycle!  But if it's a small thing ("This would be better if every character had 10 points of magical energy reserves off the bat") then go ahead and do that.

But also note where things fail, what you'd like to do to, where things went wrong.  Reflect on the whole process.  Maybe your core premise is all wrong ("This is increasingly a horror game, not really a fantasy game.  Maybe it works better that way?"), or maybe you found something interesting you hadn't expected ("You know, the mana level rules do some cool things when players start interacting with them, and Sue's question about raising them or lowering them through action is an interesting one.  This could be a campaign about mana-gardening, sort of fantasy-ecology-conservationism as a game!").

If you make small changes, go back and test them.  You may bounce between Step 3 and 4 for awhile, but you should keep your focus small and on releasing as soon as possible.  If you find you have big, glaring errors, patch them as best as possible, and then deal with them in the next cycle.  Remember that the point here is to get a workable framework out as soon as possible.  That, not a perfect game, is your goal.

This step will takes the results of the whole cycle and feed them into the next one.  You don't usually need to articulate this step, as I find people do it intuitively, responding automatically to the results of their test.

Step 5: Release

So, you've built it, tested it, patched the glaring errors and have an imperfect product.  Release it!

The form you release it in may very, but in the very least, document it and save it on your computer, or write it all down in a notebook, or whatever.  Get it out of your head and into a persistent format of some kind.  If you're a blogger, consider blogging it.  If you run the game for your friends, consider mailing them your current version of the rules.  If you're shy, just hold on to it.

By writing it all out, you'll also force yourself to confront certain ideas you might not have already articulated.  It also means that you'll have it down someplace.  I often find that real life interferes and you might need to step away from an idea for awhile.  If it was all in your head, you will lose it.  If it's written down somewhere, you'll be able to reference it again.  This is also useful if the design runs for a very long time, like Psi-Wars has.  When I find I need to double check a space rule, I can just go back and check it.  I don't need to stop and reinvent it because I've forgotten it.

Step 6: Repeat

I think the hardest part for people is letting go of flaws.  You need to realize, first of all, that no work is perfect.  Every creator suffers from creator's remorse, even the guy who created that really awesome work that you love so much (whatever it is).  He or she had ideas that never made it to paper, or never quite matched the vision they had.  But that's fine, you shouldn't let the perfect be the enemy of the good.

And you need to remember that you can always go back and revisit it.  But when you do, you should do it in the same way outlined:
  • Articulate the change you want to make and why it's important
  • Do the minimum necessary work to make that change, stealing where possible
  • Test the change to make sure it gives you the result that you want
  • Refine the change based on the test results
  • Release
  • Repeat
You can always go back.  Hold onto that when you find new flaws that irritate you, but don't prevent you from releasing the game.

Cycle 2: Characters

What your next cycle will be varies from product to product, but I encourage you to look at character material first.  There's a reason D&D releases the player's handbook first, and why GURP started with characters.  Your players want to know how to interface with your world, and without characters, your game dies pretty fast.

If you find that core templates don't work so well, or you want a trait list like you see in the campaign frameworks, I highly recommend the GURPS Template Toolkit series.  It very nicely outlines the relationship between core activity, niches and the sorts of traits people will want. You can also borrow ideas from existing works.

Ideally, use your templates and your trait lists as a way to enforce your vision of the core activities, and to provide interesting approaches to your core activity.  For example, if our wainscot fantasy game is about investigation and diplomacy, then we could create an investigator and diplomat templates, but it might be more interesting to create a bunch of templates regarding different forms of investigation and different forms of diplomacy.  We might also focus on having children for characters.  How would low stats impact the game, especially if the characters often deal with monsters?  Perhaps we could allow Luck and Serendipity to make up for the bad rolls characters are almost certain to have?

So, for example, we might have a core template that deals with the age of the children.  Younger children have lower stats, tend to be more pure and innocent, and have more luck and serendipity.  Older children (or teenagers) have better stats, tend to be afflicted with the sorts of problems teenagers have.

We might then offer lenses for how characters handle investigation or diplomacy.  Investigative lenses might be:
  • Bookworm (Lots of research skills, hidden lore and high levels of IQ: learns things by reading about it)
  • Explorer (Lots of physical skills, climbing, crawling, getting into places you shouldn't, and surviving weird situations; learns things by going to weird places)
  • Street rat (Lots of stealth, thievery, area knowledge; learns things by doing things he/she shouldn't)
  • Angel (Has good skills for interacting with humans, especially adults, and has means to access adult-level investigative resources and problem solving abilities, though obviously can't call humans to help with the monsters because the grown-ups don't believe in monsters, duh)
  • Weirdo (Strange abilities, divination, precognition, omens; learns things by receiving visions or "just knowing")
Diplomatic lenses might be
  • Sweetie (Getting monsters to work with you by being charming, attractive and compassionate.  The sort of kid who offers candies to the monster under his bed, or the sort of girl who kicks off a romance with a vampire)
  • White Knight (Someone is going to want to fight with monsters; we can create a template that mixes combat skills with "war as diplomacy."  The character has multiple means to subdue, but not kill, a monster, and also to protect his friends if things start to go wrong)
  • Bully (Similar to the white knight, but with a greater focus on intimidation and size)
  • Crybaby (Evokes sympathy, or annoyance, from monsters, and uses straight-up manipulation to get what he/she wants from the monster; Pitiable is a must!)
  • Witch (Understands the monsters because is fascinated by monsters; has unusual abilities that allows them to manipulate the monster directly, like spells, or knows the "language" of the monsters, literally or metaphorically)
Players can mix or match, and I think when people start to see something like this, they can already begin to see how characters might play out ("Oooh, I wanna play a tough girl teenager street rat white knight who worries about what monsters will do!" "Okay, I'll play an explorer cry-baby kid that you need to babysit who is always getting away from you, ending up in the hands of monsters, and totally wrapping them around his finger!")

Cycle 3: Subsystems

Gear, magical powers or unusual mechanics tend to require their own cycles.  Try to focus on those most immediately relevant to the game you're trying to create.  For example, in our wainscot game, gear probably isn't that important (gizmos and doodads might be, though), but in Psi-Wars, technology is critical!  In a cyberpunk game, hacking deserves its own cycle, while a kung fu game needs at least one cycle for martial arts.

These cycles tend to refine all that came before them.  The addition, or the improvement, of a subsystem might interact with other subsystems and it will definitely interact with characters.  With each change, you'll need to go back and edit the characters you made.  In fact, it's possible to skip the character cycle entirely and just focus on subsystems, derive the core mechanics from those subsystems and create character elements out of those.  That said, I do recommend having at least one cycle that focuses on characters so you have at least a placeholder in which to put your mechanics, or a rough idea of what your mechanics will look like.

For our wainscot fantasy, we might look at investigation (borrow them from Monster Hunters or GURPS Mysteries?), Diplomacy (Social Engineering), magic (GURPS Magic, GURPS Thaumatology?  GURPS Ritual Path Magic?).  We might also look at innocence vs cynicism, and create a Corruption system based on GURPS horror where characters need to balance their humanity with their interest in monster, with characters who spend too much time with monsters risking becoming "lost" and being unable to return to the human world, while being too human, and "growing up" too quickly risks losing connection with the monster world, similar to Changeling's "Banality" concept.  Angels might start with a lot of humanity, while Weirdos and Witches start with a lot of Monstrousness.

Cycle 4: Setting Elements

Likely not literally your fourth cycle, as subsystems can take up many cycles of their own, but I recommend holding setting for last.  You don't have to have a setting.  None of the GURPS Campaign Frameworks do, as they're toolkits for building your own premise (an After the End with a focus on zombies and demons is entirely different from an After the End that focuses on rampaging killer robots).  When I tackle Heroes of the Galactic Frontier, I'll focus more on offering tools to build your own setting than on a specific setting.

Sometimes, though, you do want a setting.  Sometimes the setting interacts heavily with the subsystems and the character assumptions.  For example, a historical crusades game obviously depends heavily on the setting in which it is built, and you might need to choose which religion your character follows, or whether they're knights or what have you. Cherry Blossom Rain templates essentially boiled down to generic Warrior or Ninja templates from Martial Arts that got modified based on Clans, which were built into the setting.

You don't have to take the whole setting at once.  You could poke at individual elements.  Cherry Blossom Rain worried about clans, but little else when it came the setting.  Psi-Wars has focused almost exclusively on factions and organizations so far, because you need to have the war between the Empire and the Alliance, and where that war happens is less important.  The Wainscot fantasy might focus on monsters and their relationships with other monsters, and not particularly worry about the exact location.

But you can do a complete setting, if you like.  And if you do, you should go through the same basic process.  Does your setting actually work?  What do people use?  What don't they use?  How can you refine it?  The Psi-Wars version of this has been too big and cumbersome to easily see, but I do work on tests for each setting element behind the scene, and once I've finished philosophy I plan on doing a complete refinement of all the elements I've done so far.  I do think Psi-Wars is a good example of being careful when approaching setting, and why you should do it last: Setting can easily consume a lot of time and despite claims to the contrary, it is a lower priority.  You need to have your core gameplay elements first.  The perfect setting with no gameplay elements is no game; the perfect game with no setting can run on an improvised or obviously-stolen setting (We can just make our wainscot game an obvious rip-off of Stranger Things or Harry Potter, if we wanted).

Conclusion

And that's it, the whole process in a nutshell.  The idea is to finish your work as quickly as possible, understanding that you can always improve, and that you should focus on cycles of improvement, but be able to break out at any particular point to release whenever you need to.

I personally think game design and campaign building is some of the most fun stuff you can do, but nothing quite beats sharing that fun with others.  You should build your campaigns to be played in, and thus build them with an eye towards how they play.

Also understand that you're better at this than you think.  By focusing on the simplest and most obvious things first, you'll get farther than you think.  You can absolutely build a professional-level setting or campaign, you just have to do it one small piece at a time.  Do what comes easiest and fastest, and you'll be fine.

If there's ever one lesson I want people to take away from my blog, it's that you can do this.  There's nothing that really separates you from the likes of Kromm or RPK or Kenneth Hite other than experience.  That might be a considerable amount of experience, and I don't want to sound like I'm dismissing their achievements (not at all!), I'm just noting that their level of capability is achievable.  And even if you're not at that level yet, you might be surprised at how good a campaign you can built.  These cycles don't just apply to your campaign, they apply to you.  It's all about building skill and experience: You try something, it doesn't work, you figure out why, you try again, and it doesn't work again, but you get closer to your desired result each time, and by reflecting on your experience, you cement your skill.  Your second framework will go faster than your first, your third will be even better, and perhaps you can publish your fourth.  That's why I say this applies to all creative processes: Ultimately, what you're doing is perfecting your skill while you perfect your work.

No comments:

Post a Comment

Note: Only a member of this blog may post a comment.

Related Posts Plugin for WordPress, Blogger...