Refine the Constraint

Last essay, I talked about a space game where you use a railgun to shoot a payload into the upper atmosphere, radically reducing the need for a complex launch stage. The downside of this would be that you would have to shape the payload to fit into the railgun's track, meaning a single stack, say 3m wide. The restriction allows for the player to carefully try to cram more functionality into that constraint, which provides a lot of the challenge and also a lot of the progression (smaller, more powerful parts).

The problem with this approach in my original vision was that the cramming only started when you started to think of complex payloads. I was still thinking of a lot of the basics as simply being stack components. Like Kerbal: you have a full-width fuel tank, a full-width engine. There's no cramming involved - you just stack them. But it didn't feel right. Engines are still a major part of the game, and to have them be supremely oversimplified seemed like it was undercutting my mechanic.

A real rocket engine isn't simply "fuel flows into the nozzle and explodes". Or, rather, it is at the most basic level, but we can allow it to be a lot more interesting. This can be part of the career mode, just like discovering mechanical struts or SAS or whatever. Just like you aren't required to actually understand the math behind things like SAS modules, you don't have to understand the math behind a rocket engine.

You might start off by choosing a nozzle and, for your first rocket, just mounting a mixing valve on top of it, and then run some pipes from the fuel tanks to the mixing valve. There you go. Rocket engine. (We'll ignore the igniter.)

Of course, this is quite a simple rocket engine that requires the fuel to be kept under pressure. The burn rate is restricted by how fast the fuel tanks push fuel into the valve. The valve can certainly reduce that from max - you can throttle down easily enough. But increasing it above that maximum is impossible, so the resulting rocket has a very low maximum burn rate.

So you research a pump that sucks fuel in. It goes between the valve and the nozzle, and is visually just a bulgy chamber with a pipe in and pipe out connection. This allows you to pull in a lot more fuel, giving you a much higher max burn rate regardless of tank pressure. It does only work so well, but you can always stack them together if you can fit them into the 3m restricted space the launch method allows. (In reality, you'd only ever use one, and you'd just make it bigger and more powerful. However, that doesn't fit as well into our game mechanic.)

This pump works great, but you find that you frequently overheat. So you research a nozzle with a heat exchanger built into it. That's the loop and bulge that's attached between the nozzle and the combustion chamber. The heat exchanger hooks into the pump, so you can run ice-cold fresh fuel around the chamber, heating the fuel and cooling the chamber - both good. If you want to you can run other, dedicated coolants through instead - that's up to you. The more effective the cooling of the chamber and the heating of the fuel, the better the efficiency.

And there's no reason you can't have four nozzles bunched up, fed from a single valve... you have tons of options. You can even use mechanical winches to separate the nozzles to wider than the 3m limit once you've launched... Then you invent the gimbal, and so on. The complexity is introduced piece by piece, and you never feel lost. You are the source of most of the complexity.

The key here is that we're integrating the design of the rocket engine into the core play mechanic. Even our fuel tanks: we don't have a big orange "LOX" tank. The player would create each of the two (or more) internal tanks separately, and run pipes. Externally you could paint it orange and nobody would be able to tell, but by making the player build them separate internally you make the player choose what kind of configuration they want, whether they need to add coolant systems or pressurization modules, whether they want to cram the fuel canisters tightly together or leave plenty of room... options.

Since our core play is all about arranging components within the constraint, the rockets and fuel offer a very good early guide to the concept, as well as allowing us to gently explain that empty space is not the enemy. Gaps between the two LOX fuel tanks are not evil, nor is the empty space around the rocket valve. The constraint isn't "fill all empty space", but "get everything into something less than 3m diameter".

Anyway, the other half of this lesson is designing your first command module, cramming in seats and computers and shit.

Constraint is Interesting

STILL THINKING ABOUT SPACE GAMES.

Last essay I talked about the idea of adding mechanical polymorphism. Things like arms that can transfer goods and whatever else I could come up with. But it didn't feel compelling. Today I'm going to restrict that mechanical polymorphism while talking about research. It's more interesting than it sounds.

Fundamentally, it is very compelling to unlock more stuff. It's interesting to go on a mission using a bunch of shitty components so that you unlock a better version of one of them so you can go on more missions. It's very compelling. But I don't like rocket launches as a primary mechanic. What can we use besides that?

How about a railgun? A hundred miles of magnetic rail that shoot you off the top of a mountain. This takes care of the first launch stages, so your designs can focus on the more interesting final stages and payload.

But if you take out the launch stage, you lose a lot of research potential. A big part of discovering more modules is discovering better launch modules. Larger tanks, larger engines, better fuel management... take that out, and what do you have?

Well, a lot, of course. You can focus complexity and growth into anything.

See, the biggest restriction is still the launch platform. But instead of being a giant cluster of rockets, it's a railgun. The railgun never changes, nor does the atmosphere. So our payload has to be a specific kind of shape to properly fire from the railgun, and has to be aerodynamic enough not to tumble, shatter, or excessively brake in the atmosphere. IE, it has to be one stack.

So our progress up the tech tree isn't about "bigger", but "smaller". For example, an early generation computer might be the same size as a cockpit - but after a few thousand science points, you can use something the size of a thumb that has hundreds of times more power. Similarly, you might start with inefficient solar panels pasted to the sides of the chassis, then figure out how to make versions that fold out a bit when you reach orbit, then figure out how to make them massively expand - the exact size and weight of the payload component will vary, but the final result will be significantly better.

There's no reason to leave the simple stuff behind, though. You can also figure out how to use solar paint - no folding out, but ultra-lightweight and quite efficient. Similarly, there are times when you'll still want a giant computer on your payload - but the new giant computers are so much better than the old ones. So there's always a lot of possibilities.

The biggest and most interesting challenge to this is the "unfolding". It's pretty easy to attach rockets and stuff, get the payload going in the right direction. But a lot of payloads will want to be in some shape besides "stack of fuel tanks". For example, you might want a space station with long struts, or a lander that has a dome shape. The launch profile has to be a stack, but you can always make some components of that stack fold out, inflate, assemble, or otherwise change shape.

For example, you might create a stack where you have a four-arm fold-out module that will create a 4-way perpendicular set of arms. But what's at the end of the arms?

Well, whatever you originally packed in line with the column, crowded into a stack segment divided four ways. And maybe one of the things crammed into that space is, in fact, another mechanical device which folds out and in turn has its own divided substack segment... You can see that we've changed the name of the game from "more fuel and rockets" to "packing shit in more efficiently". Rocket Tetris.

There's a lot of room for manual labor, here. Not everything can always be packed in line with the stack, so maybe you send it up in another payload, or maybe it's in a different part of the stack, a place where you could fit it. Then an astronaut puts the two pieces together manually.

There's a lot of fun complexity hiding in this concept, and it's a much deeper and more interesting concept than the ones I've come up with previously. I don't want to go into excessive detail about the play cases here, but if you try to imagine how you might drop a rover on the moon using this kind of system, I think you can start to see how interesting it might get.

By adding a strict constraint (everything must go in one stack, no projections) we add a lot of depth in trying to work within that constraint.

As usual, there is a good reminder in this. Games are born more out of constraint than freedom. I tend to forget that.

Machine Dance

Several people have suggested that I basically remake Kerbal, since I love it so much. Well, there's not much point in that: Kerbal has some flaws and some design choices I wouldn't have made, but fundamentally it's very well done. If I want more Kerbal, I'll just play Kerbal.

But it is true that I want to build something that draws on Kerbal's inspiration. The reason I keep going back to Kerbal and talking about it ad nauseam is because it's really pretty unique. Even though the concept has been done before, it's never been executed like this.

At the end of the day, there are a lot of things I want to learn from Kerbal... but it's not a game I'm interested in making. The focus is all wrong. Kerbal is focused too much on physics and launching, which are not what I want to talk about. I'm happy to play a game about them, but in order for me to be interested in making a game, I have to have something I want to talk about... and the physics of rockets aren't really high on my list.

Instead, I'd prefer to talk about the other parts the space age. Science, inhabiting inhospitable worlds, getting along in zero gravity, the long isolation of a space station, the scare of relying on machines... to me, these are all more interesting things to talk about. They don't have a damn thing to do with launch or landing physics.

It might be a mistake to keep chanting "KERRRBBALLL" while thinking about gameplay that's so far removed from the core idea of Kerbal. It's a preoccupation I need to shake.

Instead, I'd like to talk about the idea of the machine dance. First, however, I need to talk about player generated content.

In brief, there are a few different types of gameplay rolled into a content creation tool.

One is the "model kit" style. This is when the player wants to create something they invented or imported, with only weak ties to in-game functionality. This is building a mansion or a sky castle in Minecraft, or trying to make a perfect moon lander replica in Kerbal.

Another is the "extended function" style. This is when you try to absolutely maximize the statistics of the product. This is asparagus staging in Kerbal, or growing wheat in Minecraft. Without much concern towards aesthetics, you try to crush the constraints that normally slow you down.

The last I can see is the "alternate function" style. This is when you try to do something different with the tools, but rather than having a specific model in mind, you are aiming for new functionality. This is creating songs and computers in Minecraft, or a self-assembling robot base in Kerbal. These are not things that the game preassembles for you, nor are they constraints that you normally deal with. The weakness of alternate function is mostly in whether or not the end product is useful or entertaining.

In many (most?) cases, some combination of the three is what you end up using at any given time. For example, a beautiful "flower" that unfolds in space, perfect for creating a massive comm system that can handle dozens of satellites.

With that in mind, I'd like to talk about the idea of the machine dance.

This concept is about making the system interact with itself much more aggressively. Rather than focusing mostly on how you interact with the outside world, we need to focus on the system interacting with itself. This is important because most of the space topics I find interesting are about how the systems work in and of themselves, not how they confront the world around them. The whole point is that there is very rarely any world around!

One way to do this is to create systems that work over time, changing slightly along the long mission hours. Fuel is burned as you accelerate, so if you want a truly long-term space ship, you'll need some way to generate fuel. So you include a component that generates fuel.

However, this doesn't add gameplay! It actually removes gameplay - the difficulty in loading up enough fuel is gone. So in order to make this worthwhile, you have to recalibrate your difficulty to make the generating fuel thing interesting.

One way to do it is to make it extremely chunky. For example, generated fuel isn't piped into the engine's fuel tank, but into a capsule. Then you have to exchange the empty canister in the engine for the full canister in the generator, either manually or using an automated robot arm. This activity strongly constrains the patterns in which you can use your engines.

Another option is to make the generation itself constrained. For example, requiring you to be facing the sun, or generating a massive amount of heat, or any number of other constraints that actively interfere with the performance of other components.

Both of these options inter-relate the various components and activities of the system. When you build an engine, you have to consider how your replacement canisters are going to move into place. You have to consider whether it'll work in deep space, or whether the waste heat from the engines will overheat the generator and visa-versa, and whether that interferes with the science module. The system has become much more tightly inter-related because each of the components has a set of constraints and effects that are turned on and off as you like.

I think this is the secret to making base building interesting: mode-changing topological challenges. It's not simply a matter of whether you have a bio lab or not. It's whether your bio lab is placed in a way where it can be used reliably, where there's no interference from the radiation lab, or from the vibrating engines. It's the pattern in which you can use the bio lab, and whether you have to wait six months without turning on any other systems in order to complete the bio experiments. And it's all organic: the player is allowed to design a ship where the lab is located whever she likes, and it matters.

But the mechanic runs deeper. I mentioned that you could either run the fresh canister over to the engine with a person... or with an automated mechanical arm. And here is the "dance" part of the machine dance.

The idea isn't to simply design a bunch of things that turn on and off optimally. There's a lot of fun to be had in designing it to reconfigure itself in certain ways, allowing you to have a lot of freedom as to what things are doing what.

Mechanical arms are one of the things. There's a lot of potential play hidden there: mechanical arms that swing through a shared space and have to be careful not to strike each other. Gantries that arms can slide along, so they can carry inventory long distances and stow it in cargo stacks.

But there's a lot of stuff besides mechanical arms. For example, you might mechanically rearrange your modules so that they are more optimally arrayed. You might print out a new module using a 3D printer, then reabsorb it. You might have a module which inflates/unfolds, giving you a lot more interior room but cramping the exterior and becoming fragile. You might even have sliding gantries for entire hubs, allowing you to dock hubs with the hubs above or below them... or put a space gap between them when your modules need to be separated due to heat generation or whatever.

Mechanical reconfiguration is fun ish, but it's limited to the clear and uninspiring rules of mechanical devices. You move devices because you need them to have less noise, or a direct connection to another node - these are simple restrictions that are difficult to build arbitrary complexity into. In the end, the complexity probably hits a pretty basic wall where you figure out how to move things in an optimal way and that's that. There's nothing fundamentally different about scaling it up or aiming for something more complex.

To make that matter, we have two options. One is to add in additional complexity when you rescale or add functionality. For example, we might have a "heavy core" system where modules in the stack don't stack along the center, but instead stud the sides. This would offer a more complex way to inter-relate modules as there's now two dimensions of contact rather than one. Similarly, the mechanics of moving them around would be a bit different. We might add in some kind of "laser bond" where modules can be connected over a distance by a high-powered laser to provide information or particles or whatever, which in turn means neither of those modules can be moved while the laser is active. This would also allow us to have mirrors, which could be used to redirect the flow in real-time so that you COULD move laser-bonded modules as long as there was a tracking mirror installed... and, of course, you could just build laser light shows for fun.

Tossing things around could also be fun, allowing you to have very long or large stations. Instead of using an arm to drag something from point A to point B, arm A tosses it through space to arm B. Works fine... as long as your engines are off. Wires could also be used to slide along or reel things in... so there are options as to how to add complexity, and you could make it very interesting by adding in different kinds of complexity for different sizes and functionalities.

But the other option is that we can add in a human element. Right now the space station is just a mechanical device. There's certainly something compelling about a big aluminum tin can, but most construction games include people for a reason. People are compelling. Even if it's something as basic as Kerbal's nearly useless astronauts.

I think we could easily integrate astronauts into this machine dance game by simply making them move around inside the modules. So the 'outside' of the modules is where all the mechanical stuff happens, but managing the 'inside' is a separate challenge.

Some parts of it would be pretty basic. Everyone needs a place to sleep and so much air and so on. But you don't have to manually dictate that stuff. Astronauts is smrt. They can figure out how to get from work to their bed without your help, even if it does require them to go on a space walk. Instead, you handle their work assignments.

Astronauts can be assigned to specific modules for work. This allows modules to be vastly more productive depending on whether astronauts have been assigned. It also allows us to give each module three states instead of two. Instead of just "on" or "off", we have "off", "holding", and "active". The bio lab can be put in "holding", where the projects are put into a slow-moving crawl but not canceled. It is less sensitive to interference and has fewer requirements/interference of its own.

The thing I like about astronauts is that you can introduce them as a helpful way to make your modules more productive... then steadily introduce their personalities as the mission continues. Anyone capable of going into space is going to be able to work for a week without letting their idiosyncrasies interfere with their jobs. A month, maybe. Depends on the person.

But at some point, the astronauts are going to begin forming lives in space. They'll start to have relationships, good and bad. They'll get lonely, or want to work on their hobbies. The more time passes, the more the astronauts resemble humans instead of cogs.

This doesn't degrade their work. On the contrary, properly managed it will actually enhance their work, because they're getting used to how things work and are healthy and happy. But you have to manage them. This isn't simply having the right modules installed: you need to massage their personal lives by changing where they tend to go and who else tends to go to those places.

Which is a topological challenge that can be worked through by mechanically rearranging modules and changing their primary assignment.

To make matters more interesting, you can have certain things generate only when astronauts have acclimatized to space: producing cultural goods such as movies, songs, babies, etc. These can have value if you can wrangle them properly, and exactly what kind of life you give your astronauts will change what kinds of cultural goods they create.

Anyway, just thinking aloud. Brewing ideas, as usual.

Mission Pacing

I'm in love with pacing. For example, I think the most important part of a survival horror game is not the enemies, graphics, or gameplay... it's the pacing!

Pacing does interact with those things, though. It can't really exist on its own. So I'm always keeping my eyes open for games with pacing I haven't really seen before.

Like KSP. Yeah, another Kerbal essay.

KSP's pacing is extremely unusual because it is completely player-driven... but still very compelling. I can't think of many games where the player is allowed to fine-tune the pace to this degree, and none where the pacing is still compelling.

The core of the pacing is KSP's mission flight gameplay - launching, coasting, adjusting, coasting, adjusting, coasting... it's a simple but compelling loop that keeps its vigor because every mission and every ship has its own parameters, and you can never see 100% of the mission. It's always a bit of a mystery exactly how much adjustment you'll need, exactly how long you should coast, exactly where you should land... and that's compelling. A simple, continually changing loop.

I was thinking about other kinds of gameplay that might have the same feel, produce the same pacing.

For a long time, I was stuck on the idea of physics. But KSP's physics are actually just constraints, not really ongoing challenges. I don't think I've had to deal with in-flight physics issues on rockets, landers, or space stations for at least 40 hours. It's just not a piece of the gameplay at this level. I generally don't even have launch physics issues, unless I'm trying a completely new configuration. It's all pretty pat.

No, it's not about physics. It's about traveling.

Could you make a game about swimming? Flying? Driving? Boating? These are all systems of travel... but none of them have the right coast-adjust loop. They're "always on", at least as they are normally implemented.

Well, we might be able to do something with a sailing ship. The wind in your sails, coast along. Adjusting needs to be more complex than merely turning, though, so you'd have to do something interesting to make adjusting interesting. Perhaps it involves accurately reading the wind, or dealing with sea currents, or perfecting the angle of the sail and the angle of the hull... well, it has promise, but it might be difficult to make it feel juicy. It's also problematic because the ship doesn't change much as play progresses, which means the loop will feel a lot more repetitive as compared to something like a space ship changing mass and dropping tanks.

But this is an interesting point: it doesn't have to be about travel. It just has to be something where you coast and adjust.

For example, maybe you can turn a 90s hacking movie into a game. Coasting involves letting your BBS, wardialer, and botnet operate as configured. Adjusting means changing their parameters, hacking new machines, and so on. You keep an eye on your BBS, your email, your scripts, and in doing so you identify possible opportunities and dangers before they happen. Adjust your setup to avoid them or tangle with them at an advantage.

It's rather singular, though. Unlike KSP's missions, there's no real payload/launch variation. You'll always just use your best stuff, and the configuration of your systems doesn't have the breadth of expression that KSP's payloads tend to have.

So I'm just trying to think of some other methods.

Science projects: let your research teams continue on their current trajectory with their current subexperiments, but adjust their allocation and direction when it becomes clear that certain directions are dead ends and others are more promising. The development you're aiming for would need to be very freely definable, though, to give it the same variation and complexity as a KSP payload.

Country/city building: let your city continue to develop with current policies and zoning, change them when you want to redirect. To make the looping work correctly, the price for adjusting policies and zones would be a lump sum for any amount of adjusting, so there's impetus to adjust it all at once. Each city (or country, or space base) would need to have a specific construction/topology that is interesting and some kind of target endgame, to make them as varied as KSP payloads.

Terraforming. Same as city building, but across the whole planet.

Raising fighters. Whether mons or football players, let their training regimen develop them in "coast" mode. Alter their regimen just before game to bring them into proper fighting trim. Tweak it again afterwards to not interfere with their recovery, then bring it back to the "long haul" regimen to raise stats again...

Hm.

I wonder if anyone else gets what I'm aiming for, here.

The Wait And Click

There's a kind of mechanic that gets a bad rap: the "wait to click" mechanic. Largely considered to be a cheap and nasty mechanic for Facebook games, I'd like to consider it fresh. I think no mechanic is inherently bad, and there is some potential here.

The thing that made me reconsider this mechanic is KSP's new career mode, where you build science vessels. See, pacing is a huge part of Kerbal's appeal. You build for a while, then you launch, wait a bit, adjust, wait a bit, adjust, wait a bit, adjust... sometimes, the waiting can be quite long, such as if you're trying to reach Jool using a xenon engine and you just have to sit there and fire engines for fifteen minutes straight.

The waiting never feels too onerous because it's MY waiting. I designed the rocket. I picked the mission. And, sure, I'll pop off to program or sketch or browse the web during that time - but, again, the game isn't a Facebooky-abusive-scheduler game.

It's very possible to make a game that feels almost the same, but makes you angry about the wait. This is because player agency is, for once, actually important and delicate. People have talked about player agency so much that there's annoyed backlash, but put that aside for a moment: this is about allowing players to choose their wait, and adjust it.

There are a lot of games where you "choose your wait", but the wait always increases as you tackle higher-level play. That's not "choosing" your wait... that's railroading with a candy coating.

Even in KSP, it can feel that way sometimes when you're trying to do a solar orbital maneuver (say, to Juul), and even the highest time acceleration is just a crawwwwwl. I generally don't like going on missions to Juul because of that long wait, a wait that is forced on me. Of course, there are mods that could help - for starters, I could use an alarm clock mod. Let KSP run in the background while I go to work or whatever, it'll pause when it reaches the specified point. In this manner I could change the weight of time without changing the actual wait required. The less attention I have to pay, the less the wait weighs.

The reason I started to think about this so carefully is because of KSP's new career mode, as I mentioned. This has dramatically changed the pacing of KSP's missions. Now the mission's "active" points aren't the minor adjustments required to change orbit or land. Those still exist, but they're pretty mild compared to the catharsis of clicking science modules and uploading data, five times each module - click click click click, wait for the big broadcast to finish, click click click, adjust the timescale a bit so I get more sun juice...

People often dismiss that kind of gameplay - there's not any particular punishment for doing it poorly, and there's no particular expressiveness... in the end, every player will end up in exactly the same situation, performing more or less the exact same process. It doesn't even have any strong interlinking within itself - unlike a level of Super Mario Brothers, it doesn't matter if you do A then B, or B then A. There's no skill, no meaningful choice, no agency.

But there is agency in getting there in the first place. I designed the ship. I chose the mission. I placed the science components. I landed the ship.

That's meaningful. That's interesting. And the catharsis of the payoff is much stronger because I'm actually performing the payoff mechanics. The ship doesn't just automatically upload all the science: I have to do it. Even though there's no skill or meaningful choice involved, I have to take action in collecting the results of my labor.

This is similar to the old conceit of open-world games. The world missions are all static and railroady, but because you have to walk into the glowing circle and click, it is your choice to commit to the railroady mission. You don't feel railroaded because you chose to take on this situation at this time and in this manner. It's the same thing backwards: the reward is already decided by the time I reach the end of a KSP mission phase, but having to manually collect it makes it feel more real and rewarding.

I guess it might feel cheap to talk about this kind of gameplay as "gameplay", because it really isn't very good at being game or play. But it is very good at pacing the player, punching up their experience. It's a mistake to dismiss that kind of effect out of some kind of false pride. Sure, the mechanic is often used in trashy freemium games to abuse the player, but that's because it's effective. You can use that effectiveness in a decent game, too.

It's an interesting dynamic, and worth pursuing.

Accessible Complexity

I've built a number of game prototypes about science, and I've discovered a lot of subtle things involving complexity.

As I touched on in the last essay, the science part of games is not usually complex. It's usually quite simple and straightforward, and the complexity of the game lies in the framework of how you generate science.

For example, the new version of Kerbal (KSP) includes a compelling science system... but the way you do it is to build rockets and ship stuff around the universe. The science itself works the same no matter how the instruments get to the new location. The complexity is, as usual, all in the other part of the game.

And building a rocket sure has a lot of complexity to it, at least in Kerbal. They physics of the game are quite complex. The exact structure of every rocket varies, as does how it handles and so on. There are some very clear "optimums" once you play it for long enough, but in the beginning it feels extremely open and free.

Getting that level of complexity is actually a bit challenging. Basic physics is something we're wired to understand. We learn from birth (and perhaps even from our fundamental brain structure) that things have weight and react in certain ways when pushed. We understand that things can break, or swing, or spin, or bounce, or do any number of other complex physics stunts. So physics comes with a massive stack of variety and complexity that we take for granted.

If you decide to use something besides physics, you have to use something with the same level of complexity and emergence. But here's the thing: there's not really anything else we intrinsically understand to that degree.

So most complex games use methods to teach the player the complexity of the game. This is generally done through two methods: the "maturation" method or the "replay" method.

For example, in Civilization you build cities and terraform the world tile by tile. Nothing about the starting cities or terrain is complex - it's all very straightforward. However, as time passes the cities mature, their complexity grows. A player grows familiar with more complex structures and technologies as their cities grow into them. Of course, each city follows the same basic trajectory, so it's the pioneer cities that train the player to understand the situation, and then the the player guides the bulk of her cities down the same path with aplomb.

The "replay" method is found in games like Dungeon Keeper. Again, the foundational pieces are pretty easy to understand. However, rather than maturing them, the game forces you to rebuild your base from scratch over and over. Each time, the way the enemy pressures your base and the options you have change slightly. KSP is actually similar to this, once you get into learning how fuel actually works.

The big difference in terms of the complexity these games use is this:

In a "replay"-centric game, the complexity is all available right from mission start. Like a fighting game, once you learn the complexity you have it all at your fingertips at all times. On the other hand, "maturing" games always start you with only very simple pieces, and you have to lay out the foundation that will mature. Because of this, maturing games are much more focused on careful layout planning, while replay games tend to be focused on economic balancing. Both types have both, obviously, but there is a distinct difference in focus.

Are there other ways to create complexity that the player won't get lost in?

Sure. The key here is that the player has to internalize the nature of the complexity. For example, when I talk about KSP rocket designs, I might say "Well, even with the advanced SAS module we may still need some RCS spin assist". And everyone who's internalized KSP's complex gameplay understands exactly what I mean.

But there's lots of ways to internalize something besides simply playing the game for a long time.

The easiest is to import complexity that's already been internalized. Physics is the biggest example, but there are others. We don't intrinsically understand these things, but we do have a scaffold that we can fill in very rapidly.

For example, the Force from Star Wars. We don't know exactly how it will work in every game, but we have a grasp on the ways it might work, and we can very rapidly slot the game into place and get going. Similarly, space ships with shields and lasers. Hacking the internetz. Any concept we've internalized from common culture.

The downside of these is that at the moment we're not using them to create complexity. We're just using them to create spectacle.

There is no game where the Force has complexity. In every Star Wars game, the Force is just a stack of powers and a simple "light side dark side" scale.

But imagine a game where the whole purpose is to create multiple Jedi. Like designing a rocket or a dungeon or a city, you design Jedi. The internal workings of their soul are laid bare: the machinery of the Force. You send them on specific missions, and the powers your machinery has enabled in them help them on these missions. But the Force is also related to the emotions we feel, and therefore the machinery of the Force will change as the Jedi goes through various experiences (which in turn depend on which mission the Jedi is on).

So it's a balance: you can build a powerful Jedi, but you need to be careful that she won't fall. A Jedi that is exposed to the grinding hopelessness of poverty and disease in the undercity will suffer very different emotional impacts than one that has to fight Sith while also fighting the rage in their own hearts. The "mechanical" structure of how their personal force is laid out will also need to be different.

I think that game would be hella fun!

Science As Gameplay

Well, the Kerbal update came out and, yeah, blew me away. It features a career mode where you actually do science to gain technical advances. It's a little opaque and oddly balanced at the moment, but it's a killer mode. The core idea builds on Kerbal's strengths: there's only a few scientific techniques (a bay full of goo, taking surface samples, etc), but they yield different scientific results used in different places, so you have to travel to different places to get more science. Kerbal's strength is the rocket travel, so it makes sense that their science would revolve around travel as well. Ship the same seven instruments to thousands of different places on different worlds.

But it really got me thinking about the nature of science as gameplay. There's a part of me that loves the apparatuses of science. The weight and grandeur of a telescope array, for example, is very compelling. The immensity of CERN's colliders is astounding. This is sort of the opposite of having seven basic instruments and carrying them to more and more exotic locations.

It's clear to me that you can think about science in games in a few different ways.

One is as a simple gating/pacing method, similar to how you would view money. Invest in science, build a more advanced murder-bot. This is the Civilization method of science, the Starcraft version. There might be a tech tree, or maybe not - the important thing is that "science" is an amorphous concept that responds to simple, abstract investment.

Then there is the idea of science as a driving force. This is science used as an excuse to get the player to do more, explore more, expand their horizons. Kerbal's new career mode uses science to push you to go new places. I might use science as an excuse to build ever more elaborate facilities. The end result might feel the same as the gating/pacing method - a certain amount of science and a tech tree - but earning science comes with a lot of complex baggage that pushes gameplay forward.

Lastly, there is the idea of science as actual research (and development). I haven't seen any games like this. I've seen a few where you do science, but they don't progress according to the science you do - the science is just standard puzzle gameplay. The concept here is that you actually perform science, which allows you to perform better science due to the advancements you make.

For example, there are a few puzzle-chemistry games. If they were to fall into this third category, you would be allowed to mix the chemicals in a far more open manner, and the chemicals you created would then become available in the game world (with the efficiency and runoff that your method uses). Everyone might discover an oxidizer for their rocket fuel, but there would be many variations and many different manufacturing processes.

Obviously, this is a nasty problem to tackle, because your science needs to be incredibly robust and permissive, allowing players to create a huge variety of results and apply them in a bunch of weird ways. If you can create a chemical that is an oxidizer for rocket fuel, you need to have the concept of "rocket fuel" as well as a robust method of modeling how combining chemicals to create rocket thrust would work. In turn, this ends up being quite limited: you're not really able to invent new concepts, you just fill in the existing concepts in your own way.

Well, if that's the case, you might as well just have science as a driving force and make manufacturing the main gameplay.

It might be possible to allow for "open" science somehow, but I can't think of a way. In short, science as actual research is a phantasm. It's not a mechanic that can be used.

But you can use science as a driving force, so that's what I recommend and will design for in the near future.

Aesthetics of Player-Created Starships

I love player-created content. But, of course, most players are not creating content with pro-level 3rd-party tools. They are creating content with whatever the in-game content tools are.

For example, you can create a character in an RPG. Aesthetically, you're limited to the options the designers provide. This may seem like a huge variety, but in the end you can only create characters that fit into the game's world. You can't create a toon character, can't create your own hairstyle, can't make a dragon, can't wear a T-shirt with your favorite logo on it...

When you create a starship or rocket, you often have the same kind of freedom. For example, in Star Trek Online, you can customize your ship with a variety of sections and colors, as well as the statistical customization coming from the installed hardware.

But in something like Kerbal or many of the new space combat games, you have a whole new level of freedom, where you literally assemble your ships out of base components. Sometimes the components are mostly aesthetic, but sometimes they have important functionality. Obviously, if the choices are functional, that both constrains and fuels your designs.

I prefer functional components, because they allow the universe to develop its own aesthetic. If your components are largely aesthetic, then players will tend to want to clone outside designs - weakening the uniqueness and flavor of your world.

Aside from that choice, the real difficulty is how you allow the players to create the ship in the first place.

The most common method in the next-gen space-fighting games is to use blocky components that can be stitched together. A less popular option is Kerbal's free-attach system, which has only been very lightly explored. A third option is the basically unknown option of being able to design the ship's contiguous spaceframe rather than building it out of component hull pieces.

The spaceframe is by far the most critical element of a good starship design, so let's discuss that.

Most of the most famous ships in fiction have a strong silhouette, a strong spaceframe profile. The popular "size comparison" charts show that.

We can actually learn a lot by looking at the size comparison charts. for example, most starships tend to be shaped like the part of a ship that is above the water, plus a shallower reflection for the bottom half. This is extremely common, even among the "box with flanges" contingent. Theirs simply look like barges.

Another common profile is one based on marine life. Fish and prawns are common inspirations. A few are based on the strut-and-module design of the ISS, which has a cool lumpy aesthetic. A few are also based on cities, which is kind of dull. A very few are vertically "stretched", using spherical or tower shapes that are as tall or taller than they are wide - very unusual, but most of them are simply tilted or stretched ship reflections. A few are based on basic geometrical shapes, especially spheres.

Of course, all of these are often heavily modified by protrusions such as wings, curls, or towers. In fact, the primary distinction between starships in today's media is the kinds of protrusions they have, big and small. We'll get to that, but I want to talk about the core space frame shape a little more.

All in all, by far the most common spaceframe is a navy ship with a muted reflection. However, this default is not necessarily the best option if you want to be distinct.

Most universes have some kind of preferred aspect for their ship designs. For example, Star Trek has nacelles. Warhammer has slooped noses. Star Wars has the wedge with the equatorial stripe. Eve online has the smooth-shell-over-complex-innards for a lot of its ships, similar to Rototech's biological wobbles. Freespace has the "n" curve to all their ships. Even within nonvisual media, you have unique elements that guide the ship design, such as the Honorverse's warships designed around the heavy energy walls their drives produce.

These aren't universal, certainly. In an attempt to make individual ship designs look unique, or to distinguish factions from each other, ships often do not conform to these standards. That's fine when you need to tell a story, but all told these ships have a particular design for a reason. Sometimes the reason is because the writer has a particular design sense. However, in many cases there are in-universe reasons for the ships to be shaped like that. Even if they are retroactive.

For example, the wedge shape of the Star Destroyer may seem arbitrary, but the reasoning for that is simply that the weapons in Star Wars do not scale. The Star Destroyer doesn't have any large guns to build its spaceframe around, nor does it have any single incoming cannon that it needs to armor against. Instead, it is studded with weapons and armored in general, because battles of attrition are the way capital ships fight in Star Wars.

On the other hand, the nacelle-oriented design of Star Trek's Federation ships is because of their warp engine technology. The design of the Zentradi ships comes from their pseudo-organic nature. And so on.

These are all functional reasons. The aesthetics are, at least in part, governed by an idealized understanding of how the ships are used. Sure, it's all made up and none of it tends to stick very well, but these are narrative universes guided by the writers. In a game where you create the starships, the rules of how the starships work will obviously be much more strict.

And therefore, the rules should give rise to in-universe designs.

The default "ship and reflection" spaceframe is just a fallback. When you don't have any unique ideas about how your starships work, you simply fall back on the tried-and-true "space is an ocean" trope. Instead, I recommend coming up with a unique mechanic or two that guides your ship creation.

For example, let's say that your magic technology is the ability to create plasma wings from a core module. You can't have anything in the way of the plasma wings: they don't magically appear around the ship, they actually emerge from the node, and happily cut through whatever ship components you've stupidly surrounded them with.

The result of this magic technology is that ships will be designed with a unique profile, depending on the kinds of plasma wings they are designed to deploy. You'll get teardrop-shaped ships sometimes, or figure-8 ships, or ships with a glowing spire... there are a variety of designs that emerge as you approach this technology from different angles and with different intents. But all of the designs feel new and fresh, because the technology is guiding the designs rather than the designs just being an arbitrary aesthetic choice.

This does not change the basic question: how can you give the players the tools to build these spaceframes?

Obviously, the biggest and most basic option is snap-together components. However, you will end up with a specific boxy look if you do that. Even if your parts are curves and slants and wings, you'll still have a chunky, broken-up look. There are a few other options.

One is to make many of the snap-together components have curves or slants that smooth out the boxiness. This is difficult to do using unchanging stock, but you could easily do it if your components could all be algorithmically reshaped to smooth and blend the profile of the ship. Still, that might be extra coding and art constraints you don't want to tackle.

Another is to allow the players to simply draw the profile, then fill it in using smart mesh creation. This is a lot simpler than you might think. You can allow the player to create secondary hull sections in the same way.

Another is to give the player a few default core hulls in common shapes, then allow them to heavily distort them using drag brushes.

All of these approaches can be combined in different ways if you really feel up to it.



The core spaceframe ship is not the only element that makes a starship unique. The surface of the starship is equally important and should not be underestimated.

Some surface elements are huge enough that they might even qualify are spaceframe elements. For example, the Star Destroyer's conn tower, or the many spires on the various spiny ships that have become popular recently.

Both of those examples are still surface elements rather than spaceframe elements because nothing is mounted on them. They are mounted on something, but nothing is mounted on them.

Surface elements are absolutely critical to defining how your ships look not in profile, but when viewed "for real". And they come in a wide variety, so let's cover some of them.

Color is important. Most universes prefer specific palettes, and within a universe every faction will generally have their own preference. For example, Star Trek is universally white with blue highlights for the Federation, and red with yellow for Klingons. Star Wars' much more navy-inspired designs were originally focused on functional gray, but later introduced a lot of blue undertones to the hulls.

Color is not just a flat wash, though. Not only do secondary colors matter, but the way in which they are put in matters. Star Wars capital ships commonly have a dark streak around their equator, for example. Star Trek ships have glowing panels - windows and phasers and nacelle equators. Eve's ships tend to use rounded rectangles of either glowing or dark patches to give a kind of an "office building of the future" feel. In Mass Effect, the colors are actual paint jobs, giving the citadel a very aquatic feel due to to the paintwork.

Surface texture is important, too. While nearly all ship designs have "smooth" surfaces at first glance, in truth the surfaces are much more complex than you think. First off, the smooth surface is typically riddled with detail elements such as windows, depressions, and sweeping plane changes. Secondly, there's often a secondary surface across much of the ship which has a different texture than the smooth surface. And thirdly, the smooth surface itself can have very different feels as to how shiny it is, whether there's subsurface scattering, and so on.

There's also planar elements. These are the surface elements which define the planes/surfaces of the ship. For example, the iconic Star Destroyer vs the Executor-Class Star Destroyer. They have much the same profile, aside from the Executor having a tapered engine section instead of a flat back. But they are very distinct from each other because their planes are defined differently.

The surfaces in question vary pretty simply between three options: flat surfaces, complex surfaces, and engraved surfaces. These three options are actually pretty much the same three options in any universe, but they are especially clear in Star Wars.

You can see the same three options in Star Trek's iconic designs, and see how they differentiate themselves from others. See, the Star Trek "flat" isn't flat: it's windowed. Star Trek doesn't do "armor", so their flat surfaces are not armor plate, but iPod-like smooth windowed regions. Their engraved surfaces are engraved with glowing phasers and energy traceries, while their complex surfaces are subdued intakes and connectors.

If we applied Federation surfaces to Star Wars' iconic Star Destroyer profile, we would end up with something that tasted more like Star Trek than Star Wars - the difference is severe.

Similarly, we can look at something like Eve's ships. Eve's flat surfaces are engraved armor plate. Their engraved surfaces are typically very wiggly topological contusions rather than the glowing lines of Star Trek. And their complex surfaces tend to be where the glowing parts come into play. In many games these days, the complex surfaces would be gun protrusions or arbitrary spines.

Now, we're defining these as "surfaces", not as "modules". While most games think in terms of mounting a cannon or a sensor dish, in terms of the visual design the two are equivalent and we don't care about the specific size the gun or sensor dish should be according to in-world rulebooks... we just put on a gun or sensor dish that fits the size of the surface we've defined.

Obviously, the ship needs to be built around core elements. Every ship has engines, for example. However, those are the original technological constraints we talked about earlier. The actual design process could be thought of as "how does this design want the core constraints? How does this design want the spaceframe shaped? And, finally, what surfaces where?"

Now we can think about how the player could design ships in that manner.

When the player has created the basic spaceframe, they can choose from a list of surfaces depending on their faction. For example, a smooth "crew deck", a "weapon mount" complex surface, a "shield rig" engraved surface, or a complex "science" surface.

The ship's hull shows a grid patterned all over - maybe a hex grid, maybe just a vert grid, or maybe a full-detail UV map. The player paints the surface onto the surface of the ship in whatever configuration they like. The resulting components are added to the ship.

If they paint crew quarters, the crew steadily increases. If they paint science, their science stats go up and various scanners are added to the exterior of the ship on that surface. If they add weapons, guns are mounted on the surfaces you paint according to the way you've painted. And so on.

This could even be made into a topological game. For example, painting a single square of surface gets you a light blaster. Painting three in a row gets you a forward-facing phaser cannon. Painting a "+" gets you a torpedo bank, and so on.

Anyway, there's some new ideas for how to let players build ships. I'm not saying these are the best ideas, but I would like to break the hold that "modules" have on ship design. Even small ships would use customized elements for everything - spaceframe, engines, computers, crew cabin layout - it'd all be custom. Just about the only thing that might be standardized are weapons, and then only if they need to use standardized ammunition.

Modules don't allow for the seamless customization ships should have.

Starship the RPG

So, I'm thinking about space ships. SHOCK.

I'm thinking about RPGs, too. One of the cool factors with modern RPGs is that you can design your character both aesthetically and statistically. As the game goes on, your original choices weight how your character evolves - what skills you pick, what armor you equip, how you approach various challenges. Each of those is, in itself, another piece of player-generated content.

True, choosing a sword or wand isn't quite as "pure" as shaping a character's face and carefully weighting their statistics. But it is still a player choice that customizes the world to some extent, so it's still player-generated content.

So, I was thinking about starships.

Let's create a game where you design starships. You put together the modules, the layout. You choose half a dozen crew, put them in various rooms and give them various ranks and roles. The starship itself has a specific mission - go to Jupiter and mine Jupitite or whatever.

That's creating a character.

In the course of an RPG, the primary shaping force your character faces is the onslaught of endless waves of enemies. We don't have enemies in our starship game. Instead, you face an endless onslaught of interpersonal drama. You literally bring the monsters with you, because your crew is the source of your difficulties. The longer and more stressful the voyage, the more severe and dangerous the drama is. If you fail to deal with it, it'll damage the relationships of the characters (making the next drama worse), or even escalate to violence against the ship or the crew.

So you deal with it by directing the crew to use specific parts of the ship. If Anna and Bob are fighting, you can send them both to their quarters (or just one, if you prefer) to let them cool off. That's equivalent to "attacking". You can repair relationships and sooth interpersonal bad feelings by having the crew participate together in a recreational activity. That's equivalent to "healing".

Sounds simple, right? Well, not exactly.

Just like an RPG, as you spend time in space your ship develops. The characters begin to customize the modules and get used to them, allowing you to "level up" a module's performance on a specific character. Retrofits and software upgrades allow you to alter and upgrade the kinds of actions a module allows. You can even add in new gear, in the form of replacing modules, redecorating, planting new plants, etc. All of these serve the same role as skills and equipment in an RPG. And, of course, you "level up" (gain customization points) by successfully solving interpersonal drama events - that makes sense, since you come out of it understanding your crew better, and can therefore make your ship more comfortable to them.

It's a relatively simple idea. At the beginning of the flight, your crew might get into arguments over whether to have eggs or waffles. But after a year in deep space, they will all be ready to snap, snarling insults and over-reacting... even as the most critical part of your mission now needs them all to work together! How do you keep them under control?

Just like an RPG, you choose a "class" in a variety of subtle ways. For example, you might go with luxurious crew cabins so your "basic attack" is very effective. Or you could save a ton of mass and maintenance by going with a "crew bunk" system that severely limits your ability to send the crew to their quarters to cool off, but frees up a massive amount of mass and maintenance for other things. These strongly shape how you will deal with the different kinds of drama your crew goes through.

After the mission, when the ship returns home, you can reallocate the crew to other missions (after a vacation) and either dismantle or reuse the starship itself. Either way, the same crew won't be willing to serve on the same ship, so to some extent most of the leveling will be lost.

Mode-changing Designs

One of the things that's been kind of circling around in my head is kind of hard to describe, but I'll try.

When you design a starship (or a starbase, or a lander, or a floating castle, etc), there are certain things that are required (engines, places to live, electricity, etc), but there are a also things which are optional, depending on the nature of the mission. For example, solar panels vs nuclear generators. Comm dishes vs heat shields vs planet-scanners vs docking systems...

There are a wide variety of things which may need to get done on any given mission, but fundamentally the missions tend to be very slow and limited. If I launch a mission to Duna, it has one particular purpose and is engineered to do that one thing. If I want to do multiple things (for example, land and then return home), I would typically build several vessels, each of which has one particular task. Sometimes vessels would be strapped to other vessels, sometimes they would be largely independent, but either way the design is "a lot of single-purpose vessels".

A big part of that is simply that Kerbal's focus is fuel restrictions. If you turn infinite fuel on, you can easily create a multipurpose ship... but the "multipurpose" is really just "landing and launching over and over", which isn't terrifically interesting.

I was thinking: what if we build a multipurpose ship instead?

This is a little bit of a difficult topic, because "multipurpose" is pretty vague. Kerbal has a pretty limited set of purposes you can multi, so let's invent some that Kerbal doesn't really cover. Let's say we want to build a ship that can do orbital transfers, planet-scanning, aerospace maneuvering (not just landing), sample collection, research, and launch.

Ordinarily, the way we would approach that would be to stick modules serving each of those purposes and try to make a ship that could do all that at once. So you'd have this big, knobby research module and you might start to consider maybe leaving it in orbit, etc.

Instead, what if we presume we have quite good 3D printers aboard our ship?

This means that our ship can "transform" by deconstituting our special equipment, then reconstituting a different set of special equipment. So we turn our solar sails into wings, turn our wings into treads, turn our treads into vehicle bays, turn our vehicle bays into research stations, turn our research stations into launch components (heavy rockets)...

It sounds overpowered, right? But we can add in some really fun restrictions.

1) Fab size constraints. Each mode you add takes up more space in the computer/fab labs, which are a constant through all modes and therefore add to the size of each mode... effectively making space and mass requirements more like "modes ^ 2" rather than "modes ^ 1".

2) Core structural constraints. The fab can create all sorts of complicated stuff, but it can't create strong structural components. Therefore, your ship design is as much about the underlying frame you create. The frame contains both internal spaces (heavily shielded and resistant to acceleration) and external spaces (along the surface, or along beams projecting out from the surface). It can also be fun to create an adaptable structure, such as heavy "wing guide" struts that can extend at various angles to allow for various kinds of modes to have various topologies.

