Monthly Archives: August 2015

An NPC Grid

I was watching some clips of Leverage, as I am sometimes wont to do, and I was particular taken by a sequence of supporting characters.

The thing about Leverage is that the crew are very capable, but they also have a code, something that makes them good guys. I’m calling this clarity, but feel free to pick your own word. It’s important that there are two axes, because they provide a useful comparison to the characters around them.

That is to say, if there is someone important to the show who is not a member of the crew, they are lacking in one \of those two categories. Characters who have capability but not clarity tend to be enemies or foils (Sterling, Chaos and so on). Characters who have clarity but not capability tend to be allies and supporting characters (the FBI agents, Maggie, Jack Hurley). Characters lacking in both tend to be mooks or victims, and sometimes marks. It’s all pretty easy to illustrate in a grid.

 

Marks, notably, fall outside of this arrangement because their role is very different. They are often more and less capable than the crew, and may have both more and less clarity. I’m ok with that for Leverage.

 

Anyway, I’m intrigued by the grid because I want to remember to use it in my own games, specifically to make sure that I have names in every box. It’s easy to remember the foils because they’re so much fun, but it’s worth the effort to remember the sympathetic NPCs. If your heroes have clarity regarding who they are, nothing tests that like someone else trying to live up to the same rules and failing.

But it’s also kind of Leverage specific, since it’s a game where it’s appropriate that the PCs are “up and to the right”. That’s far from common, so I tweaked the model a bit for more traditional games.

 

Notably I replaces “clarity” with “drive”. This partly moves away from the moral component from leverage, but it also allowed me to move the foils to the right. 🙂 In this case, drive equates to the strength and direction of a character’s agenda.

The lower left is still largely the same, except the foils have been replaced by neutrals – characters who could act, but choose not to. On paper, these should be the most boring of characters, but in small doses they tend to be quite compelling.

Above them is the Old Man From Scene 26, which is the stand in for overpowered NPCs with no reason to be there. They tend to not contribute much to a game, but some setting shave a role for powerful observers or the equivalent. They may be more prize than participant.

To the right we have the mentors – the folks who are similar to the PCs but more capable. As with the Old Man From Scene 26, these can be a problem, and it’s best to either remove them from the board early, occupy them, or make them a source of trouble in their own right (in the sprit of the elders of Amber).

I put villains in the upper right, which may seem weird, especially since it’s so close to the PCs and the mentors, but consider: what makes a villain interesting is that they are at odds with whatever the characters want, and they cannot easily be turned from that path. Without those two characteristics, the villain is merely a challenge.

Foils re-emerge on the far right – they are as capable as the PCs, but their motives take them elsewhere.

The lower right is the category I’m east sure of – NPCs with little capability but a lot of drive. That is to say – plot hooks. And that’s great as far as it goes, but I’m not sure what I’d do with an NPC who lives in that space.

 

As with the Leverage grid, the utility of a grid like this is to be able to drop your NPC names and see if any gaps reveal themselves. It’s a simple trick, but maybe useful.

Goblins Cannot Build

Hopping back to the Elvish Empire for a moment

For the elves, “goblin” is a catchall term that encompasses the brutes among thier populace, as well as numerous monstrous races, most notably goblins, orcs, bugbears & hobgoblins. The accuracy of using a blanket term for all these races is fairly questionable in any abstract sense, but these distinctions are unimportant to the elves and their subject people.

It is well known that the goblin armies were the most pernicious enemies of the elven reclamation, and it is frequently asserted that it was the threat of goblinkind that forced the elves’ hand, triggering the reclamation in the first place in order to unite the peoples of the empire to stop them.

And stop them they did. The goblin armies were shattered, and the survivors forced to flee or to bend knee. Some called for the eradication of these monsters, but the elves stayed their hand, and instead showed mercy, imposing only a single rule upon these now-subject peoples – Goblins Shall Not Build. The penalty is death.

Nowawdays, people think of goblins as monsters and don’t think much deeper than that. Some remnants of the old armies exist within the empire, a point that kinder souls take as evidence that they are capable of civilization, and it is only that those existing in the wild have chosen a monstrous life. The Goblin Law is ironclad, but is seen as only fair punishment for the horrible harm caused by their armies.

