To assure you that I have some street cred in what follows, let me disclose, or re-disclose, that in my day job I work as a scientist and I have a snappy degree from a snappy school.
All scientists use models to validate certain ideas about how a system behaves. I especially like "toy models", models that are deliberately simplistic, because if they behave in ways similar to the experimental observations, then it's a great aid in interpreting the experimental findings. For example, in modeling how atoms move around on a surface, a toy-model approach uses "cubonium": pretend the atoms are actually cubes, on a 2D square grid. That's not accurate at all, but if you see similarities in the behavior of cubonium and your experimental findings, you know that the assumptions you built into the model have some validity, and that the system is explicable in terms of those simple assumptions without the need to invoke more elaborate effects.
One system that's resistant to modeling is the electronic behavior in atoms, molecules, or solids. It turns out that once you have more than a single electron (i.e. anything other than hydrogen) the electron-electron interactions make the problem computationally intractable. There's a sophisticated computational apparatus called density functional theory (DFT) that makes certain useful approximations and assumptions that allow you to calculate electronic behavior for a variety of systems. This is a rigorous theory and (justly) won the Nobel Prize. I have several friends and colleagues who are full-time DFT modelers. It's a serious, and challenging, scientific discipline. And yet!
DFT has an open secret. Experimentalists like DFT because if you can find agreement between your experimental results and first-principles modeling like DFT, well then maybe you understand what's going on physically, and DFT is a "first principles" model and is therefore way more rigorous than the toy models I mention above. But just as Stalin said "show me the man and I will show you the crime", it's equally possible to get DFT to tell you what you want to hear, just by controlling the input conditions that go into it. Serious modelers don't do this, of course, at least not on purpose, but it's possible to use this tool in an undisciplined way to get the results to say what you want them to say.
We are living in a moment where those in charge of public policy look to the scientific community to navigate the uncertain waters of a public health situation in which accurate data has been hard to come by, particularly in the early stages. Thus many consequential decisions, especially early on, have been based on models. As a scientist, this worries me. A lot. It's one thing to say, "look, this is our best guess at the moment, let's try this and correct as appropriate." Epistemic humility is the first quality the scientist should cultivate, and I think by and large we do that pretty well, but not everyone who wants to invoke science, and in particular scientific models, in their arguments understands the importance of holding scientific conclusions tentatively.
But more importantly -- and yes, I get that this is a slippery slope argument -- it's not clear what limiting principle would prevent the abuse of scientific models as a means of exerting control over a population, should someone want to do that. But if a rigorous hard-science model like DFT can be wrong or can be manipulated, how much more a soft-science model that has behavior as one of its inputs?
Game designers understand this very well. If you say to a publisher, "I coded up a model of my game and have simulated my game 10,000 times, and I'm sure it's balanced, so it's ready to publish", they'll laugh in your face. If you haven't played it with real people, you haven't even begun to playtest, because people don't always behave in the ways your model predicts. Your model relied on assumptions and approximations, and those may or may not have been accurate. Data is of significantly greater value than models, which is why we playtest. When data is not available, that doesn't necessarily justify using models as the best or even as a good alternative to data. That's true in game design and it's true in public policy as well.
Let's turn this in a more upbeat direction and talk about models in games. I talk in Ch. 7, and here at the blog, about a game's "central idea": what is the game about, what is its literary theme, what is it saying, what are we the players saying by the decisions we make? These are fun and important design questions.
But there's a different design question that I think is perhaps insufficiently appreciated among modern designers, namely the idea of a central abstraction.
As readers here know, I think Puerto Rico is partly to blame, in that it taught us that trying to include everything was a valid design strategy. We have to produce goods, ship them, sell them, build stuff, bring in workers: lots of different things happening! And look how quickly we go from that to Agricola's kitchen sink theme evocation, where there are so many aspects of subsistence farming included that you wonder how subsistence farmers managed to do it without a detailed instruction manual. And same thing more modern games like Scythe or Maracaibo or Terra Mystica or Terraforming Mars. All of these games, and the many others we can think of, force players to grapple with many aspects of the games' settings all at the same time.
It wasn't always thus. Witness a game like Acquire. Acquire is ostensibly a game about hotel chains. Now in the real world, there's a lot to running a hotel chain: site selection, permit acquisition, bidding out the project, overseeing construction, paying the construction firm to build the hotel, hiring staff, acquiring all of the items needed to run the hotel, paying for utilities, acquiring customers, providing hospitality, maintaining the grounds, maintaining the hotel, and many more things besides. And yet, in Acquire, to build a hotel, you drop a tile on a grid. That's it. That's because Acquire's central abstraction is that hotel chains grow. That's the only thing that interests us: chains get bigger, by moving into more cities or regions or however we want to think about it. Acquire isn't interested in the specifics, only in the growth.
Consider another of my favorites, Lost Cities. Running an archaeological expedition is obviously also a complicated affair: lots of library research, securing funding, acquiring tools, getting permits to dig, and a bunch more things, you get the idea. But in Lost Cities, the central abstraction is that archaeological expeditions progress. And it models this by having us place numbers in increasing order. The more we explore, the more interesting things we learn, the closer we get to the big discovery, the more valuable our knowledge becomes. In Lost Cities, the value of acquired knowledge from a dig is cumulative.
Consider yet another of my favorites and favorite go-to examples, Web of Power. In Web's central abstraction, we place cloisters into regions, signifying that our religious order has a presence in that region. The presence of advisors in turn gives us (collectively) permission to place advisors into that region's court. Religious orders score for the regions in which they have a presence, and for the inter-region machinations they're able to execute as a result of having an advisor presence on both sides of the border between any two regions. There are of course many other details to running a religious order-- moving into new regions, gaining sufficient influence to capture the ruler's ear, maintaining communication over large distances when correspondence happens at the speed of foot traffic, and so on--but all of these details are abstracted out so that the game can focus on the actual problem that confronts the players: how can I make my religious order the most influential, the most powerful?
Thus a good central abstraction is a model of reality but only a particular subset of reality. It says, this game is about this aspect of the game's setting, and no other. Different games can of course emphasize different things in their abstractions. A different hotel game could emphasize hospitality, in which case the game wouldn't be about chain growth, it would be about meeting customer demands. A different archaeology game could be about gaining information about a lost temple whilst avoiding taking on hubris (heh). And so on.
The key point is that every game has abstractions, even very heavily involved thematic games like the ones we mentioned above. Or for that matter, my game, Sands of Time, in which you build, battle, expand, advance, govern, build trade routes, raid, collect tribute; lots of stuff going on. And yet there are still many, many abstractions in this game, in spite of its complexity. And so the point isn't necessarily that every game should be as simple as Acquire, but that we should be mindful of the abstractions we're making and should always be open to considering abstracting just one more thing down. If we keep doing this, eventually we'll arrive at some minimum kernel of abstractions that the game needs so as to function, and it's at this point that the game can really start to sing.
I think it's worthwhile to have a central idea for your game, and I think it's probably also worthwhile to have a central abstraction. The central idea helps you make design decisions: does [this element] support the idea, does it steer players into grappling with that idea? The central abstraction can function similarly: does this potential additional system express the central abstraction, or is it another element of the theme that we're now going to try to incorporate?
In your race car game, where players have to make pit stops strategically to refuel and replace their tires, is it also important to have drivers have to take bathroom breaks, or is it ok for the game to not have to go that deep into the simulational weeds? In your movie-making game, in which you have to cast the best talent, is it also important to include negotiating rates with union representatives or is that an extraneous distraction from the central abstraction that "movies are made by writers, stars, and directors"?
The central abstraction, then, helps you filter out those long lists of helpful suggestions playtesters make of all the things you could add to the game. "You should totally add bathroom breaks to your race car game!" "Thanks for the idea, but the model here has more to do with how drivers jockey for position on the track, not at the row of toilets in the locker room."
Every take a hot take
29 Sep 2020
- [+] Dice rolls