Tuesday, March 17, 2015

Optional Things Exist

I had a bit of a conversation about Nintendo today. One of the things we talked a bit about were the gold suits in the new Mario games. These are the suits you get when you die a lot in a level. They basically make you an immortal godling.

We came at this topic from very different angles. Obviously, the gold suits are a boon to unskilled or young players. But they are the reason I stopped playing.

I know they were optional. Sure, they're optional. A lot of devs seem to think optional things don't exist as long as you decide not to use them.

The opposite is true.



Let's talk about in-app purchases, which is how the whole thing got started.

The most common kind of in-app purchase is a gameplay helper. Whether it's a stat bonus, a rare item, free gold, more moves, whatever. It's always "optional". You can keep playing without them.

But they wage war on you just by existing. Every time you make a move and that glowing icon tells you that you could be doing it better, it's psychological war. It wears on you. You aren't playing the REAL game. You're playing a shadow of it.

Now, the golden suit is not asking for your money. It's free.

That doesn't mean it's any different.

The intent of the developer is almost unimportant. The thing that matters is what the player sees. And, to me, the glowing golden suit is exactly the same as a glowing shop button. More powerful, if anything, because I know it is provided out of kindness.

Sure, I can struggle to ignore it, but just by existing it cuts the foundation away. Why am I struggling through these levels? Even the developer doesn't give a shit how I beat them. It's especially bad because the developer gives up far before I do. They actively cut off my struggles before I'm done - "yeah, I can see you're trying, but your efforts are doomed and worthless."

It's not simply that the opportunity to bypass the levels exists. It's that it is pushed upon me so aggressively. The developer isn't saying "oh, here's an out if you need it", they're saying "you're playing wrong." If the suit could be turned off in an options menu, I wouldn't feel cut off at all. I would enjoy myself, knowing that there is a safety net cached away in an options menu I never have to look at.

What I'm getting at is that "optional" things exist. They have a weight and a presence. Even if a player chooses not to use them, the player still chooses in regards to them. And every time you offer the optional thing, you force the player to choose again, to take that optional thing into consideration, to consider the intent of the developer and weigh their own plans.

This isn't always bad. Many RPGs offer you optional things you can choose to do or not do. To be good or evil. To steal or not. To kill or not. To use magic or sword.

We choose what to do and what not to do, and that's the heart of our experience. Done badly, it can be repetitive, sure. But it never feels like the game is short-circuiting itself for the sake of offering those options.

Maybe it's because those options exist within the game world, rather than being inexplicably imposed onto it like the golden suit or the IAP shop. Maybe it's because the options are gameplay-centric rather than gameplay-avoidant. Maybe the lines vary from player to player.

There's lots to discuss. Quicksaves and quickloads become a part of this discussion. Permadeath. Multiplayer. They all exert pressures, put options in front of the player. And even if the player chooses never to use an option, that's still an active choice that the player must make every time the option is presented.

And I chose to stop playing, because the gold suit made the game feel pointless.

The developer kept telling me that trying to beat the levels was pointless, so I finally agreed with him.

Wednesday, March 04, 2015

Best Laid Plans of Mice and Mods

I'm finally wading into the guts of the new modding system. Anyone who's made space for mods understands the tradeoffs: where do you leave space for modders? What is hardcoded, what is "softcoded" so modders can interject?

But this project is a bit different. It's intended to be open source, so nothing is truly hard-coded: the players can always edit the core code. Similarly, mods are created in the Unity project and exported from that space. It's not simply open source, it's a project where every modder is going to have the source code, even if they never really interact with it.

During this experiment, I've found myself developing in a strange way as a thought experiment. I've been trying to make absolutely every part of the gameplay a mod.

Some things are largely hardcoded. The way construction is handled, the way the basic menuing works, the light of the sun, the core existence of FacilityObjects and FacilityMOBs. In theory, these could be overridden, but they lay outside the modding infrastructure. A mod would need to aggressively intervene into the core systems in order to change those things. But... that's what most mods actually do in other games. The mod experiment has changed what I would consider "acceptable".

