I played some of Obsidian's new game: Pillars of Eternity. Obviously, I haven't finished it. I only spent about 40 hours on it.
It's good, but I'd like to talk about design a bit. I am vaguely creating an RPG engine, so it's good to think about these things, have tools ready to help people do them.
So let's talk about the Obsidian NPC method, AKA the Bioware NPC method. I first ran into it in KotOR, so it's Obsidian's method to me. It was also used in Dragon Age, Mass Effect, and of course, Pillars of Eternity.
This is a very polished formula, and if you follow it, you'll produce good results. That said, it's not applicable everywhere and has its flaws. Well, let's learn it!
Step 1: Pick stereotypes
Your characters are based on stereotypes. You want to pick a variety, because every player will have different preferences and therefore feel happy with certain stereotypes and annoyed by others.
For example, in Mass Effect, Liara is the sexy nerd stereotype, Ashley is the no-nonsense career woman stereotype, Kaiden is the earnest man, Garrus is the brash man, Tali is young Romani, Wrex is the jaded warrior.
The stereotypes can be quite niche ("young Romani" is a pretty rare one, as is "fast-talking uber-nerd"), but they're still stereotypes.
Step 2: Pick facets
Each character has two things that they explain about the universe. Normally, one of these things is their species or culture, and the other is how their job is related to how the universe works. These should hopefully gel well with their stereotypes.
For example, Liara embodies her species (sexy) and the search for the precursors (nerd). Garrus embodies his species (manly) and the lawlessness of the Spectres (brash). Wrex embodies his species (jaded warrior) and explains the non-earth, non-citadel militaries (jaded warror). Ashley embodies earth military but also the racism endemic to the earth military. Etc.
The characters serve as windows, introducing the player to their concepts and, in turn, the concepts that make the universe tick. As the game progresses, they will continue to weigh in on these topics and offer side quests related to them.
It can be difficult to balance these facets. Liara represents her species, and her species is a constant background hum to the game, popping up frequently. So that's a good facet. But her other facet - investigating the precursors - is not a good choice. The precursors aren't ambient noise and don't pop up a lot in the course of play. Instead, they are critical plot points. That means she has to do a lot of exposition and cannot really express herself as a character.
Tali is a really good combination. Her species aren't as common as Liara's, but she has a lot to say about them and it strongly affects her design, so they are present through her. It also supports her being able to comment on the opulence of your civilization. Her second facet of Geth obsession seems like it'd run its course and stop, but it segues nicely into her having things to say about the Reapers as a whole. It also supports her having things to say about technologies in general. She is rarely required to be exposition, because the things she has to say are rarely required to understand the situation. So she is free to comment from her personal standpoint, which makes her seem alive.
Looking at KotOR characters, you can see the same kinds of designs. The Force-sensitive characters have things to say about the nature of the Force instead of their species, and it works pretty well.
Step 3: Audiovisual Design
Each character needs to have a distinct audiovisual design which makes their character unique and appealing while reinforcing their stereotype. If they are another species, then their species design needs to also support their stereotype.
Visual design is important, of course. Color and costume shouldn't be overlooked, either. Audio is often overlooked, but it shouldn't be: Garrus and Tali were popular largely because of their modulated voices and memorable voice acting.
The problem with the first Mass Effect game was that 99% of the unique design came from the species rather than the characters. This really showed in the human characters, which were so blandly designed that nobody could remember them.
In the later games, the human characters were designed to be a bit more memorable - largely through costume choices. It's tough. You get a stark breadth of possibility when you're using different species. Trying to distinguish within a species is always going to be more difficult.
Step 4: Integration into Game World
In order for the NPC to be memorable, they have to make an impact on the player's mind. The best time to do this is during their intro segment - they will typically join up during a particular mission and you will be more or less forced to use them until the mission is complete. During this time, they need to shine.
After that time, it can be difficult to guarantee that they will be in the player's party. If they are in the player's party, they are going to be able to comment on things - even just simple shouting during combat can make a big impression. But if they aren't in the player's party, they might tend to fade out of the player's mind pretty quick.
Performing "impact in absentia" is therefore very important. The way to do this is to have the facets the character represents keep coming up. The player will remember that the representative character exists, and perhaps switch them in so they can get their ambient opinion on things. You can also have them call in with comments, or even be hanging out in the game world when they aren't in your party.
You can also force or strongly insist the player take specific characters - for example, if you go to Wrex's homeworld, taking Wrex just makes sense.
Ongoing updates/unfolding backstory are also a good way to do this. Chatting in the safe zone, getting quests, unlocking new costumes or powers, pursuing a relationship, etc. Just keep in mind that if a character isn't in the party, the player probably doesn't like them very much, so you have to write with that possibility in mind.
Note: Things Not Included
A lot of typical character design concerns are simply not important in this scaffold.
First off, you don't have to worry about character arcs.
The player is probably going to want to earn the NPC's trust and allegiance. This is normally done through some dialog options and side quests, and while you can make that a character arc, it's not necessary. The character's important change is in how they interact with the player, not what their fundamental personality is. If you do decide to make it a character arc, be careful not to alienate the player with the "before" half of the arc, as with "Ashley the Space Racist".
Second, you don't have to worry about softening or hardening their stereotype.
They are integrated into the world through their facets, so they should feel like they exist already. Their personality should feel like it naturally arises from their situation, so you don't need to go out of your way to alter their personality. The stereotype will soften naturally because of the nature of the structure.
Conversely, don't try to play up their stereotype. Liara and Tali are borderline offensive stereotypes, and if either one had been played up even an inch, it would have been obnoxious. Because their personalities seemed to flow from their situation and didn't feel forced, they were largely accepted.
If a character seems iffy when you don't try to adjust them, their core stereotype is probably bad. Don't use it at all. Don't try to "soften" an offensive or ill-fitting stereotype. Just don't use it.
The Numbers Game
As you might guess, not all characters appeal to everyone. Because of this, there is one last piece of the puzzle: having the right number of characters.
The Obsidian/Bioware approach is to have 5-7 NPCs, but only have a party of three people total. That is, two NPCs. You need to choose two out of the seven.
This percentage is good: there are going to be two stereotypes you can generally get along with. But there are also going to be at least that many that the player can't stand, because they hit sore spots. And then the rest will probably strike them as too bland to bother with.
You need to carefully balance your combat/skills to allow for flexibility. If the player ever feels forced to take a specific NPC due to a skill or combat role requirement, they're going to be annoyed. Being forced to take an NPC because the NPC is actually involved in the situation is a lot less obnoxious.
Fundamentally, playing the numbers game is actually a numbers game: you need to be sure that every given player will feel comfortable and happy with at least two of the characters, and not so offended by any of them that they stop playing immediately.
This shouldn't be considered "weakening your vision". Considering your characters from a variety of diverse viewpoints is pretty reasonable, and the result should feel like your universe is full of people with a lot of different viewpoints.
IE, realistic.
Final Thoughts
This NPC method is not always the best. There are a lot of times this fails. In fact, I think it fails in the new Obsidian game. But it's worth understanding and it's a pretty good formula if you don't know where to start.
Monday, March 30, 2015
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.
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.
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.
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.
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.
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.
... 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.
Subscribe to:
Posts (Atom)