Using official terminology to minimize understanding

I was reading a review of a laptop recently and saw the typical inscrutable label for its screen resolution (“QHD”, in this case), and finally decided I should find out what the heck that even means. So I poke around, and discover that it’s a morass of thing with conflicting names and ambiguous naming schemes. Who names these things? Why not just use the actual resolution (i.e., 1920×1080, or whatever it is)? Continue reading →

Niche vs Schtick

I’m going to run a supers RPG for one of my game groups, and one of the players has never played in that genre before, so before creating characters they had a question: do we need to create the characters as a party so that we make sure we have all the bases covered?

After a little discussion, it became clear that they were thinking of, say, D&D, where your game might not go well if you don’t have a cleric or don’t have a thief. Not that you can’t have a D&D party without one of those roles, but that it significantly changes how the game plays. Or any number of other mission-driven genres where specific skills are expected—like Cyberpunk 2020 without a netrunner.

It seems to me that there are two distinct things going on here. I’m going to call them character niche and character schtick, slightly abusing the terminology to label the distinction I’m talking about:

  • character niche: a niche is a particular story-important mechanical capability of a character
  • character schtick: a schtick is a—or the—core reason that you want to play that character

Rules Define Niches

A niche is a part of the character mechanics that is significant in the play of the game. In some RPGs, niche diversity is important. The game assumes that certain niches will be filled, and if they aren’t, the game won’t play in the usual manner. For example, D&D assumes niche diversity. If you don’t have all the major niches filled (fighter, trap-finder, healer, spellcaster), the game will play very differently. Niche diversity tends to be important in team-based, mission-based genres, like dungeon-delving, espionage, military, and cyberpunk.

In other RPGs, niche protection is important: Having multiple characters in the same niche risks making it un-fun for one or more players as their character gets overshadowed. Being the second-best tracker tends to mean that you don’t get to track (unless there’s a need for multiple people to be tracked at once, or the game has a mechanical way for multiple trackers to work together). Most RPGs at least make the niches obvious, and provide enough of them that you don’t need to overlap. Powered by the Apocalypse games make niche protection explicit by requiring each playbook be unique and building each playbook around unique mechanical capabilities.

OTOH, some games are remarkably tolerant of niche overlap. For example, in D&D you can easily have three fighters in a game and everyone still have fun. Two clerics can work great. Even the trap-finder, probably the D&D niche most susceptible to getting their toes stepped on, doesn’t have to be unique, so long as the GM takes that into account. D&D even works fine with a single-class party.

Don’t Step on My Schtick!

Not every RPG has meaningful niches. But schticks apply in almost every RPG. When you sum up your character, say as “a drunkard dwarven warrior”, you’re describing their schtick or schticks—the core elements that matter to you about your character. Your character’s schtick might include significant mechanical elements of the character, or it might not. Schtick protection is almost always valuable in RPGs—without schtick uniqueness, you end up with Boromir and two hobbits you can’t tell apart. Or two characters riding a skeleton horse of fire. Which can be great fun if it’s intentional, but ruin someone’s fun if it’s not.

In some games, particularly those with classes or other strong categories as part of character creation, niche and schtick tend to overlap heavily. And I don’t think they’re ever completely distinct—they’re very close concepts, so it’s pretty easy for a character’s niche to also be their schtick, or for their schtick to completely subsume their niche.

In fact, in Powered by the Apocalypse games arguably the uniqueness of playbooks is more about protecting those schticks than it is about niche protection. After all, probably everyone in your Dungeon World game is pretty good in a fight, and there are even multiple characters who all fill the same niche—fighter, barbarian, and paladin all fill the “tough guy, able to dish it out and take it” niche, and there are multiple playbooks that fill the “casts spells” niche. But each has a distinct schtick encoded in the rules (like the fighter’s weapon).

My Schtick is “Superhero”

In superhero stories, there are a relatively small number of niches—look at the list of character types in Champions or the classes in Mutants & Masterminds—but an infinitude of schticks. While niche protection isn’t particularly important in superhero stories, schtick protection is. Let me explain with some examples.

