Player-Generated NPCs

Hey, let's talk about player-generated NPCs, and sending them to other players.

In order to turn player-generated content into content for another player, you need to add context and a reason to play. This isn't too hard in mechanically-oriented games, but in an RPG it's tough.

Imagine playing Fallout 4 and running across random player settlements. Most players make facilities that are focused on making the numbers go up. Recontextualizing that into an RPG point of interest doesn't work out well: you end up with a dozen nameless NPCs and a bunch of empty buildings with beds in them. Hardly compelling RPG content.

The problem is obviously in the recontextualization. The settlement was created to make numbers go up, and now you're trying to interpret it as an RPG town? There's no connection.

The answer might be to make the original context an RPG context, so the player's created settlement is RPG content right from the start.


Pushing Context In

Let's pretend we're designing a Mass Effect game: players create colonies, which are then exported and encountered by other players.

As you play through the game, you make various choices. You visit the turian homeworld. You choose whether to side with the turians or with the humans.

If you side with the turians, you receive a number of applications from turians, willing to move into any colony you make. If you side with the humans, you get human applicants.

When you build your colony, you can add any applicants you like.

When your colony is exported so other players can visit it, the game checks to see what they did on the turian homeworld. If they did the same thing, those settlers are friendly. If they did the opposite thing, those settlers are more hostile. If they haven't been there yet or didn't take sides, those settlers are just background color.

This is an extremely fast and easy way to push RPG context into your colonies, and then continue to push that context forward into other players experiencing your colonies.


Pulling Context In

In addition to this, we can use simple keywords to keep these applicants interested in similar conflicts. Those turian applicants came because you chose turians over human interests. That means they will continue to have opinions on decisions regarding turian vs human competition, or more generally turian vs any other species.

If you visit the Citadel and side with a turian shopkeep over a human shopkeep, the turians back at your colony will compliment you for it, gain loyalty, become more effective citizens. If you choose the human shopkeep, the turians in your colony will be a little annoyed and rib you about it, although there probably shouldn't be any statistical punishment for such a minor event.

If you visit the citadel first and choose the human shopkeeper over the turian, you'll probably get a human applicant. Then you visit the turian homeworld, make your choice there, and your human responds appropriately.

Since it's keyword-based, events can be done in any order, and mods can be integrated smoothly.

In this way, your colonies will have a vested interest in your continued adventures, and you'll be taking your citizens' opinions into account as you journey.


Generating More Context Globally

Tying your colonies into the galaxy is important: if your colonies feel entirely isolated, that's not very immersive. So your colonists need to do more than have generic responses to keywords.

They should put their thumb on the scale.

If you visit the turian homeworld, get some turian applicants, and then get into that turian-vs-human shopkeeper conflict, your colonists should call you up to chime in.

Here's the key, though: it should be the wrong colonists.

If the colonists that actually care about turian/human competition call up, they'll try to convince you to choose the turian side again. This creates a feedback loop where you have more and more pressure on you to choose the turian side of things. With no counterweight, that's not a good idea.

Instead, you should hear from different colonists with no stake in the turian/human competition, and they should put their thumb down on the other side.

For example, since you chose turian last time, a quarian might call you up and say the turian sold them a lemon last time they visited. The idea is to push the choice back into balance.

Basically, if NPC A has a vested interest in turian/human conflict, that causes a situation where NPC B reweights the conflict to make it hard for the player to choose a side.

There will be some conflicts where the player has a particular favorite. If they really like turians, then you might need to apply quite a lot of pressure to make the choice difficult. In situations where the player doesn't seem to have much interest and are easily swayed by the third party pressure, it makes sense to create additional conflict by having your colonists come in on both sides and have a bit of an argument about it. Raises the stakes.


Generating More Context Locally

You'll need to generate a lot of RPG-context content in the colonies you build. Otherwise, the player will get stuck in a statistical, base-building mood.

RPG rewards, RPG missions, RPG context deepening, and RPG/statistical linkups are the tools we'll use.

In short, we can generate random missions when you talk to NPCs. But these missions are not the generic fetch quest blobs you're used to: we can generate much more interesting missions because we understand how these NPCs got here and what they care about.

If you talk to the turian that applied because of how you helped his people, he'll generate a mission about turian/human competition. Perhaps it's entirely local: him competing with a human colonist, or perhaps him falling in love with one. It might be partially local: for example, buying a human grabloxotl to improve potato growth speed. It might be entirely nonlocal: a lost ship he wants you to rescue.

The sides of this conflict can be weighted understanding the player's recent turian/human choices. If you've chosen humans recently, this mission is a chance to prove that the colonist wasn't wrong to trust you. If you choose turian a lot, then this is a chance to do some dirty work for the turians... or perhaps a chance to improve turian/human relations instead of keeping them pitched against each other.

The mission generation does not need to be terribly difficult - pretty basic missions will do. Instead, the key is that they generate RPG context.

One kind of context would be to reshape the local context. If it's a turian/human local competition, helping the turian makes them the boss. Helping the human does the opposite. This will create RPG context in that there's now a new social context.

Another would be to link RPG context to statistical performance. If you help the turian, his stats go up. They don't gain levels otherwise, so this is important.

Another would be to give the player versatile RPG context rewards. For example, new applicants, new colonist gear, new permits to plant potatoes on a new world...

These generated quests intend to be a change of pace from the rest of the game, letting you 'come home' to do some unwinding. So they should generally be fun and silly, rather than grinding. The difficulty or time taken is not the point: choosing a side is the point. The "body" of the mission is just there to make sure you understand what's going on and what the stakes are.


Showing More Context Locally

