Taxonomy of Features for Incremental Authors

[tundish]

This springs from some dissatisfaction directed against Cloak of Darkness. I feel like I posted quite critical of that important touchstone without providing any valuable alternative. So I have taken a bit of time to come up with something more constructive instead.

It might not be to everyone’s taste, so please feel free to be as honest in your displeasure as frequently I am on this forum at this time of night .

Rather than try to redefine this canonical construct, I thought I’d have a look at all the features one might hope to see in a game framework.

And when I say ‘one’ I mean ‘one or a few’. Hobby authors. Small collaborations. And I don’t want to try to impose my definition of ‘Interactive Fiction’ either. So I came up with the designation of ‘Incremental Authorship’.

It strikes me that what characterises this genre of work is that the author cannot commit full time to writing. Nevertheless, due to the very powerful free tools for text editing and source control, it is possible over time to construct a significant corpus of well-written art. In fact, the length of incubation, if well socialised, can actually serve to build a network of supporters and contributors which would otherwise be very hard to assemble.

Anyway, what I came up with was eight themes. I’ll list them below. Each theme has 4 articulations. They chart the sophistication of the embodiment of each theme.

Here are my 8 themes in support of Incremental Authorship. They have slightly romantic names, for reasons I will explain in a moment:

• Business
• Sensory
• Rumour
• Mobility
• Risk
• Burden
• Legend
• Stewardship

Yes, I know that sounds nuts. I am working on a full description of each theme, and I hope to post all that over the next few days.
Part of the challenge I am facing is to avoid using terminology which in this community has accrued a very specific meaning. So for example, the idea of INVENTORY in Interactive Fiction. It’s there in this model, but I call it Burden.Ownership .

I was hoping by this evening to have a full specification, but there is still some work for me to do. But I’m not going to be able to sleep unless I post something so here it is

More tomorrow, hopefully. I intend throughout to be attentive to your reaction.

[tundish]

OK, so we have a result. There is now a resource you can download and use as you wish. I will post the link below.

Its name is FRISIA: “Features Required In Support of Incremental Authorship”.

It’s a taxonomy, or score-card for authoring frameworks. Also maybe a way of analysing Interactive Fiction to identify certain features.

The category names I mentioned above were a result of my fevered brainstorming. I’ve reviewed and moderated them, so they now line up like this:

• Economy
• Sensory
• Reactions
• Mobility
• Risk
• Obligations
• Persona
• Facility

Underneath each of these categories are four articulations of the theme.
See, I’m trying to keep it manageable. Thirty-two criteria by which to assess an authoring system or a work of Interactive Fiction.

The file you want is frisia.toml.

The comments in the header describe how it can be used.

Any questions, quarrels or quibbles? Please reply below.

[mathbrush (Brian Rushton)]

I made a first lookover at it, and I enjoyed the wide variety of attributes. I think I’ve found that some of them tend to be mutually exclusionary in games (not out of necessity, but out of social convention). For instance, game with crafting and attribute development are often not the same games that have sensory occlusion and compass navigation (although the excellent twine game Trigaea has all four).

Do you take the position that all of these are good? I’ve recently been thinking a lot about, in parser games, whether a blank-slate protagonist is better or a strongly characterized one. I’ve seen a lot of voices in favor of strong characterization. Interestingly, customization of characters seems largely absent from parser games (outside of games like Flexible Survival, which I haven’t played but apparently allows quite a bit of customization).

I wonder if you shouldn’t just post the whole thing here, using the ‘code’ format, as it’s not especially long.

[tundish]

@mathbrush

Do you take the position that all of these are good?

No, I hoped to clarify in the file header that choosing everything is not the way to goodness.
The project I picked to illustrate the use of the example sections was Sphinx, a documentation framework (ie: a generator of browsable text, with some basic search functionality). Nevertheless it has a plugin to embed online advertising. So basic at the core, with one significant embellishment. But that works in the context of that project.

[jbg]

If you’re just looking for a descriptive taxonomy to provide a formal(-ish) nomenclature for talking about game design, why roll your own instead of using e.g. MDA?

