Boiling the Yarnball

I've been thinking about why I like the construction games I like.

I'm including things like The Sims into this category. Whether you're constructing vehicles or facilities or people, there is one specific feel I like, and a bunch I don't.

I think it's yarnballs.

Big, soft, messy challenges that can be approached in a lot of different ways with a lot of different entanglements to the rest of the game.

For example, you're playing a space game. The rules are: you must have one point of life support per astronaut.

This is a small, hard constraint. There's no softness, no flexibility, no entanglement... no mess.

But in Oxygen Not Included, that rule is turned into a yarn ball thanks to the physics sim. I can create drafts of carbon dioxide, let rooms sort themselves into bands of gases and keep people in the oxygen zone, let them breath diseased oxygen, use pressure gates to optimize pressure for ideal algae conversion...

A combination of complex approaches (scrubbers, cleaners, algae, natural oxygen sources, etc) combined with complex topological possibilities (pressure, natural air sorting, air filtering, wind, etc) creates a lot of possibilities, a lot of bizarre, fun approaches that affect everything else in my facility.

It's not me balancing a spreadsheet. It's me building a facility, with all the complexity that entails.

One thing that makes this yarnball approach shine is how it ties into the rest of the construction, and how it turns a challenge into a narrative.

Challenge: you need to provide air.

Narrative: "the third and fourth floors of our Mars base are pressurized. Whenever we venture down to the first floor to change out the algae, we hold our breaths and work fast. Sandra got real sick when she couldn't hold her breath long enough."



The thing about yarnballs is that you do, eventually, sort them. Maybe not to some perfect standard, but you develop a method that works for you, and you'll usually stick with it.

That's why it's so important that the construction game is a huge pile of yarnballs.

If I sort one, there's another behind it.

More importantly, as I sort that one, I realize it's tied to the first one, and I didn't sort it well enough!

This creates an endless chain of narratives as I watch my facilities struggle with challenge after challenge, all their difficulties largely being my fault.



Another example of a yarnball is having children in The Sims.

Not only are the children themselves fairly complex, but caring for them is a convoluted, messy yarnball. You may think you have it solved, but then you realize your stay at home parent this time is a neat freak or something, and your timetable falls apart.

Or how about building a defensive entrance in Dwarf Fortress?

You have to deal with the threat of invaders, so you build a defensive gate. But how big is it? How do people get through it on their daily lives? How many resources can you afford to spend on it? What traps can you build? When you need to upgrade it, how will that work out?

And when the invasion happens, the gate helps turn the rather blunt narrative of "you lose, everyone dies" into a more nuanced narrative: "Bjornblatt lost an arm fighting off the goblins that got through the traps, and Hjornol is now responsible for rebuilding those traps into something more effective..."



I think yarnballs require a certain presentation to catch my attention.

I call it "boiling the yarnball".

This is a technique where nearly all of the game is incremental. In The Sims, your skills slowly go up, money slowly trickles in, you slowly do better at your job. In DF, you slowly farm, slowly build another bunkroom. It's all incremental.

Except then it's not. There's a challenge you're working towards.

In The Sims, is it time for a kid? Time to move? Time to get a promotion? Maybe just time to throw a big party?

In DF, is it time to build a defensive gate? Internal waterways? A magma forge? Maybe just time to rearrange who sleeps where?

What the player considers to be "a big thing" will vary depending on skill and interest. But you're usually working towards at least one big thing. You're playing the game to push the edge of what you can do, what you understand.

If the goblins trashed you last time, this time you're playing to build goblin defenses. If your sim died old and alone last time, this time you're playing to make a family. You build towards those challenges, and some part of your construction is difficult and challenging... because you haven't mastered that yarnball yet.

So the premise here is that the yarnball isn't thrown at you. It's something you walk up to. Something you explore.

The challenge that creates the yarnball might not be so gentle. The goblins will eventually attack. You will eventually get old and die. But you have some leeway before then.

Otherwise, there's not enough time to try and detangle the yarnball.



So I like to "boil the yarnball". You let the challenge that defines the yarnball simply sit there and simmer. When the player's ready, they can begin pulling at it... at which point, the narrative becomes more concrete.

To make it more concrete, I think there are four phases to this. I'm just getting started with my thoughts on this matter, but here's what I've come up with so far.

1) Planning
What challenge does the yarnball address? How will that challenge affect your facility? How will different levels of addressing it change that? How much space do you have to build in? How many resources do you have? How many workers can you divert, for how long, before things get risky?

Tie the planning into the overall flow of your facility, so it becomes part of the narrative: "in fall of 392, we began to defend ourselves. As harvest season ended, the farmers turned their hands to construction..."

2) Construction
Did you plan it right? What goes well? Poorly? What opportunities do you seize, or threats do you face that affect your construction efforts? Again, the construction is part of the narrative of the facility: "The great iron gates in the plan were changed to wood, at the request of the lord of the land, whose brother owns a lumberyard..."

There should be no real randomness in the mechanisms of construction. The randomness comes from outside: "oh, there's a gold seam where I wanted to put a wall. Oh, my workers are throwing tantrums because of the rain..."

3) Daily life
How does your construction affect things that aren't that challenge? The 'daily life'? What new opportunities does it create? What troubles? How does it integrate into your normal daily narrative?

For example, "The gate lay open, guarded by a single lookout. The lookout became very good friends with the hunters and lumberjacks, as they passed by nearly every day..."

4) Spotlight
How does your construction actually do its job? Specifically, how does it change a challenge into a narrative?

For example, "When goblins attacked, our lookout was slacking. Several got through the gate before it could be closed. Fjornblatt is fighting the intruders while, outside, torches are being lit..."



Each of these four phases of a yarnball helps to cement the narrative of the overall facility. The yarnball is positioned specifically to turn a challenge into a narrative, not just in the moment that the challenge arrives, but in an unbroken chain throughout the course of planning, construction, and daily life.

If you turn this idea towards other genres, you can see hints of it in other games. Coincidentally, those tend to be the games I like.

In an open world RPG? Building a character is several yarnballs. Watching the character face the challenges I intend them to face is great fun, as is watching that build struggle through challenges not related to their specialty. That's the part of an open world game I like.

Contrarily, without boiling yarnballs, even games in genres I like aren't very interesting to me.

For example, most "factory builders" where you assemble cars or medicines or whatever don't hold my interest. Either because the optimizations are all very cut and dry, or because the yarnball isn't presented in a way that helps me digest it.



How about you? Any of this fit into your idea of what's fun and what's not?

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?

Voxels and Architecture

A lot of games use voxels to allow players to build whatever they want.

But the key in that sentence is "they want".

What do they want? What will they want?

Obviously, players will come into the game with some ideas from outside. People are always going to try to build familiar things. But your design of the voxels and the rules of the game will influence what they want to build later on, when they start getting used to the game and wanting to push their limits.

Most voxel construction games have cubic meter voxels, which is a good size to allow people to build personal-scale architecture. It's a good balance of personal freedom of expression vs complexity.

With this scale of voxel, most construction voxels are simple bricks, then further decorated with detail blocks such as stairs, chairs, paintings, and so on. While those decorative elements do matter, the fundamental construction of the walls, floors, roof, garden - these are almost always done with simple cubes of various textures and colors.