3) Reused elements. Modes which share elements can be transitioned between quite quickly and easily, since those parts don't have to be changed out.

4) Direct interaction as astronauts, robotic arms, hinges, or sliding rail systems change the specific layout of a mode without actually changing modes. For example, changing the angle of wings from re-entry to cruise.

5) Speed of transition/prep space. In any given mode, you can add in "prep" spaces. After the mode transition is made, the prep spaces begin to fill with parts for the next anticipated mode, allowing you to shorten the final transition time quite a lot... but taking up a lot of space.

And 6) Available resources and means to gather more.

By allowing players to create a good fundamental layout and then design multiple modes of operation, you can allow players to build a bunch of ships in one, and switch between them depending on the situation. Of course, that means the situations have to vary so there's some reason to do that, which means it can't play like Kerbal. It has to vary much more than that.

We should also consider not just starships, but also space stations and settlements. How would mode-changing fit in with something like that?

Fundamentally, the situations a starship will tend to find itself in are different from the situations a base finds itself in. A lot of the things a ship does involve moving around - hence it being a ship. Bases, on the other hand, mostly just sit around. The situation doesn't change much, and they tend to run on automatic almost all the time. So switching modes is hard to make compelling for a base, since they rarely have any reason to do so.

Instead, let's think in terms of modules.

