A sketch for a "cute little dungeon crawl"
I’ve got a whole philosophy of game design I’m sitting on here, but today I’d like to share just one little provocative tidbit: game designers design players too.
Imagine you thinking through the design of some cute little dungeon crawl. You are going to have caverns connected by twisty passages, a hero/jerk who is capable of slaying roaming monsters/bunnies, and some inventory to hold potions and loot/bling. This isn’t a complete design, its just a setting and maybe a sketch for some rules saying how objects in the game world might interact. In conversation, you might follow up this description with a little story showing the rules in action (and filling in some interaction details): the hero starts at the mouth of the dungeon, she continues down a hall to a room with a large hatch, while gathering some loose coins she encounters the feeble but unfriendly monster, after slaying Skormo she descends past the hatch into a pit and encounters Multhar on patrol…
Yeah, this little narrative is the start of a play trace (or user story if you like). I wouldn’t make the claim that you always invent play traces for you games (sometimes coherent traces don’t emerge until play testing), but I will claim that part your primitive idea included a pile of expectations that describes how a player intersecting your idea will act. You knew that the player would attack Skormo right after it proved hostile, you knew she wouldn’t try to add the monster’s corpse to her inventory and then immediately try to use it like a potion, and you knew the hero wouldn’t just hang out at the dungeon’s exit — its just common sense. Well, you didn’t really know, the player could probably do all of those silly things in the completed version of your game, but your design told you what to expect.
Call it a pile of expectations, call it a “player model”, call it what you will. Can you think of any coherent game design that didn’t come with a “player” in this sense?
Even they craziest design admits a player design like “anything goes”, but a better design will tell you that some things are more likely to others, that some are outright impossible, and that some things are near certain. An even better design will include several, distinct player designs that tell you how one kind of person might react in one way while another stays oblivious to some game event. These players in your head are what give you internal go-ahead to quickly make changes to rules that you think won’t be noticed, or tell you to focus on a particular rule or setting element because your player’s choices critically hinge on it. Most designs never make it out of your head, let alone get in front of another live human — so relating to your player expectations are aspects of your design, not as properties of some external meat-bags, might give you deeper insight into your own design processes. Sometimes changing how you think your players will think can have a bigger effect on your end product than a particular change to the concrete game rules at an early stage (because it changes how you decide which design changes are reasonable to make in the future). Design speed-runners, design meta-gamers, design bumbling fools who don’t pay attention to on-screen instructions — decide how these players are going to fit into your games rules, setting, story, and even marketing. If something (or someone!) resonates with you, find a way to reinforce it, and if something bugs you (or is a bug) find a way to eliminate it. You don’t need to “fix” every exploit at the code-level, you can fix it by changing your target audience. Doing so is a valid, first-class design move.
Ok, rant completed. Stepping back, why does it even matter if “game designers design players too”? Well, in our lab we are looking at game design from a computational angle, and part of this is coming up with a formal, code-level description of the various processes a designer carries out. Should a computational level-designer just place blocks and power-ups in the world, optimizing a magic fun-ness metric, or should it play through its own levels and use information about what it took to beat the level into account when deciding where the level’s structure? The first one might make for a semi-decent program, but the second one seems a little more honest. If another system were designing whole games, would a “game” be represented as a pile of game-world assertions, or should it have a slot for holding expectations about players? If I am correct that game designers design players too, then I had better add that slot.
9 Comments