Topological Construction Play With Scenarios

I love building things in games. Whether it's cities, planets, space ships, or nanomachines, I just love putting things together and letting them do their work.

But this kind of play requires careful construction. A lot of games rely on a "spreadsheet" approach, where the modules just add to numbers on a spreadsheet. This is almost universal on mobile, and is sadly common in indie games on every platform.

You want to build a city? Add a fishery for +5 food! A space ship? Add an arc reactor for +5 energy!

The problem is that spreadsheet play is fundamentally passive. The thing I'm building doesn't do anything, it just drifts along as a pile of numbers.

The things that bring a construction to life are the challenges it faces.

If I build a city, how does it fare in winter? If I build a castle, how does it fare against siege? If I build a starship, how does it fare during re-entry?

It's possible to push a spreadsheet to respond to challenges, but I prefer having more direct control.

I prefer topological construction. That is, where I put things matters.

The details of this matter. How do you make placing things relative to other things matter?

Well, there's three pieces: the mechanic, the load, and the scenario modules.

The mechanic is how you make the location matter. The key to the mechanic is that is has to be a local effect with consequences. It shouldn't be pass-fail: the whole point is to create a soft, widely interlocking mechanic that the player can adjust in a lot of ways.

For example, in SimCity, the main mechanic is traffic. Traffic produces pollution, and if you fall short, it also produces economic slowdown, unhappiness, and road failure (in that overtaxing a road results in a traffic jam).

In a space ship game, the mechanic might be power. Power transfer produces lot of heat and nearby elements may degrade, and the laser will fire slowly and weakly if you fall short... Or perhaps the mechanic could be damage, coming in from an outside vector, needing to be blocked and dispersed...

In a boat or plane game, the mechanic might be water or airflow - how it exerts pressure at various speeds.

As you can see, not all mechanics are internal-only. Many of them are about how your system interacts with the wider world. And, of course, most construction games have many mechanics, some larger, some smaller: SimCity has traffic as a mechanic, but also pollution, economics, happiness, weather, water...

The load is how the mechanic expresses itself in local space, and what modules the player can use to handle that.

For example, SimCity has roads for cars... and also road/car variants like subways, buses, etc. The player is given freedom to optimize: put in a subway from the residential district to the commercial district, and most of that kind of traffic will go through there instead of through the more limited surface roads, freeing those up for shipping...

In a space ship game, it might be power cables, capacitors, etc. Or, if damage is the mechanic, it might be armor, magnetic screens, shock absorbers, air gaps, shield projectors... the idea is to make it something local, so shipwide shield generators do not count.

In a boat or plane game, it'd obviously be the hull itself, both hull plates and elements that happen to be exposed.

Scenario modules are elements you install specifically to create or respond to scenarios. Sometimes these are not specifically spawned by devices inside the creation, but even then the creation will be arranged to respond to a specific scenario and you must allow that scenario to be fired.

In SimCity, houses and office buildings create an interlocked scenario where traffic goes from one to the other, then the reverse. In exchange, you get money. There are constraints to prevent you from crowding houses and offices together (noise pollution, etc) so you're forced to connect them via long traffic routes.

Of course, SimCity has dozens of traffic scenarios and the modules to affect them. Shopping centers, airports, external highways for import/export, farms, floods, etc. And SimCity also has scenarios that aren't traffic-related, such as whether to use green energy or high-pollution coal energy or a nuclear reactor.

Allowing the player to choose which scenarios to accept in which locations gives the player a lot of room to explore and express themselves.

In a space game, scenario modules would be things like engines, lasers, etc. These are installed with the understanding that they will be useful in the scenarios of the world at large, and that those scenarios are the ones this ship will usually be in. Of course, they create load by being used, but they also take up space and perhaps have a secondary load even when not in use...

In a boat or plane game, one scenario module set would be engines, with the idea that different amounts of different engines would propel you at different speeds and different heights. Are you building a submarine? A high-altitude spaceplane? Which engines you choose will determine what kinds of scenarios you can face, so those engines are a scenario module.

The point is to get the player to select what scenario challenges they want to face, and allow them to create something that deals with those challenges. The idea is almost never to deal with a single challenge, but is instead to deal with a parade of challenges, often tightly themed.

An example of this would be Dwarf Fortress, where there are four or five categories of challenge: invasions, mood swings, the elements, supplies, etc. The player builds their fortress with these considerations in mind, depending on where they built. Your fortress has a death zone for attacking invaders - but make sure you know what kind of invaders you'll be facing. You have a jail for depressed or berserk folk. You have dug deep to find water, and now need to pipe it up into the living quarters.

You can see how each of these challenges can be abstracted to traffic patterns with side effects. Here's the pattern for incoming enemies. Here's the pattern for water. Here's the pattern for farmers going to work. Here's the pattern for quickly isolating a self-destructing inhabitant. Here's how they interact - the farmers walk right across the incoming enemy lane, that seems dangerous...

Well, it's the same thing no matter what the theme of the game.

My space ship should face the challenges I want it to face, and that will test the setup I created.

