Aug 25 2011

Hollowpoint mission design

I’ve had a chance over the past few weeks to get lots of input from actual play and even to participate in a couple of games with new players acting as ref. This has been very insightful and led me to think a little harder about what makes a mission work. As usual, a lot of game design for the VSCA is translating what we do instinctively into a set of rules and we frequently leave a few things out — sometimes on purpose, mind you — and therefore leave to instinct.

One of these is the fact that in Hollowpoint there’s no strict mechanical pressure to use one skill over another. The intention is that this pressure comes from the context of the scene and a certain amount of peer pressure to narrate appropriately and therefore not use KILL in an interrogation. The rule is fairly straightforward: if you KILL someone they are dead. Dead people do not give up information (though it’s worth noting for those of you out there skinning this cat — if you have magical powers — like talking to the dead, say — in your game, KILL might be a great way to get information). Therefore successfully killing someone fails the objective for the scene.

So let’s try to codify this a little by breaking out some basic scene objectives.

If you are trying to take some territory (flee a bank robbery to safety, say, or occupy an enemy fortress), KILL is a very good choice. KILL takes territory by eliminating resistance. TERROR is also very good. TERROR takes territory by neutralizing opposition (whether they flee or collapse is irrelevant). Despite the name, TAKE is not a good fit. CON might be a pretty sly way in if the story is good. DIG is not helping. COOL…well, I’ll talk about COOL because it’s a kind of universal skill though not in a way I see as problematic. You can use it for practically anything but they are almost all hard stories to tell. Pick COOL as your peak stat only if you’re up for some very creative narration that works. For taking territory, I’d say no, generally, but there are stories out there that scream “yes”.

If you need to gather information in a scene, KILL is not helping. TERROR might. CON is always good. DIG is the obvious choice. TAKE…well maybe, depending on the specifics and the story the player comes up with. COOL, well I already talked about COOL.

If a scene is about putting the Fear into someone — making them toe the party line by encouraging them forcefully — and that someone is not present in the scene as a principal (you are “sending a message”), then KILL is okay! TERROR is a perfect match, clearly. CON not so much. DIG, maybe, with a good story, but generally a tough sell. TAKE? Don’t see it, but again if the story to date sets that up, maybe. Just to be clear, the horse’s head in the bed schtick was clearly TERROR and not TAKE. The characters didn’t keep the head for anything. I know, no one knows what happened to the body. Maybe they took that. Whatever, you’re quibbling.

Now if the scene requires that you acquire something from somewhere, KILL is not useful at all: KILLing doesn’t get you things, it kills people. TERROR is pretty weak too. TAKE, obviously, is perfect, but so is CON. DIG is a hard sell unless the thing you want is information.

If you need to accomplish something without alerting authorities1 then regardless of the objective, KILL might be the wrong choice.

Now this is still kind of vague (though less, so, I hope!). If the scene is set such that someone has a brilliant territory-taking solution with DIG, well, let it stand. The system self-balances even if everyone always takes their peak skill through a few mechanisms:

  1. Typically there will be a diversity of peak skills and the optimal solution to a simple fight is to all use the same skill. Therefore some people will be using weaker skills in the optimal group solution.
  2. Having a lot of dice can be a problem, so it may be the case that you want a weaker skill. This is more often the case when asking for help — you might figure 7 dice is perfect, so you want to use your peak (5) and get help from someone elses 2. Or maybe use your 3 and ask for help from their 4. You’ll have to work out for yourself where the sweet spot is for dice, but let me tell you, getting a 6×5 and a pair of 1s sucks hard. You leap out unprepared, surprise them, take a die, and then stand around as a target.
  3. The Catch requires a specific skill. Make it one that is not clearly primary to the context (escaping a guarded fortress but you have to crack the key code on the door with DIG or it all fails!). Use the Catch if skill use is getting dull. If no one is very COOL, make the Catch a seduction!
  4. A principal in a scene creates two targets to take out, and they could be taken out with different skill effects. If the objective is to interrogate the principal, then KILLing the henchman is fine, but someone better be doing something else to the principal.

Now you might be thinking, well, what about that rich scene, where someone is killing guards while someone else is taking the objective and someone else is hacking the computer system down. How does that happen when everyone picks the perfect skill for the mission? Well that’s easy — whatever skill gets brought to bear, it is useful in picking off dice before the effects actually get laid down, and so those skills become part of the story even if they are not strictly addressing the objective of the scene. That is expected and desirable. That happens very frequently unless the team lacks diversity and everyone has taken KILL 5. Or COOL 5, though those scenes are intrinsically awesome.

Well they better be. If you are narrating for a COOL 5 character, you better be on your toes and prepared to sell it. Flick that cigarette butt off the bouncers jacket and stride on through the door, partner. Flash that grin. Be confident as hell not just because you are the dog’s balls, but also because Amy is outside with a bazooka and she likes you.

She likes you a lot.


  1. Hey, it happens — set the scene: “The heat is on and you can’t afford to get noticed now. That last firefight in the junkyard might be a valuable diversion for this next action, but another mass murder could bring the hammer down on you. Your boss can only protect you from so much.”

Jul 19 2011

Research and development and gunfire

This is not related to the fact that I work in the R&D department of a (non-military!) branch of a national defense contractor.

It is about the value of research and development in game design and in particular in the effects of the VSCA “playstorming” model for R&D. This is interesting at this very moment, because Hollowpoint is an unanticipated spin-off from an R&D effort for a completely different game. Maybe even more interesting is the fact that the target game, J B Bell’s Chimaera, is ostensibly about non-violence. Hollowpoint, of course, is pretty much completely about violence (both in the expected literal sense and in the broader sense in which the non-violence movement intends the term).