The most difficult and delicate part of making the colony RPG-ish is getting the player to feel like their settlement is an RPG hub.

The player will only intermittently visit the colonies, will be focused on their statistical nature, and will probably forget the details between visits. So creating local context requires A) unmistakable, easy-to-read elements, B) remote-friendly elements so their video messages create context, and C) creating context via direct interactions when the player is around. Optional, D), linking colonies together to create "global but player-local" context.

A) Easy to read elements probably involve three things: colony decorations, colonist clothes/gear, and non-player-centric interactions.

These can all be used to create NPC-specific context, colony context, and plot/conflict context. For example, if there are bales of corn everywhere, you know what the colony's doing. If someone's wearing an elegant evening gown, you know they are a socialite and that the colony has a swanky side. If a boss is reading the riot act to a subordinate, you feel one way about it, while if they're gently guiding their subordinate, you feel another way.

These decorations can be generated randomly, or they can be supplied by the player. For example, if you back the human shopkeeper, rather than get a human applicant, you get an evening gown you can give to any colonist. This isn't simply cosmetic: giving a colonist an evening gown retroactively forces the colony to have a swanky side.

Symbolism is also a factor. Different colors and building designs give different feels, and having a bunch of turian flags waving tells you right away that this a turian-focused colony. These can quickly give you an overall impression of the colony.

B) Remote-friendly elements would be elements that show up in messages. This would be character elements that show up on headshots, background elements that show behind headshots, and topics of conversation. These should be focused on reminding the player about the nature of the colony, rather than telling them about the nature of the NPC.

C) Direct interactions are things the NPCs do to each other or to the colony. Too many games slot the inhabitants into either "work" or "sleep" and that's it. It makes more sense to use animations to tell you who these people are and their relation to the colony. So rather than digging in the plant bed, it makes more sense to show them teaching someone how to dig in the plant bed, or bragging about their plant bed, or anything that gives you a stronger impression of their social role within the base. This can randomized, or, again, it can be inherited from missions in the game world.

Recontextualizing for Another Player

When it comes time to export your colony for other players (or import their colonies), it's important to keep it as interesting as possible.

Recalibrating Opinions

Probably the most fundamental element is to simply recalibrate how the NPCs treat the player by looking at how this player has handled the same choice axis. If this player chose the humans, then the turians will dislike him. This can be scaled pretty easily: by looking how severely the player has preferred the humans so far, the turians can be calibrated anywhere between mildly standoffish to instantly murderous. Most of the time, it'll fall between the two - for example, they might interfere with your missions, or lock your ship down, or try to assassinate you in the middle of the night.

Obviously, these frequently become mission content.

Final Missions

Unlike the creator, the new player is unlikely to revisit this colony. So we can go all out generating missions for this colony: it's fine to blow things up and kill colonists. In fact, it's preferable.

These missions have the same basic role as the missions we generate for the creator, but the volume is turned way, way up. If the creator chooses humans, the turian might grump at them, or maybe even leave. But if the new player chose humans, the turians will start a mission to get vengeance. This will embroil the whole colony, and may involve impounding the player ship, launching assaults, blowing up facilities...

However, in the end, it's still about the player choosing. So even in this kind of mission, the player will be expected to choose between turians and humans again. This time, it'll be something like whether to save a turian child or let it die as you escape.

Aside from the mission, the colonies should generally offer amenities - shops, etc. The player may never visit again, but they should at least be able to do normal things while they're here, assuming the colony isn't specifically built to prevent it.

Of course, if a colony is too similar to the player's choices, you can always generate an invading monster or a weird disease or something. This will give the locals a chance to show off their social nature.


Leads from Elsewhere

Another key to integrating this player-generated content into the universe is to mix it into the universe. Partly, this just involves getting leads from somewhere else.

If the colony is heavily turian, then a player will get a lead from a turian: "my family lives here, you should go visit them!" Or perhaps, if they are anti-turian, a human: "this is a turian stronghold..."

More than that, additional content can be easily mixed into friendly colonies. Recurring NPCs, threads of ongoing missions, or minor loyalty events for your companions can be interwoven into the colony. Characters that are oriented around a conflict this player doesn't care about can be easily removed and replaced with known quantities from this player's game. IE, if this player seems to not have an opinion on turian vs human, those turians might be replaced with an asari psi-broker telling you where to get the next link in the psi investigation chain.

This can be punched up as necessary by making you have to rescue them from whatever's going wrong.

Generating these missions can be as complicated as your algorithms allow, as you can see. But even if it ends up fairly simple, it should hold up.


Recontextualize-Friendly Construction

Another trick we want to use is to leverage the simulationist nature of these colonies. Because we're simulating so much, there's no need to always just offer mission-mission-mission-shop.

Like in Skyrim, sometimes you'd visit a town just to steal things. It's really fun to try and figure out how to get away with your theft.

This is similar, except we have a wider variety of simulated objectives. For example, you can change who's in charge by helping them, giving them better gear, etc - or by harassing their opposition. You can change the culture by arguing about things - for example, if you argue that the turian culture is inherently corrupt, you can sway things towards the human side of the turian vs human conflict. You can hack computers, steal vehicles, reroute credits, teach children, rearrange their defenses, get them better deals on their exports, get them better gear for their processing...

These things are all already being "weakly" simulated. We had to, in order to create both the statistical and RPG contexts in the original creator's world, and to link those two contexts together. Therefore, we can expose some of that simulation and let the player do something besides chat.

We're not talking about deep simulations. I mean, in Skyrim you steal stuff, but the shopkeeper doesn't actually get any poorer. This is the same sort of thing: we expose enough of the system to let the player interact with it, but we don't have all the pieces deeply connected, and we don't need to.