Not intended as a criticism, I’m just trying to figure out what you’re trying to accomplish here. With something like Cloak of Darkness I see the hook, so to speak—you have a new engine/framework/whatever, and in order to see it work you have to implement something in it, so Cloak of Darkness is a standard bite-sized chunk of gameplay to implement. I also see the advantages of something like, say, specifications like C11—if I’m using a compiler that’s C11 compliant then I know that when I declare something as a unsigned integer it’ll behave the way I expect it to.

What I’m working on here is: okay, I have this new taxonomy. What can I do with it that I couldn’t do before? Is it something I want mostly when I sit down to design a game? Or when I’m trying to talk about existing games in reviews? Is it something I might put in an ABOUT message, like I might do with a description of a games “cruelty”?

[tundish]

@jbg

why roll your own instead of using…

Rolling my own is the way I tend to, er…

Seriously though. I was getting to feel that my interventions on this forum were mostly to gripe about stuff, and I wanted to tip the scales in favour of having contributed something useful.

Also, I know that in academic circles there’s a premium on scholarly lineage, but that’s not where I’m coming from so I don’t have a particular allegiance to any of that.

I’d rather try and make something which can be understood and put to use without any preparatory education.

Having said that, I’m aware that most here won’t be familiar with TOML as a structured data format. I wanted something that was agnostic of any runtime environment. TOML is new, but it will catch on.

[jbg]

@tundish

I’d rather try and make something which can be understood and put to use without any preparatory education.

So it’s intended to be a way of categorizing individual games by enumerating which specific features from a standard list they implement, and the selling point is that it’s easier to learn/use/understand than the alternative ways of enumerating features?

If that’s accurate, then I think the thing I was finding confusing is that it seemed like you were framing it as an alternative to something like Cloak of Darkness, when (if I’m not misunderstanding something) it’s a categorically different thing: Cloak of Darkness is a shorthand way of talking about IF authoring systems (like for comparing I7 and T3); what you’re talking about is a shorthand way of talking about individual IF games (Cloak of Darkness vs Lost Pig).

[tundish]

@jbg

something like Cloak of Darkness, when (if I’m not misunderstanding something) it’s a categorically different thing

Yes that’s right. At the top of this thread there’s a link to a discussion on improving Cloak of Darkness. And I was one of those who chipped in to say it should be ‘better’.

So the obvious question is, better how? And if you don’t have the vocabulary to answer that question, then you have no chance of improving anything.

By the way, FRISIA doesn’t try to tell you what’s ‘better’. It’s just a format for applying 32 questions to a thing you are contemplating to make. A way of clarifying intentions. Capturing examples. Focusing on requirements. Perhaps to reverse-engineer inspirational works.

[zarf (Andrew Plotkin)]

@jbg

What can I do with it that I couldn’t do before?

Well, one thing you could use this for is an exercise list for a parser IF development tool.

Here’s a list of ways that various games have extended the rudimentary GET LAMP / OPEN DOOR model world. No single game does all of these things, but any game might want to do some of them. So if you write a short example of each of them, then (a) you’ve demonstrated that your tool is flexible enough to cover a lot of IF needs and (b) you have a recipe book for future authors.

I don’t think it’s going to be that helpful as a taxonomy. That implies that it’s a complete list, covering every wacky thing done in any IF game. Which it’s not! And trying to make it complete is an unwise quest – you’ll just burn yourself out. But it’s a characteristic list, which has its own value.

[tundish]

Thanks @zarf, I think that’s a great summary .

And for those who wish for a complete taxonomy. Well, it’s just a text file. From the Internet. By all means go ahead and add to it

[jbg]

@zarf

Well, one thing you could use this for is an exercise list for a parser IF development tool.

Right, but that’s the value proposition of a descriptive taxonomy in general, not this descriptive taxonomy in particular.

[tundish]

Yes. So you could use this descriptive taxonomy to understand possible enhancements to CoD. Or some other as you prefer. Or neither.

Don’t choose ‘neither’ though.

[tundish]

Also, this descriptive taxonomy adapts rapidly to demand.
I thought the term “policy” was a bit weird, so I switched it to “priority”.

Let me know if you have a perspective on that. Please don’t feel constrained by any scholastic mores. We are in a different world now. Any suggestion you have could deliver enduring value to this community resource.