This morning I wrote electrical systems into the game. Power is a critical component of base management, so you can consider this a core feature. The vehicles you drive up in have solar panels attached to them, and can also generate electricity through their chemcell engines using some kind of liquid fuel. They have a specific amount of energy storage. These resources will last you some time, hopefully long enough to establish your base as an energy source instead of an energy sink. This is critical because it takes energy to build some things (for example, sintering sand requires energy, welding requires energy, etc). The more vehicles you build and take with you to your next location, the better off you'll be at the start.

There are a number of things the electrical system play requires. When you mouse over a car or a solar panel or whatever, the context popup needs to tell you how much energy is available/generated there. When you look at the facility overview, you need to know how much total energy is available, how much you're producing, how much you're using with standing facilities, how much you're using for construction or one-off activities. Moreover, it needs to continually update every time you build something new, do something new, toggle the behavior of an energy producing facility object, etc.

Sounds kinda... complicated and core, right? I mean, not complex in the grand scheme of things, but wired into a lot of the core game systems.

It's a mod.

Literally. "Core Electricity mod. Requires: Core Facility View mod. Priority 99"

A flip of a toggle, and the mod turns off. Nothing costs any energy. All the things that produce or consume energy stop caring about energy. Maybe some of them will stop being added to the list of available objects, when I care to bother dividing that stuff up.

Now, in a few small ways this is a cheat. Most of the core content is "integrated" with it, in terms of having an electrical cost to build. If you turn the mod off, that electrical cost stops mattering, but it's still part of the content. Similarly, most additional content later will probably also be integrated with the electrical mod. You can't really "not install" the mod, because it would involve not installing nearly every piece of content.

But you can "disable" the mod - all the content stays, but you are no longer limited by electricity and no longer receive reports about it.

All the reporting - the context popup, the facility overview, the build limitations - is part of the mod.

And this is how I've begun to think about my game systems.

Everything is core. Nothing is core. The systems are all stitched into the framework in the same way.

"Isn't that kind of a nightmare to develop?"

Well, I programmed the heart of the electrical systems before work this morning. In half an hour.

The key is the easy combination of ScriptableObject mod definition, the two GameObjects you specify as the overview menu item and the context menu item, and the UnityEvents that hook in automatically. It gives you an extremely easy "in" for hooking into the game world and running calculations.

"Isn't it painfully limited?"

Well, it's basically an API. The mod itself is fundamentally a way to interface with the game framework. But unlike a rigid mod API, this happens inside the Unity framework. In addition to the ease of integrating with UnityEvents and the inspector, you can use Unity's debugging capabilities and interact with the rest of the systems using actual code.

I've found that it produces extremely crisp results. Game systems tend to get complex and inter-related very fast and in very convoluted ways, at least when I program them. This keeps the systems so crisp you can actually turn them off.

This probably wouldn't work for every game. But in games which are largely statistical, this seems very powerful.

I'm sure I'll encounter drawbacks soon, because otherwise everyone would develop this way already. I'll keep everyone posted.

Monday, March 02, 2015

Mod Integration

So, it's one thing to talk about easily integrating mods into your game's content. But there is a more complex question: how do you integrate mods into the player experience?

Most mods simply add some content. No biggie. It shows up in the same lists as all the other content, the player experiences it the same way as any other content.

But many mods go further.

For example, in Kerbal there are mods which change how aerodynamics work. In Skyrim there are mods that change how you manage and use your NPC followers. In RimWorld there are mods which overhaul the nature of combat entirely.

In terms of code, all of these mods work. That is, they are coded and the code executes and the game simulation runs properly. But from a player perspective, these mods are clumsy and difficult to use. Even smaller mods such as adding in a new kind of stealth attack or a new kind of thermal simulation are often difficult for a player to understand, difficult to see running.

In Skyrim, this is solved via menus. Some of them are solved via conversation menus - talk to someone and you get a five-deep branching tree of options and possible commands. Others are solved via the mod menu mod, which lets mods put their parameters in a menu for tweaking. But neither of these options tells you how things work - it's just an interface for tweaking the mod. When you're done, the mod goes back to silently doing whatever it was doing.