Final Thoughts

That was long.

And some of it might be a bit of a stretch.

Fundamentally, I think we can give player-created colonies a lot of RPG context by tying the people, facilities, gear, and options to your RPG adventures.

And then I think we can wire that back into the world, to make your colony part of the RPG adventure.

And then I think we can export your colony to other players, and make it part of their RPG adventure.

What's your opinion?

Modular Space Planes

So, in The Galactic Line, you build space ships out of modules. Therefore, I model and texture the modules, animate them as needed, and so on. It's reasonably decent.

It inevitably results in an "industrial" look. The modules get slapped together in whatever way seems best. Even though you're not locked to a grid like in many voxel space ship games, you're still working with parts that have a fixed size and shape, and their seams will always look heavy and industrial.

Moreover, repeated parts will always be the same size, so you tend to end up with straight lines and boxy profiles. This is especially noticeable with habitable areas, since you rely on door-to-door connections, and that typically means all your habitable areas have the same connection profile - leading to straight lines and flat profiles.

Most space ships that are properly designed have flowing lines, tapered elements. They feel almost organic.

That's a high bar for modular spacecraft. Flowing lines and tapers are tough to do in modules, because baking them into the modules means the modules can only be assembled in one order, and with no missing parts. No reason to make it modular, then!

I've been struggling with this as I try to make a spaceplane set, so let's talk about a few methods to make modular ships have flowing lines.

1) Algorithmic tapering

It is possible to adjust the meshes of the modules to taper according to some algorithm. You can easily make a fuselage of modules into an organic tapered shape. This has some problems, though.

First, it can't mask the seams of the modules. This means most of the modules have to have identical connectors, which radically limits the overall look. It's always going to be a tapered fuselage, just with different surface greebles representing the different parts. More complex seams are possible, but the tapering won't mask them, so you'll need to be aware of that.

Second, if the modules have interiors, it's going to screw up the tapering. A room that shrinks or grows might become inaccessible or out of proportion. If the rooms are size-locked, now you have a problem where the windows need to stay attached to the outer hull, so now there are specific sub-elements of the mesh that must be scaled at different rates to get the final taper. Interior halls twist and grow, room ceilings rise while the rest of the room remains the same size... it's a mess.

Without R&D, tapering could only be applied to non-habitable elements such as engines, tanks, machinery, etc. I don't know if that's worth the effort.

2) Masking elements

Slipping coats on the outside or shims on the inside is perfectly possible. For example, if you want your straight fuselage to take on a triangular shape, slip on a triangular bit of armor around it. Any shape can be mimicked like this, and the flow of the ship profile can be built primarily out of these masking elements instead of their contents.

One problem is precisely that: the flow of the ship is mostly determined by specific masking elements, and is therefore pretty restricted.

Another problem is that the masking elements inherently conflict with the surfaces they mask. If you're turning a straight fuselage into a triangle, then the windows on the fuselage are now, at best, recessed several meters into a concave pit. This is substantially worse if your fuselage modules have significant surface elements, such as bay windows, solar panels, machinery, or inflatable areas. Masking elements constrain what you can put on your core modules and where, meaning that they may look 'unfinished' when not masked.

It is possible to do the opposite. If you have a split body rather than a fuselage, you can slowly move the elements apart or together and fill in the interior gaps. This is a fairly robust approach, but it means you'll have twice as many parts, twice as many halls. From a simplicity standpoint, it makes the most sense to "shim" with a hallway rather than a hull part, making the core hallway widen or narrow or have gathering points to change the flow of the profile. This can work, but care needs to be taken on how the attached rooms actually attach. Otherwise it will still end up looking very linear and dull.

3) Adaptive sizing

It's possible to set up the individual elements with blend shapes or bone animations to slightly change their shape. This is fairly adaptable, since it is per-part, but it does require that the linking areas remain interconnectable. So you can't go too off-the-wall.

This can be used to taper elements, but they would all have to have the same basic taper characteristics in order to connect without big chunky seams. Perhaps more feasibly, it would allow you to raise or lower the exits, which would break up the linearity without feeling too forced and without any complex interconnectivity requirements.

Of course, you could also just make some parts have a rise or fall inherently, which would accomplish the same thing. This would force players to accept specific patterns of shapes, but it's much cheaper.

4) Painted hulls

Another option is to let the players place the rooms/modules, then adaptively generate the flowing hull. This wouldn't be too hard - a convex mesh calculation with some holes cut for the windows and panels you want to expose. However, since I haven't done it, I don't know how good the result would really be. "Shrink-wrapped space ship" seems like it might be a bad look, and you'd need a lot of smart texturing algorithms.

Even with that approach, you'd still need to use offsets to keep the habitable areas from going excessively flat.

A subset might be possible. "Adaptive surfaces" are less difficult that fully generated ones, and it might be possible to create masking elements that "melt" into the existing objects, including making way for elements that need exposing. This is a bit of a challenge, but not as excessive as generating the full hull. Also, it'd allow for a lot more control over what the ship ends up looking like

A super-easy subset would be adaptive surfaces that have shapekeys built in. The various shapekeys align with various shared shapes among the modules, allowing you to adjust the hull to fit properly. This is a big step up from simply allowing the meshes to overlap, but it does mean you'd need to have only a few, very common shared shapes.

...

Anyway, that was my very technical essay on a specific thing I'm doing.

Stats, Classes, and Fantasy Races