Despite this, you can have quite a complexity of structural results. With just simple cubes, you can model anything from an ancient cave to a modern home to a huge castle to a mighty bridge. There are some constraints, though: it is quite difficult to model things like roundhouses, or anything else that is deeply non-orthogonal. Despite that, the variety of things you can build is pretty amazing, and you can do quite a few complicated architectural things like drop ceilings, natural light control, and so on.

Unlike those games, Medieval Engineers and Space Engineers have massive, 10 cubic meter voxels. These voxels are scaled way up because the things the players are supposed to build are not personal-scale: you're supposed to build huge battleships and massive castles.

However, because of the large scale of these blocks, they are usually not simple cubes. The players want more control than that.

In Space Engineers, the blocks are frequently angled or rounded, to allow for the common hull shapes you see in fiction. Because of this, rather than having many block types and varying between them, most space ship hulls are built out of only one or two block types. The player's efforts are spent entirely on switching the shapes of the blocks, and perhaps painting them afterwards.

Similarly, in Medieval Engineers, almost no construction voxels are simple cubes. Instead, they are common medieval castle shapes crammed into a 10m3 package. A curved wall. A gateway. Thick or thin stone battlements.

A very tightly-themed game, Medieval Engineers is focused almost entirely on castle construction. The voxels have been limited to specific kinds of evocative, themed shapes to help the audience build variants on the accepted theme.

In both cases, the theme is much tighter than in a game with smaller voxels. Nobody in Space Engineers is interested in building a medieval castle, and nobody in Medieval Engineers is interested in building a space ship... but in Minecraft, people frequently build both in the same world.

I'm not saying that these themed large blocks are "worse" than the unthemed small blocks. Once you get used to the system, it's easy to build huge, beautiful things in those games.

What I'm saying is that constraints matter.

When you put together a construction system, you're not putting together something in a void. You're building something that exists specifically to help players build stuff. The methods and the constraints are critical.

Even if you're doing standard small blocks, constraints and construction methods will radically change the outcomes.

For example, in Eco, roof tiles automatically form into slanted roof elements to make convincing roofs. This happens to have an edge case where, if you have a 45-degree roof, you end up with a stepped roof with a wonderful gap to let light in. Just this small foible is enough to create a whole slew of architectural possibilities. It influences what players want to build... even though it's just a small visual idiosyncrasy!

A more obvious example would be monsters. If you are playing on a monster-filled Minecraft server, your homes will have various ledges and overhangs to prevent spiders or creepers from being a problem. This creates a distinctive feel to many survival-mode houses.

This isn't really an ideal constraint, though, because it's not integrated into the game very well. For example, there's nothing preventing you from simply building a floating house. Going in the other direction, there's no real way to use the attackers in a more interesting way - they just randomly wander up. You can build traps for them, but the traps are usually coffinlike underground pits, not any kind of interesting architecture.

Redstone is also a missed opportunity in Minecraft, because it does not attempt to create any sort of architectural opportunity. You can see hints of what could be when you look at vertical redstone torch elements and such, but architects have to try really hard to force redstone into an interesting architecture.

Imagine if redstone had more interesting topological constraints. For example, what if a vertical stripe inverted the charge? What if parallel, horizontal redstone trails would damp each other, making both null unless both were active? What if redstone healed people nearby? What if it had to be regularly repaired by direct access? What if a redstone "window" generated charge by harvesting sunlight, instead of using a torch?

With a rethinking of how redstone works, you could easily see integrating redstone into your living space, or at the very least having a redstone system be architecture.

If you want less fanciful architecture, you could also include less fanciful constraints. Heating is not hard to simulate at that level, and including a heating system would inspire players to create lots of different heating and cooling arrangements that would be similar to the real world. Moreover, each biome has different patterns of hot and cold ambient temperatures, meaning more variation in houses!

Well... adding all these complexities naturally raises the complexity of the construction.

Space Engineers has a way to calculate whether a space is pressurized. However, because it's very hard to figure out why an area is failing to pressurize, this remains one of the most annoying parts of the game. Similarly, it allows for rotors and pistons, but because they are so buggy and unreliable, trying to use them is just an exercise in aggravation.

Adding complexity constraints is not always the right idea, but it becomes the right idea more often if you "work up to it". That is, if an ordinary construction by a newbie wouldn't encounter any problems due to it.

For example, if you have a structural integrity simulation, but it's gentle enough that an ordinary player house in an ordinary biome wouldn't be at risk. It's only when the player begins to try to build that megacastle on Mars that they have to start worrying about it. Or, similarly, if active redstone slightly healed anyone nearby, players could use it for that without having to try and delve into computation.

These sort of things are great fun to think of, and would definitely be more interesting to more players!

There are a lot of things I want to try to put into a construction game! But... even the smallest ones feel like they could make a game all by themselves.

For example, what about a construction game where you want birds to nest in your house? What about a game where views matter, either because people like them or because systems can only respond to threats they can see? What about a game where you whittle your starship hull instead of voxel-build it? What about a game where natural lighting is the most precious resource? What about a game where annoying extended family members are constantly visiting and you need to keep them impressed while also driving them away?

What I'm saying is: you can sculpt what you want players to want.

Methods of Topological Constraints in Base Building

I love base building games, and I love it when the base building is a challenge.

Most base building games are spreadsheet games where the checkboxes happen to be on a map somewhere. There's rarely much in the way of topological challenges - it's mostly a matter of building the right things in the right order and dealing with whatever semirandom challenges the game throws at you.

But I like topological challenges. So here's some methods to introduce topological challenges and constraints.

Time compression is by far the most common method. Most base-building games feature inhabitants which walk around your world, and they only do their jobs when they're at the right place. Since time is dramatically accelerated, this means that the time they spend going from A to B is a major part of their day. You can see this in games like The Sims, Dwarf Fortress, and any base building game with people that walk around and time that passes.

Personally, I don't much like this constraint. It is overused. It's especially bad in games where the worker AI is semiautonomous: you can't really optimize the worker's habits and instead just have to dully crowd things together and hope it works out.

Connective constraints are also quite common. This is when base component A has to be within X distance of base component B, or you need a physical wire, or some other method of constraining the shape of the base by requiring things to be within certain ranges of other things. Often this only applies to specific types of facilities - typically electrical. For example, in Fallout 4 and Rimworld you need to wire up your bases for electricity.

Some games are much more constrictive. For example, in MewnBase you have to have every pressurized unit connected directly to another pressurized unit. In Space Engineers, booster elements have to be directly attached to boostable components.

Some connective constraints are so common and natural that we don't even think about it. For example, every base-building game where you can build vertically requires the next story to be built on top of the previous story. This kind of "crushing constraint" we'll talk more about later.

Simple topological constraints is when you can only build in specific places, and the explanation is very bluntly "you can't". For example, in Dune you can only build on concrete, and extending your concrete is a major factor. In fantasy citybuilder, you might only be able to build on the valley tiles, and not on the mountain tiles. You can't build over there because you can't build over there. Simple.

