Thursday, October 18, 2012

Silly Name, Fun Idea

So, the Marvel Heroic RPG has one of the most clever initiative systems I've ever seen. For the unfamiliar, it basically breaks down as follows - someone goes first, and after they're done, they choose who goes next. Repeat this pattern until everyone has gone. This idea (which I call "pass-around initiative") is pretty simple, and while specific implementations need to answer specific questions (like, 'who goes first?', 'how can I interrupt?' and 'how do you reflect faster characters?') the core idea is portable to many other game designs.

This was on my mind when I encountered another very common RPG occurrence - rolling to determine who to do something bad to.

You've seen it before. A monster makes a surprise attack, rocks fall, a god smites - something bad is going to happen and you need to decide which player it's going to happen to. Hell, when everything is going OK, then it can be doubly important to do something nasty to keep things going. The questions is always who to do it to. GM's want to be fair, so they tend to use rules or randomization to make these choices (since just picking someone could be seen as mean) but this can produce uneven results.

So, I was struck by an idea for handling this inspired by pass-around initiative, and thus the doomball[1] was born.

So, at the start of the game, give one player the doomball (Ideally in the form of some physical token). How you decide which player is totally arbtrary, and if you want to use a classic method (like randomization) feel free. My suggestion is to give it to whoever was holding it at the end of last session (or to whoever missed the last session), but there might also be mechanical systems in the game that might help with this too; Amber DRPG has "Bad Stuff" which might be a great way to determine this, for example.

The player holds the doomball until the GM comes to a point where something bad needs to happen to someone. In this case, the GM targets the player holding the doomball, and once she's done, the player passes it to another player. The only rule about the handoff is that no player can get the doomball until everyone else has had the doomball.

How often the doomball gets passed depends a lot on the game. Combat brings up the possibility for a lot of passing, but it shouldn't necessarily be used for every attacks. Enemies often have specific logic by which they determine their attacks - a logical choice doesn't invoke the doomball, but an open choice of targets might.

This can certainly be the end of it - its a simple determinant to resolve issues as they come up - but there can be more to it. It's easy to build mechanical hooks into the system, such as abilities that make you take the doomball or allow you to pass the doomball early. Hell, this may be a more useful way to reflect luck-based effects (like blessings and curses) than the usual bonuses and penalties to attacks because this feels more like luck.

Anyway, it's a slightly silly name, but the idea is pretty usable, so feel free to go nuts with it.


1 - The name was inspired by the tvtrope of the idiot ball

Monday, October 15, 2012

Tempo Lives

A while back I posted the system I was using for a spies game, and I talked a bit about using it as a platform to design a game.  That went silent for a bit, but it bubbled to the surface this past weekend, and I finally ground out the first draft.  So, for the curious, this is Tempo v0.1.

I've already gotten some good feedback, and something that Jason of the forthcoming Spark RPG had to say has me really chewing on combat.

Warning: What follows is seriously nerdy.

So, at a high level, the idea behind combat is that one side usually has the advantage, and leverages that advantage to do cool things.  Effectively, you sacrifice the advantage to impact the situation, so if you have a minor advantage, you give it up to add an aspect to the scene.  A moderate advantage can be give up to put an aspect (like an injury) on an opponent.  A significant advantage can be used to end the conflict on your terms.  There are also some benefits to holding advantage. You get narration rights (with progressively more authority) and you win ties.  There are other mechanically fiddly bits to it, but that's the conceptual core.

Jason brought up the very reasonable point that this could be handled with a simpler currency model, where Minor advantage is 1 point, moderate is 2 and so on.  You accrue advantage, then spend it.

This is _really_ compelling. While it gives up some of the linguistic nature of advantages, it makes for a simpler, more streamlined model. What's more, it makes other mechanical hook ins MUCH easier.  Suppose, for example, I do a martial arts hack - it becomes easy to have cool maneuvers have specific tempo costs.   That's nicely elegant, and I was trying to figure out why I was resisting it on a gut level.

When facing an issue like that, I find it useful to ask yourself what you're really trying to accomplish, so that's what I did.

The goal with this system it to encourage gaining then "spending" advantage, since such expenditures should be the kind of interesting things you want to see in a fight. The cadence I'm looking for is the alternating escalations and unexpected reversals that I have previously only really gotten out of good diceless play, and that brings up a seemingly small, but utterly critical mechanical point.