In Ye Olden Days of RPGs, you would roll stats straight. Only then would you start thinking about who the character was. You would choose a class to leverage whatever decent stats you had, and you might choose a race to push your understrength stats into a viable range. So the races and classes were less about building a character you wanted to play, and more about coping with brutal random chance.

These days, we build our character stats along whatever paths we want. There's no need to cope with randomization, but we still have the same fundamental structure. We've gotten used to it, but it's pretty bad. The added complexity doesn't serve any real purpose aside from making the game's high-level play be almost entirely about knowing which stats and classes and races interact in which ways.

If we want to make our game more approachable, that is a useless kind of skill. We want our players to excel at playing the game, not excel at setting it up.

This is a common concern, and many modern RPGs reflect this tendency. We've begun ripping out stats or classes or both.

But there is power in the gap between stats, classes, and races. The way they augment each other is quite dense and interesting. Just ripping out those cornerstones means you lose all that depth!

Without the resonance between the layers, you end up with a very shallow approach and extremely straightforward builds.

Easy example: Skyrim. No stats or classes, just a few skills. Worse, improving any skill is incredibly expensive, since the enemies scale with the number of skill points you earn, not your maximum combat skills. This means your approaches are going to be both extremely basic and extremely focused. Moreover, many approaches seem viable at first but at midgame peter out entirely - for example, pure archers don't end up working out, and having to fall back on melee means you're better off just building a melee character.

A few recent games have tried to keep the complexity of stats, class, and race, but they tend to end up feeling mishmashy and sodden. Pillars of Eternity is a good example: their attempt to make all builds viable results in all builds feeling largely the same.

Statistically speaking, that's what they have to do. Otherwise you're back where we started: learning to minmax would be the primary player skill, rather than learning to play.

Is there any other approach?

Sure! Here's a simple idea:

Stats and classes, basically normal setup. However, the stats don't give bonuses. Instead, they are capacity.

For example, if you have 8 strength you can carry 8 points of gear. Say, leather armor (6 points) and a broadsword (2 points). 10 intellect? You can focus on 10 points of passive skills. Say, detect hidden (3 points), monster lore for crits vs monsters (4 points) and deflect criticals (3 points). 6 points of spirit? You can equip 6 points of spiritual gear/enchantments/spells. Magic deflection (4 points) and a ring of sparks (2 points).

This is just one idea, but the core here is that stats don't have to offer statistical effects. By splitting the class and stats into orthogonal concerns, we can give both a much wider range. A magician with a high strength might seem like a waste, but in practice it allows her to carry 3 staves and 4 wands. She can just pull the right one out in any given situation!

It also allows for midgame optimizations. You want to shave a point off the strength price of that spear? It might be more important than giving it a magical +2 damage bonus! You want to merge a bunch of magic rings into a single artifact set with a lower total spirit cost but ruin them as separate objects? Sure, sounds good!

Races? Sure. Lower the price for specific categories of gear. Elves get bows one point cheaper. Dwarves get armor one point cheaper. Maybe you have a family heirloom? It's not great, but it's super cheap for you alone. No need to modify the stats!

In addition, I find this just flat-out makes for more memorable characters: their equipment variation will be cleaner and sharper.

If you're only controlling a single character, this kind of approach is a bit iffy. If you make it light enough for a beginner, it will usually be uninteresting after a session or two. Make it heavy enough, and people will forget their setup after a week away. But if you're controlling a party, it's very easy to make it work out.

The lightweight approach combined with gear serving specific roles means that players can tell who a character is and what a character does at a glance. Even after a week away, the gear will still be easy to see and you can slip right back into the flow of things. If you're worried about stagnation, a steady trickle of new gear variants or abilities that change the prices will keep things swirling nicely.

Anyway, I thought I should mention it.

Stats vs classes vs races: it was originally built for a completely different purpose. It's ok to not do things that way. It's ok to reinvent the wheel.

Just make sure your new wheel turns, or you'll end up with an oversimplified pile of mush.

World Weaving

In the past few days I've been writing a lot about getting players to engage with procedurally generated or tool-assisted worlds.

The basic idea is that you have to get the player to actually engage with the content. That's the idea of the mining/survival gameplay in most of these games: mining resources and shooting monsters involves engaging with the randomized hills, sprayed plants and rocks, random monsters, etc.

I posted a lot of tips about how to improve that engagement, but then I read this tweet and something became obvious: you can make players engage with your content in a much deeper way by making gameplay that pushes them along a specific physical path. IE, a golf course.

An open-world golf game. Randomly generated golf courses make up the world. You can wander the world as you like, and if you feel like playing a hole, you can. The structure of the world matters because you have to painstakingly cross that terrain to get from the tee to the hole. Every variation will be felt. Every plant that can get in the way, every animal that will chase your ball, every boulder with a tunnel through it.

There are some other things I can think of that work like this: hunting, hang-gliding, racing, even grand-scale base-building. But when I started to prototype these things, I found only the golf version felt right. Why?

Well, only the golf game had underlying structure. The racing, hunting, base-building stuff was a layer that gave context to the world, but the world itself still felt unstructured and arbitrary. On the other hand, the golf courses created a fundamental pattern that could be sussed out, and you could feel that there was a structure you could embrace or ignore.

After experimenting with the paper prototype a bit more, I realized that this was not just an illusion: creating the world out of crisscrossing golf courses was fundamentally creating a world with rigorous overlapping patterns. I created a world where the green of each hole is placed in a simple grid pattern, but the rest of the course goes off whichever way it wants, twisting and turning, until you place a tee wherever you end up. They cross each other wildly!