This is typically a level-bound constraint - that is, the player is challenged to make their facility work within the constraints of the level. The connective constraints we discussed before are module-bound constraints instead - that is, these modules have the same constraints regardless of the level you're on. The two typically work in conjunction to put a lot of pressure on a player. These two constraints working together have produced some of my favorite base-building games.

Perimeter constraints are when there is a fitness test waged against your base in a topologically consistent way. For example, a windstorm blows through every month, always from the same direction. Invaders spawn at the edge of the map and march towards you. Space lasers hit your battleship from predictable directions while you're in battle.

While there are many kinds of fitness tests, these perimeter constraints deserve special attention because they are topologically enforced. This isn't you running out of gold or whatever: there's something producing stress on your topological perimeter, and you have to build your perimeter specifically to deal with the threat. Extending your base is often expensive simply because you have to start with your defenses!

Some perimeter constraints are more brutal. For example, if the island is constantly sinking, so after a while all your perimeter buildings are simply erased.

Topological stress constraints are similar to perimeter constraints, except they're not based around your perimeter. This is commonly used as a secondary enemy type in enemy-centric games. For example, teleporting troops pop up in the middle of your base, or there's lightning strikes that hit randomly somewhere in your facility.

These produce topological stresses, but at semirandom locations. For example, in Evil Genius, one kind of hero would dig through the walls of your base and pop up inside. The places they can arrive are predictable, but typically well inside your defense perimeter.

Building your base to withstand these arbitrary pressures is quite a challenge, and typically these sorts of threats are considered advanced or high-level, since building a functioning base in the first place is the main challenge.

There are other kinds of topological stress constraints:

Self-induced topological stresses are similar, but these are topological stresses you create with your own engineering. In a space ship game, this might be heat: you can't fire your lasers for long because you didn't put in enough nearby cooling. In a fantasy game, it could be height: building a skyscraper in Medieval Engineers is challenging because of the physics of building tall stone structures.

Personally, I think self-induced topological stresses are the most fun. I like to change connective constraints into self-induced topological constraints by adding in concepts of quantity, speed, and gravity. For example, many base-building games allow you to pipe water. In most games this is a simple connective constraint - pipes must connect to pipes. But if we introduce some basic physics, we create a lot of interesting new challenges.

At lower levels, piping water would be basically the same as if we were just doing connective piping, because that's how the physics is weighted. But when we try to bring in a lot of water, or water under high speed, or lava instead of water, we have to get really clever. Imagine trying to build a medieval castle and figuring out how to pipe in lava, or maybe using high water pressure to create a defensive cannon.

Moving constraints are rarely seen, but they are simply topological constraints coming about because you can move portions of your base. At the most basic level, this can simply mean locking the doors or raising a drawbridge when enemies attack. At more complex levels, it might involve sliding ladders, moving staircases, inflating rooms, tuck-away furniture... but I think this concept can be pushed far, far harder. We just generally don't think about it much.

Constraint Result Types
While we've talked about the kinds of constraints we might see, it's also worth talking about what happens when the constraint hits a fail state.

"Hard" constraints aren't ones that are difficult, they're ones which literally cannot be failed. You can't build on mountain tiles. You can build levitating buildings. If you somehow manage to get into an illegal state, the facility is erased - it collapses, explodes, etc.

A medium-hard constraint is one where you can get into an illegal state, but if you do, the facility doesn't immediately vanish. Instead, it is simply nonoperational or begins a countdown to death. This is often found with things like not wiring up your power-hog modules: the player is allowed to realize their mistake (or plan ahead by building illegally), then fix it up afterwards. This is also often found with things like structural stresses: the overstressed pipe doesn't immediately explode, first it springs a leak.

A soft constraint is where there's not really an "illegal" state, it's just that the state gets worse the more stress you put on it. For example, as you route more electricity through a wire, it gets hotter and hotter and you have to deal with the heat output. Or the taller your building, the thicker the lower story walls get, until they're so cramped that people can't even get through.

Anyway, those are some of my thoughts, mostly to myself. Let me know if you have any opinions on the matter.

Designing Inhabitant-Centric Games

This is an example game design for a person-centric base-building game. Sort of like Rimworld, except the people are the focus and their stories feel more solid, like in The Sims. See the previous post for details of the why and how.

One thing we need to do is abstract jobs more than Rimworld and other base-building games do. If jobs are simulated in the same space and time as the home, then duties won't be very isolated. This means it's difficult to control the way duties work and the events they cause, and it also makes the duty time 'permeable' - people can swing in and out as they see fit. Those are all bad things.

Therefore, our first goal is to create workspaces separate from our home spaces. The two obvious approaches are out-map and in-map jobs.

Out-map jobs are simply duties that take characters out of the densely simulated home area and off to somewhere else. For example, a farmer leaves to tend the fields, which are not part of the same map. Or a superhero leaves to patrol the city, which is obviously not inside the secret base. These remote areas can still be managed by the player - setting up exactly how many of what fields are where, or what the patrol route is - but they're not simulated in the same space and the workers are not available to the people still at home. Of course, out-map jobs are also good in that you can change the remote conditions without needing to change the local conditions, or visa-versa.

In-map jobs are when the worker is still in the home space, but not being simulated as part of the home experience. This could be something like a woodshop - the worker is technically still on the map, but they aren't wandering around or chatting or worrying about whether they need to go to the bathroom. In a superhero setting, this could be researchers or radio support or training - anything that can be done locally and allows us to lock them into a set pattern for the day. The difficulty with this approach is that it doesn't naturally give a schedule - you can train whenever, you can research whenever, etc. That makes it a little harder to create scheduling frission between different jobs.

Obviously jobs aren't the only thing that matter in our design, but with this in mind, we know that a big part of our design will be outside the map, or at least abstracted within the map.

Within our densely-simulated space, we need to design carefully. The purpose of this space is to help build personal stories both in gameplay and in the player's mind. Most of the base-building games that are popular these days are meter-by-meter designs. This has many advantages, allowing the player to express themselves freely while also locking the player into topological challenges presented by both the initial setup and the player's own previous base-building choices. It's a good way to create opportunities for the player to freely create a base with a lot of unusual elements both incidental and purposeful in an attempt to optimize performance.

But that's a base-centric approach. If we plan to be people-centric, we need our bases to support story and context, both with game mechanics and in the player's mind.

What can do that?

Well, if we want to create context, then we have to make the inhabitants relate to the space with context. That is, the people in the world have to want to use the space in specific ways that produce familiar or memorable stories.

In The Sims, examples of this would be the bathroom. There are rules about exclusivity in the bathroom - it's usually one person at a time, but perhaps family can use it at the same time. You can create different kinds of bathrooms to give the player funny stories about how the bathroom works - for example, sticking a window in it facing the living room. The exclusivity rules are in-game rules that are familiar to the player and create good context, while the funny design alternatives are mostly in the player's head, but still create good context.

Bedrooms are similar: is it one person's room? A big bed for the parents? A crowded row of beds for a bunkroom? There are in-game rules about the effects of these things, but even more important is how the player has expectations for these things and feels a heavy sense of context depending on how it's built and the people living in it.