A common superhero niche is “superstrength”. Sometimes a character filling that niche also has roughly that as their schtick—like Hercules or the Thing or maybe Colossus. But lots of superstrong characters—characters that fill that niche—have something else as their schtick—their core aspect. Superman, Aquaman, and Wonder Woman are a great example of how you can put 3 superstrong characters on a team and, for the most part, not have them step on each others’ toes narratively.

So it’s important to recognize whether something is your superhero’s niche or their schtick. Is it a thing they’re really good at, or is it the reason you want to play that character? If your character’s schtick is “super strong guy” and you decide the reason they’re strong is because they grew up under the ocean, you’re going to be frustrated if there are two other characters on the team stronger than yours—you’ll rarely get a chance to be in the spotlight as “the strong guy”. But if your character’s schtick is “king of Atlantis”, with command of everything under the waves and even the water itself, then the fact that the “good-hearted savior from another world” and “divine champion of the Amazons” are both stronger doesn’t really matter. Your character’s superstrength is useful, but it’s not the core element that makes your character special to you.

Similarly, Beast’s schtick isn’t “best fighter in the room” or “strongest guy on the team”, so the fact that, while superstrong and a terror in a fight, he has teammates who are stronger and better in a fight isn’t a problem. Because his schtick is “Dr Jekyll and Mr Hide, at the same time”, and nobody else on the team does that better. Your schtick is what excites you about that character. Having two characters with the same schtick usually means at least one of the players isn’t getting to shine. If you’re not sure, ask! Find out what the other player thinks is important about their character—how they want to stand out in the game. And then do something else. If two of you come up with really similar schticks, maybe a small tweak can make sure you’re both unique. Maybe in talking it out you’ll realize that the part that excites you about your character isn’t the part that overlaps another’s schtick, so you can change that overlapping part and still have the character you want.

Necessary Superhero Niches?

Oh, and related to this: superhero stories are about unusual solutions to problems, moreso than most other genres. Characters are all about breaking the rules, even of the universes they exist within. So niche diversity isn’t particularly important. That is, there are no “necessary” niches. You can have a superhero team without a brick or without a speedster or without a blaster or without a flying character. Some of these would be unusual, but probably any superhero niche you can think of, there’s a story out there of a team without one.

So, to sum up:

  • Know whether you’re talking about your character’s niche—what parts of the game they’re good at—or their schtick—what’s important to you about playing that character.
  • Know whether the game you’re playing has required niches.
  • Know whether the game you’re playing works will with niche overlap, or is better if niches are unique.
  • Schtick protection is always important. Don’t use the same schtick as another character unless you’ve talked to the other player about it and you both want to do that.
  • In the case of supers, there are no required niches and niche protection isn’t particularly important.
  • In the case of supers, schtick protection is especially important. Don’t step on someone else’s schtick!

And due to the diversity of character options in superhero games, communication during character generation is extra-important. Talk to the other players. Make sure you know whether a core part of a character is their niche, and overlap will be fine, or their schtick, and you should steer clear.

Four Colors al Fresco: 20th Anniversary Edition

We’re creeping up on Four Colors al Fresco being 20 years old. I released the beta (what I’d now call an ashcan) in 2001, and it was already a largely complete game, mostly lacking in examples and setting details. But the game’s design dates back to the winter of ’99-’00, so I’m thinking it’s about time I produce the “finished” version of the game. So this blog post is the first in a series, serving two purposes: to show you snippets of the finished game, and to publicly announce a deadline in order to help me get it done.

The latter purpose needs a little explanation. I’m a one-person shop, here, and gaming time hasn’t been as abundant as I’d like of late. And without gaming, for me, game design and game writing tend not to happen, either. I was frustrated with Four Colors al Fresco’s not-done-ness. Plus, I was in grad school for several years there, earning my MLIS, while still working full-time, which pretty much ate up my free time. Those are reasons, but they’re also maybe excuses. I work well with deadlines, but find it easy to leave things 80%-finished if there isn’t pressure to finish. I’m hoping there’s still some interest in Four Colors al Fresco, and I want to get it done, so by making a public announcement, I’m putting myself on notice so that my friends and the game’s fans (if it has any) will help me get this done. Is this going to be the first RPG whose 1st edition is also it’s 20th-anniversary edition?