When your construction ship arrives in orbit around your destination, you'll need to construct a base.

Let's say that the base being constructed can be made out of modules rather than as a single unit. By stacking modules (space station) or linking them (ground station), you can create whatever base you want piece by piece.

Therefore, in our design phase, we can do the same thing that we do for a ship - create a basic module frame that can interlock with itself, then create various modes for it. Unlike a ship, the modules don't need on-board fab labs, so you can create a lot of different variants. Then you load up the construction ship with a number of those frames. Since they interlock, the empty frames hulk out in front of the construction ship, many times its size, just locked together in skeletal form until ready to be unlinked, filled in, and fitted properly into permanent place.

With this constraint (all modules in a base must have the same fundamental framework) we can make the same basic gameplay (designing modes) work both for ships and bases. Of course, the game would still need to be designed such that the actual moment-to-moment situation was complex and changing enough to make that modular design worthwhile. If you can plan ahead too easily, then you could design too easily.

Perhaps something like a "mission" mode would be worthwhile, where any given ship or base is in the midst of some kind of evolving situation that couldn't have been predicted back home. Anything from getting caught in a permanent hurricane to being infected by an alien virus to having to deal with a metal-eating radiation to discovering that a valuable deposit of unobtainium is laced with dangerous screwyouium. Or maybe even something like a crew member ascending and gaining psychic powers, and trying to come up with a layout that uses those new powers well.