Public spaces like living rooms are equally high-context. These are gathering places where people get together. Sometimes in passing, sometimes to cooperatively do something (eating, watching TV, etc), sometimes to do different things in the same area at the same time (one person cooking, one person dancing). Public spaces are further leveraged by scheduled events such as parties and family dinners. All of the various ways people can gather have context, and the space itself enables those contexts while simultaneously creating additional context in all the ways it doesn't quite fit. For example, if your party can't easily get food, you get more context: hungry guests moving into the kitchen instead of staying in a completely open space, now standing clumped together.

All that said, The Sims still uses a meter-by-meter construction system. Well, there are some differences.

The Sims construction focuses on walls to a great extent. Most base-building games have walls that are one tile thick: meter thick walls! But The Sims has paper-thin walls, and this allows the player to carve up map quite densely and with ease. This packs far more useable space into the same size map. This may sound unimportant, but it's critical. Not only can you fit more, larger characters onto the player's screen at one time, but the characters are also substantially closer together, allowing them to interact more regularly and freely. For example, someone in the kitchen can easily chat with someone in the living room, whereas if the walls were a meter thick, that would feel more like shouting range.

These seem like small details, but when it comes to creating human context, human details like that matter.

The Sims also has complex standing positions. Rather than "one tile per person", people in The Sims can stand in arbitrary places and in arbitrary groups. Although I don't think The Sims uses proximity as a reflection of intimacy, this is an obvious use: people who stand closely are more intimate than ones that stand meters apart. Similarly, people who sit on a couch together are in a different social situation than people sitting on random chairs.

In short, a dense space that can be used by people standing in a wide variety of configurations. A dense space with variable publicness and utility.

Combined with our off-map jobs, this clearly reflects a focus on someone's home, rather than the more widely-scoped mixed spaces of most base-building games.

Classically base-building games have avoided being solely about someone's home. Statistically, the other aspects of the base are more interesting. But statistically interesting is not what we're interested in. Topologically interesting, yes. But we're simplifying the statistical aspect, and a very easy way to do that is to chop off all the job-related base-building stuff.

From here, deciding a genre is probably critical, since 'home' has a different meaning depending on the genre.

If we set it in the modern era, it'll be very Simslike, because we've basically reverse engineered the core features of that game.

A superhero genre would work well. A team tower or secret base would be our home. Our characters could have night patrols, daytime rescue missions, media reachouts, school, day jobs, investigations - those would be off-site. On-site abstracted jobs could involve training, radio support, research, crafting, etc. This would no doubt be an interesting setup, but there is a weakness in that superhero bases tend to be attacked. This isn't as bad as in most base-building games, because 90% of your assets are locked into your inhabitants, not your facility. Rebuilding or moving is cheap enough. But players would still focus on defenses, and that may be hard to make feel just interesting enough without taking over the game entirely.

A fantasy setting could go rural or adventurous. A rural setting would allow people to go off map for things like farming, crafting, etc. It would also allow for interesting long-term setups, since sending children away for years would not be uncommon. However, I'm not sure that the feel of rural fantasy life would make much of an impact on the player.

An adventuring setting could be fun, though. You could run a guildhouse. It would have a lot of similarities with the superhero idea, but missions would often take several days, and managing funds would probably be more important. The medieval lifestyle simplifies the living space considerably, and characters would be far more likely to have to spend their leisure time together instead of separately watching TV or whatever.

A sci fi setting might be fun. You could create a Mars base or something, with dome bubbles for inhabitable areas. Within each dome, only thin walls would be used for weight and air permeability, allowing for very dense space. The lifestyle of science fiction might not have much impact on the player, but sci fi is more flexible than fantasy, so it's possible to just make their lifestyles more familiar even if it doesn't really make too much sense in the setting.

Well, you could also do something like Firefly, where it's aboard a space ship. The problem with this is that space ships often have very heavy, environmentally-sealed areas. In addition, there's not really any "off map" to go to, meaning that our job management might be hard.

A fantasy sailing ship might be fun, too. Job management might be hard due to the lack of 'off map', but I think it could be managed.

There are a lot of possibilities. I don't really feel the need to push further down any given road right now, though. I'll just let my brain rest a bit.

What do you think?

Building More With Less

In a "building" game, I always want to use fewer types of parts to build a wider variety of results.

I want the game to feel expressive, like the player can make a bunch of different things with a bunch of different goals.

For example, do you have a "gatling gun" component? Even if I am making a war ship, a "gatling gun" is an inexpressive element. It's going to be the same for everyone, take up the same space, do the same things in the same way.

Which is why you also have a "laser gun" and a "missile launcher" and a "sniper gun" and whatever other weapons you can think of... that's expensive. It takes effort to make them, space to have them in your game, and visual clutter to make them all selectable. Even after all that, they're still not terribly expressive.

Adaptive Elements

How about a system where you have a "gun" module, and then you can tweak the settings?

Change the accuracy, the range, the rate of fire, the ammunition type. To keep it balanced, you could use a points system - extra points in accuracy means less points for rate of fire!

If you allow for this, then players can change their weapon loadout to fit the role they want the weapon to fill... and use a lot of fine grain knobs to do it. As long as combat actually interacts with those stats, you've created a method for players to specialize in different combat roles using a very fluid, adaptive system. Depending on the metagame, players might start using unusual combos that canned one-off weapons would never have though of, like sniper missiles or hyper-accurate micro-range burst lasers.

If the settings reflect suitability for different roles in the greater game environment, they'll be great fun! Just makes sure your UI reflects their settings so the player doesn't forget what is what.

Soft Constraints and Constraint Systems

Rather than using a "points" system like above, it's better to use a soft constraint that ties into the greater game environment.

For example, each shot generates heat - the better the shot, the more heat. This is conceptually the same as a points limit, but since it leans into the rest of the world, other kinds of game concerns can affect it. For example, what about firing in short bursts and letting the weapon cool off manually? What about attaching extra coolant systems to cool the weapon faster?

In this case, the greater game system we're leaning into is heat management. This makes heat management a "constraint system", and those have to tie into as many different things as possible to make innovative and interesting builds possible.

For example, attaching "coolant modules" to the gun is extremely dull. It doesn't integrate with anything else. But if you have to actually pump coolant, now you have a topology constraint with a lot of possibilities. For example, maybe you want to run colder coolant? Now you need to build coolers. Is your coolant heating up as it moves between the ten things you're cooling? Hm! What do you do afterwards - vent the heated coolant out of the ship where it's likely to be spotted by enemies, or perhaps use it to pressurize living quarters? Run it around the perimeter of your ship to cool it and de-ice your wings? Use it as a low-grade propellant?

Depending on the scenario, the external parameters and concerns will vary - and the player's own ideas and goals will also cause parameters and concerns to vary.

You do need to make sure your UI can handle players grappling with these systems.

Carry and Produce

A related concept is 'carry and produce'. What we did in the last example was turn "heat" from a fungible number into a tangible good. Tangible goods offer a much more interesting challenge with more opportunities for fun constructions. This is especially true if two systems combine into a single tangible good - for example, heat combining with a specific kind of coolant into a single good.