This can be played up even further by scaling the courses - these are minigolf, these are short holes, these are long holes, these are giant courses that you play in a mech. Even the generation is easy - you can just make every course a simple path edged with local debris (trees, rocks, sand), but have overlapping zones turned into hazards. So two courses crossing over each other have a sand pit or waterway in the middle.

As I expanded on this concept, I quickly found that I could tweak parameters and overlap rules and suddenly I had a planet with rivers and oceans (megamaid-size golf hazards), mountains and valleys (courses at different altitudes), and so on. Moreover, basic rules allowed me to place houses, cities, etc (wherever there are a number of tees near each other).

By using structured challenges in my procedural generation, I could weave those challenges together to generate a complex, meaningful world full of a variety of golf challenges.

...

Well, this isn't about golf.

This same idea can be extended. We can build a world out of crisscrossing race courses - some for high-speed drifting, some for off-roading, etc. We can build a world about hunting as long as we make "hunting paths" where the player stalks a target that is taking a specific path. We can make it about hang-gliding where we define expected launch positions and paths of descending height...

As long as we generate our world out of paths, we can weave them like a tapestry. They don't even need to be individually complex at all, because their overlaps create the complexity.

So... we can generate a world out of paths!

The player can choose which paths to engage with, but they'll be affected by (engage) nearby paths as well when they do. Moreover, even if they just wander, they'll see natural flow and charming obstacles!

Neat!

We can...

...

Hey, we don't have to build physical worlds.

What if we wanted to generate NPCs?

We have to drop the idea of "quests". Those are points, we need lines. So each NPC has a variety of "directions" they want to "go".

The obvious answer is stats: what if each NPC has an "arc" of stats they want? She wants to gain 20 armorsmithing points and then gain 15 strength. You need to build her up using the least number of resources (moves, political energy, days, cash, goodwill, whatever). Trying to build strength first would be "hitting into the rough", although if you could find a way to gain both at once that'd be fastest.

But the key to this whole affair is that the paths cross each other. Unless another NPC interacts with her stat growth along the way, there's not much depth to this.

I think there are a lot of ways to do this, but one way is to tie matching stats. She wants to increase armorsmithing from 10 to 30, but there are NPCs with armorsmithing of 19 and 23. So on her way up, she'll run into them and have to work around them - either by defeating them in armorsmithing, winning a seasonal competition, charming them, frightening them, or pushing their skill up to 30+ as well.

An extremely simple algorithm can "carry" these collisions along, so that these same people continue to engage her as they automatically try to raise their skill to higher than hers, which naturally creates events where she's pulled into conflicts with her own recurring set of rivals.

Moreover, it's very easy to simply allocate a new arc at any time, and if we detect no NPC collisions (too skilled/population too low) we can either spawn new NPCs with the required stats or require that character to move to a new location with more skilled NPCs (making it in town/the big city/the capital/the celestial palace/valhalla).

This is a very simple algorithm but, as you can see, it creates a fairly compelling environment with recurring character conflicts, inherent drama, contests of skill, and so on. Adding in more details such as relationships, families, memory, and so on can make it even more compelling, but even at the basic level it's already more compelling than just randomly generating NPCs.

Because we can put the skill gain locations into the world (training halls, for example), this also links our NPCs to the world. While you can increase your armorsmithing stat in the armory, that's not the only place you'll go. In addition to always needing to increase another stat somewhere else, the conflicts that arise with other characters have solutions that involve going to other places. IE, who can make the best silver breastplate for the prince's seventh birthday? Well, meet the prince -> gather silver -> talk to the jeweler -> bribe the jeweler with wine from the coast -> gather gems -> meet prince again -> forge breastplate -> party & final judging.

This kind of setup could involve playing as those characters, but the strength of this approach is that it's "open world". Switching characters is valuable.

You can have a bunch of different games based on this.

For example, you play a helpful newcomer trying to earn their place in a new city. Or you play a ghost. Or you play Dumbledore. Or you play the floating head that recruits Power Rangers. Or you're the manager of a gym. Or you're collecting Pokemon.

...

Right now, we generate 'points'. Our worlds are filled with plants and animals and buildings and people, but they stand alone.

By finding ways to create "paths" the player can follow, we can weave those paths into a world. Whether that's a physical world or a social world or some other world. It creates engagement, creates meaningful patterns and variations, and allows the fundamental variations in the content (such as size, stats, or personality) to matter more.

That's my thinking this week.

What do you think?

Exploration Play

For the past twenty or so years, I've been thinking about exploration games. I've created hundreds of prototypes and several tabletop games about exploration, so it still irks me to see video games that drop the ball.

Let's talk about specific techniques to make exploration gameplay fun.

For starters, flow is absolutely critical in this kind of game. Your goal is not to reward the player or keep them interested, but to keep them in their flow. Unfortunately, flow varies over time and all players are a bit different.

So 1) establish flow and 2) keep the flow flowing.

1) Establish Flow
Establishing flow is tricky, but to me a big part of it is letting the player smoothly adopt a variety of short- and medium-term goals, discarding and rearranging as they see fit. The problem is that most exploration games start off with "here's a three hour tutorial".

Well, here's three hours where there's no flow state.

Every time you interrupt the player unexpectedly, every time you tell them what to do, you're resetting their "flow counter". On the other hand, if they don't see enough implicit short- and medium-term goals, they can't start their "flow counter". So both are bad.

My focus when I create exploration prototypes is to create a lot of easy-to-grab short-term goals that lead into medium-term goals quite naturally. New players will grab at the obvious short-term goals and, in the process, learn medium-term goals.