A lot of functionality has to vary wildly based on the situation. Physics stuff, sure - but also things like research, data transmission, fuel harvesting, and so on. As the mission's conditions evolve, the player will need to choose whether to deal with the screwed-up parameters with additional resources, or just eat the penalties.

Anyway, that's my thoughts on the matter. I really do think that designing a core frame and then fleshing it out with "modes" could be very compelling.

Basic Infrastructure

I've been thinking about a mechanic that base-building games overuse and misuse:

Building basic infrastructure.

Nearly all base-building games heavily feature basic infrastructure. For example, in Evil Genius, you always needed to create all the various kinds of rooms to get your mook ecosystem running. Same with Dungeon Keeper. In SimCity, you need to get your roads and power and sanitation running, etc, etc.

These games feature you building one base (or city, or whatever) at a time. The complexity of getting the infrastructure "right" is the main focus, because it takes quite a while for the base to mature and many of the weaknesses in your approach appear at different levels of maturity. That is, the game introduces more and more layers of infrastructure ("your citizens demand police stations!") and your basic structure becomes less and less effective.

However, in games where you build a lot of bases (or rockets, or whatever), this isn't a good approach. You can see that in something like Starcraft: the infrastructure required to get a base running is generally pretty straightforward. Mastering the various paths of optimal construction is a pretty low-level skill - it's pretty much assumed you have the infrastructure part of the game down pat before you even play your first multiplayer match. Then the skill lies not in laying out the infrastructure, but in choosing the path and timing.