Not a spreadsheet, but a living entity that responds and changes on a local level.

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?

Adaptive Modules in Construction Games

One thing I like in construction games is being able to create different modes within a creation. For example, a car that can turn into a jet, or a space ship that can switch between science mode and warp speed mode.

Very few games reward this kind of thinking due to one big constraint: single-purpose, static modules.

Non-adaptive modules.

For example, if I want a space ship that can switch between science and warp speed mode, there has to be some advantage to switching rather than just being in both modes at the same time.

But the modules for science and warping are always the same size, always the same configuration, always require the same amount of power, etc, etc. The only "switching" we'll likely do is simply turning one or the other off to save power, rather than something that creates a fun visual or play impact like sliding parts around, expanding or shifting, etc.

There are a few ways to create the opportunity for players to build adaptive designs, and they all boil down to adaptive modules. Here's some types.


1) Folding modules.

If our science and warp elements can both fold down to take up less space, then we can have them share their expanding zone. To allow for more interesting results, we'll want to allow for at least some adaptiveness in the folding. Perhaps science modules come in a variety of shapes and expansion zones, while warp engines can expand arbitrary amounts, allowing us to pick and choose exactly how much space they share, when.

This can get even more complex with things like power capacitors and tanks being extended when full, etc.

The folding can also be complexly related to the flow of ship resources. Perhaps the science devices unfold and create a new control room people can walk into, meaning it has to be butted up to the pressurized section. Or maybe it has in/out fluid flow, and the position of the outlets changes as it inflates...


2) Expensive timing elements.

If our science and warp elements take quite a bit of juice, simply turning them off and on is important. But to make things feel meaty, simply turning things on and off won't work. We need timing elements.

Perhaps the computers take a little while to boot. The engines need to spool up. The science sensors require a massive influx of water to extend.

To make this really meaty, give us the option to accelerate the timing with outside resources. Computers boot faster if other computers lend it processing power. Engines spool up faster if you use a flywheel assist. Science sensors expand faster if you send them water faster.

Note that these all start up fine with no assist, it's a matter of time savings. That way, even newbies can create this stuff, no need to wire it up in a complex way to just get it working at a baseline level.


3) Incompatibilities.

If modules are incompatible, then turning them on and off is an important technique. To make this especially meaty, the incompatibility should be manageable in some way if you make your ship clever enough.

For example, the warp drive spits out a ton of radiation noise when active, rendering science sensors useless. Computers vibrate when in use, radically lowering the performance of nearby modules. Science sensors require 180hz power, while warp drives require 30hz power.

These incompatibilities mean you can't simply throw more power at your systems to have them all on at the same time. But you can design cleverly. Have an extending strut move the engine away if you need science sensors on at the same time. Have the computers on their own module off to the side of the ship. This gives a reason to create fun, unusual designs.


4) Service requirements.

Requiring human access can make your ships very interesting to design. Why is the engine on a piston rather than permanently floating way out behind the ship? Because that brings it in line with the rigging, so spacewalkers can get to it quickly and easily for maintenance purposes.

This does require you to put in some adaptive human access options. Extending ladders, cables, etc. But those also look great, so they're not a bad call!


5) Stacked modules.

It may seem obvious that every identical module should have identical requirements, but for the sake of making things meaty, the opposite is true.

If modules are stacked on top of each other in a specific way, they should have different performance stats and require subtly different resources. IE, every science sensor arranged in an exact row performs better than the last, but requires power at a higher hz, or requires more cooling.

This will allow players to stack or destack modules to fit their personal vision and constraints. One player might have five stacked science sensors and a big module for providing them with their complex support needs, while another player might have ten unstacked science sensors... requiring more people and more space, but without the complexity.


6) Careful design of multipurpose baseline elements.

Obviously there are baseline elements constraining your operational modules. The most obvious example is electricity, used in nearly every construction game. Other examples might be fluid, food, computation, etc.

Designing these carefully is the key. You want them to inspire specific layouts all on their own.

The easiest way to do that is to make categories of element, then allow a multipurpose system to handle anything within that category. This allows for the same infrastructure to serve multiple roles, while also creating bottlenecks. For example, pipes can handle water, fuel, oil, air, exhaust - anything that flows. Players can create huge numbers of dedicated pipes or fewer pipes that take up less space if they can figure out how to switch the load on the fly...

The basic approach I use is designed to make these baseline elements inspire interesting configurations.

a) Flow types: one type of module moves the generic resource around, one type collects it in a spot (often adaptively sized), one type pushes or pulls it, one type transforms or creates it. For example, pipes, tanks, pumps, intakes. Or network cables, tape archives, sensors, and computers.

This four-fold approach gives me a flexible way to drive different layouts by simply changing which elements take up space in what kinds of ways, or require which secondary resources to run. For example, there's a huge difference between tanks that can expand and tanks that can't. Similarly, there's a huge difference between pipes that take up one voxel space per pipe, as opposed to network cables, where you can bundle any number of them along the same one-voxel channel.