Playstorming is what we have pretty much always done when we sit at the table, because we just can’t leave well enough alone. Fiasco is probably the first game that we didn’t instinctively playstorm as soon as we got it.

Playstorming is a deliberate play on “brainstorming” and I think its meaning is pretty self-evident. We sit down at the table with some broad ideas and see if they are a game by playing them, changing them, arguing about them, philosophizing about them, drinking some more, playing some more, and iterating over all of the above. Most often this produces fairly little, but it’s fun to do and so that fact that it does have some net product makes it worthwhile.

In this particular case, J B was looking for a dice system to underpin Chimaera. J B has a fetish for dice systems and I don’t, so it seemed like a good thing for me to look into. We’d just come off some Reign gaming (though we are always coming off some Reign gaming — it’s a staple) and so I was thinking ORE-like thoughts. We’d also been playing around with 3:16 Carnage Amongst the Stars and while that game didn’t get as much play as we’d hoped, it did stir up a lot of ideas about character and content and the relationship between the two.

Anyway, I worked up this strange dice system for Chimaera and we took it to the table.

It sucked

It sucked. Well it didn’t really, but binding it to other elements of Chimaera proved a bit of a chore and J B was not happy with the ref’s role in it — it didn’t deliver the kind of one-on-one, guy-versus-guy, monster hunting action that a good non-violent game should. I, however, was still enamoured with it. And so I stole it.

Stripped of the rest of the Chimaera context, this dice system seemed like a good way to spur and spark and even generate story in the middle of a fight. So I decided that its best use would be in a game that was basically about fighting. Or at least being very bad. I had probably also been in some juvenile debate about “roll-play versus role-play” and found myself very much wanting to smash that phrase to pieces. To do so, I chose to develop a system in which the dice and the role-playing were so intermingled that the dichotomy would be exposed as artificial once and for all.

And we got that. In Hollowpoint, there are of course the usual free-form role-playing scenes. You can’t stop people from doing that and why would you? But the real meat of the narration comes during the fight, when the dice hit the table, and you are forced to make sense of what happened in the context of what you intended. You chose to use TERROR but you got nothing in your dice, so you burn your “ceramic hula girl” trait, add two dice, and get two shiny new sets. Now you are officially TERRIBLE and it has something to do with that ceramic hula girl. Tell me about that. Make each set make sense as it does harm, as the glass shatters, as the dumpster fills with holes, as you laugh and they cower, as the hula girl shatters. Roll-play like hell, you monster.

And so I came to the table with something from my earliest gaming memories: a typed sheet with a mission on it. It was Top Secret , 1980, all over again. We used to play a lot of that game and the way we played it would inform Hollowpoint: as a ref I would come to the game with a typed set of mission orders and that was the extent of my preparation. The game would invariably take place right in my home town, which is part of why the prep was so effective when so light — your home town is a crazy-rich setting that all your players know more about than anyone knows about Forgotten Realms.

So we would do that too.


Needless to say, I was excited by the results. It pushed all kinds of buttons for me, from childhood cops & robbers to Top Secret (now I’m a little concerned that VSCA games are all going to actually be strange re-constructions of old classics) missions to assassinate my math teacher, to narration-from-dice. This was all very unexpected — recall this started as an experiment for another game, and an experiment that went badly. But what I wound up with was a game that was basically everything I wanted in an action game. I just hadn’t actually thought about making an action game yet.

And that’s the thing about good R&D — failures have a context, and if you reconsider the context, you may find yourself with an accidental success. Risk is necessary (I recently told a colleague that innovation meant “new” and that “new” meant “risky”, and so de-risking an R&D project is basically killing it) for innovation. But you have to have a sharp eye and an inclination to sift through the rubble.


Jun 27 2011

Robots and Role-play

This weekend I had that great moment where you get to reveal something awesome you know to people who don’t know it. And you know they want to know it. In fact, you know they are going to take it and run like hell and probably score touchdown after touchdown with it. This is especially wonderful when you are pretty sure you are not going to score touchdowns with it. The football in this case was the Mythic GM Emulator.

