Examining the Stavro Principle

A bit ago, Daniel Solis posted this image on his blog, about an observation on RPG design from intent to play, which Luke Crane titled the Starvo Principle (after the guy who came up with this, John Stavropoulos):

I’m having a complex reaction to John Stavropoulos’ model, because I agree with the base ideas, but see it differently.

User Interface, not Tools

What John calls tools I see as the user interface, the things that the players directly contact with. But it’s not just character sheets, dice, etc. It’s also the text, post-layout. Not only because pages can be printed out in order to to be ad hoc cheat sheets, but also because layout is the tool by which a book cements certain key ideas into the minds of readers.

Which is to say that if rules are the (or an) implementation of intent, and text is the implementation of rules, then user interface is the implementation of text. Although that’s someone strange, because much of user interface is developed in concert with rules, and text is a product of merging the two.

Intent and Play Culture

Here’s where I have a really weird reaction. Intent is treated as a separate thing, and to me, intent is all over that chart, like jam on toast. What I would put in its place is play culture, or reaction to play culture. And our interface axioms start from there.

I’ve been big about discussing play culture over the years. The indie scene in its early days (and sometimes still today) was pretty bad at creating books that required an understanding of the designer’s play culture in order to successfully execute. Or, as my good friend Paul Tevis said about one indie game[1] back in 2007, “The game isn’t in the book. It’s an oral tradition that happens to also have a book.”

Minimalism makes the assumption that the reader either is in or understands the play culture intended by the designer. That understanding is a context channel. It’s easy to unintentionally be deficient in explaining how your game works beyond it’s mechanics if you’re not used to explaining your play culture.

However, when your game is the result of your reactions to a play culture — usually when there’s something you really don’t like or doesn’t work for you in a certain mode — it becomes prudent to go beyond minimalism and explain said play culture. Which, to go back to John’s model, carry your intent all the way through the rules, text, and tools. I’ve had this experience working on Mythender, because the way the GM is suppose to act is a reaction to what people have called “epic” games in my play experience.

This is why I see intent not as the bottom rung but as a separate input to rules & text. Intent as expressed by mechanics & rules isn’t the same as intent as expressed by advice, which is in the realm of text. Which leads us to…

A Place for Advice

There is no clear place where advice or best practices hooks it. It doesn’t really hook directly into text, because it’s parallel to rules. It’s developed along the same time as rules, even if not yet clearly explained until a first draft[2] is written. Some instances of advice live in the intent/play culture layer, yes, but not all of it. And because of the language used in the chart, rules are prioritized far over the idea of advice & best practices.

Unless you consider advice to be “rules” along with mechanics. Then cool. But many people don’t see that definition of rules. (I do, but I tend to have to explain such things assuming that a good portion of my audience doesn’t, thus this entire section.)

To phrase another way: the when & why of rules is as important to the interface as the how.

John Is In No Way Wrong

It may sound like I’m criticizing John, but that isn’t my intent (hah). John has gotten me to think about my own model, and in blogging about it, made some of those thoughts concrete. I invite you to do the same — I know some folks have around the internet.

John Stavropoulos is one of the sharpest guys I have ever had the pleasure of chatting and dining with. He could write papers on RPG scholarship, GM practices, group dynamics, all sorts of things. he’s achieved something pretty cool here (which Daniel has then turned into something somewhat larger, by applying a visual tool to John’s text[3]).

So, what has it made you think about?

– Ryan

[1] Remember, I never talk about a product publicly unless I think there’s some merit to it, however flawed.

[2] Tomorrow’s blog post (which was actually written before this one was).

[3] Which is a great illustration of the top tiers of John’s model.


11 Responses to Examining the Stavro Principle

  1. Eric Lytle says:

    That quote from Paul – “The game isn’t in the book. It’s an oral tradition that happens to also have a book.” also applies to the early versions of D&D like white box with chainmail. If you weren’t already playing wargames with miniatures those texts are nigh unreadable. Let alone playable.

  2. Kit says:

    I’d love to hear more of your thoughts on explaining culture of play at some point. I think I hear echoes of the criticisms you gave us with our first draft of BH here, actually: sure, our writing was pretentious and all, but really, we weren’t explaining how to play, we were just explaining the rules-as-such. I hope we managed to get more of our culture of play into the eventual text.

    • Ryan Macklin says:

      My thoughts on play culture is…not easy to encapsulate in ever a series of blog posts right now. That’s why I started a (now-closed) forum about it, Cultures of Play. But as we’re effectively neighbors, I’m sure those discussions could be had. Which then may turn into future posts.

      – Ryan

    • Kit says:

      Yeah, I was hoping for some in-person conversations over good beer! Let’s arrange another time soon, eh?

  3. So I mentioned the following on Twitter and got an interesting response from Ryan, so I thought I’d comment here and see what others thought. (It appears my brain makes strange connections)

    I’m a software engineer by day, so I had the following thought. If we consider a tabletop rulebook as a design document (which it is), then the most obvious place to put advice / best practices is in some kind of appendix or addendum to the rulebook.

    • Ryan Macklin says:

      I’m also a software designer, and honestly, I could not disagree more. The point of a design document & a rulebook are much more different than you’re giving credit, and the audience goes beyond the intensely technical-minded than a design document is.

      – Ryan

    • Hmm. Revise to rulebook as user’s manual, with advice / best practice akin to a design document?

    • Ryan Macklin says:

      If you are going to use a software analogy[1], a rulebook is a end-user manual. In which case, when tools are introduced, some discussion of advice & best practices should be alongside that because of contextual learning. Then if the size of that additional information is too great to comfortably fit nearby, include forward references to where to find more, in a prominent way as to say “Hey, if you want to read more on this right now, go here. Otherwise, cool, it’ll be there when you get to it.”

      And sticking things in the back of the book without prior contextual references is asking for it to not be read.

      – Ryan

      [1] One of my rules on analogies is don’t use software ones. They only work for software people, and one should speak to a broader audience.

  4. Jesse Coombs says:

    What’s a design document? Ha. But no, seriously. Is it like a series bible for tv?

    As far as the intent “jam” goes, if the game’s intent isn’t finding it’s way all they way through to the tools, no fuck that, THE PLAY EXPERIENCE itself, well, then I’m sad about it. I think if the intent gets muddled away, well, then we’re just playing with toys?

    So, yeah, I think I agree with you. Intent is a different thing than the other stuff in this hierarchy.

    • Ryan Macklin says:

      A software design document is (to be brief & non-technical) a set of specs, expected behaviors, things like that. If there’s an analog, it’s more like a bullet-point playtest draft or outline. It’s what you give to developers to execute the process of making said software, like a blueprint for a building.

      Well, there is an analog in the video game world, the game design document. Which was an interesting process when I wrote one last year for that freelance gig, because it was similar in some ways to a SDD and other ways to the writing I’ve done for tabletop games.

      Links there if you want to get your learn on.

      – Ryan

    • Ryan Macklin says:

      It’s also interesting to me that, if we stick to the original model, text is usually the last thing to be properly initiated. More than one project has been held up in product due to the “we need the character sheet designed so I can write the rest of the character creation chapter” sort of thing. Which means that while it may be an order of interface, it is not an order of development. And in that manner reminds me a bit of how people look at GNS.

      – Ryan