b) Reward both centralization and decentralization. There's beauty both in duplication and in centralization. People should be able to find a cool way to implement "a hundred pipes" approach, but also be able to implement a cool "one big pipe" approach.

In general, one big pipe is what players will tend to rely on if they're just piping lots of one resource. If every module requires water, there's going to be one big water pipe. But as the resources get more varied, the player will tend to go for multiple pipes. Whether this is different temperatures of water, or different fluids, creating converters or mode switching is overhead some players do not relish.

Having resources that vary inside themselves can be very powerful, especially if they can change state and be moved in another way.

For example, if the engine needs fuel... well, maybe each stacked engine performs better, but prefers fuel injected at a hotter temperature. Therefore, the fuel subresource varies on another axis (temperature), making wrangling it more complex without requiring any extra content. Clever players might supherheat the fuel into gas for fast transit, or even freeze it into wax for long-term storage.

Either way, this complexity should arise only as the player embraces it, since this complexity can create a difficulty cliff.

c) Allow suboptimal setups. Allowing the player to fall short while still having a decent result is critical, both for players that aren't great at construction and for players that are trying to be very clever.

An example of this might be if the science sensors require computation to run. If the player doesn't have enough, the science sensors continue to function, but at a reduced rate. Even at zero computation, the science sensors should still function a bit.

You can make this more complex by creating pseudogenerics. For example, the science sensors require quantum computing. Any kind of computer can generate quantum computing, but at less than half speed if they aren't quantum computers. This allows players to use somewhat unsuitable setups in a fun way.

Similarly, you might have pumps specialized in fluids... but they can pump gases a bit. Or visa-versa.

Combining these elements means the players have a ton of flexibility. It also makes for the opportunity for them to add complexity by creating switching systems to use the proper pumps/computers when required, while reusing the same generic flow containers (pipes/wires).

Allowing for extremely high-performance single-use elements is fun as well, but make sure they have other constraints. IE, the fuel-only pump requires tremendous cooling...



... anyway, them's my thoughts on the matter.

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.

Constructive Difficulty

As you know, I like construction games. I like building things.

But nearly all construction games make construction too easy!

I don't think the games are too easy. I think the construction is too easy. I don't need goblins attacking in waves or plague or economic challenges. I'm here for the building! Give me a construction challenge!

A long time ago, I fell in love with Medieval Engineers, because construction was a real challenge. At the time, there was no inventory: if you needed ten stone to build a wall, you had to get the ten stone within a few meters of the wall. If you were building a tower, you had to build a scaffold first, so you'd have a place for stone vertically close enough to the wall. In turn, the mechanical elements - carts and pulleys and stuff - were actually useful, because you didn't want to lug those stones up yourself, one by one!

In short order they added a magic inventory. Also, they made the buildings more structurally forgiving, because they decided to focus on warfare, and the idea was to see how well your building could survive bombardment instead of if your building could stand at all.

This ruined the game for me.

The problem is that Medieval Engineers is actually more about siege combat than anything else. With that focus, simplifying the construction and focusing on how the buildings survive sieges makes sense. It allows players to get to the meat - the sieges - faster and more robustly.

Of course, I don't give a single crap about sieges, so to me the game is now pointless. But I can't really blame the game devs for not having the same priorities as me.

I want to build. I want to have to figure out how to make a three-story building and use buttresses to keep it from falling over. I want to see how high I can build a tower, and what clever things I can do with internal supports to eke out a few more stories. I want to build a castle on a cliff and have to figure out how to wire it into the cliff so it doesn't go sliding down the mountain. These are the challenges I like.

This isn't limited to medieval stuff.

When I build space ships, I want to struggle to get them to work at all, so that when I make even small, functional rockets it feels great. Kerbal used to be quite good at this. However, as Kerbal came closer to release, they carefully dumbed down all the physics elements. It's now extremely difficult to get a rocket to fall apart: everything auto-welds and the forces have been much reduced. The game is much more focused on simple payload/fuel calculations, which isn't nearly as interesting to me.

Starship Corporation is a lot more my style, with intricate construction and extremely interesting testing phases. However, the game's difficulty doesn't revolve around engineering challenges, but around contractual obligations and research constraints. Once you understand the complex, nitpicky nature of things like power and oxygen, you can engineer a lot of interesting ships... except the game doesn't give you any additional parts or hulls until you've spent hours and hours and hours doing absolutely nothing. Again, the challenge isn't related to the construction, the challenge is based around some external measure of fitness that can't really be turned off.

There will always be some external measure of fitness, some external gating or rating system. Otherwise the game would be completely freeform. That wouldn't necessarily be bad, but it would fail to engage a lot of players. So the external ratings continue.

But these external ratings could be tied to the actual construction of stuff, instead of to how well you do things outside of construction, such as stabbing orcs or balancing a corporate checkbook.

A good example of this would be a skating game. The game is all about doing tricks and stunts. You earn scores based on your tricksiestuntness, but the scores are largely open ended.