I'd like to think that there's a third option hidden between the two.

That is: instead of layering on more and more types of infrastructure as time progresses, we start out any given base with the layers already present, chosen by the player.

Let's say we're making a SimCity game. There's a lot of complexity to be found in laying out roads and sewers and power, but we decide that we're going to simplify all of that. Instead, what we're going to do is make the environment matter a lot more. While it is pretty easy to lay out roads and sewers and power, now you have to consider how those requirements will differ depending on things like winter snows, boiling-hot desert days, a continual flood of poor rural folks moving to the city, and even just simple things like hills. Moreover, the complexities can overlap. You might want to build a city in a hilly desert with a flood of rural immigrants.

The core gameplay is the same in the sense that you're still setting up cities. However, we've moved the complexity from a single, complex case to a number of small, simpler cases that interact. This makes it more suitable for creating many cities at a faster rate, rather than only a few cities at a very slow rate. This, in turn, allows us to leave cities running and allow the player to have a constellation of cities they (and their friends) created.

Let's come up with a different kind of game: there's a fantasy world, and it's got floating islands above it. But nobody's been able to get to the floating islands... until now! You invented the hot air balloon! So the game is about building cities on these islands.

The camera is strict side view. The thickness (depth) of the island at any given brick is how high up you're allowed to build above ground level, creating some easy and flexible topology limits. In terms of basic infrastructure such as places to live, warehouses, plumbing, etc - that can all be handled by very simple modular buildings. No need to painstakingly lay those out - it's not the focus.