In Kerbal it is also usually solved by a menu as well, but the menu is displayed right on the main game screen. The problem is that the menu is always in the way, and if you have eight mods, you have eight floating windows. There have been attempts to consolidate using a toolbar mod, but that has issues of its own.

In RimWorld mods really have no say in the interface at all, as far as I can tell. So all mods run silently, not even allowing for option tweaking.

I'm taking the opposite approach.

In my game, there are several spaces the player looks to find information.

One is the contextual popup. When you mouseover a tile or person, it reads out the details of what that is, whether it is navigable, whether it's friendly, what the temperature is, how much electricity it uses, etc. If you click on them, these contextual readouts become solid and interactable - perhaps giving out tooltips, perhaps becoming a button you can click to open a more powerful menu.

The key here is that a mod may, if it wishes, add a line to this context menu. In fact, the core features mentioned - electricity, nagivation, friendliness, etc - are all handled using the same methods as the mods use. So if you want to add a mod for sorted cabinet inventories, it's considered as "core" as the concept of electricity. You can even plant advanced functionality in your widget to draw on the game world for things like radius, heat mapping, etc.

This allows a player to see what the mod is "thinking" about the various objects in the game, and also provides an on-hand way to tweak the tweakable elements of the mod.

The other place a mod might want to talk to the player is in the facility overview tab. The electricity mod shows you total kWh available, total generated, total on-demand, etc. Friendliness might show you how many people of various factions are visiting. Etc. Moreover, these can be interactive. You can tweak things by clicking on the panel or, if there are too many options, you can even have a button which pops up a full-screen menu.

I'm not overselling this: Unity's core functionality is available, and both the context widget and the overview widget are simply considered GameObjects and spawned into the scene. There are a bunch of default hooks - onMenuOpen, onMenuClosed, etc - but you can also add in UI buttons and widgets of your own choosing and code them to do anything you want.

Not all mods need this. A mod that adds a new gun or a new person doesn't need a menu item. The basic mod management screen is plenty for that kind of mod - just allow the player to turn it on and off, no need for ongoing management as you play.

But I want players to build overhaul mods. I want players to turn off my shitty core electricity mod and replace it with their custom mod that does things better. I want players to create a mod to make the NPCs behave very differently, with a variety of context commands and AI cues. I'm happy if a player adds a new gun, but I want them to feel the urge to change the game as well.

That's what I'm working on these days.

Monday, February 23, 2015

Basebuilding With People

So, I played a LOT of RimWorld recently. I think it's a great game, but let's talk about some of the places it could have gone. Some of the tantalizing bits it showed hints of, but never went into.

One of the things I really liked doing in RimWorld was disaster recovery. Like most basebuilding games, the challenges RimWorld introduces are usually "nasty things trying to kill you". This is a really boring kind of challenge because it's very binary: you tend to either win handily or get annihilated, neither of which is very fun.

But RimWorld has a few situations that are a bit unusual. If you're attacked by people, they often survive your gunfire and go into shock. You can then haul them back to your base as prisoners.

The prisoner system in RimWorld is really primitive. There's no work system or deprogramming or any of that. You can do some nasty things - sell them as slaves, harvest their organs - but it's very basic and flat.

The thing I liked doing is repairing them.

Most of the time, they would be pretty screwed up by the firefight. I enjoyed making cybernetic limbs for them, patching them up, and letting them go. There's no bonus for doing this. Your faction score doesn't increase. Even the individual prisoners don't like you any extra for it, so it doesn't help you convert. But it's relatively engaging.

Then I discovered a mod that brings a whole starship crashing down on your head. You tend to pick up half a dozen survivors, all of whom are really ripped up by the crash. Suddenly there's a very specific drive to your opening game: you want to patch up the survivors. And this drive doesn't really stop, because once you've given them peg legs you realize you can give them cybernetic legs, then bionic legs, and so on.