At present, advantage does not help your roll directly - if you want a bonus, you want to use it to create or tag an aspect.  The intent behind this is because the behavior I want to avoid is someone sitting on their advantage, building it up, then cashing it all in at the end for a big win.  That's mechanically optimal, but dull in play.

Similarly, advantage does not accrue[1].  If you've got a minor advantage and don't spend it, then gain a minor advantage in the next round, your advantage doesn't bump up - it stays minor.  Again, the goal is to incentivize  spend.  And this is where the tension arises.

In a currency based model, I would expect accrual.  A certain MoS gets me X points of tempo, so in this case my minor advantage (1 point) followed by another minor advantage bumps up to 2 points.   Now, this is not necessary, but if I _don't_ have accrual, then currency is just another labeling method (Which is not necessarily bad, especially if it's a clearer label).

But I'm not sure if that's a problem with the system or my assumptions. Accrual is not automatically bad, but it's problematic in conjunction with the possibility of a one-hit takedown. But if you changed engame conditions, then accrual opens up some interesting possibilities.  One big one is the element of playing chicken - only one side has advantage at a time, so your entire accrual can be wiped out by a bad turn as your opponent seizes the advantage.  Thus, you have an interesting choice of spending for an effect or holding out for the chance to spend for a bigger effect.   This would call from some number crunching, but might be fun.

Anyway, I don't have a solution yet.  I definitely need to kick that part around some, and I'm nto sure what the final shape will be, but I want to call it out as the sort of thinking that happens when you really start getting into the guts of a rules system.

So, thanks to Jason for you feedback, and I encourage anyone else to feel free to read and comment.




1 - The one exception: it is pretty hard to get a significant advantage on a straight roll.  Once you have advantage, the threshold for significant advantage is lower.   This sort of works, but not very well. It rewards sitting on Advantage and swinging away, so it's going to change.

Thursday, October 11, 2012

Xbox Task List

Outside of games, I put a lot of time and effort into trying to stay organized.  I've tried various systems and tools, and I usually gravitate back to some variant on Getting Things Done, usually to good effect.  The main thing I've learned in this is that while specific tools (processes, software etc.) can be neat and fun in its own right, what's important is understanding what you want to do and why so that your system solves _your_ problems.

When I was younger, I thought of the idea of maintaing task lists or neatly labeled file folders as uselessly anal retentive.  Why exert the effort on such things when you could just be doing cool stuff instead? This was a pretty useful all purpose excuses to get out of a lot of responsibilities, but at the time I at least thought I was being sincere. And I probably was, but I was also being kind of stupid.

The purpose of a good system is not to do *instead* of the cool things, it's to *enable* the cool things.  It carves out space for thought, freedom and creativity by removing uncertainty, doubt, fear and all the other little obstacles that you may not notice but who are responsible for you getting to the end of the day and wondering why you didn't write, or play video games, or go out or whatever was important to you.[1]

Now, implicit in this is an idea that I think was best summed up by Merlin Mann as "You don't need to set a reminder to play your video games."  There are things in your life which you don't need to organize because they're what you really want to be doing - the purpose of setting up a system is to build a structure around those things so that you can get to them without worrying about all that other stuff.

This concept is directly contradictory to one of the major tenets of contemporary RPG design, where it is expected that rules drive towards your fun things, and that you will pick a game based on which rules do so most successfully.  I've never been terribly comfortable with that idea, but articulating why has always been a bit of a trick, and only today did I stop and compare it to putting "Play Xbox" on your todo list.  And the more I think about it, the more it holds up.

Partly because it's not so clear cut as good/bad.  There are times when I _will_ put "Play Xbox" or equivalents on my task list.  Not because I'm going to forget that I want to do it, but because some other factors (like a very busy day) make it useful to me to put in a reminder to take a break and prioritize myself form time to time. Game rules can certainly do that.[2]

And, in fact, rules can do a lot of useful things.  This should absolutely not be considered an argument against RPG rules in general.  But it is me wondering if having rules for the part of play you love is automatically the best use for rules.[3]




1 - I still fail this more often than I'd like.  But when I do, It's usually pretty easy to track back to the source.

2 - Though if they do it a lot, I wonder what else is going on in the game (either in the system or at the table) that keeps making people forget what they want to do.

3 - Yes, blah blah blah, fruitful void. I'm not talking about theory discussion. I'm talking about how games are designed, used and clung to.