And goblin armies figure heavily in song and story. Numberless hordes of fierce soldiers, hungry for blood. They are the classic image of opposition to be found in most of the empire’s art.

Only a handful of scholars realize that it was not the armies of the goblins that made them dangerous, but rather the goblins themselves. A clever, industrious people, the goblins had made numerous technical and infrastructure advancements which did not rely on magic. They had entered alliances with numerous peoples (included all those currently considered to be “goblin kind”) and were experiencing a golden age of advancement and enlightenment when the elvish reclamation began.

Coexistence was not an option, and since their defeat, the elves’ zealous enforcement of the Goblin Law has kept them from reclaiming what they have lost while allowing the elves a lawful seeming pretense for the systematic oppression of their people.

Since any new construction will draw the forceful attention of the elves, the goblins have become nomadic, finding shelter of opportunity. Old caves, abandoned buildings – any existing construction which allows them to live without drawing elvish ire is likely to draw goblins.

This is not a matter that is given much thought in the empire, save among the gnomes. During the reclamation, the gnomes had close ties to both the goblins and the elves, and worked tirelessly (but fruitlessly) to come to some sort of accord. As a result of this (and subsequent generations of offering goblinkind what shelter it can) the gnomes have a poor reputation among the other people of the empire, as shifty, untrustworthy goblin lovers.

Apologies if there’s a bit of noise on the feed. I’m experimenting with a new client to see if i can make microblogging as easy here as it is on G+. Specifically, seeing if it might be suitable for smaller posts. Like…about this big.

Less Than Unique

templar-shield.pngDungeon World does an interesting thing where a character playing a class is the sole representative of the class in the world. They are the fighter or wizard and whatnot. It’s a nice gimmick, and a few games use it, because it underscore the role of the characters as protagonists, not just interchangeable pieces.

Contrast that with D&D 3e, which did something very clever with “NPC classes”, which followed the same general rules as PC classes, but were simply less awesome. Most NPCs who fought were “Warriors” of whatever level was appropriate, and while they were capable at fighting, they lacked the bells and whistles of the PC classes.

The game I’d like to see is somewhere between those two, where PC roles or classes are meaningful, but not unique. That diminishes PC spotlight somewhat, but the tradeoff is that it gives them a stronger social context. A world where you are The Paladin is maybe a little bit different than the one where there are a dozen Paladins, and you are one of them.

The exact number doesn’t matter a lot – it could just as easily be 108 Paladins. It just matters that there’s enough of a boundary that it matters, but not so much that it has no context.

 

Yes You Kan(ban)

Kanban is an agile methodology that has its roots in japanese manfacturing, but for most people the term is synonomous with “lots of sticky notes”. The rub is that both of these things are true, but because of terminology, things get weird.

Kanban is used for work that proceeds like a production line, where the issue is not schedules, but predictable workflow through a number of stations. To use a hypothetical situation, let’s say we have a little pizza place. When someone calls up, the following things happen:

  1. Someone answers the phone and takes down the order
  2. Someone grabs a round of pizza dough and spins it flat.
  3. Someone adds the toppings to the Pizza
  4. Someone puts the pizza in the oven
  5. Someone takes the pizza out of the oven
  6. Someone boxes the pizza
  7. Someone copies the delivery information onto the pizza
  8. Someone puts the pizza in the “to be delivered” stack 9) Someone grabs the pizza and delivers it

Now, that’s unpacked pretty far. In practice, a lot of those steps can be collapsed because they’ll be done together. With that in mind, we might define a number of workstations:

Workstation 1: The Phone, where orders are taken.

Workstation 2: The prep area, where the pizza is made, then put in the oven.

Workstation 3: The finishing area, where cooked pizza is boxed, labeled and put in the stack.

Workstation 4: The stack, where pizzas to be delivered go.

In theory, at any given point, a pizza will be at one of these stations.  But that’s not quite correct – there is another pseudo-workstation between 2 and 3, where the pizza is cooking.

So if you drew this out, i might look like:

pizzaflow

This is a rudimentary workflow, and it’s a great starting point.

