10/4/2019
One of the big take-home lessons from the later Wittgenstein is that it pays to be careful of the human tendency to assume that things can only work one way even in dealing with cases where there is nothing that would keep them from (sometimes) working in different ways. The question, “What is a game?”, which often comes up among game designers and game critics, was one that Wittgenstein found to be so intractable that he chose game as his prime example of a family resemblance concept-- an idea that could not be pinned down by any set of necessary and sufficient conditions (that is to say, by a definition in the traditional sense), but only understood as a kind of network of examples, some similar to others but without any necessary similarities between all members, or even any rule for determining what does or does not fall within the concept (indeed, the notion of family resemblance was taken to be more basic than the notion of a rule altogether, so it is no wonder that we could not understand the former in terms of the latter!). If he was right about the kind of concept that game is, then it is no wonder that game designers and critics today still haven’t managed to offer an ironclad definition for it, because there can be no such thing.
At this point, we could go into a discussion of anti-essentialist and post-anti-essentialist treatments of the relationship between defining art and creativity in art, and how the same thoughts could be applied to games, but I’d rather take this blog post in a different direction, and let Weitz, Danto, and company sleep for the time being. Instead, I’d like to look at some of the other abstract-level game-dev questions where it’s worth realizing that there isn’t just one answer, but rather, a whole range of different ways that games can be. Specifically, I mean questions like:
“Should you sacrifice realism for the sake of game mechanics, or game mechanics for the sake of realism?”
“Are games, fundamentally, a story-telling medium?”
“Is it more important for a mechanic to promote immersion, or to increase strategic depth?”
Teleological structures in game design
What all of these questions (and many more) have in common is that, if you view games at a very high level of abstraction, the questions become questions of teleological structure-- that is, the relationships of purpose that hold between the different parts of a game. At the relevant level of abstraction, “parts” refers to very general things, like mechanics, theme, or story.
A nice thing about knowing the purpose of something is that if you know what something is for, that carries with it a very intuitive notion of what it is for such a thing to be good or bad, and for what it is for something to be good or bad for that thing. For example, a snow blower’s purpose is to help you move snow, so a good snow blower is one that enables you to move the snow that you need moved, when you need to move it, as efficiently as possible, while a bad snow blower is one that fails to do that (maybe it gets stuck a lot, or just doesn’t move a meaningful quantity of snow). Likewise, if you shove a metal pole into the works of a snow blower, and all of the little parts shatter, you’ve done something destructive-- you’ve broken it-- because now it can’t move snow anymore, whereas, if you paint it a different color, even though you’ve made a significant difference to the machine, you haven’t broken it, because the change you enacted did not hinder the snow blower’s ability to perform its job. And, if you know what a human life is for-- perhaps something like the exercise of reason-- then you can work out what it takes to have a good or bad life, and thus, what you should do-- or so Aristotle thought, at any rate...
So anyway, if we can figure out the purpose of something like mechanics, theme, or story, we’ll know what it is for those things to be good or bad, and can understand what it means for our choices as designers to make them better or worse. For example, if we know what mechanics are for, and we know what a change we’re contemplating will do to the mechanics (this is the actual hard part, and not something this post will deal with)-- say, in the spirit of one of our questions, it’ll greatly reduce the possibility space defined by those mechanics, but make those mechanics conform better to reality in the process-- then we can assess whether or not that change will count as having made the mechanics better or worse.
Now, what we could do is make a tempting but naïve assumption: that all games have, or properly ought to have, one and the same teleological structure. But, instead, let’s open our eyes to the full richness of the world and explore various possible structures, how they work, what sorts of games might be built along them, and how the structure shapes the game that results. If we find that there’s just one teleological structure shared by all games, it’ll follow that the standards for mechanics, theme, or story-- what it takes for each to be good or bad-- are always the same. But, if we find that there are a number of different teleological structures where, when we look at them, we can see actual or possible non-terrible games that follow them, then we’ll need to be prepared to be more flexible.
To do this, let’s invent a tool: the teleological structure diagram. We can represent the teleological structuring of such parts by means of a diagram using arrows, where each arrow means “derives its purpose from”, or, more simply, “serves”. So, for example:
story → mechanics
describes a structure where a game’s story exists to serve its mechanics, whereas
mechanics → story
describes a structure where a game’s mechanics exist for the sake of its story.
We can make these diagrams a little fancier, but perhaps more intelligible if we add some kind of final purpose-- we’ll designate these with square brackets ([]) to indicate that they’re not actually parts of the game. So if we have a structure
story → theme → mechanics → [entertainment]
then what we’re looking at is a game designed to entertain (and I’m not saying this always has to be the goal, though it often is), where the mechanics are designed to produce entertainment, and where the theme exists in order to help the mechanics do their job, and where the story in turn exists for the sake of the theme (to flesh it out a bit, perhaps).
This example, incidentally, is a very common structure. If you’re making a MOBA, for instance, it’s the gameplay that generates the actual fun. But raw mechanics, abstracted from any theme, are hard to learn, hard to relate to, and hard to keep track of during play even once you have the rules down. Adding a theme-- here are some heroes fighting a war; they use skills and/or cast spells; they equip items-- makes the mechanics make sense, which helps the player to understand, at an instinctive level, how to play, and makes it easy for the player to evaluate the state of the game by sight. Even chess, as abstract as it is, makes use of this technique-- think of the knight: horsey jump!-- or the pawns: the little guys! Where your MOBA might differ from chess, though, is that it’ll probably have a lot of different heroes who are a lot more complicated than your typical chess piece. So, to help the player understand them better, you might deepen the theme by adding some small-scale story elements in the form of character backstories. Because these exist to serve the theme in serving the mechanics, they should be designed to deepen the player’s impression of the character in a way that emphasizes what the character actually does, mechanically-speaking.
Here are a few character bios that I wrote for an old Brood War mapping project. They’re short, because of the limited number of text lines that Brood War was comfortable displaying at a time, and because (once again, owing to the structure of Brood War maps) players would be reading these in-game, effectively on every other player’s time-- but if you think about the purpose that these are supposed to serve, it should be clear that they don’t even have to be long. League of Legends champion bios face none of the same constraints, and they’re longer than the examples I’m about to give...but not that much so.
Anyway, here’s the first one:
Bill Carlyne
A professional boxer who got tired of using his fighting skills for entertainment, and left the ring in order to engage in real combat for "good causes." Wound up joining the Falcon Group, who have discovered that he is sufficiently trusting that he will believe them when they tell him that he is doing the right thing, regardless of the true nature of the mission.
What can this bit of story tell you about how this character fights? Well, for one, you can be pretty sure his main attack will be a melee attack. But there’s more to it than that. If you try and imagine what this guy probably looks like, above and beyond the Protoss Zealot that I was using to represent him, you’re probably picturing someone big, stupid-looking, maybe with a nose that looks like it’s been broken one too many times. In other words, you’re picturing someone who looks like they fill the “tank” role, someone with abilities that aren’t too flashy, but who soaks up a lot of damage. Which is exactly what he was supposed to do.
On the other hand:
Pierre LeArne
A homeless man who wandered onto a battlefield on Rikaus X and was taken up by the Roche Band as a kind of mascot. Soon demonstrated violent tendencies, and was therefore fitted with a set of powerful (but painful) electric weapon implants for use as a human weapon.
This guy is probably a mess-- disheveled, twitchy, maybe his eyes don’t focus quite right. The guy you’re probably envisioning is not sturdy, nor fast, nor tricky, but he is extremely dangerous, the kind of guy who will flip out and go ultra-violent for completely insane reasons. That’s because this character is an ability-focused glass cannon. If you’re on the other team, and you step into the wrong spot relative to the shapes of his damage outputs, sudden death is a very real possibility.
For a balanced, dependable, more newbie-friendly class, consider his comrade:
Tyrone Jin
Career soldier, formerly with the Lorne Federation Army. Twice decorated for valor, but dishonorably discharged after being caught in bed with his CO's wife and daughter (simultaneously). Now a core member of the Roche Band, in command of that group's Beta Division.
This guy is a lot less colorful. He’s basically your stereotypical bad-boy soldier type, which I meant to fit with his role as a simpler, less specialized character.
Anyway, the point is that here we have an example of story serving theme. But what if we had a different structure? What if we had:
theme and mechanics → story → [entertainment]
If you think about it, you’ll probably realize that narratively-driven single player games often adopt this structure. Now, we can see how theme can be shaped to serve story, by serving as a backdrop, but what about mechanics? This is done by choosing mechanics that harmonize with the story. Want to show a character’s frustration? Have the player do something frustrating. Want to show the results of a character’s training? Strengthen the player more than the enemies, so that he can slaughter them. From a mechanics-first perspective, doing that makes no sense-- where’s the skill or strategy in it?-- but for a game where mechanics serve story rather than visa-versa, it’s appropriate. When this strategy goes wrong, that is, when mechanics should be serving the story, but wind up taking away from it instead by clashing with it, you have a case of the much-discussed “ludonarrative dissonance”.
Even theme can come first:
mechanics → theme → [entertainment]
You see this kind of structure in things like hardcore simulators, where the entertainment value comes from the game’s connection to something cool (to the player) in reality, like driving a train or learning to fly an A-10. When a player wades through the many-hundred-page manual of a combat flight sim like DCS World, it’s not like each and every system on those pages plays a vital role in furthering the skillfulness or strategic depth of the sim’s combat model. Rather, the idea is that, since the A-10 (or whatever other aircraft) in the game works like an actual A-10, the player comes away thinking that maybe, just maybe, if they found themselves in some kind of horrible emergency situation in real life, then perhaps, admittedly with a very small percentage chance, if there happened to be an A-10 at hand, they could get in it and maybe, with a lot of luck, and not really thinking the scenario through too hard, go rain death on some n00bs, and are therefore just a little bit more badass than they were before they played. To give the player that feeling, the mechanics need to serve the theme-- in the A-10 case, for instance, they have to match how an A-10 actually works-- rather than the theme bending to fit the mechanics (as would be the case in a more arcade-y flight sim). And, of course, if the software has a different goal, for example:
mechanics → theme → [education]
as in the case of a flight sim designed for training purposes, or other, similar “serious games”, there, too, the mechanics need to be fitted to the theme rather than visa versa.
An interesting take-away from all this is that there clearly isn’t any one teleological structure common to all games. If that’s the case, and the questions we started with are questions of teleological structure, then it follows that there are no universal answers to the questions. Rather, different games are structured in different ways, and which elements serve or are served by which others will depend on the particular structure of the game in question.
Simple and less simple uses of teleological structuring
Now that we’ve introduced the idea of a teleological structure, let’s talk about what we can do with this tool. The simplest thing to do with it would be to pick a structure for your game, and design your game in accordance with that structure. Picking a teleological structure is convenient, because it provides answers to the tricky questions that we started with for your game. Want to know whether your game should sacrifice realism for the sake of mechanics or visa versa? Look at the direction of the arrows connecting theme with mechanics in your teleological structure diagram. If you’re making your dream arcade shooter Super Blasty Man 50000, your arrows probably go from theme to mechanics, so realism should be sacrificed. On the other hand, if you’re working on Passenger Trains of Great Britain 1852-1853 (and you’re using the title seriously, not ironically as some kind of damn hipster-wannabe jab at the world of semi-functional German-made simulators and the people who play them), then your arrows are going to go from mechanics to theme; you probably want to make all the train fans happy by getting the trains correct, even if that means that operating them is just a matter of going through the procedure correctly and not some big puzzle/strategic challenge/train-driving-skill-test.
First complication: none of this is actually anywhere near as clear-cut as I have made out. Parts can have multiple purposes, equally, or with greater or lesser emphasis. A game can have theme to support its mechanics, and also because that theme is just cool. A game can be mostly realistic, and give you a bit of that “Wow, this’d actually work IRL!” feeling, while making some concessions to mechanics so that it’s also fun just to play. A game can attempt to provide entertaining gameplay, an engaging story, and an immersive world all at the same time, using each in support of the others, while trying to accomplish the goal of creating a compelling experience on all three fronts simultaneously. I suspect that many designers actually want to create:
Aiee, right?
Second complication: games aren’t always the same all the way through. Structures can change as games progress; sometimes, they must change, in order for a design to achieve its ultimate form. In other words, some games are designed to embody dynamic teleological structures.
Ever wonder what the point is of the repetitive mechanics found in traditional RPGs, especially JRPGs? If so, here’s a theory for you. Let’s say you have a story to tell. In other words, you want to build a game with the structure
theme and mechanics → story → [entertainment]
So let’s say you build your story, give it a setting, enhance it with mechanical tricks like we discussed earlier, and you find that it has certain problems. First off, you wanted to build a great setting for your game, and to develop your characters, but now the beginning of your game drags on and on. Second, you find that, even though your story is slow, it’s still not epic. After all, a slow beginning doesn’t automatically get you an awesome ending.
Now you could just work to improve your story, but that’s tricky, assuming it’s even possible for the story you have in mind. Or, alternatively, you could basically make two games in the same world. The second game will have the structure you were originally thinking about, but the first will be structured
story → theme → mechanics → [entertainment]
In other words, you’ll start off with a mechanics-focused game. If you’re making a typical RPG, this will be a game about going around and killing stuff using some basic turn-based tactics. The world, in this game, is primarily a bunch of loot, dangers, and potential XP all scattered around; the characters are the tools by which the player takes that loot, defeats those dangers, and spends that XP.
The nice thing about this structure is that it does not require the world or the characters to be intrinsically interesting. Rather, they can be extrinsically interesting: they serve the mechanics, and the mechanics are what generate the entertainment value of the game. Geographic and historical information about your world might not be gripping in and of itself, but if those things are a game’s way of telling a player about where to find cool fights and good loot, and the fun of the game is coming out of the fighting and the looting, then the player has a reason to be interested.
The reason why that’s convenient is that if you put these two games back to back, and kind of melt them together a bit in the middle, then by the time the player gets to the point where the story becomes the primary engine for generating entertainment value, you’ve already had a chance to build up its setting and characters. The mechanics (which might be getting a bit stale by that point anyway) can then shift from being the main driver of the game into playing a supporting role. If we introduce a triangle symbol to represent a transition as the game progresses, we can represent the combined structure as:
story → theme → mechanics → [entertainment]
▼
theme and mechanics → story → [entertainment]
Think, for a second, about the structure of Escape Velocity: Nova (hey, if I can use a 2D Newtonian spaceshooter example, I usually will). Early on, the game is all about the combat, and about building up your ship so that you can be stronger. You’re encouraged to explore because exploration means not only finding new potential trade routes and enemies to grind, but also new stuff to buy, since each faction gets its own distinctive ships and outfits. There’s a long tradition in the Escape Velocity games of the player being incentivised to head further and further out because there’s good stuff to buy in more dangerous areas, and your first serious warship often comes from dodging your way past a bunch of pirates, bribing your way onto one of their stations, and then paying a visit to its shipyard.
Meanwhile, you’ll be doing missions. At first, the missions are very boring; not only are they usually fetch-quests, but they’re generic, repeating ones at that. As you progress, though, the missions will get more interesting, and also more dangerous, often involving some quite hairy blockade-running or some challenging fights. These can be fun to do; at the same time, the game pushes you to do them because you’ll start running into the limits of how strong you can get without unlocking more ships and weapons through missions (arguably Override does this bit better than Nova; Nova has some modded medium-scale ships flying around, like upper level Pirate Valkyries and Starbridges, that are really powerful without being too huge to capture in a readily-purchased ship, and which a player might well end up flying until purchasing ships becomes irrelevant-- more on that in a moment). And so, not only are you exploring and learning about the galaxy and its factions, but you’re also starting to meet characters and form associations.
But then something weird happens. The missions pick up, and before long, they’re chaining together one after the other in big arcs, cutting out the trading and the grinding. Fights get bigger and bigger, but not necessarily harder and harder. And then, at least in many of the possible storylines, the game gives you a ship. And not just any ship: a strong ship, more or less fully equipped. Probably, for that matter, your last ship. And one that’s more than capable of unleashing a massive amount of hurt on anyone foolish enough to get in its way.
Think about that for a second. You’ve got this whole game about flying around to different planets and trading goods, engaging in piracy, and so on, so that you can get better and better ships and outfits. And then the best ship turns out to be one that you neither buy nor capture; you just go through the storyline, and eventually, there’ll be a point where whatever you’re flying (suddenly) gets swapped out-- yes, the game takes your ship away!-- for a fully loaded death machine without equal.
For a pure arcade game, the progression of Nova would make no sense. Mechanics, and opportunities to exercise them, being added would make sense: more variety of ships and weapons, hairier and hairier trade routes with the better and better payoffs that you’d need to buy those ships and weapons, wickedly hard battles, and so on. But Nova is structured as an RPG, with that shift in structure that we’ve been talking about. So, by the time you’re given an Auroran Thunderforge (or the equivalent from another storyline), the teleological flow guiding the game’s design has already shifted to being one where mechanics serve story rather than visa-versa. Thus, the Thunderforge isn’t a tool for blasting through obstacles to interplanetary commerce or for capturing bigger and better ships; it’s an expression of how the player’s character has risen to become a mighty warrior and a respected leader among the Aurorans. And you feel that character’s might every time you give some poor fool a faceful of triphammers to chew on. At the same time, getting an ultimate ship also wraps up a lot of the old mechanics, like trading and piracy (unless you need some extra cash for outfits, though this is unlikely), that would clash with the story by this stage in the game. The design decision to give the player a ship thus reflects the shift in guiding principles specified by the game’s dynamic teleological structure.
First rejoinder to the complications: the fancier and murkier you make your teleological structure, the trickier you make things for yourself as a designer. Nova, with its RPG-style dynamic structure that is so much more complicated than the more purely mechanics-driven designs of the earlier Escape Velocity games, runs into various problems. For one, the galaxy is built wrong. Why, you may ask? Open up your copy of Nova, load in a post-storyline save, and look at the map (or, if you don't own the game, you can Google for an image of the map).
See those big, colored expanses? Those are the territories of the largest factions in Nova’s universe. They’re also boring as hell to explore (as are the dead areas, for the same reasons). Why? Well, here’s the thing. From a story perspective, the expanses certainly have a function: they show that these factions are major powers, controlling some serious territory, not just rinky-dink little space empires or what have you. They also provide a lot of different worlds to serve as backdrop for the storylines. Heck, you’re dealing with factions here that are big enough to have their own sub-factions which, sure enough, provide plot fodder.
The problem is that exploration, by and large, isn’t happening during the latter part of the game; that part is heavily story-driven, so you’re mostly going from mission destination to mission destination, sometimes in a hurry, without wandering off in between (that would take you away from the story, after all); if you haven’t explored already, you probably won’t do so then. Rather, exploration occurs during the first phase of the game, when it is still centered around mechanics. And, from a mechanics point of view, those expanses are boring. The worlds in them might, in-universe, be culturally or historically interesting, but they’re not offering the player any gear that they can’t already get at the one or two best worlds of the factions, nor any different enemies to fight from one another. Worse than that, by and large, there’s nothing on the other side of them. Override was really good at that. Head west of UE space and struggle through the expanse of the Voinian Empire and eventually you’d meet the Emalgha, from whom you can buy crude wooden ships and crude but deadly rotary autocannons. North and east you have dead zones, with various alien factions on the other side (once again, with their own techs). South you find a few independent human worlds, then some dangerous renegade worlds (where you can buy pirate ships!), and south of them, more aliens. Classic EV put pirate worlds scattered around the rim of the galaxy, plus a few anomalous systems with good stuff randomlishly placed around the middle. Where I’m going with this is that both Classic and Override drive exploration by making it mechanically relevant (and indeed heavily incentivized). Nova needed to do the same thing because of when exploration occurs relative to its dynamic structure, but it failed to do so.
There are other problems, too. For instance, you don’t always know what faction’s storyline you’re joining when you do it-- which would be fine, or even good, for a narrative game where you don’t want the plot to be too predictable, but in Nova, it’s happening during the mechanics-driven phase of the game. From a mechanics perspective, not knowing which faction you are joining means not knowing which weapons and ships you’re going to be unlocking, which is only slightly removed from losing control over the game entirely!
And then an even more offputting design decision was that one of the major storylines takes away the player’s ship and starts him on a path of automatic ship upgrades very early on. It’s a moment that makes you want to throw your computer through the window, or better yet, through the game designer, because it happens when the game is still in its mechanics-driven phase, and basically negates all of the impact of your money-earning, your ship-stealing, your systems-tweaking, everything. Not good. Know your teleological structure and design accordingly, or this is the sort of thing that happens!
Second rejoinder: even if teleological structures are often, in practice, complex and indistinct, they can be useful as a tool for fitting your design to your strengths. Choose a teleological structure that fits what you are good at making!
Perhaps the most serious problem with Nova is that, quite frankly, most of the storylines just aren’t that good. Friends who have also played Nova agree with my assessment that the Auroran arc is the best of them, and the others lag considerably. The funny thing is that the older EV games weren’t exactly storytelling masterpieces either, but in those cases, it didn’t really matter, because they didn’t have the same dynamic structure as Nova. They weren’t attempting to change into narratively-driven games halfway through. They weren’t taking your ship away so that you could become the inheritor of a pirate legacy or whatever. You’d sometimes be given a weapon as a mission reward, sure, but always in the interests of continuing your development of your ship, not to negate that part of the game entirely. And, while the lategame missions would, indeed, have some plot continuity with earlier missions, they were first and foremost about the game having an excuse to throw a truly unreasonable number and/or strength level of enemy ships at the player. So, if the plot was a bit prefunctory (sometimes self-consciously so, especially in Override’s Strand missions), it wasn’t important. On the other hand, if you’re making something like Nova, you need stories fit for a story-driven game. If you don’t have them, build your game around a different structure.
That’s not to say that there’s anything wrong with Nova’s structure. There’s a total conversion plug-in (mod) for Override, Martin Turner’s brilliant The Frozen Heart, that does the story-driven-RPG dynamic-structure thing right. If you have an old Mac or SheepShaver virtual machine with a copy of Override installed, go scavenge TFH from somewhere (maybe Ambrosia’s databanks will still have it when you read this) and play it. Go now.
Anyway, the point is that you need to choose the right teleological structure for your strengths. If you compromise your mechanics so that they can serve a mediocre story, players will just be pissed that you took their ship away (or whatever happens to be your game’s equivalent move). I expect you’ll find similar problems if you compromise your story for the sake of mediocre mechanics. Always keep in mind which parts serve which other parts in a design, and pick a design where the main thing that’s in charge of fulfilling the purpose of the software as a whole-- whether that purpose is entertainment or something else-- is going to be really good.
So, even though a game’s teleological structure is neither a set thing throughout the game nor an all-or-nothing, absolute rule for how each part of the game should be designed, it can still be useful to identify, both before and after you’ve settled on what you want to make. Hope this little conceptual tool I’ve laid out can be of use to you in your projects!
Cheers,
JL
Connect with Us!