The former purpose, you’ve seen before. I’m excited about this game, but it’s a little unusual in setting and mechanics, so I want to share it with you.  There’ve been lots of little (and one big) changes to the rules since the 2001 ashcan. I’ve refined how I explain some of the mechanics. At some point, I’ll probably get over my fear of the camera and put up some short (<5 minute) videos showing some of the mechanics in action. I’ve clarified how the various genres interact in Four Colors al Fresco and how you can lean into them in your play. I’m hoping I can make you as excited about Renaissance superheroes as I am, and make you want to play Four Colors al Fresco to satiate that excitement.

So, bookmark this blog or set notifications, and you can look forward to lots of talk about the writing of Four Colors al Fresco. Plus, there may be ideas for characters and adventures and snippets of setting that won’t make it into the final game, but I feel are worth sharing.

Adding Difficulties to Powered by the Apocalypse

I’m introducing a group to Ars Magica—they’d all heard of the game but not played it. Two out of three of this group are generally more comfortable with storygames, and one of them was primarily interested in Ars Magica because of the shared/rotating GM structure. After our first session, they asked if it would be possible to have a flexible free-form magic system like Ars Magica in a Powered by the Apocalypse game.

I of course immediately said ‘no’, because PbtA doesn’t have difficulty levels, and doesn’t even really have rated skills in most iterations. Generally, either you can do a thing or you can’t, and if you can do it you do it just as well as someone else does.

Continue reading →

Time & Temp Matrix

I’m running a game of Time & Temp, the awesome and ridiculous game of minimally competent temp employees protecting history from tampering and paradox. It relies on a shared “Temporal Matrix” and “Anachronometer”, but we’re playing online.

So I put together a Google doc to share. I also added a couple additional notes about rolling the dice and the Temporal Villainy Index. Oh, and identified where you start marking the Anachronometer for Temporal Villainy, because I had to cross-reference several bits to figure that bit out the first time, and it’s the part I have to re-figure out each time I play it. 

With Eppy’s permission, I’ve made a copy of this to share with everyone. The colors don’t have any semantic content, so hopefully this should work well for people with color vision deficiencies, too. The shading does have some semantic content: darker areas are informational; lighter areas are for input. Obviously, feel free to make your own copy and strip the color out or improve it in any other way. 

To use it for the game, I keep this as a master sheet and make a copy for each time/place. I also set protections so that the players can’t accidentally modify the master sheet, and protect everything except the input areas on the time/place sheets from editing. I haven’t decided yet what I’m going to do about indicating the value of locked paradox dice. I’m thinking I’ll change the shading of that cell when I check it. 

Why do RPGs have Attributes?

OK, first of all, I know that not all RPGs do. This is only talking about the sort of RPG that tries to model characters with some combination of “attributes” and “skills”. For purposes of this discussion, “attributes” are character stats that are defined by the game as being more-or-less inherent, and either they don’t change or they don’t change easily. They’re meant to capture how we think about intelligence or healthiness in the real world—we don’t usually think of someone as becoming more intelligent or less prone to illness. “Skills” are defined by the game as learnable, or at least explicitly improveable.

So I was just thinking about what purpose do attributes serve in this model? Mechanically, (1) they often provide a baseline or fall-back for skills. If your character doesn’t have the history skill, they can make an intelligence check to see if they know who was regent in 1237; if they don’t have the athletics skill, they can make a strength check to climb a tree.

(2) Attributes often mechanically reinforce the notion that people have inherent aptitudes. Skills will be cheaper with a high attribute, or attributes are added to skills so you get to a higher effectiveness with fewer points spent on skills. There are other methods, of course, but the point is that usually skills are either coupled to attributes or stacked with them in play.

But then I was thinking about research questioning the notion of intelligence as an inherent quality, and how a person could seem to get colds easily but be physically resilient, or smart about math but poor with language, or agile but have butterfingers. Obviously, one solution to this is to have more, narrower attributes. But at some point, you get into the same problem that dis/advantage systems sometimes create, of encouraging excessive specialization that creates characters that aren’t believable.