Now, imagine that you put this up on a board.  When a call was received, the first person wrote all the information about the pizza on a post it, and slapped it up under call received.

When the person in the prep station freed up, they’d grab the next card under Call’s received, and start prepping it.  When they finished, they’d put the pizza in the over and move the post it to the “cooking” status.  When the oven dings, the person at the finishing station grabs the pizza and the post it, and boxes and labels it up, then moves the post it and the pizza to the “ready” column.

(Aside: This is simplified for illustration, so roll with me here).

Now, that workflow chard has become a means of keeping track of Work in Progress. It might look something like this:

pizzaboard

 

 

This is a “Kanban Board” and it’s what most people think about when they talk about Kanban, because this kind of board is a FANTASTIC way to make work visible.  At a glance you can see what’s happening where. There are a lot of applications for this, and many of them are outside the scope of Kanban itself.

See, in Kanban, we’re not doing this as a convenient dashboard, we’re doing it to identify capacity constraints.  What does that mean? Well, notice there are a lot of cards on Prep, but nowhere else?  Prep probably takes longer than taking a call, but it only takes about as much time as finishing, so what’s the holdup?

The holdup is that the oven is a bottleneck.  It can only process one pizza at a time, and so no matter how fast or well we take calls or prep pizzas, we’ll never go faster than the oven.

There’s a bunch more to this.  Consider, for example, what happens when our oven can handle 4 pies at a time, but there’s only prep space for 3 pizzas – we waste that extra capacity.

And this is super valuable when you have work that needs to get done, and this approach can be applied to many more problems than may be immediately obvious.  But for a lot of people, the *board* is a more useful takeaway than the capacity part.

And it’s hard to fault that. While the model is designed for a one way flow, it works equally well as a state tracker, where things might move in either direction. To use a gaming example, suppose you’re doing a Fate style fight across 3 zones.  You could draw the zone to track them, sure, but just as easily you could do:

fightboard

 

 

Note that by introducing color, I’ve introduced a new way to track information – the PCs are blue-green while the monsters are yellow. I can mark them up and move them around as the scene progresses, no problems.

Now, there’s a reason we have minis and maps – they’re already pretty well established information technologies.  This is not just a substitute for that.  To see what we can do, let’s consider a more complicated example.  Perhaps you’re running a more political game, in a city with a powerful nobility, clergy and guilds.  The players are trying to get support to, say, fund an anti-dragon initiative.  This is not a single scene, but rather something that’s going to drive lots of play, as players talk to movers and shakers, cut deals, trade favors and so on.  As the GM, if you want to keep track of this all, perhaps you do something like.

 

intrigueboard

Note that I have added something new – the cards are now distributed into bands, or “swimlaines”.  In business, these might be used to denote different projects using shared resources, but the idea is portable to anything where a littler separation would be informative.  For example, it is clear at a glance that the guilds and church lean in different directions with this.

The key is that as play happens, this layout can change, with cards moved around based on events.  The GM can keep a general overview of the state of things without needing to over mechanize it.  This comes in equally handy when you want to keep track of the movements of a conspiracy, the threats to a border town, or the agendas of megacorps.

The bottom line is that the kanban board is a powerful, versatile tool that you would be well served in adding to your toolkit.

Why Agile?

QmarkSo, it’s great that Agile can improve software development, but what the hell does that have to do with games?

To my mind, quite a lot, and on several different vectors.

First, there is *direct* overlap between games and agile as numerous people have been creating games to illustrate and teach the principles of agility.  There are games like Cards for Agility that use existing game models to teach these ideas.  There are learning games like the ones that you can find at Tasty Cupcake.  Books like Gamestorming and Innovation Games take game ideas and apply them to solving business problems.  There is a whole school of thought surrounding “Serious Games” (games with a purpose other than entertainment) and most of the conversations I hear out of that space have a lot of room for improvement on the game side.  it’s a conversation we should be enthusiastically engaged in.

Second, Game Design is as much a discipline (and a business) as software design, and there are lessons that we can learn from the process.  This may not be as relevant to the lone auteur, producing work in isolation, but if you are producing work with collaborators (editors, artists, other designers) and incorporating user feedback (play testing and actual play reports) then the patterns of your work may echo those of software development, and by extension, may benefit from the same agile tricks that help in those environs.

