RPG Characters: The Obsidian Method

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.

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.

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.

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.