The scoring is usually weighted to prefer long combos - meaning that you typically want to string tricks together rather than go for one ultimate mega-trick. This shapes the way you do tricks, but it's still fundamentally about your own stuntwork and allows for plenty of personal self-expression.

Alternate ratings systems - such as bonus points for being higher off the ground or moving at faster speeds - would result in different priorities for our tricks. Moreover, these would typically be just as easy to implement. It would be trivial to make it a toggle: join one team and get rated based on chained tricks. Another team, rated on speed. Another team, rated on height over the ground. Now the player has a ton of freedom to shape their own external ratings system to match their own stunt construction preference.

I want building something to feel the same way. I want my construction to feel like a neat trick chain in a skating game. Something I personally did, with my personal skill and priorities and artistry.

And that means it has to be hard to do, but also with enough slack that I can do a lot of different things for any reason I feel like.

Can that exist as a game people want to play?

I dunno.

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?

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.

Good Bad Game Design Pt 2

Today, I'd like to talk about construction games. But I do need to revisit the last essay on RPGs, because that has direct bearing.

I discussed good bad RPGs. Basically, open-world RPGs are often considered "badly designed" - poor characters, weird pacing, 'dull' mechanics. However, judging them by more linear RPG standards is a mistake. Open world games have different specialties and their best kinds of play are different from what we have grown used to. You can't judge them by linear standards, and liking one genre doesn't mean you'll like the other.

One of the biggest features of a linear RPG is the main quest. It's right there in the name of the genre: "linear" RPG. So you have a central rail, a quest that the whole game is hung from. This affects everything about the linear RPG: how you fight, how you get and spend resources, how you level up, who you can interact with, what you can do. With a strong core, you can create a wonderful game.

In an open-world game, the main quest is typically something you do when you get bored of goofing off.

Instead, we choose our own path. There are many tiny quests scattered around the world, and we can pick them up whenever we want. Some of them might be multi-part and pretty epic, but in general they are smaller things. Moreover, the fundamental nature of progression in the game world allows us to improve along a path of our choosing even if we don't do any of those side quests. Combined, this gives us a huge amount of freedom to play as we like.

The slack built into that kind of design also allows us to easily include mods. Since there is no core quest constraining us, it doesn't matter if we include a mod that turns all the NPCs into zombies and adds a giant volcano right where you normally start the game. Everything still "works fine".

We could polish this! We could make open world games with that in mind from the start. An environment to carve a path through, rather than a train ride to enjoy.

...

This is exactly the same as construction games.

In the past, construction games were mostly linear. You had levels and challenges and you built to achieve those goals. There were some games that were more open, such as Sim City, but there was no content or systems in place to allow the player to truly forge their own path. The kinds of things you could do were quite limited, even if you had freedom to do anything the game could allow.

The ur-example of a linear construction game is The Incredible Machine. If linear vs open world is a spectrum, that's pretty far to the 'linear' side.

As time went on, we became better at allowing for any kind of construction.

However, we still aren't very good at it. Our "open construction" games are a lot like the early Final Fantasy games. FF6, FF7 - these allowed you to go a wide variety of places, do a lot of things. But they aren't truly "open world", because the structure doesn't reward you carving your own path.

Many other games are more truly open world. Sure, recent games like Fallout 3, Skyrim, etc. But also archaic games like Wasteland, Fallout 1, etc. The difference is not technology, it's design.

These games are structured to reward doing things however you want. The progression system is open enough that you can progress in any direction. The world is designed to offer quest fragments to you no matter where you wander. The world is structured "lumpily", so you can switch between different gameplay experiences by simply moving around - wandering the wilds, delving dungeons, or talking in towns. The player chooses which kinds of things they want to do when, and how they want to do them.

Although FF6 is a fantastic game, it isn't open like that. There is momentum built into the game, both in terms of how your stats progress and how the world quests progress. Although you can "go anywhere", there is no contiguous reward chain for going wherever you want, and there's not really much variety in the kinds of approaches you can take.

Anyway, that's where we are with open construction games.

Games like Minecraft are open construction games in the same way that FF6 is an open world RPG. You can go anywhere, build anything, but the universe isn't configured to reward you for it. Normally, the community is responsible for rewarding you for building things. That's a different topic for another day, but the point is that we can design the game itself to shoulder some of that responsibility.

Space Engineers is a bit more open than Minecraft, largely because it has more construction pressures that you can choose to optionally enable. You can choose exactly how much inventory space should be multiplied by. Whether guns need ammo. Whether power is unlimited. Whether you have to weld blocks, and how fast. Whether engines damage nearby blocks. Whether blocks can be damaged at all. Whether stations can be shaken free. Whether there are enemies, and how many, how often, how close. How safe the world is from natural catastrophes.

In addition to those environmental factors, the universe also allows you to tackle specific engineering challenges as you see fit, both large and small. Pressurized environments? Renewable energy? Docking allowances? Interior defenses? Cryo chambers? Medical bays - wired or unwired? Turrets? Mining? Refining? Natural gravity? Planets? Cars? Tools allowed or banned? Jetpacks allowed or banned? All of these can be tackled in any combination.