This is all possible because of the ridiculous Dwarf-Fortresslike body simulation. It's quite easy to empathize with someone who has suffered, and seek to ease that suffering through the medical mechanisms of the game.

Even the basic challenge of the ship crashing down around you is fundamentally interesting, because it's something you weather, not something you defeat. If you lose people or resources or whole buildings, you can be assured that you can come out of the other side anyway. It's not like the disaster will hunt you down until you defeat it, unlike goons with guns. For a basebuilding game, this kind of challenge feels fundamentally better: there's no terminal state, so you can see how your base performs and then fix it up.

However, this runs into the weakness of the basebuilding genre: faceless NPCs.

See, all the NPCs in this game have a variety of traits and stats, just like in most modern basebuilding games. There's a complex simulation of their physical state, and a marginal simulation of their mental state. They often have a marginally unique sprite due to combinations of body and hair sprites/colors. But once you hit about six people, you can't remember most of them any more. You can only actively remember a few of these NPCs, even though you can remember dozens of real people with ease. Why?

Because people aren't defined by a list of stats. They are defined in contrast to other people, including you. This forms a social terrain.

Look, it's easy to remember when an NPC is missing limbs, because their physical body is defined in contrast to the physical world. You can see them move slower (or not move). You can see them work slower, more clumsily.

An NPC's "social body" needs to be defined in contrast to the social world. And there isn't one.

Basebuilding games use a massive amount of time compression to keep you focused on building and managing your base, and this makes it very difficult to get a feel for any kind of social situation. The only way an NPC has time to show social inclinations is if you remove them from the brutal pressure to manage their day as efficiently as possible.

You can see this in Dwarf Fortress. There is a basic social structure: children, nobles, enforcers, and so on all feel like they belong to a social structure of some kind. However, this is accomplished by removing them from base management. In order to give them time to be socially distinct, you remove them from the time-compressed burden.

Well, why not drop the time compression?

Time compression is inherited from RTS games, but there's no need to keep these RTS mechanics. Let's get rid of the guys with guns and let's get rid of the time compression.

Instead, we can just use time chunking. When you decide to start the day shift, time moves forward rapidly until the end of the day shift. You have a basically unlimited amount of time in the morning and evening to plan out your base, schedule your people... and more importantly, watch them interact with each other and you.

There would need to be some kind of thing to do during the slow periods, but that's the point: we can start to really rev up our people skills.

We can structure your base personnel in a much more explicit social world. A branching tree of social leadership. A mental simulation as complex as our physical simulation. Tweaking people's mental state in the same way you'd tweak their physical equipment or cyberwear.

This is only possible if we remove the time compression. After all, socializing is what you do when you're not under crushing pressure.

Well, you can socialize while working, or at least have a presence in a social society while working. But only if you're not under time compression. Time compression means you still don't have enough time to express yourself, and even if you did, the player would not be paying attention. They're too busy planning out some other part of the base.

Hm.

Those are my thoughts. I have a lot of prototypes in mind, but I'm so busy.

Playing RimWorld.

Wednesday, February 18, 2015

Investigative & Expansive Exploration

There's a game design concept I haven't seen used much. It's a way of designing exploration/open-world games. It requires algorithmic content, but that's pretty common these days, so I think we'll see this concept become more and more common as well.

Let's discuss a game like Spore or No Man's Sky. The game is theoretically about exploring space and discovering wondrous things.

The problem with these games is that there really aren't very many wondrous things to find. It's mostly just an endless array of the same things with slightly different aesthetics.

But it can be made much more interesting using the "Investigate & Expand" design.

In this mode, when the player stumbles across something they find interesting, they have the option to explore it in more detail - investigate it.

For example, if you find a space village, you can go to their cities or talk to their people. This is a different scale of exploration, allowing the player to choose to get closer to something they might find interesting. Or not, if they don't find it interesting.

Some games certainly do this. They generally stop there. But you need a follow-up. You need a reason why investigating matters.

That's the second half: Investigate, then Expand.