Wednesday, October 3, 2012

Why Feats Fail Me

So, I started actually making up 13th Age characters the other day, just to get my hands dirty.  If nothing else, it's a pleasantly fast and dirty job.  The skills and one unique thing end up being almost necessary though, because the rest of the mechanics are not quite so grippy.

Not saying they're bad, but stats, class, talents and feats dont' tell much of a story.  Some of that I'm ok with - Stats and class are kind of expected to be blandly interchangeable, and it's overall a good thing that they are, since they're kind of foundational.

Jury is still out on talents.  I like them mechanically, but I'm not yet sure if they say enough about how my fighter is different from your fights, especially if we can't otherwise describe that difference in terms of differences in gear.

But feats...man, feats always break my heart.  I really want my feat selection tot ell me something unique and interesting about the character, and it doesn't.

This is not 13th Age's fault - this is a problem I've had with pretty much every incarnation of feats from 3e on.  And it's a problem with two big roots.

First off, there's something of a historical divide within feats that demands that they can have meaning in the setting or be mechanically potent, but not both.  There are a handful of exceptions, but by and large if a feat ties you into the setting, the reward is probably a (non-stackable) +2 to two skills.

There's a good reason for this. The more mechanically desirable a feat is, the fewer constraints you want to put on it. So many different types of characters are going to want to use two weapon fighting that you don't want to limit it in any way, so it's built to be generic.[1]

Second, feats tend to be a little bit too small.  Feat _chains_ (usually 2 or 3 feats) often tell a story (even if that story is 'I'm a two weapon fighter') but a given feat usually just teases at what it could be.  Again, there's a good reason for this - small rewards can come more frequently which is fun for players.

Intellectually, I acknowledge the good reasons for the way feats are, but they always result in some disappointment on my part.  I always want them to be a little bit more.

There are ways to fix this, of course. Lots of different ways. But that's it's own post, and one that may wait until we see the 13th Age SRD.




1 - Most exceptions to this are racial, and that's true in 13th Age as well.  That's a serious bit of D&D legacy which is, I think, almost habitual by now. It's also a tacit acknowledgment that it's hard to make races awesome and balanced at the same time, so a lot of racial awesome gets offloaded to feats.

Tuesday, October 2, 2012

Quick 13th Age thought

The obvious hack for 13th Age + Eberron is to make the 13 Dragonmarked houses into the icons.  Yeah, sure, you'll want some feats for Dragonmarks[1], blah blah blah, but that's the easy part.  I'm more curious what happens when you refocus Icons in this fashion.

The most self-evident change may be the least important. Yes, replacing the Icons as individuals with organizations removes the possibility of a personal relationship, but as I've noted before, Icons are also their organization, and that organization is the part players will usually interact with. With the switch to houses, that part remains the same.  Now, you'll probably need to populate the houses in a way that interests your players (since names and faces are still critical) but that's a good practice anyway.

What intrigues me is that in doing this you are explicitly *not* encompassing the world with the Icons.  The Dragonmarked houses are just one axis of the setting, and using them (rather than, say, the various kings and such) makes a statement about what kind of game this will be.  That is, it is a game that is going to center around the intrigues, conflicts and alliances of the great houses. The other setting elements still exist, but they will be encountered through this lens.

This fascinates me.  It takes the broad, kitchen sink nature of the average setting, and pare it down to a thematic core.  Want to use the setting again for a different type of game?  Use a different set of icons!

Now, there's something similar that happens when you look solely at the subset of icons that players choose, and one might argue that you could offer any number of icons in a setting, then focus on using only the ones that players choose. This definitely makes for a strongly player-directed game, but I don't like it quite as much as the great houses approach because it produces too clean a dataset.  There's nothing thematically tying the players interests together, and there are no rough edges of things that are important to the game, but not personal to the players.

Why does that matter?  It provides a necessary contrast.  When a setting revolves too strongly around players, it can start to ring false.  One good safeguard against that is to make sure that the setting has elements that are important, but not personal to the PCs.  Not too many, of course, but enough to make the world feel alive.

Anyway, I keep thinking of other ways to apply the Icons model, and for some reason, Eberron popped into my mind today, and I figured I'd capture it.

1 - And while we're at it, make them cool. Dragonmarks were always much more interesting as described than as mechanically implemented.