The way construction and use can be decoupled offer additional challenges. You can build something in creative, but intend it to be used in survival. Or perhaps it was planned in creative, and you use a blueprint to slowly manufacture it in survival. Or maybe it was created in survival right from the start, painstakingly assembled block by block. The resulting ship is just a ship, but the exact method of its design and construction radically changes the experience.

There is also room for your own personal ideas - recreating a popular starship, or making a starship that's actually a challenging adventure map, or trying to make a personal ship that suits a fictional character you created. A planetary base, a floating chair, and office building - things that make no sense in the context of the game, but make sense to the players.

The freedom to approach your construction in such a wide variety of ways, with such a wide variety of goals and such a wide variety of optional challenges is very "open".

Add in mods, and it all extends even further.

...

Space Engineers is a bad construction game. Compared even to something like Minecraft, it is needlessly complex without adding much of value. But those judgments don't apply very well, because Space Engineers is not a survival crafting game, nor is it a linear construction puzzle game.

Space Engineers has a survival crafting element in it, but only as an optional challenge. There is power in tackling that challenge - but the challenge is not a lump sum. You can challenge it piecemeal - create a mining ship in creative, build a refinery in survival, change the inventory rules, alter the assembler speed multiple, switch back into creative...

Space Engineers isn't structured "perfectly". I don't think it pushes things anywhere near far enough, and the bugs inherent to its multiplayer wall off at least a dozen kinds of play. But you can see hints of how things could go: a construction game where you tackle challenges with a huge amount of freedom.

One thing Space Engineers doesn't have that an open-world RPG does have is continuity. It's not easy to "chain" your constructions, so there's not much sense of history or progress between builds. I would like to see a game where designs were "chained". You build a mining vessel, and then there's some kind of reward or flow to building a refinery base that interfaces with it. You build a frigate and then there's some kind of flow or reward for building a fighter or a carrier or something that travels with it.

Space Engineers cannot do this because they have more technical debt than any other game I've ever seen, and are too creaky to implement something like that. But it's certainly possible.

Anyway, I originally had a lot more to say. I wanted to talk about Kerbal, and Dragon's Dogma, and some theoretical game designs, and adding human elements... but this is the fourth time I've written this essay, so I had better stop.

Hope you found it interesting!

Medieval Misstep

A while back I tried to write about Medieval Engineers, and I don't think I quite managed it. I put it off for later.

Well, there is no later, they just ruined it. So let's talk about what was.

Medieval Engineers had no inventory system.

A construction game with no inventory system!

It felt like a good match. The medieval setting combines well with every component having a physical presence. The weight of all the stone and lumber exists in the real world, and it felt real, it felt right. Building a house requires a houseload of lumber!

You would have to hew the lumber, then put it in a cart, then drag the cart - perhaps along a road. Then unload the lumber. It was a chore, but one that felt real, and could probably have been mitigated using NPC workers (which already exist).

Moreover, staging the construction became a major, interesting challenge. Those logs and stones have to be within a few meters of the thing you're building. So if you're building a five-story-high stone wall, you need to create a scaffold, haul the stones up, and put them near the next floor.

It really felt like medieval engineering. It was a hint of a powerful idea that could have been absolutely unique.

Well, I don't know if people complained or what, but they removed that idea. Now you have an inventory.

Even at its smallest, in the demo, it shows you being able to carry around 20 sledgehammers. So, yeah, stuff your pockets full of boulders and logs, who needs staging? Who needs carts? Who needs cranes or roads or quarries?

...

In any engineering game, the question is: what are you engineering around? What challenges are you trying to solve?

For two weeks, Medieval Engineers had a new challenge. One I've never seen before. You were trying to engineer around your own engineering. It was a wonderful seed of an idea, and it felt so promising, matched the setting so well.

But it is important to be generic. If you're unique, some players might complain that you're not exactly like the last game they played, and you wouldn't want that. It's got to be exactly the same, down to the exact flat-slot inventory model.

Unbounded Construction: An Emerging Genre

The genre is outpacing the fore-runners.

Space Engineers, Kerbal, Medieval Engineers, Minecraft, and many similar games have started to create a pair of new genres. We're going to ignore the "survival crafting" genre, and instead focus on the "unbounded construction" genre.

Players have always wanted to build anything they please, and devs have always struggled to let them. But it requires three things, and only in the past few years have all three become widely available. The raw power to render and simulate large constructions. The fast, fluid UI to allow players to quickly build, refine, and import their constructions. The easy, integrated sharing of constructions.

These three recently came together to form a new genre.

It's becoming clear that the fore-runners of the genre aren't what the genre will look like in the long run. Let's see if we can talk about what the genre might become.

(Of course, maybe I'm the only one seeing this genre, but let's look at it anyway.)

The genre's name gives away what I consider the core concern: unbounded construction. But we've always tried to create unbounded construction. What makes something like Minecraft different from something like Sim City or Civilization?