Once you've investigated something, it integrates into local space and you can help it expand. For example, the space village will contact you whenever you visit a star near their space and give you an optional mission - "can you find a plant we can eat?" "We have an abandoned base there, can you set up a beacon on it?" "One of our ships is damaged near there, can you find it and rescue the crew?"

Completing optional missions expands the space village - a larger home base, a new colony in that star system, etc. Which, in turn, means more missions over a wider swath of space.

This is a one-two punch: investigate something interesting, then help it expand if you want.

The expansion phase is extremely powerful, because it gives you a new context for any barren hunk of rock you stumble across. People and things you've chosen to help have a vested interest, so you have a vested interest. Whether it's something simple like tagging resources or something more complex such as finding a crashed ship, your exploration now has a context. You are here to help - or to choose not to help.

Exploration is also powerful because you can have multiple missions from multiple people as expansions continue. "We have a crashed ship in the area", one says. The other says "we're in the area, could you carry us some supplies?" Depending on your engine, you could even make the missions intertwine - you can only complete one, or both are from the same cause, of whatever.

It's easy to start imagining advanced algorithms, but this can be done with very simple algorithms. The algorithms for the missions can be simple, that is: the algorithms for the space villages are significantly less simple.

Every space village would need to be unique enough that players would have an opinion on them, specifically. Moreover, every space village would need a presence with particular needs and practices, so that as missions are accomplished they could organically expand. Moreorover, you would need to allow for investigating again, after a time, and discovering those new growths and changes.

I don't think these are overwhelming technical issues, but let's talk about a short cut: an open-world fantasy game. Skyrimlike.

The various party members you accrue can be "investigated" by talking to them. More advanced investigation might involve unique level-up patterns and algorithmic reactions to situations in the world, but let's leave that for now.

The expansion phase is also relatively straightforward. Instead of gaining XP by killing monsters, characters gain XP if you complete sidequests for them. The things each character cares about and the kinds of missions they request are preprogrammed, but these are not scripted missions. Rather, they are a simple framework: you enter a city, the urban thief gives you a mission to steal from a specific too-rich noble. You enter some woods, the elf gives you a mission to find as many glowing lichens as you can. Enter a different city? A different noble. Enter the first city again? A different noble. Different forests? Different plants.

The reward for each? XP.

These missions could be made more interesting because the characters are actually with you. As you get close to the noble, or wander near some lichen, the character that gave you the mission can pipe up with advice or commentary. Perhaps they gain a stat bonus while you are "on" their mission. It can all be quite generic: no advanced dialog engine is required.

You can then directly tie their level to how much they trust you, such that their next dialog option becomes available with each level.

This system requires no generative world content. Helping the thief doesn't rearrange the politics of the city. Helping the elf doesn't establish a new elf stronghold. It's very simple, very shallow, very easy.

It's the same thing. Investigate and expand.

I think it's a good design concept, especially if you have a lot of chaotic content. For example, if you allow players to create/share NPCs for your fantasy open-world game, you can rate each NPC by how high a level the players usually help them reach. The higher the hit rate, the more appealing/interesting the character is likely to be: probably a good choice to put in a new player's world. Less popular/new NPCs can be put in the worlds of more experienced players.

The same is true of alien civilizations. Same thing.

Well, those are my thoughts on the matter.

Friday, February 13, 2015

Boring and Unfocused as Good

I wanted to talk about how boring, unfocused games are good.

... Okay, this might be a bit hard to talk about clearly, and I might be overstating things. Let's try it.

What I really want to talk about is the fact that there are at least two different goals for gameplay.

One goal is that the gameplay should be "good". Intense, interesting, fun - whatever your measure is, the gameplay should sparkle. This involves careful pacing and balance in addition to structuring the surrounding game around the gameplay. Driver: San Francisco, for example, is all about driving. The entire game (setting, fiction, and all) is engineered to make the gameplay flow exactly as designed.

But not all gameplay serves that goal.

Some gameplay is designed to be boring.

If you ask the devs, they'll say they designed the gameplay to be "good", but that's not really the case in these situations. And that's fine. Boring gameplay can be good. In fact, if you make the gameplay good, it'll screw your players over and make the game fall apart.