I was hanging around in Gamefiend’s D&D 4e IRC server (that’s #4ednd on and talking about online role-playing. I like me some online role-playing, especially by IRC. I like it because it tends towards the multi-GM model — lots of people in the mix feel relatively free to grab a little narrative authority and hours of great fun can pass before a designated GM even shows up. This is huge fun for me, but the stories that come out of it are mostly chatty — characters trying to get other characters to put them in a situation where they can divulge their backstory. That’s fun, but it’s not a whole evening’s worth of it.

Well the GM Emulator came up in regular conversation and I think it meshed with ideas Gamefiend already had about adding some automation into the role-playing chat channels. Anyway, there was a flurry of PDF purchasing, and then a bunch of great and heated back-and-forth about what to implement, and then bang-zoom-code. Brent Newhall packed together a bot in python within a very short time and soon it was in the lab.

The bot is called Arbiter and what it does is really simple. If you ask Arbiter a question, it answers with a yes or a no and, some fraction of the time, a twist statement. What this does is really interesting. For example, I was playing Keln, who I wanted to be an airship pilot. I didn’t know if that was a kosher choice in the setting but rather than ask a GM, I ask Arbiter. This is where his name is important — he doesn’t just say yes or no, he implicitly grants authority to you.

So Arbiter says, “Yes, with the twist of a beautiful woman and a gambling debt.” 1 So now I have been granted authority to not only be an airship pilot but I have also been granted the authority to introduce some new elements and everyone sees and is engaged in helping that out. So my internal story is that I lost my airship to a beautiful cheating gambler. Someone else latches onto this and clearly wants their character to be that gambler in disguise. Spark spark flame.

So here are the themes that are interesting to me.

Simplicity drives complexity. Arbiter does not need to be any more complex in order to be awesome. Features can be added but at this point it’s pretty much gold-plating to do so. Yes or no, optional twist and you get triggered complexity from participants.

Authority comes from one place. In order to have authority it must be granted. It can be granted implicitly (I’m the GM in a game that has a GM) or explicitly through the rules. With Arbiter, authority actually resides in the stupidest member: Arbiter! He’s like the worst umpire ever, randomly saying “ball” or “strike” and not paying attention to the game at all. But as my favourite professor once said, that umpire is 90% of a good umpire. You need someone to decide more than you need someone to be right.

Those who want it, drive it. Because Arbiter is optional, it only triggers when someone demands information. Even then, it is only attended to (in the twist) if someone decides to do so. This is wonderful because there’s no pressure to perform (which can paralyze) but someone is bound to grab that hook and do something with it. No one is unduly put upon — if you want to mostly coast and react2, you can do that. But if you want some authority, you just ask for it.

The smarts are in the humans. For two reasons. First, and obviously, because humans interpret the answers creatively in order to produce content. But more importantly (and this was Gamefiend’s expectation but not mine) because the essential creative power is actually in asking the right question. My initial concern was that some high percentage of answers would just be “no” and this sounds boring to me. It is boring, absent the context of the question itself. When you know that those are the limitations of the Arbiter, though, you craft questions so that the answer will be relevant. My airship question, for example, was a grab for authority to establish certain setting facts. A “no” might have been boring there, but the possibility of “no” was essential for the authority of a “yes” to be legitimate. I swear there are other examples but I don’t have the chat log handy. Watch this space.

So this has my brain by the nuts at the moment. This is super cool space for gaming. All it needs is an underlying resolution system that is also very friendly to the fast pace of IRC play and can use arbitrary (see what I did?) granting of authority rather than rely on the coordination of a single human. And maybe a way to keep track of the facts list that evolves (something that a GM would normally prepare but that this system kind of demands emerge from play).


  1. Not verbatim
  2. And I don’t mean to denigrate that — a party full of high-initiative people all grabbing at every hook can be a nightmare.

Jan 5 2011

Lessons Learned 2010

Last year we spent a lot of time imagining, writing, and testing new games. We expected to get two titles out of this at least and maybe three or four. We didn’t get any. Well, we got one (Hollowpoint), but it’s still not in publication because I am a lazy bastard and am still laying it out. I will spend a little energy thinking out loud about what this year taught me and why that translates into so few new games.

There’s a great book you should probably read called The Mythical Man Month by Fred Brooks. It’s about software engineering in the 60s and it’s not strictly true any more with respect to software engineering, largely because of critical changes in communication technologies which change the cost of interaction, possibly below some critical threshold. Anyway, whether or not the core premises are obsolete, the book still contains powerful insights about system projects, and games are system projects.

A system project is a project that builds some relatively complicated machine that can be broken down into sub-components that are also machines. Machines are things that take an input, crunch some process over it, and create an output that is more useful. A lever is a machine. It takes force in one side, uses some basic physics relating to length and mass, and produces different forces on the other side that might be more useful in some contexts. Games are machines too. Complicated games are systems of machines (a randomization machine — dice, a narrative effect machine — modifiers, a spotlight-management machine — taking turns, etc.).

Making a system is complicated because you care about the interaction between sub-system as well as the specific function of each sub-system. And you can get effect loops, which is where the real monsters hide, where a sub-system affects the operation of a seemingly unrelated sub-system because you didn’t do a complete feedback analysis. Anyway, a game is sufficiently like a software project that there might be something interesting in this book if you’re interested in games.

A lot of what’s in that book is no longer strictly relevant, but one thing I think certainly is: the second system syndrome. This is when you finish one system and it works and is well-received and so you start work on your next one and you imagine all the things you did wrong on the first one. Or find new enthusiasm in focus on some particular element of the previous one. Whatever your passion relating to the first system, you over-focus and produce a plan for a second system that is broken because you’ve lost sight of the explicit requirements of your project and instead see only the passion from the first project. Projects can progress for a very long time down this fruitless path before aborting or reigning in the process.

We kind of went there. Reading The Mythical Man Month does not make you immune to it. We floundered around with several ideas which looked good to me because am designing-as-art a lot of the time and having a great time doing it. But in play it was not coming together and it took a long time to figure out that I had to start over rather than keep pushing at something that was very pretty as a machine but did not function as intended.

The eye-opener was playing other games. Note to self: play other games.

Partly this was playing games that did not work for us. Some failed because they had exactly the same pretensions I had. Some failed because they were quite the opposite of what I want to do (whether in play or in design). Some failed because character creation was not fun and I need it to be fun. Most of these failures revealed errors in my own work. Some gave me clues to new features because I didn’t know I didn’t like some things. It pays to analyze failure.

The other part was playing games that did work. Gamma World was a hoot and yet it is very far afield from my own design interests. We played some Wings of War and the elegance of that card-controlled simulation struck all kinds of chords for me. And we played several sessions of Diaspora, which reminded me what parts we did right — and that we should at a minimum not throw those bits out when designing something new with the FATE engine.

So last year we built a few second systems but, to our credit, we didn’t pursue them too far. Well, barring one, but I will reconstruct Soft Horizon this year so that it’s more fun than clever and see if we can’t rescue it. It was a fun year with lots of creative frustration but also lots of great gaming with very smart, witty, and above all, patient friends.

Oh yeah, the lesson learned? It’s not really how to avoid second system syndrome, because having read the book I didn’t really discover a way to avoid it in the first place. I only discovered that it happens. And the book doesn’t teach you how to avoid it because in a way it’s not avoidable. Rather it’s something that you can recover from once it happens.

So here are some lessons. FATE is pretty bloody good at what it does so don’t dick with it too much. The cluster generation system in Diaspora is awesome but it’s not automatically awesome — getting the stats right is critical (yay Chimaera, nay Soft Horizon). Phased character generation is a reliable way to get shared character generation sessions to work — start there. A cool new system isn’t automatically cool for every new game idea. If Tim’s not having fun then something is actually wrong. Ignore the advice of anyone who does not actually play games.

And derived from that last: play games.


Oct 15 2010

When failure delivers the goods

My day job involves research. It’s commercial research and has all the limitations and caveats that that kind of research must have, but it’s still research. One of the things you learn early when doing research is that if failure is treated as failure, you are not doing research. This is because you are in search of facts, and failures contain at least as many demonstrable, recordable, measurable facts as successes. Failures deliver the goods.

So I’m not shy about having a really good time failing. This is when there is the most stuff to learn.

Soft Horizon was a grand experiment and a kind of Brooksiansecond system” for me. Not in the sense that it was huge but in the sense that it reached too far, reaching in fact for things that weren’t actually fun. Much energy was spent trying to find the fun in them. Now, any time you get to recognize your “second system” for what it is and throw it the hell away before it consumes you, you count yourself among the very fortunate. The more you can learn from it the better.

We had a case in miniature with Chimaera last night. JB and I had some play mechanisms that were very fruitful in the narrow context we initially tested.We extrapolated the mechanism to embrace a much greater context (five players instead of two and contrary intentions to those tested — supporting instead of undermining opposition), wrote it up, and thought “this will be awesome”.

It sucked so very hard.

Fortunately this is also awesome. Two things (at a coarse scale of “things”) came out of it. First was a bunch of elements of the system that were and could be reproduced elsewhere more successfully. Second was a long discussion not of how to repair it (because that’s development and not research) but rather why it failed. This long and detailed analysis revealed very powerful facts about this game, about games in general, and about the people who are developing this game. This kind of thing is pure gold.

One thing we learned is that it’s not just hard to make non-violent support and compromise tactical, it’s also not really very fun. It’s hard to find the actual conflict to really get your tactical teeth into. In many ways it’s just more fun to talk this out than to dice it — if both sides of an issue can find a common ground to examine and resolve the issue, that talk might be more fun than simulating that talk.

Another thing we learned is that the above is only true when you are doing simulation at the resolution scale. That is, when the pattern is to declare intent and then dice to determine success or failure, it’s deeply unsatisfying for some kinds of conflict. If you flip it around, though, and get some dice out based on your rough intentions and then use the play of the dice as the basis for story — “reading” them, in a sense — it’s way more satisfying. We see this in a fairly traditional context in Greg Stolze’s Reign, where everyone tosses the dice and the interpretation of these dice describes the detail and rhythm of the fight itself. The narrative for a round’s activity is discovered rather than declared and tested for success or failure. We see this as well in Vincent Baker’s Dogs in the Vineyard, where a declaration of intent is made, dice are brought out and rolled, and the results are bid by turns to one-up the other guy and story develops from this exchange.

Hollowpoint exploits this pattern as well, allowing the details of ultraviolent behaviour (especially when it goes wrong) to derive from big compared and manipulated dice pools.

Now it’s interesting that this is how we used to play Chimaera but it was unsatisfying for reasons we had not adequately examined. It turns out that the flaw here was maybe not so deep that the system needed tearing down. So this is the other benefit of all this talk and analysis about the failure: we got down to brass tacks regarding what the lead designer wants and why previous failures were failures. This is important because it was delivering on all (well many anyway) cylinders for everyone else before. This is a clue that perhaps not much is wrong.

What we discover is that the GM was bored with the old system. It didn’t give him enough to say about the story. In Hollowpoint this is a feature, as far as I’m concerned, because the stories are so very much about the player characters and their successes and failures. In Chimaera, though, we have a more detailed setting with opposition that wants (demands) a piece of story too. Well, once the actual issue is pinned down under the harsh illumination of some failure, the fix (or rather a possible fix to test) is discoverable. In this case we add another axis of information to the dice game and suddenly story opportunities balloon (and, better, become easier, possibly alleviating some of the creative burden on players).

The other thing we discover is that the desire to behave well (non-violently, constructively) is already built into the game and doesn’t need tactical simulation to see play. In fact it’s already part of player motivations for reasons that are much more satisfying: rather than delivering some benefit to be spent later or being a fun non-violent tactical mini-game, the larger scale map, the communities and their links to each other, suggest (in some cases insist) player action that will change the map to at least be more interesting and at best be more beneficial to everyone. We can improve the safety of the road between Makata and the Dim Tower if we can just start getting this regular shipment of soybeans through, starting a regular trade. We can stop the war between Etios and Makata if only we can get the warlord and the general together to talk this out. And these things are implied (mechanically!) by the community map already. All this work (play!) only to (re-)discover that the game already knew how to deliver what we wanted.

So that’s what I call a productive evening’s failure. We didn’t play anything through, we did some character generation and community mapping and we talked (heatedly at times) and threw a lot of dice and learned a lot of extremely valuable stuff. This is a very highly rated failure in my ledger of failures. And that’s a thick and powerful book.


Oct 10 2010

Chimæra update

Yes, it still lives! A recent development for Chimæra was figuring out, with precision, what makes a Human different from a Daemon different from a Mutant. Where this came from was trying to get back to one of my RPG-design Holy Grails: emulating nonviolent action, satyagraha, Soul Force. Numerous RPGs do allow persuasion with equal footing to violence, and a few enforce nonviolence as preferable–Dead Inside is maybe the most prominent example I know.

I haven’t found those fully satisfying, and though Chimæra Alpha 1, as I’ve come to think of it, did deliver interesting play, conflict wasn’t that engaging for the GM (me), and tended to come down to fairly classic ass-kickery.

Introducing the idea of “needs” as given in works on Nonviolent Communication (especially the book of the same name by Marshall Rosenberg) into the game explicitly opened up several things. First, I put my (previously hidden or gotten at circuitously at best) priority for nonviolence on the table. Second, and a very happy by-blow, it clarified what makes the different “races” in the game what they are. Humans (generalists as in so many other games) have the ordinary six needs: Community, Health, Integrity, Meaning, Play, and Autonomy (handy acronym: CHIMPA–total accident).

Daemons, being the creatures of pure dominance and submission that they are, lack Play and Community, and add Hate. This last is not hate in the ordinary sense–for Daemons it’s an organizing principle, universal among them, understood as a given. They are bloody-minded, and furthermore, they must destroy life to sustain their own. Something in humans is something daemons must have or perish. (The vampire thing here is perfectly deliberate, as Chimæra harks back to Vampire Hunter D.)

Mutants, finally, have other non-human needs, starting with the opposites of the regular six–so, you can have anti-autonomy, the need not to have a self, such as you’d find in collective intelligences, or at least, in their individual members.

Today Brad and I finally pulled this together into a new conflict system. The map (and I think having a map is really, really useful, something the Alpha 1 version lacked for conflicts, but had for the excellent community-mapping setup) is based on the needs on the character’s sheets. Things you do in a conflict are to bring need-nodes into the map, evoking them, and linking them together with one-way arrows. Your character’s stance is represented by a pawn on the map, and what need the pawn is sitting on determines the need that you defend with. So move another becomes a pretty important tactic.

Brad and I sat down to play. Pretty simple setup. The local Daemon Knight has heard about the spiritual leader’s preaching and aims to shut him down. The knight confronts the preacher in a speakeasy where the heretical teachings have been spreading.

I opened, putting the preacher’s need for meaning on the map, a defensive value of only 2. Brad countered with autonomy as the starting space for the knight’s pawn. Also a value of 2. We had everything at 2 except one we boosted to 4, rather arbitrarily. Hate for the knight, and Play for the preacher.

I won’t go into much more detail here as I don’t have the record on me. But suffice to say, Brad played the game as designed, and as he’s a smart guy he outplayed me. The really cool thing was that the fiction had the daemon knight, a tough, badass, mean character, out-maneuvered by the preacher’s mastery of playful (though not kind-spirited) mockery. I managed to get Hate on the board, but didn’t get to it before the Brad got the preacher on Play, and it was pretty well over at that point.

It was a curious experience of frustration, because losing just kinda sucks, and elation, as a kind of scene I wanted to have, with interesting detail and nuance, fell out of some fairly simple interactions. Just deciding on what kind of space to move in, and giving that a 2-dimensional representation to look at, is very powerful.

For the future I want to make a distinction where using violence (as Brad was, even though blows were not exchanged–it’s defined in-game by what features of your opponents’ character sheet you pick up to use) has later consequences. Previously violent acts contributed to an opposition dice pool, but I’ve dumped the pool in favour of a simpler system with a couple d6 and bonuses of +2.

Anyway, great stuff, finally got to some actual play-testing, and looking forward to codifying and playing more.

Oct 4 2010


No matter what you do, you have a process by which you do it. There are a lot of self-help books that tell you about the most awesome personal process for every aspect of your life, and apparently following any one of these will make you rich and happy. Interestingly, the majority of the consumers of these books are neither rich nor happy. This is not an opening salvo on processes but perhaps an observation that all processes are more similar than they are different and you already have a process.

There are a few quantum leaps in the utility of processes. The first is noticing that you have one. Before this point, you work on whatever comes up and seems to be next and you get things done. After this point, you are able to set aside distracting things that don’t need attention yet because they come later in your process. And, more importantly, once you have a process you can write it down and look at it and wonder how to make it better. This is a huge leap forward.

The next quantum leap is when you buy software to manage your process, which is when you realize that you must either adopt the software’s implied process (change is scary!) or try to make the software do what you want. You will also find at this time that your process now includes a lot of points at which you need to fiddle with the software. Occasionally you will find your process clunking along with a flat tire as you await a feature or bug fix that you desperately need.

I am not the most productive man on earth. I’m not even a very productive man because I just don’t give a shit about deadlines in cases outside my day job. This has to do with my interest in maintaining real autonomy and real choices in my life and is tied to all kinds of philosophical scaffolding that is underneath practically everything I do. The simple version is that if I am doing something for myself, I am not going to undermine this by stressing over it. This is why selling things has complicated my life — I hadn’t really considered the ethical burden it would impose on me now that there are thousands of people interested in the thing I sold. And I bear their interests as a duty and I take that seriously.

However, for myself, I won’t eat that. And so my process for work on games includes that lack of interest in calendar pressure. Now, calendar pressure does some interesting things to processes and not all of them are good. A high level schedule for a software product, for example, has nice milestone delivery dates on it because the customer needs to see progress and may have civil engineering and other contractors waiting on installation of various stages of the work. This necessitates a “waterfall” model. We try to avoid this all the time and never do — and never can because it is intrinsic in the calendar date and the dependencies. Revealingly, it is also the underlying assumption of practically all planning software and consequently no matter how hard you try to move into something more productive, you snap back like a released rubber band every time the planning guy comes round to update things.

The waterfall model is this: we need to do these things and then we will do these other things. And then we’ll be done.

The iterative model is this: we need to do this and this and this over and over until it’s done. And then we’ll be done.

The iterative model basically sticks all of your milestone objectives (say, requirements, design, code, and testing) inside one box shakes until complete. This has the downside of meeting all the milestones at once which frustrates waterfall planners to no end. And their software can’t cope with it so you can’t do it.

But if you do do it you reap huge rewards. See the thing is, even when you’re doing a waterfall project you are actually doing an iterative project. You’re just not admitting it. This makes the iterations very expensive and this increases resistance to iteration. This reduces the quality and makes me go berserk.

Embracing the iterative model means that you get the first milestone material out in a sufficient rather than complete fashion: you build just enough so that you can get on with the next bit. Then you do the same with the next bit, feeding back information gained to the previous bit and passing on you partial work to your next bit.  So the requirements guy is fixing requirements based on the design guy’s findings and the software guy is building some runnable code based on the design and feeding back his findings to design and the testing guy is building tests based on code that is actually running and feeding back his information. This requires great communication and can become chaotic and looks (and maybe is) unplannable, which terrifies many. However, here’s the upside: at any given time you are back with stuff that does something because that’s always your objective.

This echoes prettily off the “go play” and the “actual play” elements of some game design philosophies. In particular, a really great question to ask of any little mechanism is “how does it play?” In an iterative design, you always would have something ready to play. It might suck and you might already know it sucks, but you have enough to go to the table and shake some dice and know for sure how it sucks rather than speculating. In a waterfall design you hit the table with an enormous investment in untested ideas — going back to design or even requirements is daunting and can be personally hard. With that much invested, the admission of failure is expensive to the ego.

I see a lot of little ideas out there. A lot of them are extremely elaborate. Almost none of them have seen play. This is a dangerous place for a little idea, because the investment has outstripped the confidence one ought to have in it. This is a recipe for making bad decisions.

Sometimes people ask me what a game that’s in the works is “about”. This is a question about requirements, in a sense, and so while I have a gross idea going into a project, I expect it to be refined by play. This is why I find the question aggravating at almost every stage of development: it implies that I know this and that implies a waterfall model of development. That somehow we have a clear and concrete requirement list before we get rolling with everything else. That never happens for me.

What usually happens is I get a hankering for a certain kind of play. In the case of the No Contact flurry you’ve recently seen, that was a desire to recapture the feel of a very successful d20 Modern game we played once. What’s this game “about”? Well look up there because that’s all it’s about until something else happens.

So next I start writing mechanisms up. How will we actually play this? What variables will be important? What do I want to test out here? I will write enough to go to the table and play a game. That means at least: how do we define a guy and how do we have guys interact.

And next is play. Right fricking now. As soon as enough rules are in the wiki to do it. I play with myself a lot (lol) as early as possible, testing each gear in the mechanism, but it has to get to a table with at least two people as soon as possible. And this will imply new testing, changes to the mechanism, new mechanism to write, and revision of requirements. This phase goes on for a year.

This process is intellectually appealing in part because it reduces investment. Nothing gets a lot of work before hitting the table and so it’s hard to get too attached to anything (though it does happen) that’s not actually fun. It’s also appealing because it closes in on really co0l ideas by emphasizing discovery as well as invention: when emergent properties are discovered in a mechanism, this process is agile enough to exploit them heavily and also be equipped to talk about why and how it works. These results are important to me.

What this process does not do is tell you when you’re likely to be done. Or even if you’re likely to be done. You can bolt that on if you’re clever and motivated. So I hear.

Fortunately I don’t care about calendar milestones until there’s a vested interest from outside.


Oct 1 2010

Getting shot at is scary

Last night we ran a playtest of the squad-scale stuff that I’m hammering out at the skunkworks. I have this feeling that it’s a role-playing game but I need it to play very well first as a miniatures game because that’s part of the experiment — to duplicate the nostalgic pacing of gaming that I love. That’s the pacing that goes something like INTENSE COMBAT BRAWR talk talk talk talk COMBAT BOOM BRAWR talk talk talk.

I am hoping that one way to do that is to have a great combat system and interesting characters. We’ll see.

It’s actually playtesting of Soft Horizon that has led me to this place. For all that it has excited me as an idea and as a construct, Soft Horizon kind of sucks as a game. There are a bunch of good reasons for this, but basically I think they boil down to over-thinking the refinement of FATE coupled with a failure to deliver setting hooks that grab. The game sort of lurches around and is occasionally clever. But it’s not fun enough. So I’m setting it aside for now.

What I want from this new game is a really traditional strict simulation wargame but that tracks states on characters that reflect the things that really change the course of a battle rather than tracking whether or not someone is dead. Doing this without creating a system for mind control is tricky, so instead what we want is for the presentation of the simulation to be a side-effect of the representation.

Now to do this I need to track several variables and that gets cumbersome, especially as the number of units increase, so there are some physical tricks we use in play to ease this. It turns out all these tricks also facilitate conveying the necessary information as well as tracking it, so that’s an unexpected bonus. Here’s what we need to track:

Suppression. This is the degree to which you know, rationally, it would be very dangerous to stick your head up. This is not being afraid.

Fear. This is being afraid. This is the kind of reaction to danger that demands your attention and starts you focusing on yourself rather than your duties to solving the battle as a whole.

Wounds. Injuring the enemy is ostensibly why we have rifles and stuff and, while from a desk the objective is to drive the enemy away from territory you want to control, killing him accomplishes a lot of that mission.

Detection. This is badly named — Bob suggested “exposure” which is indeed better. This is how easy you are to shoot at.

Ammunition. How much ammunition you have is pretty crucial to the game’s premise — because your group is lost and alone, it’s a finite resource. It might become a kind of “treasure” even. So you need to track it but also, more than maybe anything else, it’s something worth tracking persistently (that is, between fights). We are not simulating each trigger pull, however — it’s not that kind of simulation — so this won’t mean counting bullets or magazines. It’s not expended in the way you might think either.

Initiative. We need to know who goes next.

So we take three colours of poker chip — red for wounds, blue for fear, and white for suppression. As these values increase or decrease, the stack is added to or subtracted from. The stack sits beside the unit stand on the map. This solves the keeping-track bit. It also really tidily conveys the information to everyone instantly. That guy with the big stack of red and blue chips? Not a threat.

Detection has a maximum value, so we put a six-sided die with the current value beside the unit stand. This works better than a stack of chips of a new colour because it doesn’t change as often, it has a cap that’s higher than your natural visual counting limit, and because I only have three colours of chips.

Initiative order is represented by the roll of a die, so we put that die out in front of the player to keep track of it.

Ammunition we track on the character sheet because it’s a persistent value and it’s a treasure resource. And because it’s intrinsically secret — there’s no way for the enemy to know how much ammunition you have unless he asks you and you tell him.

So a system that looks like there is a lot to remember and manage on paper actually runs at a brisk pace when these data are manipulated in a tactile and visually obvious way.

Now what do they do? Well I’ve talked before about design goals for this and how I want Fear to make units do things without having a rule that says “you are so scared you run away”. So instead there are certain actions that reduce fear or suppression. Because the three negative status effects are also penalties on your skill rolls, you want to get rid of them. Fear you have to get rid of every turn, though — that’s your animal urgency. Play shows that this method works: scared people ran away through the bushes and if that’s not feasible they lie down in one place and shoot a lot of ammunition around inaccurately. Occasionally they hit something. Suppressed people shoot less accurately unless they find better cover or lay down some suppressing fire of their own to get some breathing space. Wounded people just stay wounded.

What stories emerge from the rules? Well we had:

  • Concealed guys with good cover and difficult terrain staying in once place, safely, hoping to ambush a careless enemy.
  • A terribly wounded man caught out in the open panic-firing.
  • A light machine-gunner crawls quietly along a covering ridge-line to get a flanking position on some troublesome bad guys.
  • A confident and competent rifleman advances on a suppressed enemy, calmly firing controlled and well-aimed bursts as he walks, mortally injuring his target.
  • A rifleman fires, revealing his position, and then slowly creeps through cover to a new position. The enemy loses track of him.
  • An officer gives orders from a hilltop, enabling a team of riflemen to navigate a swamp effectively and close on an opponent they could not reach before.

These are good stories. These are the sorts of stories I want from a combat system that is about the fight as well as about the guy. And they all derived from the mechanism of play but, more than that, they derived from play the game well: there was no need to deliberately make sub-optimal choices and yet you never felt that you had no options, so there was no sense that agency had been removed. Well, until those wounds pile up and you can literally do nothing, but at that point the character can be removed from play.

This is a game that demonstrates some of the pitfalls in attempting to categorize games, I think. The structure looks super-traditional but the results are not so much (though this is not an attempt to claim novelty — other games have done this as well).

I am very pleased so far. Tweaks going in today, especially around character creation.


Aug 12 2010

When it rains it pours

Okay two things feed this. First is last week’s playtest of Soft Horizon, in which we experimented with a zero refresh for fate points and a central pool that you draw from when you narrate with a scope reference. So basically, when you play to the points you said were interesting about your character, you take a point. This unburdens the ref a bit — your character being your character is no longer my problem. When you do what you said you wanted to do, you pay yourself. I’ll make sure there are times to do that. If you are a HEARTLESS SON OF A BITCH then you can pay yourself when you act that way. I can concentrate on making the universe react amusingly (negatively perhaps) and you can take your chances by playing your character. That strikes me as a more interesting framing (at our table anyway) than the standing Fate compel system, which is unreliable in action (some tables report awesome, some report fizzle, and the causes are not well understood).

The second thing pouring in is Toph’s great actual plays from Hollowpoint with kids. Kids really dig playing the bad guys, and that shines through these crisp little reports. Anyway, what is doing the feeding here is the difficulty with the teamwork pool. And the difficulty is such that I’m thinking of throwing it away altogether. And so I sketched up an alternative.

Okay back to the first. During that Soft Horizon playtest someone produced an awesome little bit of narration and, in total violation of the rules, Bob (who shall not otherwise be named lest his true identity be revealed, which embarrasses him despite the fact that he plays games with AWARD WINNING AUTHORS AND PUBLISHERS) reached into the pool and handed the awesome guy a fate point.

That’s now a rule.

You could do this in Hollowpoint.

I re-invented fan mail. Prime Time Adventures is the most famous for this sort of mechanism and I’ve known about it for ages. But I had to see it happen spontaneously to really get it: players like rewarding each other. I think that as I prefer games with a referee there is a lot of residual baggage I have about who gets to do what, and rewards are traditionally bound to the ref. But there is really no good reason to avoid letting the players do this for each other (assuming you manage this mechanically somehow, and I’ll go there, but you could rely on trust, too, and that is a big deal for us — the Table is Trust).

So in Soft Horizon you can do what Bob did. If someone is awesome, anyone can pay them from the pool. This is self-regulating on a couple of points: there are only so many chips in the pool, and no one wants to look foolish at the table by offering rewards for stupid shit. There is too much trust and respect and naked fear of humiliation.

So maybe in Hollowpoint, teamwork isn’t nearly as important as being awesome. So instead of a convoluted system of ask and accept or reject and stuff, a fixed pool of dice goes in the middle of the table, and whenever someone narrates something awesome, any player can give that awesome player a die. You could get a die from everyone if you are truly amazing. And you can hoard those or spend them as you like (save your awesome for the final scene). Because of the way the dice stats in Hollowpoint work, this even has a nice richochet effect — if you roll a lot of dice, you increase the chance that you will get badly burned by your cockiness (hubris if you are using a serious tone): you will likely get a big fate set and go first, and then have nothing left to follow up with. This is the mechanism behind leaping out from behind cover, guns blazing, only to discover you are out of ammunition and standing alone by the pool, looking at a dozen bad guys with Uzis.

This all wanders around the fact that players get lazy and stop narrating their dice and their use of resources. Or the actual narration slacks a little. The ref can prod for it, but that gets old too, and often the dice game is still fun so it’s not really an issue. But those moments of great narration are the stories we tell about the game after, and the stories we tell after are how we generate enthusiasm in others and keep wanting to play. And get more players. So this fan mail, in two new forms, should serve to encourage sustained narrative input. When you burn a trait (shot in the Thin Black Jeans), if it’s awesome you get paid. And so, in theory, you have a little more motivation to be awesome, a motivation that balances against the inherent laziness we all bring to the table to some extent or another.

Some people say you shouldn’t bribe people to do what they already want to do. I disagree. A lot. Just because someone wants to do something doesn’t mean that they have sufficient motivation to actually do it. Adding further incentive can push them over the edge and turn “okay” to “awesome”. If all that costs is a nifty little player-managed resource juggling, fuck yes, count me in.


Jul 31 2010

The god of flowers is dead

Soft Horizon

So the last time I posted I laid down a kind of formula for getting back into the swing of things after a campaign has lain dormant a while and the enthusiasm for it has eroded. As evidence that my method works, I offer the actual play report from the session that followed.

We certainly hit all the targets we have for the game, Soft Horizon. We got big, big heroic ideas — regicide, becoming king, death magic, and the death of a god’s avatar. We have criticisms (this is playtest after all) but all good ones. None are of the form “this game sucks” but rather of the form “if we did THIS the tension would be better”. Most notably there are practically zero rule revisions but rather only clarifications, so this game is certainly on track. I mean, it’s derived from FATE, so it kind of starts out on track, but I think the changes in Soft Horizon make a better game than “just” FATE for this kind of epic fantasy.

Certainly the dice curve I talked about before is cool and functional, but dice games are really secondary to this design because, I think, part of what made epic fantasy gaming epic when I was younger was the free-form role-playing and single-roll checks and not the big dice-heavy fights. So we’re concentrating on that and even in a big detailed conflict, the emphasis is on making sense of each step in a big dramatic way. That seems to be working.

One insight we had during play that we didn’t expect, however, is that really big heroes need an assistance mechanism that is outside of the causal chain at the table. That’s opaque, I know. What I mean is that we really need to be careful to avoid what I called “chess douchebaggery” in one context — that temptation to say “you already acted, you can’t go back and change that”.

Because heroes are vastly more awesome than I am or you are, we need a way for them to make fewer mistakes. By this I don’t mean just “they should succeed more”, because actually good heroic stories are mostly about failure. But they are about making bad decisions and grieving over impossible moral and ethical choices, and not about missing your skill check because you forgot to prepare before-hand. I mean unless acting without preparation is one of your fatal heroic flaws of course.

So the mechanism, if you can really call it one, is to demand that players narrate their heroes with a flexible attitude towards the flow of time. I think we often do this anyway in role-playing games, but in Soft Horizon it’s necessary and so we call it out: when facing a bad roll and looking around for Aspects to tag, it is perfectly reasonable to tag a friend’s Aspect with the narration that she would have helped you prepare before-hand in some fashion. As a side-effect of this news flash, we also get the corollary rule (don’t know if it’s obvious to you, but the chain links are clear in my head): it’s also reasonable to ask the player who is assisting to pay for that tag. Ta dah! Now we have an assistance rule that doesn’t require a whole lot of planning before every skill check.

This is important because simple skill checks (you know where during narration it becomes obvious that we should roll for success — just one roll, it’s not a fight or anything) emerge organically. They aren’t usually planned into play and so you just sort of suddenly know you need one. But you are playing characters that are ready for the shit to go down — they don’t forget they have the powers that define them, but players sometimes do. And, further, even though the need for the skill check is immediate from the table perspective, inside the fiction it may still represent a large chunk of time, in which there is space for preparation and execution. Essentially, the time-flow inside the fiction and at the table are totally different, and it’s just kind of cheap to penalize heroic characters for being in the table’s urgent time space.

So here’s permission to play in what I call “around the heroic now”. You don’t need to play in the now. You can play a little before it and a little after it. It’s perfectly acceptable to say (after a failed roll), “Thankfully, this morning Winsome prepared all of the rites including a script for me to read here. I’m tagging his Ceremonies Aspect, ‘I know the right things to do’. And, being as I’m resurrecting him and so he has little choice here, I’d like him to pay the fate point for the tag.”

We are weak and prone to error but our heroes are rather less so. And so cheap little failings of ours should not be reflexively translated up to our heroes. They should NOT fail because we forgot to prepare. They should fail for far more engaging reasons. And they will, so don’t sweat these little things.

I was going to end there but I realized that there’s something else in here and it might be a sacred cow (well, calf, anyway, because it’s a new idol) and I am killing it. Or at least threatening it with a knife. There’s this excellent idea that you shouldn’t roll if failure is boring or stupid. This is a great heuristic, but like all heuristics it is badly applied as a rule sans inspection. And here’s why: when you fail in a FATE game, you have the opportunity to make it succeed by adding narrative based on circumstances and issues and abilities that you have previously declared are important to you. Things you want to be in the story. And so a roll even for something that is uninteresting in failure can become elaborated through forcing success with tagging. And this elaboration can be marvelous — it’s not really a failure avoided, but rather encouragement to elaborate. You’re not being told, “ahah, you are going to fail at this dumb thing so fix it”, but rather “tell more about how you being awesome makes this suddenly difficult situation resolve”. And this can be fun even if it’s just a locked door you have to get through. And the loss of resources is valuable new tension.