For example, if you start up No Man's Sky, the first thing you'll notice is that there's a space ship. This is an extremely obvious short-term goal. The sparking engines also clearly show a medium-term goal: fix the engines. Debris, tall plants, glowing plants - these all give the player short-term goals and, in the process, they learn about resources and loot.

Unfortunately, No Man's Sky falls short in a number of ways aside from that. It takes a long time to figure out how to use resources, and it's easy to run out of power before you figure out how to restore your power. Inventory management is obnoxious and opaque. This isn't a tutorial failure: it's a fundamental design failure.

It'd be fun to talk about How I Would Have Designed No Man's Sky, but in the end the point is simple: don't have popups. Don't have a tutorial, don't have early-game achievements, don't have an integrated crafting menu or complicated fuel management.

Focus on having delightful short-term goals (glowing plants, chunky debris, space ship) and a variety of short-medium-term (mine-able obelisks, minute-long walks) and medium-term (ruins on a nearby continent, requiring 300 ore to upgrade) goals. Experienced players will automatically balance this stuff out with long-term goals, but newbies need this stuff to flow naturally and easily in layers.

2) Keep the flow flowing
"Flow state" isn't one permanent thing - players constantly shift gears, and all players shift at different times depending on their personal preferences and mood. Because of this, any game that focuses on keeping a flow state needs to allow the player to shift their play whenever they want to, and lower that barrier as much as possible.

The two pieces to this are opportunistic short-term goals and floating medium-term goals.

Opportunistic short-term goals are easy enough: while you're on a medium-term goal, there should be a variety of opportunities to do small things en route. For example, seeing and harvesting good resources while running along, or seeing a hazard in your way and having to route around it or endure it.

Be careful about getting too aggressive: the player should choose how deeply to engage with the short-term goal. Forcing them to fight or trapping them in a deep cave is just distracting. Those kinds of forced engagements can come at the end of a medium-term goal, though, as a finale.

The point is to let the players choose to do a few fast-cycle loops if they want to, because they may be wobbling towards the fast-cycle part of their flow.

Floating medium-term goals are the opposite. When the player finishes a medium-term goal, they'll choose the next medium-term goal based on a lot of criteria. One of those criteria is what they feel like doing next. So try to engineer it so they have a few very different medium-term goals. Basically, some that will push them to walk, some that will push them to fly, some that will push them to warp, some that will push them to build - whatever varied gameplay you have.

Coming up with a variety of classes of medium-term goal is critical to this. In general, I define a medium-term goal as something with several opportunities for short-term goals along the way. So you can set up your medium-term goals to allow the player to choose what kind of play mode they're going to enter and what kind of experiences they're going to have.

For example, many medium-term goals are about traveling for less than 10 minutes to a known destination. But others might be about hunting for a specific resource, one which can only be found in a particular play style. Other medium-term goals might involve setting things up properly to survive a new class of environment, or caring for a pet, or buying something from a distant shop, or anything else you can think of based on your available kinds of play.

As long as there's stuff to do along the way.

Allowing the player to fluidly "change bands" means the player can stay in their flow state for longer, since as their mood changes, they can change their play.

3) Long-Term Structure
Exploration games have a few fatal flaws, but one of the big ones is that they're typically crafting/base-building games. By default, neither of those styles of gameplay actually makes sense for exploration. Exploration features a random mishmash of results, while crafting requires specific inputs and base-building typically locks you down to a location.

Base-building is largely a solved problem: either allow the player to take their base along, or allow players to revisit their built bases quickly and easily.

But crafting is still an issue. NMS shows this flaw in spades.

Because launching into space requires about six different resources (worst case), that means every planet must have those six resources within walking distance at all times. This leads to planets all feeling the same, even if they have wildly different visuals.

There are some simple techniques you can use. First off, make basic movement rely on no more than one resource (perhaps zero resources). If the only thing required to get into space was hydrogen, great. Every planet can have hydrogen on it, perhaps in different forms. The rest of the resources can be radically more scattershot.

A fantasy exploration game might require you to eat once in a while, but you can eat almost anything. Every biome just needs to have something vaguely edible in it.

Another simple technique is to use categorized resources instead of specific resources. IE, rather than requiring iron specifically, you could use any structural resource. Rather than requiring plutonium, any energy resource will work. They can have different stats, but any of them can get your crafting off the ground. This means that rare resources can fill the same slot as common resources, just be substantially better in some way.

Moreover, this allows for transmutation recipes. For example, if you just need to have any structural resource, you can turn oil (a fuel resource) into plastic (a structural resource) using some kind of machine.

The idea here is that the player is almost never "stuck" on a particular resource. They may get themselves stuck by insisting on using a specific rare resource if they like, but the game never says "you can't build X because you didn't find any copper". You can substitute in a variety of materials instead, including converting unsuitable materials via some time-consuming process.

This means the player is free to explore. When they find Xenocite, sure, it's just another structural element, but the resulting stats are off the charts. Build an engine turbine out of this, it'll be able to withstand immense strain and therefore you can go ten times faster than the same turbine built out of iron. Same thing, radically different parameters.

This also means you can let the player be isolated. You don't need a universal market everywhere, you don't need every resource everywhere. Let the player feel like they're out in the boonies or someplace super rare and weird.

Construction is also easy to tie into this, if your game has more than simply crafting. Bases made out of many different materials will all feel radically different and have different parameters. Just remember to solve the "base is left behind" problem.

4) Create Meaning
Exploration needs to have meaning to the player in order to make it fun.

A) Make it gorgeous. If the player wants to take pictures, they'll want to explore. Don't forget the audio.