But maybe we could capture the verisimilitude that attributes provide without needing attributes? Part 1 is completely solvable: you just need to have something to roll if your character doesn’t have a skill. You could define all skills as starting at 1 instead of 0, or have a dice mechanic that works without a skill input. Or say that without points in a relevant skill, you can’t attempt that action. You have to make some design decisions to go along with whichever one it is, but it’s a problem that has been solved multiple times in multiple ways.

But it’s particularly part 2 that got me thinking, because I’m not sure it’s been solved in without attributes (please, comment if you know of a system that has done something to reflect natural aptitudes without using attributes). Back to actual research: we’re increasingly finding that things we think of as inherent aren’t, and things that we think of as connected aren’t (and, meanwhile, other things turn out to be (maybe) connected). On top of that, some things that are typically treated as skills in RPGs may be more inherent than learned. But even then, obviously all the aptitude in the world doesn’t help if you are never exposed to something.

So, the split between learning and aptitude is probably artificial, and the grouping of “related” aptitudes is at least somewhat arbitrary. My thought experiment is: instead of trying to reflect these with attributes, lets just work directly with the skills.

The core of my idea is: the more skills you have in a given area, the cheaper it is to improve them or to learn new, related skills. If you want to make an athletic character, you don’t put a bunch of points into “strength” and “agility”, which then make it easier to get higher scores in the various athletic skills. Instead, the formula for cost of skills takes into account related skills, and costs fall as you acquire more related skills.

You’d have to define the skill groups, of course. For a rough version of this, you could start with a system that has attributes, and use the attributes that skills are based on/linked to define the groups. But the next level would be to have finer control over the skill groups—having 15 attributes gets unwieldy, but grouping skills into 15 categories shouldn’t be too much of a problem. And if you felt it improved verisimilitude, there’s no need for all skill relationships to be reciprocal: music skill and physics skill could both benefit from math skill, but music skill doesn’t benefit from physics skill, say. (n.b.: not making any claims about real-world accuracy here; just inventing an example.)

The cost to raise a skill might be something like ({new skill value}×3)−{number of related skills}. So putting a point into a skill makes every skill it is related to a point cheaper for every increment—a very similar result to putting a point into an attribute in many systems. But without having a separate attribute to track, and without having to decide what is “inherent” and what is “learned”—if it’s a thing you want characters to be able to roll dice to do, make a skill for it.

Is this actually reducing complexity over a typical attributes/skills system? I’m not sure. It would depend largely on how complex the math ended up being and how hard it was to create skills to fill in any gaps that attributes were handling. And even in the real world we often think of some abilities as being inherent and others learned, so would this be too jarring, and make verisimilitude harder? I don’t know without trying it. Let me know if you try something like this out.

How I Met Your Mother. Period.

Last week game night was canceled, so I had an extra night to work on schoolwork.

So of course I instead taught myself how to use iMovie† by fixing the final episode of How I Met Your Mother.

OK, here come mild spoilers for a series that ran 2005-2014. I’m going to keep this to a level that I don’t think ruins anything if you haven’t seen the series and now go watch it, but tolerance of spoilers varies, so if you’re super extra-special averse, just take my word for it that it’s excellent except the final episode, and if you’re that averse I can’t possibly explain to you how to fix it without including spoilers. But if you trust me, read on.

Continue reading →

UTIs vs Creator Codes: Consume vs Create

[Surfacing an old post that got lost. Some of the details are no longer current—there have been 6 major versions of OS X since Snow Leopard. In particular, it is now possible to set the owner for a single file, as well as for all files of that type. So it basically works exactly the way I (and others) said it should, 8 years ago. But this discussion is still relevant, even if it is no longer a complaint against OS X, as a discussion of different needs and best practices.]

I seriously contemplated not upgrading to Snow Leopard when I discovered that they’ve changed the behavior so that the Creator Codes associated with files are now overridden by other mechanisms. For those who aren’t familiar, up until Snow Leopard, Mac OS has always kept track of not only what kind of file something is, but what application it was associated with. I’ve always considered that to be a major boon: I can have this html file open with my text editor, so that I can make some more edits, but that html file open up in Safari, because it’s a saved webpage i downloaded. And a few other cases that are really common and fairly important [to me]. There are also lots of other cases that have come up over the years, but at least some of those are probably due to my idiosyncrasies, as much as to genuine efficiencies.