Well, when I say "unbounded", I mean unbounded in the logical sense, not the logistical sense. I don't simply mean you have a limitless plain to plunk down physical blocks. I mean that you can invent your own purposes, build to meet your own goals and tell your own stories. Your visions can be pushed into the game, and the game can inform your vision.

In Sim City, you could build a big midwestern city. Just that. You couldn't build anything else you wanted. If you want to build a replica of ancient Greece, you can't: the buildings are clearly modern midwestern American. You want to make a Martian city? No dice. The pieces just don't match up.

But if you make the pieces small enough and the canvas large enough, you can get a lot closer to your vision. You can pack more customizable details into more space.

In Minecraft, you can build a replica of ancient Greece. Sure, the pillars are weird and square, but you can get pretty close. In Space Engineers, you can build a Martian city. Sure, the cargo pods look different than you would like, but you can get pretty close.

Each individual piece might not match perfectly, but you can choose where to place which pieces, and the result is pretty good. It's the Lego approach.

Moreover, modding is a lot more powerful at this scale. If you want to simulate ancient Greece in Sim City, you have to find an ancient Greek buildings pack, which is awfully specific. But in Minecraft, you can scrounge together a variety of generic medieval parts and come out with a pretty convincing Greece. Similarly, if the cargo pod in Space Engineers bothers you, you can replace it. You don't have to find a "Martian city" mod pack, you can just find a slew of random parts that are closer to your vision.

This "small parts" approach is very powerful for those reasons and more, but it requires some things that weren't available until recently: a massive amount of computational power, flexible UI, and integrated networking.

Computation allows us to combine the many small pieces into an integrated whole, including functional pieces such as doors and machines. Moreover, computation allows us to execute code on the fly, integrate new models and textures, and do other things that used to be too difficult to really allow. This allows modding to be plausible, allowing us to create new parts.

Computation also allows us to have much more intricate emergent scenarios. This is just starting to come out, because it requires a whole new class of play. You can see hints of it in Space Engineers when ships collide, or in Kerbal when you try to use 60 mods at the same time.

The flexible UI is absolutely necessary as well. When you have a lot of small parts and a big canvas to paint them into, you need average players to be able to do so without getting confused. Without a tutorial.

This is partly accomplished through a new class of UI controls involving flexible lists and adaptive spatial interactions, but it's also accomplished by simply evolving player familiarity with controls. Modern FPS controls are extremely complex and opaque, but because the audience has played so many of them, they quickly grasp whether this game allows for parkour, what the weapon switch button is, whether the reload has a timing event, etc, etc.

We're seeing the same thing here. Minecraft's clunky construction controls have given way to Space Engineer's more powerful, fluid interface. But even that is clunky compared to where we're going: the emergence of VR and AR will create a new class of immersive interfaces that will rapidly evolve. While unbounded construction probably won't be explicitly VR/AR, it will benefit from those UIs and steal them wholeheartedly.

The integrated networking is necessary in order for the game to have a powerful, flexible metagame. This is not simply a nice perk: it's a core part of the genre. You need to be able to show off your creations, and see where your creations fit into the grand scheme of things. You need to be able to see the wonders other people have created in order to be inspired to create your own. You need to be able to steal techniques. You need to be able to cooperate and compete in construction, not just in gunplay. You need to be able to get mods or even whole worlds to integrate into your vision.

At the moment, Space Engineers has the best integrated networking around - automatic mod sharing, quick and easy ship/world sharing, a place to chat and share pictures/vids, all built into a reasonably large existing user base (Steam users).

But, again, Space Engineers is already showings its age. The content isn't properly integrated into the game experience, and it isn't properly partitioned away. In the end, we will see unbounded construction games where mods are local to each ship or town, not to each universe.

It's not that Space Engineers is bad, it's that the concept is bizarre and wasn't even on the radar when the game was laid out.

... I should stop playing Space Engineers and finish programming some of this stuff, I guess.

Mission-Based Iteration vs Survival-Mode

Construction games!

I love expanding the core concerns of construction games. It gives an extended, graceful complexity curve as the player becomes more skilled. I also enjoy allowing for breadth of complexities, so different players will discover very different approaches and create very different scenarios for themselves.

But, at the end of the day, that complexity is not why players care about the game. The reason players want to play is because there are things to do.

Even when those things are largely self-directed, they are anchored in a core pressure system, a basic reality of how things work.

AKA, the "survival mode".

Personally, I think that a construction game needs to have both a survival mode and a creative mode, but I think they should interact a lot more freely and fluidly than most games allow.

Creative mode, where a player is free to create anything of any size, is important for allowing players to express themselves. Survival mode is where they learn what actually works, refine their design sense and taste.

Obviously, they are free to create whatever silly, unusable crap they want in creative mode, but the survival mode pressures give them a strong sense of whether something is designed "well" or not. Still, the freedom to create anything in creative mode is important, as experiments and art pieces are perfectly acceptable.

I think these two modes are more deeply linked than even that implies.