B) Connect it to existing meaning. NMS has dinosaurs and trees, both of which are familiar and carry meaning already. Their alien species also feel familiar, callbacks to things you've seen before. Similarly, many of the stories are vignettes that simply tug on existing meaning - IE, a terrified warrior asking if you'll help him run away.

C) Chains of content. You can create meaning by making pieces change over time. For example, helping person A will make person B attack you later, or whatever. This is easy to script, but randomly generated chains need to be done carefully because the player will quickly start to categorize them and their deeper meanings will vanish.

D) Personalization. Allow the player to customize things (recruit friends, build bases, etc), then subject them to a variety of threats that test fitness and pull the player into defending the weak elements. The player will automatically feel strongly about something they own, so threaten the things they own. Just... not on a timer. Timers will break their flow.

E) Multiplayer. Allow the player to share things with other players and make it seem amazing. For example, screenshots and videos should inherently vary from player to player so that any player should think they have something unique to bring to the table, even if they're a newbie. Of course, sharing blueprints or seeding other player's content are also good opportunities to draw players in. This creates a bevy of medium-term goals as players strive to create/replicate something amazing.

Anyway, those are my thoughts.

Construction Genre

So, I just backed another "survival construction" game on Kickstarter. "Survive a crash landing on an alien planet and build-"

Beautiful game. BAD GENRE.

Since Minecraft came out, the "survival construction" genre has been booming. Unfortunately, it's a terrible genre, since it's at war with itself. Minecraft's success is not a sign that it is well-designed, it's just a sign that it had great timing and positioning.

Here's the heart of the problem: "survival" is a specific and shallow objective. Games which are about surviving require the game devs to constantly introduce new threats to you. Most games are about surviving, and the game devs spend a huge amount of effort on introducing those threats. That's the basic idea of "levels", after all.

Open-ended construction is fundamentally a player-driven kind of play. Trying to offer well-paced survival challenges to a player that is doing things at their own pace is very difficult, especially since so much of the player's resources will revolve around the specific things they've built and the specific way they've built them.

For example, in Minecraft, a player might build a wonderful base that is immune to creepers, but when you introduce those block-grabbing Endermen, it's a crapshoot. Some players, especially those that know what's coming, will have bases that don't get affected much at all. But other players, while their base is 100% proof against spiders and creepers, will collapse if even a few blocks are removed - torches go out, gaps for spiders and creepers are introduced...

This is nearly impossible to calibrate. Games where survival is key keep the calibration easy by not allowing the player to have different resources than the devs expect. You have access to X, Y, and Z guns. You have health, your speed is exactly this fast, you can see exactly this far. Because the devs know what you've got, they can present you with challenges. When the players build everything as they like, the devs have no idea what you've got!

Obviously, you can try to limit the player. But that's the opposite of what I would recommend. I like giving the player more freedom.

Letting the player construct whatever they want is really the heart of the construction genre. I don't mean constraint-free, I just mean letting the player create in the direction they want. Every player will approach the situation differently, and that's great.

But how do you create a compelling framework for this "construction" genre?

If you ask a normal dev, you'd hear two basic ideas. 1) Tiered resources: drive the player to find more useful resources in more dangerous places. 2) Phased challenges: introduce enemies, weather, and events on a schedule such that the player has to react to them.

These are good starts, but they're inherently "survivally". Let's look at a different way of thinking about it: optional constraints and challenges.

Kerbal is a good example of this. Putting aside the weird career mode they bunged in recently, there's no in-universe reason to go to any particular planet. But the fact that the planets exist is enough to make you want to go. Moreover, you can plan any kind of mission to the planet that you want, with any number of stages.

You don't simply decide to "go to Juul". You decide what kind of ship will go, manned or unmanned, what science stuff to include, whether it's a round trip or one way, what kind of landings you plan to try, whether to set up a permanent station in the area, whether to use a Kerbal-orbiting station to construct the ship and refuel before setting out, whether you want to take it slow or rush to Juul, whether you want to slingshot off the Mun or off of another planet on the way to Juul... and if you start including mods, the number of options goes up dramatically. How about an airship permanently stationed in Juul's atmosphere?

This freedom allows people to construct as they please. While it may not appeal to all players, I don't think the construction genre needs to appeal to everyone any more than the first person shooter genre does.

The way Kerbal is constructed is very clever, but there are a lot of things to learn from other games. For example, Space Engineers offers an options menu where every constraint is toggleable and tweakable. This includes things like inventory size, sure, but also things like whether there are days and how long they are. This complexity allows players to develop for radically different environments without actually having radically different environments in the game world. It also allows players to change those options during play, allowing them to develop in one set of constraints, then switch over to test or "play out" in another set of constraints, something made easier by blueprints which can be pasted into or built in other worlds.

This is a powerful concept: you can create a ship in "creative mode" with no enemies or materials requirements, then switch over to a hostile, limited world to test your ship. You can then copy it and go into a friend's server and paste it in and have a battle royale or a work together as a team...

This isn't a completed implementation. It's not very fluid, switching modes or transferring constructed content is a huge pain, and the multiplayer functionality is so bad it's actually hilarious. But it's easy to see the beginnings of a genre there.

And it's not a "survival construction" genre where you crash on a planet and have to build your own base to survive. That's just one vaguely-implemented scenario. The power of the game comes from the unfettered construction the player is allowed. Players will accept challenges and constraints just for the fun of it, and they'll come up with objectives and complex multi-phase missions that you never would have thought of and certainly couldn't organize.

So, that's my thought. If we're going to do construction games, we should have a flexible way to accept a variety of constraints and challenges, and allow players to pick and choose what they want to approach in what ways. A big part of this is making it easy to switch constraints and challenges midstream, since many players will want to build and test and iterate instead of just grinding it out in a survival challenge.