Now, this is not to say that the old way was perfect. In classic Mac OS, it was comparatively difficult to access, much less change, this information—if you knew what you were doing, you could use various tools to get at the otherwise-hidden information, and you could learn what the often-obscure 4-character codes were, but for most people, it was set by applications, and that was it. On the downside, this meant that some applications were excessively possessive about files: just opening a file with that application would change it’s ownership to that application, so that the next time you went to open it, it would launch that program again.

On the upside, every application would automagically tag any file that was actually newly-created with it (as opposed to just opened or edited) as belonging to it. This was particularly a boon for dealing with common filetypes, because sometimes one app would be better for what I wanted, sometimes another. Frex, when writing a PERL script, I might put up with a slightly poorer text editor because it had syntax coloring (while my usual text editor didn’t). But I wouldn’t want to use that for everything. I found myself going back and forth between multiple apps for images, too. And, in particular, I certainly wouldn’t want to have an image I was working on associated with the viewer—or webbrowser—I was using to double-check my work. Mac OS X didn’t make it any easier to access the Creator Codes, but it did provide a functionality to override them. Which, IMHO, was the best of both worlds: by default, you had the associations. If you wanted to change a few files, you could do it. If you wanted to change all your files of a given type to open with a particular app, you could do that, even more easily.

Which, now that I’ve gotten some context out of the way, gets to my point: I can understand why some people prefer the new method, whereby all files of a given type open with one, chosen, application. What I don’t understand is why they are happy that the old method, where some files could be automatically owned by an application, is so reviled. Previously, both possibilities were there: those who wanted to always have a given type of file open with the same app could set it that way. Those who wanted to respect app ownership could set it that way. So it’s not just a case of switching from behavior A to behavior B. We’ve gone from default-A with optional-B, to always-B. Which really irks those who prefer behavior A. And I’m a little lost as to why those who prefer B are so happy, since it didn’t take much effort to get that behavior in the past.

The other, more significant, observation I’ve made comes from reading many blogs, editorials, and attendant comments on the topic. And noting an interesting trend in who prefers what. It seems that it’s not just a matter of whim, but there is a definite situational difference. To whit: those who prefer the all-files-of-one-type-for-one-app are consumers of data. Those who prefer the each-file-to-its-app are creators of data. Now, this is just a generalization, so don’t bother “proving me wrong” by showing that you, personally, defy the categories. Of course you do—lots of people do. For that matter, I don’t think they’re black-and-white categories; most people probably are somewhere between the two poles, so, in that sense, everybody defies the categories. Nonetheless, over and over, those who prefer the new method gave receiving files with undesired Creator Codes as their reason. Those who prefer the old method usually gave creating files [in multiple apps] as their reason. And that certainly matches my preferences. I also think that those who claim that for the vast majority of users, defaulting to a single app is the preferred behavior, are correct. Most people I know don’t even use multiple webbrowsers, something that doesn’t involve associating files or most of the other costs of switching apps [though, admittedly, there is the bookmarks issue—but that’s something that can be solved, if you want to switch between webbrowsers for other reasons].

So, I suggest that there is a fairly easy solution that would make everyone happy: provide some sort of Creator-Code-like functionality that not only makes it possible to associate files in a less fragile way than the current mechanism, but make it possible to make that the default behavior when creating a file.

Then, ignore those associations when transferring files. I’m no programmer, so I couldn’t tell you how to do that. Maybe store them somewhere that isn’t preserved when using http or ftp or MIME encoding, or other file transfer protocals. Maybe specifically put a tag in that the Mac recognizes as itself—so when the OS sees an ownership tag that it didn’t put there, it knows to then ignore any creator codes it does find—maybe even strip them out.

From what I’ve been hearing, that would actually provide the functionality that just about everyone wants, even if it wouldn’t match some of the absolutist—and vitriolic—statements that some have been spouting.