While "heat" is simply a number, once we transform it into a complex good, it becomes both a challenge and an opportunity. Is it hot water? Glycol? Cool air? Liquid hydrogen boiling off? Each of these offers different specific challenges, but uses the same fundamental 'piping' mechanic. That same mechanic could allow them to be used in any other situation where either heat or that substrate is used: hot air becomes life support supply. Boiling liquid hydrogen becomes propellant.

This can be done with almost anything. For example, instead of generating "science points", what if you turn that into a tangible good - a science paper which is only converted to science points upon export? Now the science paper can be manipulated in tons of ways to make it more valuable.

Some players might specialize in quick-and-easy science papers for a trickle of science. Others might specialize in massive databanks to hold the papers until they are at the maximum possible size. Others might use supercomputers to refine the data until the science paper is small, but potent. Others might choose to generate science in different ways - often tied into other kinds of systems.

It's critical that the UI supports this - supports the player immediately knowing what is being carried and how it is being massaged. But if you can do that, you can create a wonderful opportunity for depth and expressiveness.

Changing Conditions and Triggers

One overlooked element in most construction games is changing conditions. Normally you just optimize for whatever the current situation is and that's that. About the only construction games with changing conditions are ones where you have to survive the winter, and that's often not pushed very far.

To keep using heat as an example: heat in an ice-cold winter is very different from heat under a baking desert sun is very different from heat at the bottom of the ocean or in outer space. Your initial instinct might be to simply make each base have a specific heat condition - this is an artic base, this is a deep-sea base - but that's something only beginners will find challenging.

Increasing difficulty is much more about the swing, rather than the baseline. Optimizing heating systems is more interesting when sometimes it'll be very hot and sometimes it'll be very cold. Designing a space ship that can fly through the atmosphere as well is more fascinating than simply saying "this is a space ship, that is an airplane".

In general, I think of three kinds of changing parameters, each of which increases in swing as difficulty increases.

1) Routine changes. For example, people going home for the night to sleep, or solar power only being available during the day. Combining routine changes can make for very fun results - for example, solar power is only available during the day AND at night a punishing dust storm rushes by, leaving an opaque layer of dust on everything. Now you have to have a setup that cleans solar panels or hides them at night!

2) Catastrophes. These are things outside of your control (although for game reasons the player may be able to trigger them). Fights. Plagues. Crashes. Winter. Holiday shoppers. Typically these are tests for how "disaster-proof" your design is.

3) Scheduled changes. These are things the player causes as their plans advance. For example, holding an election. Traveling to a new planet. Choosing to land. Giving crew leave. Refurbishing the facility.

In order for these situations to be fun, two considerations must be handled.

1) Soft failure. If the player falls short, they should be able to pull through with damage. This is also where beginners will start, so adjusting for failure should be something players can do manually, while panicking. For example, if a storm hits, players have to be able to order people back inside in order to weather it, and the storms should (at least at normal difficulty levels) not instantly kill anything caught out in them.

2) Programmable responses. The players should be able to trigger responses automatically using in-game objects. For example, allowing the player to lower landing gear when a particular sensor registers there's ground below, or automatically ordering people inside and barricading windows when a storm hits. These can be used by midlevel players to handle changes automatically, and by advanced players to create absurdly complex contraptions.

By the way, I am a big fan of moving parts - whole sections of facility that can move around. Normally this is implemented as full-scale facility elements being rolled around, and that's not a great solution because it's extraordinarily bulky. Instead, I recommend parts can fold up and unfold, allowing things to take up much less space when not in use.

An easy example of this: if you need to charge your laser using a big power cable, but also cool your laser with a coolant pipe, each can be folded away into a wall tile. Both can be folded away at the same time if you need to walk past. Then they unfold and fill the space as needed.

Anyway, those are my thoughts on base building. Use fewer parts for more expressive results by keeping these things in mind.

Let me know if you have any opinions.

Base-Building Games and Worlds

Let's talk about fairly advanced game design topics for base-building games. Games like Rimworld or Dwarf Fortress or Evil Genius or Minecraft or - in this case - Oxygen Not Included.

Nearly every base-building game has some kind of progression. You start with the lowest-level stuff, and unlock higher-level stuff over the course of the game. For example, you typically unlock better methods of heating and cooling your building, or better crops, or advanced building materials, or all three.

The question is: how do you unlock them?

There are a few basic unlocking methods, and we can show them by example.

You want to build a fridge/food storage room in Oxygen Not Included. At the beginning of the game, there's nothing like that. So what do you do?

1) Research a fridge.

2) Build your fridge room in a part of the map that's cold.

3) Scout around for cold-creating plants and replant them back at your base.

4) Use the physics of gases to create a carbon dioxide trap, which is considered a sterile environment by the game.

5) Evade the question and micromanage your food production/create pickled foods that can be stored on a shelf.

There is no "right" solution: which tactic you'll take will depend on your goals, your resources, and your world map. This makes for a very flexible, deep game, so it's worth examining these in detail.

1) Point-centric solutions involve spending time and resources on generic "points" to unlock a new method. This is almost always a research desk, often one with multiple tiers. For example, a fridge requires a tier 2 research desk in ONI. This is a very typical approach and pushes the player to make a "high functioning" base that has enough spare effort to build up those points. Unfortunately, this can backfire: once a base is high-functioning enough to spend time on research, you will need to introduce new challenges and complexities to keep the player struggling. Typically this is done through ever-increasing supply chain complexity with ever-increasing manpower demands. All told, this approach focuses on building a base that can function smoothly and efficiently.

2) World-centric solutions involve building facilities in parts of the world that fit your needs. This is often a random biome situation, which means that the player will examine the regions around each new base and figure out what biomes can be exploited. In other situations, this might be non-random biomes - for example, if you build mines at a certain depth in Minecraft, you know you'll get slimes. In some cases it's sort of halfway between the two - for example, it's technically random whether you have an aquifer below you in Dwarf Fortress, but you're told up front and it's extremely common. Anyway, world-centric solutions push the player to expand their base and create satellite facilities, and make rapid transit/cargo systems valuable.

3) Scout-centric solutions involve going out into the world in search of small amounts of specific resources. In terms of gameplay pressures, this is similar to a points-centric approach: is your base running efficiently enough to send people away? A few notable differences: points-centric is predictable and not random at all. Preparing resources for those that will go scouting is often more expensive than feeding the researchers. Monitoring the explorers and clearing their path eats more player attention than letting researchers research. Also, the resources found in the world are typically limited but cheap to deploy, unlike the unlimited but expensive unlocks from a research base. Having both a scout- and points-centric solution to core problems means players can weigh a variety of tradeoffs and make a choice unique to their current base instead of always having a best solution.

4) Physics-centric solutions involve constructing things such that the base generates a solution based on its layout. For example, in ONI, carbon dioxide sinks below oxygen. It's relatively easy to create a carbon dioxide trap by simply laying your base out properly. This is more commonly seen in "dungeon-builder" games, where various monsters can cause various effects and you can level them up or get better monsters based on what neighbors they have. These are typically "high skill" solutions, but it's risky: be careful not to allow them to become the dominant strategy, or advanced players will not need to take any other approaches.