[jbg]

If you’re directing that at me specifically, then…well, first of all I’m not sure I’m actually in your target audience. I’m not contemplating designing a general-purpose IF framework. And every time I’ve written my own game engine (not just for IF), I’ve always had narrow and specific design goals in mind (rather than building a general-purpose, can-implement-anything sort of thing). So standard disclaimers here.

But insofar as (I think) I understand your desiderata here, my recommendation (as a general game developer, rather than specifically a general-game-engine game developer) would be to re-brand so as to drop the trappings of being a formal taxonomy, particularly if you don’t want people to feel “constrained by any scholastic mores”.

“The Tundish Index of IF Game Mechanics” seems, to me at any rate, to encapsulate more of what you’re trying to do than “FRISIA” does. Reading down the list of bullet points, most of them don’t particularly immediately suggest the things they describe. Again, this is just speaking personally. Like:

FRISIA

• Economy
• Sensory
• Reactions

…and so on seems a little…abstract…if what you’re trying to do is make something more accessible and less “scholastic”. As opposed to:

Index of IF Game Mechanics

• 100 In-Game Economy
  • 101 NPC shopkeepers
    • 101.1 Buy
    • 101.2 Sell
    • 101.3 Trade
  • 102 Player-player trade

…and so on. Basically imagining a potential engine author visually grepping through the index as a sort of feature checklist. Items assigned an identifier (a la the Aarne-Thompson Index) entirely for ease of reference.

That’s just the equivalent of whiteboarding an example here, I don’t know that it particularly represents a good coverage of the subject. And I’m not sure that in-game trading deserves privilege of place at the head of the list.

Again, speaking entirely from personal experience here (and not pretending that this necessarily is a good way to approach the general problem), I’m generally concerned about nuts and bolts that aren’t even encapsulated in the sort of divisions you’re talking about, and I can think of several things that are of concern to game engine designers that aren’t game mechanics in this sense. So things like how are save states handled? Where, when and how often can the player save, and where does the data actually end up (saved to the cloud, in the browser cache, in a file on the player’s computer/console)? How do input and output work, what devices are supported, what provisions are made for accessibility and localization? What kind of datatypes are supported, and what kind of performance impact do they have? How modular are the engines’ features? Like most modern IF frameworks come with both a grammatical model/parser and a rudimentary world model, but that’s not a law of nature. What’s the low-level interface look like, and how “portable is it”? (In the past, writing a 2D graphical game I wanted to include a text parser to sort of emulate the effect of old Sierra games, but, frustratingly, none of the existing IF systems at the time could be used because none of them are portable in that way) Is the game engine, for example, instanceable?

I rattle all this off just because they’re real-world questions that I personally have found myself asking about IF systems in the past. And acknowledging that my personal experiences aren’t necessarily a good guide to…literally anything…it still seems like anything purporting to be general way of talking about IF games probably needs to either provide a way of enunciating these issues or to explicitly exclude them from scope.

[tundish]

@jbg Thanks for the response. I think it’s going to take me a little while to digest all you’ve said, so forgive me if this reply doesn’t address all your points.

I’ll try to deal with the easy stuff first On the subject of branding, I think a pronounceable abbreviation which is also a country of legends is a better label than anything which contains my Github handle. I deliberately chose that for its obscurity and SEO specificity.

@jbg

If you’re directing that at me specifically, then…well, first of all I’m not sure I’m actually in your target audience

I wouldn’t want to say I targeted you as such but something piqued me to prod you a little, and lo and behold…

@jbg

I’m not contemplating designing a general-purpose IF framework. And every time I’ve written my own game engine (not just for IF), I’ve always had narrow and specific design goals in mind

I think this part is really interesting. You, like me, are motivated to build authoring frameworks.

I don’t want to go on too long right now, but the short version is this; I am aware of the perils of over-analysing, therefore this ‘taxonomy’ is constrained to 32 elements.

However, I do have an ambition to create a general-purpose authoring framework. And I’m confident that can be achieved.

There’s another theme in your post about portability of the format. I can’t do justice to that right now, but please know that is a priority for me too.