What am I talking about?

Open-world games!

In an open-world game, the play isn't intended to be good. It's intended to be "weight".



As an example, consider Skyrim.

Skyrim's gameplay is not very good. There's a lot of it - exploring the wilderness, dungeoneering, fighting, helping out in cities, crafting, enchanting, picking locks, sneaking, marrying - and that's before we even get into mods. But each individual play element is really bland.

Skyrim's far from the only only example. Almost every open-world game is like this: Assassin's Creed, Far Cry, GTA - they all have very bland gameplay. In some cases it's quite polished - Far Cry generally feels quite good - but the play itself is a mess. Badly paced, unbalanced, a very polished train wreck.

And that's good.

See, in those games, the play exists to give the player's experience weight. Rather than "progressing", the player is "living".

Probably the most obvious example is The Sims. It has pathetic play, of course. But the weight of time crushes down on the player and all the player's avatars. Shipping an avatar off to work actually adds to their characterization, since they have a complex state caused by their needs and the lack of time. When you throw a party, it's easy to "understand" "how" the characters "feel" as they muddle through the party in a soup of random nonsense, needs-directed annoyances, and player directives.

If you play The Sims for a reasonable length of time, you will come to empathize fairly strongly with the characters. The more you cheat, the less empathy you'll likely feel, because the crushing weight of time and money are what give shape to the characters' lives. As the character's situation evolves, you feel their lives evolve because the pressure of time and money change how they push at you. Your opportunities and activities expand steadily, and it seems you can feel the characters struggling to live.

The same is true in Skyrim, Far Cry, Assassin's Creed, GTA, etc. You choose exactly which of the many kinds of gameplay to do exactly when. The focus is not on progressing through the game, it's on living in those worlds. Experiencing those worlds.

The pressures in these games are not as overwhelming as in The Sims, probably because the failure conditions are much harsher and more omnipresent. But the idea is the same.

When you choose to wander the wilderness, you are filling in the life of your hero. When you choose to hang-glide into an enemy stronghold, you are not trying to "progress". You are filling in the life of your hero. Filling it in with outlandish crap, sure, but it's still a life.

This is in contrast with the life provided by the story. Many open-world games assign you a hero and give them a story, but most people don't play as that hero, not in any explicit sense. The players are filling in a life, but it's not really the same life that the cutscenes try to fill in.



Now: why boring gameplay?

Well, part of it is simply that the player has to be able to jump into any kind of gameplay at any point, no matter what state the hero or the story is in. Being player-guided means balancing, pacing, and chaining play are almost impossible. Moreover, being player-guided makes it hard to impose anything on the player.

You can't create a skill gate to teach the player a skill, because the player can bypass it. You can't insist they like or dislike a specific character, or pick up a specific item.

I mean, you can. That's what the main quest line is for. But the main quest line is generally the weakest part of an open world game and everyone knows it. Tutorials feel canned and oppressive, because the gameplay is already so tired. It works fine if it's contributing to the life of the player, but the uncompelling nature really works against you as you try to teach the player how to do things.

So the play has to be pretty self-explanatory. You can't try anything too new, because a lot of players will skip your deadly boring tutorials. Even context help is more annoying than helpful, and it's a pale imitation of a tutorial.

In short, the play has to be boring. Because if it's involved, the game stops being about the life of the player and starts being the focus of the game.



With this in mind, it's possible to analyze the gameplay in some open-world games and figure out whether they can be refined further.

There are two aspects I'd like to focus on: the weight the gameplay adds to the player's current life experiences, and the way that changes to the player's life change the weight it adds.

In order for these experiences to add to the weight of the player's current life, it has to integrate into the player's life.

One way to do this is to have a wide-open approach. If the player finds a stronghold in Far Cry, they can choose exactly how to engage depending on their power, their preference, their current task, their whims - whatever. You create a place for the stronghold in the flow of your life, whether that is "the stronghold looks to dangerous, I'll just creep by" or "LEMME GO GET AN ELEPHANT!"