You don't need to make the game about survival. It will naturally become about survival if and when the players want it to. It might also be about building cathedrals, or putting together a fleet for a dozen players to work together.

There's also no limit to the kinds of challenges and constraints you can offer. It's popular to just use the basic construction ideas - some facility-wide resources, some physical constraints, some topological challenges, and realtime combat.

But you can define your game with a lot more creativity if you offer a wider range right up front.

For example, what about if you could "weather" your facilities for N years, turning them into ruins or seeing them adapted by NPCs? What if you have missions other than fighting, such as transport, medical, research - if you make them as complex to manage in real-time as combat is, you can have compelling noncombat challenges. How about simulating the people inside the facility?

Any one of these additional "modes" would make your game unique on the marketplace today, but in ten years, I expect they'll all be considered standards in the genre.

That's what I think, anyway.

Base Building Variants

So, there have been a few hints of innovation in base building games. These are barely even shadows in their games, but they have a lot of potential and shine a lot of light on the basic ideas of base building.

The first detail you need to know when you are designing a base building game is the point. Most base building games have the same basic mechanics, but the game changes dramatically based on the elements that are deepest. Usually, these are the unique constraints that pressure you as you build your base.

For example, in Sim City the supply/radius systems are the deep elements, leading to a game focused on roads, pipes, and pollution. On the other hand, in Evil Genius the focus is on congested space, so the focus is on cramming as much functionality as you can into a limited amount of space while balancing security risks.

Sim City rarely has any concern about security, and there's usually plenty of space. Evil Genius has no interest in supply lines. They have the same basic mechanics, but have different constraints.

Certain games have introduced unusually nuanced techniques. First, let's talk about Fallout 4.

The base building in Fallout 4 is mechanically perfunctory, with little to no complexity or nuance. However, the back end is heavy-hitting, with a combination of modular and freeform components that can be mixed as you see fit. The detail worth considering is hiding in that mess: the power lines.

Things which require power in Fallout 4 mostly need to be wired up directly, so you'll end up stringing physical wires between the generators and everything you need to power. These wires follow some basic rules: the droop realistically as you string them up, and there's a max length, and they can't drag on the ground or pass through walls.

Probably your first instinct was to find this annoying. Hopefully, after a little while you began to see that there is a shadow of something interesting hiding in that idea. Providing power to building interiors is an interesting challenge, involving abusing the droop of the wires to pass them through windows, up stairwells, and so on. The droopy wires interact with the rigid, modular structural elements in a way that is just awkward enough to need careful attention and just flexible enough to allow you to come up with clever ways to do it.

The concept of having multiple kinds of construction that work alongside each other, rubbing elbows awkwardly, is interesting. In the past, you might have to wire up buildings like with SimCity's road, power, and water infrastructure, but the two didn't really clash at all. Later we had the concept of modular structures plus free-placement furniture, but the placement of the furniture didn't really matter much, so it was quite shallow.

This "droopy wiring" system is one that clashes. It means building your structures specifically to allow for wiring, but it doesn't have a simple option to do that. You have to decide the best way to do it, it's a gentle pressure pushing at each design decision. Every time you think you've thought of an optimal solution, you'll see a base someone else built that uses a different technique that seems really neat as well.

Now, the implementation in Fallout 4 is pretty primitive. Space is overcompressed and nobody cares about things like lights and TVs, so there's really no reason to wire things up at all. It also makes no sense that you can't run wires along the walls or floors and have to let them hang.

The underlying idea is interesting. We can use this idea of different construction types butting shoulders freely. We can create interesting new games like this. If we start from the base concept of "modular structural elements", what can we add in that bumps awkwardly against it?

The easiest thing to do is add in multiple kinds of connectivity that have very different requirements and side effects. The basic "modular structure" approach is about creating walking paths - doors, halls, etc. What other kinds of connectivity can you add? Water, power, and air are easy examples.

But you need to make sure their connectivity doesn't follow the same rules as the doors-and-halls structure. They need to rub awkwardly. For example, maybe the wires that can fit through interior walls are limited to only a small voltage, but the heavy cables can't pass through walls and are vulnerable to accidents, fires, and damage from invaders. Maybe the air systems work reasonably straightforwardly in theory, but resonate with the structural chambers to create awful winds and chills, propagate toxins, etc.

Those examples involve integrating into the same construction space as the modular structural elements, slotted into them. However, it can also be in a different construction space, as with Fallout 4. To make this fun, your structural elements have to be permeable in complex ways. For physical objects such as power cables, that means physical holes in the modular elements - windows, doors, or arbitrary gaps. However, you could also have nonphysical things permeate the walls: light, sound, joy, heat, data, whatever. The walls also need to vary to allow those things to break through in different amounts.

An easy way to expand your design space is to focus on things besides power and water. For example, building a "digital base", or a dungeon, or a monastic enclave where natural elements need to flow in order for the monks to achieve enlightenment, or a theme park.

But you don't have to think in terms of connectivity. Another easy thing you can do is think in terms of asynchronous build systems.

For example, instead of power lines, what if it was plants? A fantasy elf village, where you have to grow plants alongside, inside, and as the walls of houses. It would be interesting to try and build your structures to interact with the slowly growing trees you plant. The underground roots intertwine beneath your homes, and the branches crash through poorly-placed roofing to reach for the sky.

Or how about having to build a facility that will wear down over time, and have to build it with the understanding that things will fail and need to be replaced... but have the replacement/repair system take up a different amount of space/resources than the original system.

There are so many other possibilities, and I look forward to thinking about them more.