Third, the actual *act* of gaming is often collaborative, iterative and continuously improving.   if that doesn’t suggest a highly permeable membrane between these ideas, I’m not sure what would.

 

Getting Agile

Ok, I have been bribed to talk a bit about agile and gaming, two things I am very into, and which I like to pull back and forth between for inspiration.

For the unfamiliar, “Agile” is a term to describe a certain flavor of how to run a project, usually in software development. The term has become jargon, and there’s a lot of other jargon associated with it (Scrum, Kanban, XP, Lean and so on), and with that jargon comes a lot of strong feelings. With that in mind, I offer this disclaimer: I am virtually guaranteed to misstate something about agile, or present an idea at odds with your experience of agile. Please take no offense at this, and just accept it as a result of the breadth of agile as an idea.

So, that’s great and all, but what the hell does it mean?

At its most basic, a project is agile if it’s collaborative and incremental, rather than top down and all at once. There’s a very famous illustration of this, so famous that I dread using it, but I guess there’s a reason that it’s famous.
Agilecar

The idea is that if you build in small increments that each have a clear “done” state, then you can more easily change direction according to your priorities (Customer needs, market conditions) and you can morosely course correct when something goes wrong.

This can be very counterintuitive. If presented with a project that might take, say, 16 weeks to finish, the instinct is to plan out what needs to get done at the outset, then go heads down and work hard to produce the finished product by week 16. That feels efficient. In contrast, breaking it down into eight 2-week “sprints” of work, where each sprint produces a product that’s a little bit closer to the goal seems baroque on the surface of it.

The reality is a little more interesting. That first approach – to plan and then do a bunch of work – works well on paper but it is very rare that a project ever actually proceed with that kind of clarity. Things change or happen which cause disruptions, and 16 weeks quickly become 30. Agile’s apparent inefficiencies become advantages when disruptions come along (as they do) because when you change direction, you are only changing 2 weeks of work, not 2 months.

An analogy I like very much is that agile is like driving a car by your headlights. They don’t need to illuminate the entire route to your destination, only the part you need right now.

Obviously, there are a lot of complexities when this hits reality. Agile is usually associated with software development because the nature of the work supports this kind of incremental effort in a way that, say, building a bridge may not. And there are a lot of different ways to be agile. The 2 week sprints I mention are used in scrum (an agile methodology) but are just one way to approach things. In contrast, Kanban is less about periods of time and more about keeping workflow moving from moment to moment.

This is a big iceberg, and there’s no way I can show it all at once, but hopefully this gives a decent starting point.

So far I’ve largely talked about how agile is incremental, but I haven’t talked much about how it’s collaborative. Another reason that Agile has been embraced by software development is that is is strongly focused on the people doing the work, with very limited roles for others. The expectation is that the role of non-developers is to give the developers a clear understanding of what’s needed, and then let the developers do their job for a while. Eventually the developers will emerge and show what they’ve built, there will be some discussion about what works, what doesn’t and what’s needed, and then the developers return to their caves to work again. Outside of that, meetings are limited to just making sure everyone stays in sync.

But all of this points to the third leg on the stool, the one I haven’t mentioned yet: Continuous Improvement. This idea is tied to “Lean” (and that’s a whole story of its own) but it’s been adopted as an agile best practice.

What this means in practice is that a certain amount of the team’s time is spent talking about how the work has been going, what works, what doesn’t work, and what can improve. There are different tools for this, but the most common is the retrospective, a dedicated meeting where the team answers:

What did we do well, that if we don’t discuss we might forget?
What did we learn?
What should we do differently next time?
What still puzzles us?

There are going to be future posts that build on this one, about how agile intersects with games and game design, but I want to make sure there’s one practical takeaway here. Take a look at those four questions. File them away, and sometime in the future, when the game you’re running wraps up a little early or starts a little late (or maybe in post mortem email), bounce them off your players. See if any of the answers help your game.

Then do it again. Do it enough times that your players feel *comfortable* answering the questions. Once it’s habit, I suspect you may find that the discussions these questions inspire may be very fruitful indeed.