5) Evasion solutions allow the player to simply not take that path by having a build that doesn't require it. You can play almost any base-building game without a fridge if you orient your food chain around not needing one. This allows players to develop radically different kinds of bases, and is a highly recommended option to include.

These five approaches, used in tandem, allow for amazingly deep gameplay that never repeats. When I saw the tech tree in ONI was so sparse, I got a little annoyed... until I realized how diverse the alternate approaches were. I don't think ONI's balance is quite right, but the ideas are all there: competing methods to get the same result, meaning each base has new and unique tradeoffs.

This is especially critical when there are timers involved. If you have infinite time, a sub-par approach will just take a little longer. The timers are necessary to produce stresses, although obviously it's best if they can be tweaked for different kinds of players.

As an example of where I don't think ONI does it quite as well, let's talk about the most brutal timer I've seen in a while: the oxygen in Oxygen Not Included.

Your people breath a lot of oxygen. Huge amounts. The main method of creating oxygen involves burning algae, a substance which seems common when you get started... but as your rate of consumption increases, you'll suddenly find you've run out. This scales with the number of people in your base, obviously, which means as your base expands oxygen becomes more of a pressure.

1) Technology. Since this highlights a smoothly-functioning base, you'd expect this to be a "set up oxygen with your algae, then research a replacement while you can still run smoothly". However, the technological solutions are pretty rough. One involves inefficiently burning a rare resource (slime) to get algae. Another involves burning a limited resource (water) to directly get oxygen. Another involves generating large amounts of poison oxygen, then converting it into regular oxygen. These are all a bit complex and wonky, but that's part of the fun.

2) World-centric: there are slime/algae-rich biomes. Most bases start with one nearby. However, there is no biome which actually generates algae or oxygen, so those locations will get mined out. Technology levels unlock more options, but they feel anemic. There are areas of the map which have oxygen in them, but none have enough oxygen to matter. There are special stones which emit oxygen, but it seems they are never fully contained, so within a few days they have all burned out everywhere in the world.

3) Scout-centric: about the only oxygen-related things you can scout for are slime puffers. These (slowly) cycle poison into slime. Normally, that slime re-emits the poison, forming a permanent cycle. You can painstakingly herd them into farms and use alternate poison sources to create slime, but herding them is extremely laborious and each one doesn't even seem to support a single person's breath after all the conversions are factored in.

4) Physics-centric: because your team can hold their breath and will walk to where there is oxygen to breath, it is possible to save on oxygen generation by only filling the top layer of your base with oxygen, reducing the loss of oxygen through secondary costs such as being absorbed into rock or lost through an airlock. This is, however, marginal. I would love to have a physics-based solution for creating algae, or even directly creating oxygen.

5) Avoiding it: your crew can breath poison, at least in this update. They really don't like to, but they can. Poison sources are extremely easy to find, to the point where avoiding them is a big part of the game. Instead, embrace the filth and you don't even have to worry about it.

I hesitate to offer "solutions" to what I consider to be a weak game element. After all, this weak game element is the core timer for the entire game, and there are a number of interesting routes you can take... it may be that small balance tweaks would be enough to satisfy me. But with that said, let's talk about how I might have chosen to set this challenge up.

In my magical imaginary version of ONI.

1) At higher tech levels, I think we would be able to exchange time, space, work, and condition management to create an alternate algae or oxygen source. For example, what about an "algae box"? Needs irrigation, a dense carbon dioxide atmosphere, and a high temperature. With effort, you can now grow algae - but it takes carefully building your base to do so. How about an even more advanced science for creating oxylite out of massive quantities of hydrogen or natural gas or something?

2) World-centric. I would like a biome that generates oxygen, water, algae, or slime in quantities high enough to live off of. Right now we do have steam geysers, and water can be turned into oxygen, but it requires very advanced tech. We also have slime biomes, but they don't produce slime. Puffers live in them, which can give the illusion of slime production, but no slime is actually being created. Perhaps a coral biome which slowly emits oxygen? Cutting the coral destroys the oxygen-emitting elements, so you just have to live there, or perhaps create a long gas pump.

3) Scout-centric. I like the puffers. I want to be able to tie a rope to them, or maybe stuff them in a sack, so they can be moved into farms more easily. I also think the puffer's rate of poison-eating should depend on the density of the poison in a very big way - if I can get them into dense clouds of poison, I want one puffer to support at least three people's breaths.

4) Physics-centric. I would like physics methods for creating slime, algae, or oxygen. Perhaps something like "boil poison water to get slime" or "pure water flowing through dense natural gas turns into algae" or "plants turn carbon dioxide into oxygen". Not sure why that last one isn't a thing.

5) Avoiding it. Right now the only method for avoiding oxygen consumption is to breathe poison. I can think of three other ideas. A) Make building a base with a low headcount viable. B) Oxygen booths which don't emit oxygen, but can be visited when you need a breath. C) Breathing poison or some not-quite-oxygen mix simply causes their learning to shut off - no skill growth, no research, maybe a stat penalty.

In the end, I like ONI.

I don't think they used this "five approaches" technique on purpose, but it's worth thinking about the best base-building games you've played, and what you enjoyed about them. It's certainly worth expanding the options within your own base-building games: the cost is typically much lower than you think.

Anyway, those are my thoughts. What are yours?

Building From the Inside

Base-building, on my mind again.

Recently, I was playing Fallout 4. One of the expansions gives you access to this massive underground space where you can build a vault using vault modules. There are a lot of weird limitations and missing pieces, but the idea is interesting enough: build a vault yourself!

This is something I am really interested in, since building a vault and building a space base are fundamentally similar. So I set about with gusto!

It's a shallow mechanic, since it's not the focus of the game. But sometimes you can learn the most from stuff that's just hacked together.

Most base building games are from bird's-eye view. You can cleanly and clearly build the base, manage the little ant people as they wander around, and so on. This gives you a lot of visibility, so you can expose the complexity of designing these systems. Which, in turn, means you can increase that complexity and create some serious depth.

Fallout 4 is kind of the opposite. Just like other first-person construction games (like Medieval/Space Engineers, Minecraft, etc), you can't see the whole base. Since you can't see well, the systems have to be simplified.

And so I dismissed the idea.

I was wrong. There is a lot of power in limiting the player.

Free to Fly
Not being able to see very far makes basic layout a huge issue. Verticality becomes a fun challenge and opportunity.

Normally, verticality is poison in a base-building game, almost impossible to track. Most people prefer to build out rather than up, simply because they can still see the whole base when they do. Building vertically obscures the lower floors, and dealing with that is a huge annoyance.

But now the base is already obscured. Being on another floor isn't any more or less obscured than being down a hall. Managed correctly, it's less obscured: rather than a maze of twisty passages, just go upstairs in the sunny atrium and walk ten feet. Suddenly, verticality is a powerful shortcut and grounding feature instead of a serious problem.

Basics Aren't
Infrastructure that was easy from above is very challenging when you can't see it. Radically dumbed-down infrastructure provides just as much grist as more complex infrastructure in a bird's-eye game.

