About Structure Sizes
RPG bloggers have noticed these things called “game structures”, and in particular scenario structures, which I believe serve to inform players on how to frame the fiction and the decisions of their characters, hopefully in such a way to make sure their choices are always informed and impactful.
One interesting thing in Justin Alexander’s definition of game structures is that he talks about them coming in different "sizes". AngryGM operates with a significantly different (though still related) definition of structures, but also talks about their relative sizes.
The question, then, poses itself: what the heck does it mean to say that game structures have different sizes? We are dealing with an incredibly abstract concept here, afterall, so what is there to 'measure' that allows people to so intuitively find structure sizes so easily?
GM Ruling x Scenario Structures
One size distinction Justin proposes seems fairly clear. Going from the smallest structures (which he calls GM Rulings) to anything bigger than that (the various macro structures, which we’ll broadly conflate into scenario structures here) means going from the resolution of a single intended action by a player to the resolution of a series of interconnected actions that resolve a singular, broader intent. The “size” distinction between GM Ruling and Scenario Structures, then, is the difference in the number of actions they are meant to resolve.
But Justin proposes that Scenario Structures themselves come in a lot of different sizes. He argues, for instance, that hexcrawls, dungeon-crawls and combat can form a kind of (inverted) pyramid in the old-school dungeon-dragonesque games: hexcrawls being the biggest structure of the three, combat the smallest, with dungeon-crawls in the middle.
[if I ever upgrade to “image-having-blog” status, this is where a picture of the inverted pyramid goes]
Significantly, Justin doesn’t measure the number of actions (or decision points) each resolves to make this comparison of sizes – it seems impossible to do so, since there won’t be a consistent number for each structure anyways. Meaning we are now working with a completely different concept of size.
Scenario Structure Size and Time
At first, I figured that scenario structure sizes would correlate to one of these two things:
- the length of in-fiction time the structure takes up
- the length of real-world time the structure takes up
Since these are the things we could be most easily be intuitively 'measuring' in our games to get this feel for what size each structure has.
The case for structure size having to do with in-fiction time is strong from Justin’s examples. When the structures in the pyramid are given explicit turns, they do cover progressively smaller chunks of time: usually, a hexcrawl turn is a number of hours or a day, a dungeon-crawl turn is a number of minutes, a combat turn is a number of seconds. So far, so good!
But let’s say we add a downtime structure to that: one where players spend time recuperating and pursuing long-term projects in town before heading off to adventure again. The “turn” for such a structure can be measured in weeks or months, so evidently it would be a super structure that would go on top of hexcrawls, right? … Right?
Well, maybe? Maybe not? We can conceive of this relation like this, yes, but I think there is also good reason why we also might not. Unlike the relationships formed between the 3 structures in Justin’s example, hexcrawls and the other smaller structures don’t really happen “inside” the downtime structure. A downtime structure may well happen on its own, resolve anything it has going in it, and end before PCs start engaging with the other structures. In contrast, the PCs haven’t finished dungeon-crawling when they engage in combat in a dungeon. Combat is a part of the dungeon-crawl, then, whereas the dungeon-crawl isn’t necessarily a part of downtime. With this understanding, downtime can’t quite function as an umbrella that covers the other structures, as implied by the inverted pyramid scheme.
So maybe what we need to be looking at is real-world time, as in, how much of our actual game time we spend on a given structure. After all, that will have a stronger impact on our experience as players, so it would make sense to use that as a basis, yeah?
Using this frame of reference would also place downtime as a smaller structure than the others, which seems correct: it is often a passing structure in a game that uses it, a brief interlude between the action of exploring places and facing threats which forms the meat of the game (though this can, of course, vary).
But then, the other relations get wonky. Dungeon-crawls can easily take up much more table time than hexcrawls; depending on the system, combat might take longer in real time than dungeon-crawls and hexcrawls both. Whatever was Justin’s understanding that led him to frame the sizes of the inverted pyramid that way, then, it apparently can’t have to do with the amount of table time it takes up.
So if we’re not measuring fictional time or real-world time, what are the structure sizes referring to? Maybe the answer is embeddedness.
Embeddedness
One of the most compelling aspects of the idea of game structures is that they feed into one another. When PCs come into conflict with some creature while exploring some dark cave, that’s the dungeon-crawling structure throwing them right into a combat structure. When the conflict is done, the players go right back to dungeon-crawling. From that example, we can easily say that the combat structure is embedded in the dungeon-crawling structure, or what we called being “inside” the dungeon-crawl structure earlier. We recognize a start point to the dungeon-crawl structure (whenever the PCs enter the dungeon) and an end point to it (when the PCs leave the dungeon), and combat can happen in the middle of these two points – clear-cut embeddedness.
Of course, nothing is ever so simple. Let’s apply the same rationale to try and establish whether dungeon-crawls are embedded into hexcrawls. What do we get then? The start point of a hexcrawl would be when the PCs leave some town to explore the world in “overland movement” mode, easy enough. But what about the end point? We can conceive of (at least) two different answers: i) the end point is when the PCs return to town; or ii) the end point is when the PCs reach some destination that ends this cycle of overland exploration. Notice that this destination may be the dungeon itself.
So whether or not dungeon-crawls will be embedded in the hexcrawl structure would depend on how you conceptualize the hexcrawl. If you think of a hexcrawl as being all of the travels PCs undertake in between going back to civilization, then any dungeon-crawls that happen outside of a city are clearly embedded in hexcrawls. But if we think of hexcrawls as being the overland travels PCs make in between any two points of interest they want to interact with in the map, then suddenly we are assuming that the hexcrawl procedure has ended before dungeon-crawling starts, and as a result dungeon-crawls aren’t embedded into hexcrawls.
This isn’t a very practical distinction, in any case, but I’d argue that it does follow from two very different viewpoints about what you’re doing when hexcrawling. A group of players who decide to venture out of town expressly to explore what’s out there and fill in their maps with points of interest is much more likely to think that the endpoint of that exploration – i.e. of the hexcrawl – is the moment they get back to town. Even if they find a dungeon and decide to go into it, that will feature as a part of their overall exploratory journey; the hexcrawl was the point, the dungeoncrawl a mere feature.
A group of players who decide to venture out of town expressly to arrive at some dungeon they can pillage is more likely to think that the endpoint of the hexcrawl is the moment they find that dungeon to explore. The dungeon they find, even if they didn’t know about it before they set out, was the intended destination from the get-go. The dungeon-crawl was the point, the hexcrawl a mere way to get to it.
Practically speaking, in both cases they venture out of a town, find a dungeon, poke around in it, and go back to town eventually. But this difference in how they interpret these events might actually create different experiences for the players, even though the 'actual' events are pretty much the same.
Anyway, back to the point. What we’ve managed to establish is that embeddedness can be a funky concept with which to “measure” the size of a structure. Does this mean that embeddedness isn’t the correct measure for size?
Actually, I think embeddedness might be a great framework for scenario structure size, precisely because it highlights that the intuitive understanding that ascribing a “size” to them is incomplete. It shows that our understanding of the purpose of the structures interferes with their relative “sizes”, since the purpose we have when we engage with a structure dictates when we conceptually think it ends. It also shows that there is an experiential difference for players between using a structure as a means to get to another one, or engaging with a structure for its own sake and having another happen as a part of the first.
Two Versions of Embeddedness
In fact, this last point suggests that we can conceive of embeddedness in two different ways: temporal embeddedness and functional embeddedness.
Temporal embeddedness refers to what we’ve been discussing so far. It is, simply, whether or not a “smaller” structure happens during the period of time defined by a “larger” structure, in between its start point and end point.
Sometimes, though, we use a structure as a piece of the resolution of another, what we might call functional embeddedness. That is the case of combat in a dungeon-crawl, or of a chase scene after a suspect in a mystery investigation. Resolving combat tells us whether the PCs get to keep exploring the dungeon, and in what conditions; resolving the chase will tell us whether the characters captured the suspect to interrogate them, or if they’ll have to look for other clues elsewhere. In these examples, the result of the smaller structure is integral to how the larger structure will unfold.
Sometimes, though, even if the events of a structure happen in the meantime of the resolution of another, this relation of embeddedness doesn’t show up. If the characters are invested in a weeks-long research scenario structure, and break it up to attend a party that won’t affect their research in any way, the party scenario isn’t functionally embedded into the research scenario, even though it is temporally so. If they were attending the party specifically to try and get some answers about their research from some NPC, however, then it would be functionally embedded in the research scenario.
We might even, in fact, be able to find instances where functional embeddedness happens regardless of temporal embeddedness. The characters spend weeks researching a monster – whether that research will reveal the monster’s secret weakness or its preferred tactics will play a large part in how things will go when they finally set out to hunt it down. Research isn’t temporally embedded in the hunt scenario, but its outputs' main function is to change the conditions of said hunt. The research is, in a way, embedded in the hunt, it serves primarily as an input for it.
As a result, we might even come to the conclusion that the hunt scenario has already started when the PCs start doing the legwork that will be necessary to undertake it, even though the actual work of physically chasing the beast hasn’t started. This suggests that functional embeddedness is so strong that it might even reframe what the start and end points of a scenario even are to accommodate these functionally embedded structures into a temporal embeddedness as well. This is all a matter of interpretation, though, and different people will understand these relations differently. That’s fine and expected, it just bears keeping in mind!
Another interesting quality of embeddedness as the focal aspect of structure size is that it can apply whether you’re building structure with an eye on how the fiction relates to itself or on how the gameplay will flow or on how the narrative is built. So if you’re thinking more in terms of encounter scenarios that make up adventure scenarios, the embeddedness shows the difference in structure size here. Same goes if you’re thinking in terms of dramatic beats fitting into, say, on arc of a three-act structure.
In Conclusion
Structures are abstract concepts, only somewhat observable from our conversational patterns at the game table. People correctly observe that some of them loom large over others, and refer to the quality of this observation as a change in structure “size”. The general point of this observation comes across well in the metaphor, but it is worth noting that there’s nothing we can objectively measure that objectively defines this difference in size.
So far, then, I think the size of structures are best understood through a relational lens of embeddedness. Which structures fit inside of other structures? Which structures have other structures inside of them? Which structures exist to serve another structure? Which structures are the point of playing the game in the first place? All of these are questions that define what “size” scenario structures have in our minds.