Instead, we have a number of other facets that do require infrastructure, and the player is allowed to choose how much he wants to tackle these. For example, building docks for airships. Catapults to throw supplies to other islands. Giant nets to catch incoming supplies (from the ground or other islands). Dangling rope "elevators" to transport to and from the ground. Signal towers to communicate with other islands.

All of these have some amount of infrastructure required. Not only do you have to put in the structures to perform the tasks, but the exact speed and quality of the performed task will vary depending on how well you support it. They also can interfere with each other - you need to keep airships out of the catapults' line of fire, and keep them out of the smoke from the signal towers...

And the player gets to make those decisions. How large are the catapults - that limits how far they can fire, yes. And more of them is a higher fire rate. But how long they take to winch back and reload also depends on the support structures built around and beneath them. The player gets to try to cram as much of the kind of functionality she wants into the limits of the space.

That's some basic functionality - networking between bases - but there's a lot of other kinds of infrastructure.

Productive infrastructure. Not every base needs to be able to brew mistmead, but you might have one base that specializes in doing just that, providing your whole network with the benefits (and profiting). Not every base needs to have a mystical research tower. Not every base needs to gather books from all around the world. But all of these tasks can be done to any extent with any base that the player chooses. In addition to having interesting specific infrastructure requirements, they get along well with other infrastructure requirements. The librarian city will want to host a lot of travelers. The research tower will want extensive signal towers. The mistmead city needs a lot of heavy shipping and farms...