I think this is a place where much better visibility wouldn't hurt. Rather than trying to hide the infrastructure outside of the visible space (exterior piping, buried power cords, etc), I would run it inside. Along the ceiling, the floor. This gives the player the ability to easily track it, makes it obvious how it's serviced, and also introduces some much-needed floor height alterations (IE, running floor piping underneath a raised area breaks up the flatness of the facility).

There's always an urge to introduce complexity, but with this kind of setup the opposite is better: simplicity is king. You don't need to worry about if you have enough air pressure in your vents or if the load on this particular electrical line is too high. Instead, just the fact that they've been piped in is enough.

This is because the players will want to push themselves to create more epic layouts. Bigger rooms, or lots of smaller rooms. How do you provide power, air, heat, water, whatever is needed in spaces too big or small to easily run cables through? Especially if outlets take up set space: can you make a tiny bathroom if you need air, water, and power outlets taking up their required chunks of space?

More complexity can be added by having specific systems require specific supplies. Data cables, pneumatic tubes, fiber optics, high-tension lines, whatever. Just make sure there's a reason to put these better systems in shared areas, so those new cables have to share the space.

You also need to think about how those cables can be interrupted. For example, how does a door work if you're running cables across the wall? Maybe you can move them to the ceiling, but only one type of cable per meter of hall? Rules like this are easy to understand, and the player can simply walk along a cable if they're not sure what's going on.

The key is to start simple and get steadily more dense, since the limits of the visible space are what you're highlighting. Sure, run cables along both walls... but don't expect to have any doors!

Lifestyle
A lot of base-building games feature lifestyles. Like The Sims. These games use time compression to make it very expensive to do anything. Going to the bathroom takes hours. This isn't useful for a first-person base-building game, since A) you won't see it happen and B) the punishment for having to walk is having to walk.

This was a sticking point in my thoughts until I made myself a personal bedroom in Fallout 4 and tried to sleep in it.

I could clearly hear the slot machines from one level down.

Now to me, the player, that's pretty insignificant. There's no impact on my ability to choose "sleep" from the popup menu.

But for lifestyle... why not have that matter?

Rather than having the residents walk around and have that eat up their schedule, just look at where they live, where they work, and where they play. Calculate various good and bad factors based on either radius or simplified LOS. Congrats, they now live in a place and can wax poetic about it.

While things might statistically be good, bad, or ugly, I recommend having only a few things that are clearly good or bad. Make most of them just notable. This is because making notable things will give the base personality, while making them clearly good or bad will simply make the player optimize the same way as everyone else.

For example, you have an apartment above the main air filter. It goes "RRRRHMMRMRMRMMMMMMM" all night. You might want to lump this into a generic "noise is bad" set, but I think the people above it should grow to accept it. Like how people grow to be at peace with the sounds of traffic whooshing by, or hilariously loud rain on a tin roof. It's a marker of home, and if people feel at home in your base, you've built a home. That's pretty powerful.

It's much easier to show in first person than third person, because you'll experience all the things they experience. If you go there, you'll hear the RRRRRHMRMRHRRMRMMMMM. And they'll talk about it amongst themselves, so you hear about it as well as hearing it directly.

See-Through
A huge problem with building in first person is when you run up against things you can't see. For example, you can't extend that hallway because there's a rock pillar in the way, or because you have a perpendicular hallway blocking it, or whatever.

In Fallout 4, the standard is: you have to rip away the wall to build out, so you'll be able to see whatever is that way. I don't think that's good enough: there's no reason not to show a faint hologram of the rest of the base. That would allow you to build out without manually ripping things up and then putting them back down.

The hologram could even be limited to showing only in a patch near your head as you approach a wall in build mode. It wouldn't be distracting at other times.

Keeping the base in mind when building is a big deal, especially since the default method (a map) is 2D and suffers hugely from the verticality you're putting in.

Expensive People
One big issue is that people are expensive.

In bird's-eye games, your residents are pretty small. Whether 2D or 3D, they are too tiny to need much detail. But in first person, your residents can fill the screen, and they have to feel like they have personalities.

This means that you will need a pretty robust, high-quality character system that makes your residents feel very distinct and personable. This is a price we're just going to have to accept: for a base to feel lived-in, it needs to be lived in.

The upside of that is simple: you can make your base feel real and lived-in. This is something that's very hard for other games to do.

This became very clear when playing Fallout 4. In comparison to games like Space Engineers or Minecraft, the vault felt inhabited because people were wandering around doing things. Sure, the stuff they were doing didn't make a lot of sense, but it was lively.

Games like Dwarf Fortress or Rimworld feature lively characters, but because they're indistinct and small, it takes a lot of effort to feel that they are alive and personable.

While this is a cost we are forced to eat, the payoff is arguably the best reason to make this kind of game in the first place!

Other Thoughts
There are a lot of things that matter a lot more in first-person games. Decorations. Lighting. Cleanliness. Clothes.

Variation is critical, but don't limit it to the obvious things like lights and wall coverings and chairs. The shape of the interior is also critical, and you want to have that vary as well, so the player wants to strive to build more interesting, complex rooms and layouts.

For example, having large, open rooms is fun, but if the floor is flat, it'll feel really awkward. You can provide tools to break the space up: stairs intended to be placed near the center of such rooms, raised flooring, large decorations like trees or verandas. Also, walls don't have to be completely solid. Not just windows vs doors, but also open-plan halfwalls, supports, etc.

These are enough to give the player the chance to make something interesting, but it may also be worthwhile to incentivize it. Raised floors give social bonuses to those on top, and you can run cables underneath them. Columns can have cables run inside them. Open-plan halfwalls are a free standing table to hang out at.

Simply making the NPCs hang out in ways that highlight the player's constructive choices seems like it'd be incredibly powerful feedback. Even if there's no statistical benefit to a raised floor, if the NPCs gather to watch someone standing on top of it, it automatically becomes a stage.

Sim Savings
Another big advantage of this kind of base is that we don't have to simulate anything in real time. Because the player isn't watching the whole base, you can just stuff residents in wherever the player goes. There will always be NPCs hanging out or working or sleeping or whatever. This is a great way to A) save on expensive simulations and B) make the base feel densely populated even if there's only a few NPCs.

We can use these sim shortcuts to allow for other kinds of gameplay. Since we're not actually monitoring where people are at all times, we can simply track where they tend to be. In doing this, we can easily determine who they're likely to have relationships with. We can throw together convincing relationship growth by making up a situation that happened offscreen at a specific place and having both sides reference it. "Oh, we met at the pool!"

This can even be turned into sidequests or governing missions.

These people hang out in the atrium after work, when they're exhausted. But these people don't have those jobs and come to the atrium to play. So now you, the governor, must determine the rules: is the atrium intended as a party ground, or a quiet park?

... anyway, those are some thoughts I have on first person base building games. 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.

Programmable NPCs

I love programming games. In theory.

In practice, programming games are too esoteric, too separated from anything that feels meaty and fun. In the real world, the "programming" games I love run without any programming at all, and I wedge programming in for extra fun. Kerbal, Space Engineers, and so on: all work fine with no complex staging or programming.

I've been analyzing the concept. Thinking a lot. I think what we need is a way to allow the player to program easily and freely, but more than that, to smoothly slide in and out of non-programming, full-programming, and simple scripting elements.