Right now, I think the big problem with construction games is that their creative mode and their survival modes are too chunky, too binary, too separate. If you're in survival mode, you had better eat and mine and survive monster attacks. If you're in creative mode, you can build anything with no constraints or pressures, never die, etc. This kind of thinking, this binary divide, is oldschool. It inherits from the idea of a "map editor", and that's not a concept that exists in a construction game.

Instead, we need to think of creative mode as an extension of survival mode, or visa-versa. There's a sliding scale where you shake off some of the survival-mode limits but keep others in order to refine your approach. Similarly, you'll want to have a method of porting those refined creations down into the survival world. "Iterated construction" is my goal.

As an example, in Kerbal you can build any kind of rocket you want, launch it, and pilot it for hours... and then revert it all. This "test" allows you to refine your rocket design and mission plan without pressure. You can keep trying all you want, until it goes right. Moreover, the diversity of possible missions lets you try a lot of different designs with different parameters.

Kerbal's recent updates have been focused on making survival mode more rigid and pathed, involving research, budgets, part and mass limits, and lots of ground-side complexity. When you try to build a ship, the parts you haven't unlocked are hidden, and you can't even test-fly a rocket that is too expensive, heavy, tall, wide, or complex for your facilities.

I don't believe this is a good path, although it's obviously quite subjective. This by-the-nose guidance really feels awkward: "survival mode" in Kerbal was trying to survive the mission. It's about designing good rockets and learning orbital mechanics. And that was reflected in their core constructive play: people enjoyed building larger, more intricate rockets as their skills expanded.

Now the survival mode is about making profits, taking contracts, upgrading ground facilities. Those don't help guide you towards building better rockets! At best, they might help you build cheaper rockets, but that's kind of a boring core aesthetic, don't you think?

The old idea was that you would survive a mission to distance planets. You would land on weird moons, or on worlds with dense atmosphere and lots of gravity, or a world with no ground at all. Each of these mission profiles suggested themselves quite elegantly: they exist on the map, therefore they are a place worth going. Each had different tolerances and requirements, and therefore each one tested and refined your construction skills. You could build more complex missions off of these pieces - an orbital station around Juul, a colony on the Mun, a rover that works on Eve, etc.

Those missions still exist. You can get a contract to go to Eve, a contract to put a space station around Juul. But they are hidden and metered. The new survival mode does not support the creative mode. It does not guide you towards building more elegantly and awesomely.

The original problem was simply that building things in Kerbal is a bit of a difficulty wall. Hundreds of parts and no understanding of things like aircraft parts vs rocket parts vs science parts vs crew parts vs... well, it's a bit overwhelming. The idea with the original science mode was to have those parts unlock - you start with so few parts that you can't possibly be confused for long. It's a good idea, but we need to stop confusing "tutorial" with "survival mode". They are completely unrelated.

Tutorials teach you how to make the game work. Survival mode teaches you to make the game sing. A survival mode with an integrated tutorial is dangerous: you might end up with a survival mode that just teaches you how to keep playing the survival mode. As with Kerbal. Completely sidelines your core play!

But Kerbal did do something very right with their original sandbox mode: their survival mode has distinct challenges and difficulty settings that are fluidly integrated.

You can see this with a few construction games. For example, in a diving game you quickly learn that your oxygen runs out extremely quickly as you go down deeper, and that the pressure makes it more and more difficult to keep vehicles and bases intact. Unfortunately, most of these games are not constructed to make iterative missions to those areas possible.

Once you get the radiation suit in Subnautica, radiation stops existing. Once you get the rebreather, depth penalties stop existing. This levels the playing field, which is exactly the wrong thing to do. It means that instead of trying to iterate and create better bases, you just tick off the check boxes and keep following the game's script.

Compare that to sandbox Kerbal, where once you've gone to Duna... you want to go back to Duna with a better design. This is the heart of an iterative approach: the challenges in a given mission don't exist to be flattened away, they exist to exert continual pressure.

That way you can learn to build a better design.

Subnautica - and most games like it - attempt to exert survival mode pressure by filling these areas with more dangerous creatures. However, that doesn't really get along well with the construction parts of the game. There's not really any relationship between the monsters of the deep and how you build your base. There's no pressure to build your base differently in order to make it more effective in different environments. And, of course, there's never any pressure to build a better-designed second base in the same environment.

That's the heart of the problem.

We could also talk a bit about Space Engineers. In creative mode, all the ship systems work as they do in survival. None of them really matter much - you can't die, your guns fire even if there's no ammo - but you can immediately tell how well your ship is designed without even passing it back into survival mode.

To me, this is a sign that the barrier between survival and creative is not as distinct as we like to believe. Why not let me plan out anything I want, and tell me how well it would work? Why not let me enforce specific survival limitations in creative mode? Let's mix and match.

Hm. We need to stop thinking about "survival mode" vs "creative mode", and start thinking about iterative construction.

At least, that's my plan.

Topological Play: Pull, Push, Connect, and Access

I like construction games. I especially like construction games where people live in the thing you built, like bases or star ships. I've talked about this stuff a lot in the past, but today I'd like to talk about specific kinds of pressures which make construction games more interesting.