The other way to integrate is to have an immersive approach. When the player chooses to go diving for treasure, there's not a lot of options about how to go about approaching it. But once you start diving, that is the whole of your experience: it's a different world down there, and everything is weighted and paced differently. It's still up to the player as to how long they keep at it and so on, but you can think of a diving segment as its own chapter, rather than integrating fluidly.

Integrating into the player's life experiences is critical, but an overlooked element is that life is about change. These games are not just about your avatar's life as they are, but about their life as they will be and were.

Skyrim does a decent job of this. As you progress through the game your stats improve, sure, but that's largely cosmetic. The important aspect of leveling is that your options grow and change. You don't simply get a stronger attack spell: you get a spell that turns you invisible, or raises the dead, or causes enemies to fight amongst themselves.

Far Cry does a mediocre job of this, because the 'open world' upgrades are linear. All the paradigm-shift upgrades such as binoculars, helicopters, ally strikes, and so on are integrated into the story rather than your character. They appear and disappear at unnatural, stilted times. They're not part of the player's life, they're part of the hero's life, and they don't feel very smoothly integrated into the flow of life.

Still, Far Cry does better than Assassin's Creed or GTA, both of which are almost entirely about the linear upgrades. Most of the significant upgrades they see are new kinds of play rather than new ways to engage the existing play. You learn to fly a jet, but that is a completely new kind of play that doesn't really change how you do the things you have been doing. There's no sense of closure or change to your existing life, just some new facet that has no weight attached to it.



With these intentions in mind, we can propose that an open-world game have

A) Wide-open engagements - things that come up in the course of play that can be engaged in any way the player can imagine and integrated into their life story without a bump. Disengaging or changing approaches should be relatively straightforward as well, to the point where it can be part of "the plan".

B) Closed engagements - things the player can choose to engage or disengage freely, but while engaged they close out the rest of the world. They become the world.

C) Progression which allows us to approach the challenges in the above engagements in new ways, with new options. Progression should ideally be under player control, rather than integrated into a mandatory storyline.

But there are a few additional points to add:

D) Free-roaming. This is obviously an open-world game.

E) Continuity - the player should never feel like their experience is being negated by stampeding designers. All challenges, engagements, and plot points should feel like they could happen in the world when they do happen in the world, keeping in mind the many ways the player might be experiencing the world.

F) Modding - the player should be able to make specific kinds of play much more difficult or prevalent, whether through downloaded mods or through self-imposed challenges. For example, beating Far Cry with only the bow, or installing a mod which makes all the guards in Skyrim attack you on sight.

G) Lures - the player should encounter something similar to sidequests in an algorithmic way. For example, random city citizens might need specific things. Lures should weight other things in the game world, making them stand out. Knowing someone needs a photograph of a monkey will make you look for photographs of monkeys, and in turn give the world some presence. Be careful not to assign too many lures at once, though: 3-5 max.

...

That's my thoughts on boring gameplay. They're kinda half-formed, sorry.

Friday, February 06, 2015

Creating Stories

After a little conversation on Twitter, I wanted to talk about creating stories in games. Specifically, these are techniques I've used and tested personally, not just theory.

When I think about stories in games, I generally divide it up into three types: the railroad, the setup, and improv.

When a GM in a tabletop game forced us to follow their story precisely, we called it "railroading". Most games are like this - a set of rails. Even games where you choose A or B, it's just a switch on the rails. The advantage of rails is that you can craft them really carefully. You can create a story that makes sense, is themed reliably, and is paced reasonably well.

I don't really like that method too much, though, because I'm more interested in watching players invent interesting things.

So most of my tabletop games use a "setup".

A setup is when you create a bunch of situations, characters, and setpieces which work in specific ways, but you let the players figure out how they want to proceed and what they want to do.

If it's a tabletop game, the GM can easily pull in these pieces whenever it seems like a good idea, so even a clumsy or pressured GM can generally come up with something interesting. Since all the pieces are created during downtime, they can be carefully themed and each can have a different kind of thing they want to contribute.