This can be made significantly more complex if the process produces side effects, and you have several options about dealing with them. For example, your magical research tower may produce a magical mist. The longer experiments run, the heavier the mist gets. You have a lot of options on how to deal with the mist. You can stop researching for a while, letting it fade off. You can put up towers on islands in a windstream, letting the native wind blow it away. You can put up fans yourself to blow it away. You can build your tower significantly taller than the rest of the buildings so the mist doesn't affect them very strongly. You might even be able to figure out a way to harvest the mist, or use it to grow magical plants. You can combine these in any way you please.

Besides productive infrastructure, there's also hazards. Exploring has always been a big part of our human endeavors, and exploring naturally takes us to places that are foreign and often dangerous. This can be reflected in various environmental hazards.

A city over a deep jungle might be able to harvest all sorts of interesting things with landing teams... but they won't be able to rely on the local farmers giving them any food, because there aren't any local farmers. You'll need to either pipe it in over a complex series of catapults and nets... or you'll need to grow it locally. Or some combination.

A city over a desert might be exposed to nasty levels of heat and sun. To keep your citizens healthy and energetic, you might use fans (the same ones that blow mist away) or overhanging tarps (that cast shadow as well as they would shed rain). The heat hazard is also an opportunity, though, as it makes it possible to grow desert-related plants and animals and monsters, as well as do desert-related magical research. Drying food and optic heat beams are also possible.

A city over an icy pole might be insanely cold, requiring you to heat the place up with, say, magical firepits. But the firepits have a zone near them that is too hot, and a zone far away that is too cold. So the topology becomes complex. Of course, the cold is useful as well - you can raise cold-attuned plants and beasts, perform cold-related magic, etc. You can also freeze things, harvest ice, and see the stars more clearly.

These conditions can easily be mix-and-match. For example, an extremely high-flying (low atmosphere, isolated) island above an ice field (freezing cold) in a region imbued with sinister magic. The conditions also scale: it's cold, but not THAT cold. The air is thin, but not unworkably so... etc.

In this manner, the player chooses what island to develop for what purposes. The player chooses what conditions they want to try to handle, and what benefits they can get out of it if they design well.

This is an alternative to "slow bases" like SimCity and "fast bases" like Starcraft. It's the "many bases" approach.