When you think of a construction game, you probably think of two common kinds of play:

1) Spreadsheet play. Having enough modules of the right type to get the performance you want. May also involve things like ship speed and weapon coverage stats.

2) Physics play. Having a structure that doesn't break when it's active, or that resists damage well.

These are certainly fine kinds of play, but I think there are some other kinds of play. Let's talk about them.

Connection play is when you have to put your modules in specific relationships to each other, either allowing no space between them or requiring that the space between them be filled with specific modules.

A module that adds on to another module physically takes up space. A cable running from one place to another physically takes up space.

How flexible this is can really change how the game feels. For example, can an attached module be in any adjacent block, or does it require a specific face? Can a cable be curved and branch? Maybe a cable doesn't actually fill the voxel, so you can lay many cables through an area and even walk through them - you just can't slap down another voxel in that spot. Tons of options.

This can also be inverted: a block might require an empty space off of a particular face to allow for heat venting, maintenance access, vehicular traffic, line-of-sight broadcast, etc. These are functionally the same constraints: whether it's a required component or a required empty space, the topological challenges are the same.

It's a fun challenge to stack these up in complex ways. For example, an engine might require an empty tile for venting: why not aim that face of four engines all into the same empty tile? Optimization!

Pull and push is when components exude a particular field effect. For example, a reactor might give off deadly radiation, a heater might give off heat, a factory might give off noise and vibration, an antenna might give off connectivity, etc. If you want to be complex, you can make each kind of field effect propagate differently through different materials: a heavy wall might block deadly radiation, but actively extend vibration due to its rigid structure.

Push and pull act to softly guide the player to leave certain spaces empty and fill other spaces, as well as gently guiding them to put specific modules near each other. For example, an engine gives off heat and vibration, but is almost immune to those things. So you can stick a bunch of engines together, and put them off away from the delicate stuff. A factory produces vibration, but is sensitive to it, so you can't cluster them up. A heater will keep components from frosting over, so put those kinds of things clustered tightly around the heater. You end up with a design that varies system density in a natural and believable way. Good way to do it.

Most of the time, these are binary fields - you're either inside our outside of them. I think that's not a very good way to do it, because it's too rigid and forced - I like a degrading field that has a lot of wiggle room for designers. This also allows you to play with extending or inhibiting a field in a very fluid, adaptable way, and that leads to interesting designs.

This also requires that you can model their effects in subtle ways. I recommend a combination of two factors: maintenance requirements and performance efficiency. A factory that is subjected to vibration might work less efficiently, since it must move much more carefully for the fine detailing. Or perhaps the vibration causes it to break down faster. Even if ongoing maintenance is not part of the game world, simply SAYING that it requires extra maintenance is enough to distinguish it from a better-designed ship. Ideally, you could scuff it up and make it look dirty.

Access is when you calculate clear propagations between a module and another module. One example of this might be wiring: if you wire up all the components on your ship to a central computer, you can access them all and they can all access each other. This is great for operations, but might be vulnerable to hackers or power surges.

Another example would be life support: an air vent provides air to all the open voxels it can reach, assuming it is a contained space. But, more than that: a couch provides a place to rest if people can reach it. A cafeteria provides food, if you can walk to it. A repair gantry provides access to the engines when you swing it out that way, or to the life support systems when you swing it this way.

These access networks can be very adaptable and provide a very nice "soft" way to push players to design more thoughtfully. A space ship where your crew have good access to the engines to maintain and repair them is great, and that can be calculated using an access network. It can also be done in very creative ways: maybe the maintenance space can be pressurized for really delicate work, but only when the engines are off (they produce too much heat). Maybe the maintenance space is actually solid space most of the time, but the engines can be pushed apart like sliding shelves for maintenance purposes.

Similarly, network-wide threats are a great way to make things more interesting. Maybe not everything should be on the same network, because if something goes wrong, everything goes wrong. Maybe there should be bulwarks in the network that can be sealed: airtight doors or circuit breakers. Also, because the network contains all the network flow for all the components, maybe you should separate the network to keep contamination down: keep a data network running light and fast, keep a life support network safe from visitor's diseases, keep a power network safe from sudden power draws from intermittent devices.

All at once
Of course, the ideal is to combine all these things at once, in different amounts and directions.

For example: one kind of starship engine produces heat and vibration, requires empty space for venting, and needs fuel and power lines. Another kind of engine produces deadly radiation, requires no venting or fuel, but requires 100x as much electricity.

Not only are the modules different, but how they interact with the space around them is different. The basic engine can have life support regions and computers relatively close-by, but the other one produces radiation that will cause computers to have glitches and crew to have cancer. So even though they have no access constraints of their own, they affect everyone else's constraints. The high power draw of the second one may require it be on its own power grid, while the fuel requirement for the first one might be harder to topologically manage because of all the physical piping it pulls to your engine area.

So your modules don't just have a statistical presence: they also interfere with other kinds of concerns because of their various constraints.

It sounds like a lot of fun!