You can do this through world design. In my Amber games, I would design packs of places and characters on flash cards. These would give me concrete things to show the players (he looks like THIS and you are HERE), but it also gave me concrete things to hold onto as a GM. The themes and characteristics were written on the backs of the cards, so I could keep everything straight and plan for a cast which would stress the themes of the setting even as the players were free to adventure on their own.

You can do this through "breadcrumbs". In a kung-fu card game I made, I gave each player three fragments of knowledge - things like "you saw a man with red hair in May". If you fought with someone and won, you could see one of their fragments and, if you put them together, the story unfolded. Although the story itself was prewritten, the way the players engaged with it was completely up to them.

The nature of the game also allowed for a lot of improv, as players naturally attached meaning to their fights. In the end, the players actually banded together to protect the bosses in order to prolong the game long enough to figure out the details of the story.

Even though the backstory was prewritten and the bosses were instructed to behave in specific ways, the players still created their own story.

You can do story setup through "rule weighting". In my Star Wars tabletops, I made light side and dark side considerably more complex than just a point system. There were a number of emotional scales - for example, "humility vs arrogance". If you used an emotion on one side of the scale, you got a boost based on how far along the scale you were, and you had a chance to move further along the scale. Since it required role play of that emotion, this quickly got the players used to role playing emotions. The themes native to Star Wars came through quite clearly as the players moved through the rule set, without any need for me to design a detailed plot at all.

Of course, you should also allow improv, which is when the players (and GM, if one exists) are free to inject their own stories into the world.

The problem with improv is that it's under a lot of time pressure, and the participants are very close to the situation so it's hard to see very far. In general, improv veers off-course too easily, and that can definitely sabotage the game.

The key to enjoyable improv is to keep directing it back into the themes of the setting.

For example, in the Star Wars tabletops I ran, the emotional rules naturally created opportunities to improv. You could improv off of something you did while feeling an emotion, or move from an emotional improv back into the rules of the game really easily. Because the rules created so many opportunities, the improv stayed inspired by the rules, and therefore stayed close to the themes of the game.

Similarly, I had a tabletop board game about psychics, but the players' psychic powers could only be charged by specific kinds of interplayer interaction. For example, doing someone a favor, or getting complimented, or making someone laugh. These are thematic rules which naturally create opportunities for improv while also keeping improv near to the themes of the game.

Another option is to make things a bit more concrete. If you play the card game Fairy Tale, you have a hand full of pieces of fairy tales. A genie in a lamp. A poisoned apple. Imprisoned in a tall tower. The game is improv - everyone tells a piece of the story, with the intent to hit one of their topics and play the card.

In a short game like that, it's enjoyable chaos. But it works fine in longer games as well, if you have more concrete threads. For example, in Nobilis, the players are gods of a given theme and each has their own mystical home. A GM that thinks ahead can make sure the pieces fit together. That is, if any given god starts to use their power, it naturally causes opportunities for the other gods to use their powers or their homes. This kind of resonance makes Nobilis worth playing, especially if you can interpret the domains as being thematically linked.

For example, if you have a god of hunger and a god of beauty, in any situation where one arises, the other can often find a place. Multiply this with three other players, and give each of those players a secondary power in the form of a realm, and now you have a game where the players can play off each other in a very natural, organic way while automatically maintaining the themes of the game.

It's also worth considering that there are multiple kinds of improv, and it's a mistake to have all the players operating on the same "level".

For example, in my kung-fu card game, there were players that really just enjoyed making beautiful kung-fu cards. There's nothing wrong with that at all. It's another kind of improv, and they really fired up the rest of the players. As you might notice, their improv was something that another player could easily grasp and work with.

And that's the key to multiplayer improv: shape it so that the players naturally improv fuel for the other players, all while staying close to the themes of the game.

Anyway, this was fun to revisit. I've written a lot about this stuff in the past, but it was waaaay in the past. I got embarrassed reading my old stuff, so I wrote this. ... very quickly. Sorry about the pacing.