My White Whale 2- preparing for take-off
So I got a decent amount of feedback on my previous post. Part of it was questions about what I precisely meant by 'physics', which I realize in retrospect I never really defined at all. Part of it was questions about what a ruleset like this would look like. So I decided to write a follow-up. Probably several. I'm going to try to show what I meant by making this ruleset.
We're gonna be a bit methodical about it. That's not how I usually work; I usually have a vague idea of what I want things to be like, and I have thoughts about some mechanics and I work at it from all angles at once. Doing so however would lead to a conspiracy board of loose elements that wouldn't really come together right until the end. It wouldn't make for good reading.
So here's what we're going to do.
First, we're going to create an intent for our system. We're being explicit about what we want the system to be able to do, what it should report, and what we expect the system to lead to at the table. We're also going to set some hard boundaries. I want to do this up front for the simple reason that it will help me identify in each of the stages after if what we're doing is necessary or if I'm getting stuck in the weeds. This will already be a big enough project even if I'm not bikeshedding the hell out of things, so I want to avoid that as much as possible.
Second, we're going to have a look at how domains work(ed) in our world. I'm not a historian, so I'll have to rely on secondary and tertiary sources here (any recommendations are welcome). I'm not sure yet which ones, which time periods and exactly how. I have a feeling I will focus on pre-modern, pre-industrial ones for two simple reasons. For one: this is the kind of game I generally run, so it's my primary focus. Secondly, and this might be a slight spoiler, but trains and other motorized transport changed up many of the things we're going to be talking about. Will I disregard it entirely? Maybe not, but it will not be my focus.
This look at historical domains will guide us in the third step, where we'll try to analyse these domains from a systems thinking perspective. The simple reason for this is that this is what I am skilled in. I'm a system biologist by education (even if not by trade), so this is what comes naturally to me. This is a great way to describe the behaviour of highly complex and interconnected systems as a set of components or agents, and the way they interact. I might also start talking about Hofstadter and Strange Loops. This step hopefully reads to an abstracted description of the physics I talked about in the first post.
After that we're going to have to do a few other things. I'm not sure yet about the ordering, or if there will even be one. We'll have to start putting numbers on things, for one. Up until this point I'll have talked primarily in tendencies and directions. However, without some hard numbers we don't have a functioning system. We need to know how much troops a king of a domain can field, how much income he gets from his lands, etc etc. I'll have to figure out a good way to come up with those. I'll also have to test these numbers. Theory is going to be useless without some hard proof that it works as intended. During this testing we might find missing elements in our model of a domain too, and have to go back to the drawing board. It'll also show us if we actually created something that conforms to the intent I'll have lain out in this post.
We'll also have to start looking at the procedures of play. I'm not entirely sure yet exactly when we'll have to start working on these. Intuition right now says this will have to be done concurrently with the two steps above, but it might also be a thing I'll have to write in its entirety before I can even start on that. We'll see.
Commander's Intent
What should the system cover
- The rules should cover the aspects needed to run a domain at the table. That is: given these rules, a player should be able to start running his domain without needing outside sources or help, given a frictionless domain in a vacuum. They should not need referee interference for the 'normal' tasks required for running a domain.
- It should at the least allow for running a domain in a pre-modern fantasy setting. It would be a plus if the subsystems are loosely coupled in a way which'd allow for changing out parts to allow for modern or even scifi settings too. However, this is not a hard requirement.
- The domain play should tie into other aspects of play. It should not feel clunky to go from it to the war game, for example. There should be feedback loops in place between these so that one mode of play influences the other.
What do we count as a domain
Historically a domain has been considered a kingdom, barony, or some other kind of plot of land governed by some ruler. This is the bare minimum. However, I'd also like it if it'd allow for the running of migratory domains. This would help running roaming bands of mercenaries, Mongol hordes and other similar groups. Even further, if it were to also cover non-state domains such as a large trading factions, that'd be even better.
What should the system lead to at the table
- Though the results of the system need not be realistic in the sense that we'd be able to accurately simulate medieval Europe through it, it should be consistent with the fiction we're attempting to emulate.
- They should be interesting enough that players will actually want to start a domain.
- The rules should encourage intrigue, competition and cooperation. If they encourage stagnant islands they're not doing a good job at what they're supposed to.
Rules complexity
- The rules should be easy to grok, even if hard to master. You should be able to start and run a domain when following the procedures, even without fully understanding all details of the system.
- Because of this, I'd ideally like them to span as few pages as possible. They should not cover the whole length of one of the LBBs.
- While domains necessitate some level of bookkeeping, ideally this should not be an onerous level. I will keep this vague since I am not sure yet what I consider onerous, but I'll know if when I see it.
- Given that domains will primarily be run during downtime it can take some time and effort, but it should not have to become a second job. Let's say maximally 30-60 minutes per week.
- As per my last post, these rules should not be doctrinal. They should not say (outright) "you ought to do this". It should be a series of conditionals, and causes and consequences. "If you do this, X happens. If you do not, Y". These "physics" allow for the feedback loops I will hope will reduce the immediate complexity of the rules, as well as the great number needed.
Additional concerns
- Given that the ref will most likely be running a bunch of these, we might need to create a set of shortcuts for him to do so without swamping him with work.
So now we have a set of targets to aim for. Next time, we'll look at some real life examples of these systems. Until then, count your torches and keep mapping.