What do I mean?

Imagine a game like Minecraft or Medieval Engineers, except that you have an unlimited number of NPCs to help you out. The idea is that they can help you build, operate, and maintain your world. You can create villages and so on and so forth. But the implementation is more open-ended: these aren't people with set jobs. They're state machines.

There are a few ways to let players program NPCs. Since AI is complex and depends on wrangling thousands of inputs, most of those methods revolve around picking big chunks of functionality. This NPC is a guard. This NPC is a farmer. This NPC lives here. This NPC lives there.

Let's turn that around a bit. The big difficulty is the huge number of inputs. NPCs need to analyze the terrain, their resources, threats and opportunities, their tiered goals, pre-established schedules, the weather, their equipment, alert/damage states... programming for all these things is why AI is normally supplied by the dev rather than given to the player to fuss with.

But what if we stop thinking of an NPC as an independent agent? What if the NPC is considered as part of the player, augmenting the player's capabilities?

Overlord was a good example of this, allowing you to point and send off your minions in a very easy, fluid way. However, those NPCs are a bit too simplistic and the gameplay was not constructive. Is it possible to do something like this, but with radically more complex, programmable NPCs?

One challenge is how the player interacts with the world. For example, in Minecraft you can build a house, it's very constructive. But building the house is very low-constraint: you rapidly plonk down voxels in any configuration you want, and you can even have a physically impossible floating house without difficulty. Having assistants wouldn't help in this situation, because there's not really any pattern for the NPCs to work on. They can't tell what you intend to build based on what you have built so far, so they can't help.

We could exchange the player's actions and require NPCs to execute them. For example, the player just puts down virtual blueprint voxels and the NPCs have to do the work. But this isn't any better at making complex, programmable NPCs, it just makes the game slower and the player unable to directly affect the world, both of which are bad.

Instead, what if we designed our creative systems specifically to have patterns? Then, when the player starts to create, the NPCs would be able to predict what the player is doing and build as well.

For example, if you build a road, you probably want to build another segment of road one road-segment along the path.

The road example is an easy, clear example. Let's say you dress an NPC up in road-worker costume and link them to you. Now they follow you and read your activities as their input. When you build a section of road, they read your vector and the position of the road, and move one unit further in that direction and build another segment.

Now you have augmented your power. When you build a road, two road segments get built.

You can extend this. What if you link another 50 road workers to yourself? Well... they still only try to build one block along, so you still only have two blocks of road per one block you build.

One way to fix this is to have them move N blocks ahead instead of 1, and then specify each individually. However, a more interesting option is to simply daisy-chain. The NPC's activities are also readable as inputs, so you make the second worker link to the first worker instead of you. And the third worker links to the second, and so on. Now, when you build a road segment, each worker moves along in a chain of single steps, and you can break the chain by simply unlinking the Nth worker.

This works great, especially since there's an obvious physical representation of who is linked to who: a line. The workers form a line. All linked to you, they cluster in your wake as a chaotic mishmash. But daisy-chained, they stretch behind you like a conga line.

Of course, this is really wasteful. In reality you only need one worker, as long as you're patient.

See, like any Turing machine, our workers have an input stack - a "tape" to read. When we linked them to us, we simply put ourselves in the first spot on that tape. We can add themselves as additional entries on the tape, and tweak the road-builder state to move to the next input on the tape.

This means that we build a road segment. This triggers them to build a road segment and also move their input tape, making themselves their own input. Since they just built a road, this triggers them to build a road and move their input tape... it's not an infinite loop because the tape eventually wraps back around to using us as an input.

This works, but the worker will have to complete each segment before moving on to the next, which might be too slow for your taste. It's already a relatively interesting space, with tradeoffs built right in. We're touching on the concept of parallel processing, Turing machines, IO...

Roads are an easy example, easy to use as a demonstration. But they are fundamentally pretty straightforward. While you might like a wider road, or a road that curves, it's pretty "flat" and there's no real constraints on it.

So let's talk about walls.

Rather than the physics-free voxel walls of Minecraft, what if our walls have physical presence, and roofing is actually a challenge? Sort of like Medieval Engineers?

If we we want to build a three-high wall, it's not just plonk-plonk-plonk. We need to have the resources lying around nearby. We need to build a scaffold so we can reach the upper wall areas. We need to lift the resources up the scaffold. The player can do these steps on their own, manually, but it makes sense to use NPCs to help.

For example, you build a wall, and then NPCs are set up to build a scaffold, lift resources up the scaffold, build a wall, build another scaffold, lift resources... you can do this with daisy-chaining, input cycling, or a combination of the two.

To use only one worker, you would equip the worker with gear/clothes representing scaffold-building, wall-building, and resource-toting. You would make yourself the first notch in his input tape, then himself. The order of the states is determined by the order you equip the gear, so the last one on would be the scaffold-building equipment - say, a hat. He sees you build a wall, builds a scaffold - then moves the input tape (to target himself) and switches to the next state - hauling. He saw himself build a scaffold, so he now hauls materials and switches to the next state - wall-building. He saw himself haul materials, so he builds a wall, then loops back to the first state - scaffold-building. He saw himself build a wall, so he builds a scaffold, etc, etc.

This kind of dependency simply makes the world more annoying rather than more complex, but it's a good example of the concept. In reality, the constraints I would want to introduce would be more than mindless busywork.

For example, if you want to build a 20m-high wall, the wall material will tip over under its own weight. So you have to shore it up. You could simply build it thicker, but a clever designer will instead build it banded - some areas have large windows to lighten the wall, and others have flying buttresses and thicker columns. How about supporting the tall wall with scaffolding, knowing it will fall over when the scaffolding is removed... and then putting in crossbeams before removing the scaffolding?

Multiphase and open-pattern construction are powerful features. Not only do they make programming the NPCs more interesting, they also make the world more interesting to inhabit. A skilled player will come up with interesting ways to build taller, wider, deeper, more interesting structures. Another skilled player will come up with a way to build hundreds of miles of structure, although perhaps not as impressive per meter. Yet another player will build something that isn't technically challenging, but feels real and inhabited because the NPCs are programmed to live life convincingly instead of build walls convincingly.

I've left out some details. For example, location flags/vectors are pretty important, and I didn't mention them at all. I didn't talk about how to build or edit gear to perfectly suit your needs. I didn't talk about the idea of maybe building ships, or setting it in space. I didn't talk about harvesting and transporting materials.

But I think I talked about enough. What do you think?

I think the concreteness of allowing the player to physically build things makes the game easy to get into. Combined with easy basic state editing, the player can ease into the idea of telling a wall builder or stack of road workers to follow along and help them. The more complex powers of NPCs with multiple states, state tweaking, recursive NPCs - those can be left for the people who actually want to do them.

Moreover, this makes for a truly excellent semi-shared world. Import a wall crew from your friend Alice, she's programmed them to build that 80m-high megawall wherever you plant a blue flag. Import a city from your buddy Barry. Import a ship - no, a whole shipping lane - from your half-cousin Chip. It can be done automatically, manually, or half-automatically (for example, an in-world "for hire" bulletin board).

That's what I envision.