Misusing the Moon Crystal

I was thinking about childish depictions of mad scientists and construction. Typically, they use everyday objects in ways that almost make sense, but not quite.

For example, in the new Luigi's Haunted Mansion game, the scientist cleans shards of the moon crystal by sticking them on a record-player turntable and spinning it around while scrub-brushes happen to be nearby.

The trope is hardly new. The Incredible Machine is a whole series of games about misusing common devices such as balloons, lighters, and mousetraps to accomplish whatever weird objectives you might have.

I got to thinking about this when I saw a preview of the new Terraria version. It was raining, and a lot of the enemies broke out rain gear. One of the players said they were going to kill a slime because they wanted the umbrella. The slime kicked his ass, so I never learned whether he could have gotten that umbrella, but the idea gelled a bit in my head.

I love constructive games, but one of the biggest issues with them is the functionality of the various pieces you get. If you expand the breadth of parts and functionality, you will start to drown the player in complexly nuanced alternatives that are hard to tell apart. For example, in lightly modded Kerbal, there are fifty different rocket engines. They do all have different stats. Some are vectored, some perform better at sea level, some in vacuum... but they blur together because there's so many of them. You'll typically just choose one for each size category and stick with it.

But if you misuse objects, then they come with additional color context that keeps them feeling distinct. Moreover, if the ability to misuse them is flexible enough, you can also make it easy for mods to add new items and encourage their misuse.

For example, an umbrella. You could see it being added to the game, and the stats are put in. What is it useful for? It, uh, it keeps the rain off your head when you hold it? Not terribly exciting. Maybe you add in the ability to strip it down for resources.

But what if we allowed the player to creatively misuse the umbrella?

The umbrella sheds falling water. If falling water matters, you could mount an umbrella in places to shunt water away - for example, to keep a candle lit, or with a whole bunch of them to serve as a roof. If our physics is decent, then shedding water is the same as being water resistant, so flipping the umbrella upside-down would allow it to become a boat or a water-holding dish. Sure, with low maximum strain, but that's fine.

The added capability of the umbrella to open and close allows you to use the water-shedding/retaining abilities more freely, while the existence of the handle offers a specific mount/control point. So you could create a rain-shade that moves umbrellas out and flicks them open when it rains, and does the opposite when it's sunny.

But the existence of the flip-open mechanism can be used without the water-shedding capability of the umbrella itself. You could use it to nudge things. Glue a string to the umbrella and yank on it by opening and closing. You can also use non-water things - use the umbrella to contain helium, or dog food. Whatever.

You could also go cartoony: the drag on the umbrella acts as a parachute when open. This makes it both more valuable to equip and also suitable for even more misuse if you build devices that go into the air or need to fall slowly.

Anyway, when someone mods in an umbrella, if they know what they're doing they can build it so that the player can misuse it in a fantastic number of fun ways. Moreover, if someone else mods in slimes carrying around umbrellas when it rains, this changes the context and common-ness of the umbrella, effectively completely changing its nature. People who would never have bothered using umbrellas as design objects now find they have plenty of them, and start to look for ways to use them.

The fact that they are umbrellas rather than "extendo-joints" adds a lot to the context and memorability of them. It also allows us to package several distinct pieces of functionality into one object but still make it easy to remember: everyone knows how an umbrella works, so when you see it operating as part of a device, you can quickly grasp that it can open and close and keep water out and is pretty light and so on. There's no mystery. It's one composite object with a lot of functions and attributes... and we already know them all! With a glance!

A lot of modern mechanisms are a bit too slick for this, which is why turn-of-the-20th-century mechanisms are so popular. A vacuum does specific things in grand strokes, and it can be misused in all sorts of delightful ways. A cell phone, however, has a much more nuanced and complex set of operations that makes it difficult to misuse, unless you simplify it down to "vibrates when called".

Any way you cut it, though, adding in these complex, context-heavy items and allowing the player to misuse them should allow for a more vibrant world, and a wider variety of items without the feeling of drowning in variations.

Secrets in an Open World

I was thinking about exploration as a core part of games.

A big part of open worlds is exploration, yes. Awkwardly, they are also incredibly bad at it: most open worlds have very little worth discovering, and most are vast empty areas with just vague variations in layout. This is especially true in generative open-world games like Minecraft.

Minecraft and other generative world games such as Dwarf Fortress, Terraria, and so on do have interesting things to discover, and exploring is rather fun. In the long run, however, these games boil down less to exploring interesting new areas and more to figuring out which preset terrains are nearby and which you have to go search for. What I mean is that, while the world is endless, the secrets are not. Experienced players are not exploring so much as exploiting known terrains.

Of course, non-generative worlds have the same problem, but in those games you play through the game and stop. In a constructive open-world game, you can keep playing pretty much forever. So it makes sense for a constructive open-world game to allow for exploration forever.

Sounds nice, but there's a lot of barriers to this.

The first barrier is the easy one: pacing. In a constructive game, you tend to construct things. This typically means establishing a home. You need to be careful how you define the concept of "home" and "travel" so that even after the player has built a home, they can continue to explore. As far as I know, that means one of three things.

1) The home is portable (a space ship, for example).

2) Travel is often via teleportation or some similar method.

3) The home is temporary, or some other means of making the player create new homes in new places all the time.

The second barrier is much more difficult: you need to have an infinite number of interesting secrets to explore.

Normally, secrets are custom content by the developer. For example, pre-existing mines in Minecraft, randomized super-monsters in Dwarf Fortress, jet packs in Terraria... it's entertaining, but obviously limited. Even if you try to make it never-ending (for example, by randomizing the nature of each super-monster) it still remains a known thing... just a random variation on that known thing.

This brings up the question of what "new" content really is. If I build a fortress and find a demon on Monday and again on Friday, the demons might be different enough that they provide radically different kinds of challenges. The rareness of the content and the high variability means that I'm always taking a gamble.

On the other hand, if I dig down into corruption in Terraria, it becomes pretty rote after a while. It's a common part of each adventure, and even though the layout varies, you quickly figure out various optimal approaches and go into it with the proper equipment.

To be honest, I think that last bit is important. "Proper equipment".

I think "new" doesn't necessarily have to be completely new. It just has to be a new kind of challenge to make you think on your feet. If you know the parameters of what will happen and you're prepared for them, it's not exploration. It's just mining, just a skill challenge.

To that end, I think this question of "how do you give infinite new secrets" is actually two questions: "how do you give infinite new content" and "how do you continually reframe it to keep the player off-balance".

Reframing is a game design decision of the most basic sort. You have to create a game where the player cannot always be "ready", but you still need to allow them to create - since that's the point of the game. There are a lot of options.

One is that the things the player creates are orthogonal to the content in exploration. That is, the player can create their character's appearance, but not equipment. They can create a castle, but when they go to explore they can't bring anything in it with them. The problem with this approach is that reducing the player to a specific baseline power level is just as static a frame as allowing them to perfectly prepare.

So the other option is to somehow come up with ways to allow them to have erratic power-ups based on their creations. For example, they bring two random items from their stack. Or they keep jumping into the body of a random new colonist, who is equipped with whatever the colony provided her to do her job.

You can also offer unique and varying debuffs, such as metal being forbidden in a given cave, or turning the player into a frog. Granting random upgrades has the same effect - allowing the player to fly will shake up the frame just as much as disabling their jump.

In all cases, balance is tough to maintain. It becomes more and more difficult to guarantee that a given piece of content can actually BE explored. Rather than trying to fix that, it's probably best to embrace it. Let the player come back and make steady progress later, but always with a shaky frame, always with shaky prep. Failing is fine, whether you die or go home.

Anyway, with the frame-shaking in place, we can talk about the big nasty: content.

Exploration requires content. And not just any content: meaningful content. Content that the player will notice.

There are a few subtypes of this.

1) Skill challenge content. This is the sort of content offered by something like Spelunky, where randomly generated segments challenge your mastery of the gameplay. May also be puzzles that challenge your mind - it's the same basic idea. A skill challenge. These can be largely randomized.

2) Color content. This is content that sets a mood and helps pace the play. This is difficult to create randomly just because it needs to vary, but it includes things like grottos, overlooks, tunnels decorated with appropriate objects, shattered columns, polished mirror-walls... things that the player notices when they are in any given area, but don't really have any gameplay purpose. Color content is best when it has context - that is, when the content meshes well with the upcoming/ongoing challenges.

3) Narrative content. Sometimes overlapping with color content, narrative content strongly implies that something is/did/will happen/ning/ed, and typically creates implicit sidequests or, at least, side-narratives. For example, a locked door, the key somewhere else, and the clue to help you find the key. Messages about a monster, scrawled in blood on the wall. A fairy prince who helpfully takes you on a tour of the castle. An alien spaceship hanging in orbit, apparently dead. A ring with a name etched into it.

4) Mechanical content. This is content that has strongly idiosyncratic mechanical functions. This can be mechanical as in actual gears and such, but it usually refers to the game mechanics. For example, if you're generating new monsters, you'll want to be able to generate new abilities for them to use in combat. Just adding a die of damage or a bit of health won't make the monster feel mechanically special. But allowing monsters to have extremely unique and far-ranging abilities will make them a challenge, especially since those abilities will frequently interact with the other three types of content.

All four of these kinds of content can be generated algorithmically, usually by defining prescripted segments. You grab the pieces, alter some details, and glue them together with other randomly-grabbed pieces.

But that only lasts so long, and it's pretty expensive to add in more fundamental content.

So the other option, of course, is to use player-generated content. Since we're talking about a constructive game, that's obviously a good idea. They're already building things, after all.

The problem is mechanical content.

The other three can be created by players. In fact, you can shape your game such that they make those things incidentally as they play, so there's no barrier to resharing it. But mechanical content is both the most difficult and the most important.

I'm not sure how to accomplish it, aside from letting players make mods for your game.

Hm. Just to make things complicated, in a constructive game nearly all mechanical content will relate to objects which can be incorporated into player constructions.

HM.

I feel like there's actually an easy way to do this. I just can't quite see it.

Lands of Godus

This is a rambling discussion of terraforming as a gameplay mechanic. It's me refining some design details for my mech game.

So, yes, I've been playing Godus on and off since it went into public beta. This is not really a review of Godus, although I do have to talk about Godus to get to what I want to talk about.

I really like the land in Godus. Now, the actual process of terraforming it is quite clunky, but the feel of the land itself is incredibly nice. The fine layers end up building some really nice layouts.

For example, when chasing buried treasure, I ended up digging a deep "bore hole". When building a flat region for a "village", I created some hundred-foot-high pure, sheer cliffs that broke into jagged regions at the edges. When created stepped terrace "villages", I ended up with a beautiful, meandering hilly village.

The feel of the land is spectacular.

Unfortunately, the game itself is pretty crap. But the feel of the land sticks with me. I keep going back for a few minutes each day, not because I care about the game, but because reshaping the land results in very compelling results.

I thought about how to make a game more intricately linked with this kind of land. Godus is just about flattening everything down for human use, which is a very dull kind of landscape to aim for. I started to think about other kinds of uses and aims we might have. Also, since my focus is on science fiction, I'm not thinking about primitive human villages.

So, a big part of the feel of the terrain comes from variation in height. I feel most interested when I create interesting topologies. Cliffs, boreholes, terraces, patchy surfaces. What use could they have?

My concept is basically to make the surface of the planet into a Minecraft-style crafting bench. When you want to build a building, you have a certain size frame in orbit. You call up a reticle, and it highlights an area on the map the same size as the frame. The building that will be constructed depends on the topology of the surface.

If it's just a flat region, you'll build a hab module (at one particular size). On the other hand, if there's a borehole there, you'll build a water trap. If there's a little bump in the center, you'll build a mech assembly tower. If it's a gentle slope, you'll build a terraced vacu-farm. This can be made more complex by having special tiles inside the reticle, such as ore or trees or water or something. It's not just height, but also resource.

This is one way I plan to force the player to spread their colonies across a planetoid instead of just putting everything down in one spot: the resources will be scattered around, so if you want a functioning society on a planetoid, you'll need to have different kinds of colonies specializing in different things in different places.

Unlike Minecraft, the resource tiles are not actually a single tile of that resource, but are simply markers indicating that a tile has access to that resource. For example, an icy tile. You could certainly chip it out and walk away with a block of rock with some ice on it, but that's not a resource tile, it's just some resource. The ice tile in the wild represents the way ice will form in that spot, and therefore a building on top of it will be able to rely on a steady ice diet. Similarly, an iron ore tile doesn't mean there's iron on the surface, but instead represents that there is iron somewhere beneath that tile. A mining building will dig down to the deep ore, but stripping away a few surface layers won't get you much if any actual ore.

This offers a means to help us create interesting terraforming opportunities, because we can talk about resource husbandry.

What causes an icy surface to form on the dust and rock? Well, ice forms in areas that are constantly in shadow. This means that you can create environments which create icy tiles by carving down or building up such that there is a shadow. The height and direction of the wall you'll need to create depends on the latitude you're at. If you're at a pole, the sun will hang low on the horizon, and a single layer of land will cast enough shadow to keep an area perpetually in shadow. Nearer the equator, you'll have to build a very deep hole - and even then, the ice may fade in the summer.

This is a pretty simple system, right? But it creates vast amounts of potential.

For example, what if we want to start terraforming our landscape? We want to create a stream. Well, one way to do it is to create a lot of ice patches and, when they melt in the summer sun, a trickle of water will flow from each. By etching courses into the landscape, you can control this trickle of water and cause it to course along a specific route. Life could grow in the waters, especially if you direct them into still pools that might be able to last until next spring. With enough time and effort, you could even start to grow plants from that water.

This terraforming has nothing to do with putting down buildings or colonies. We create a landscape that serves other purposes. Environmental resources and hazards - weather, radiation, heat, cold, water - respond to the shape of the land to some degree. So we can adapt the world to suit our needs.

A big question with this sort of thing is "what about caves?"

Caves would obviously allow for shadow even at noon, and allow for shelter from wind no matter what the time, and so on. But caves are a complicated topic. They could be a whole game in themselves.

So I don't think I'll allow for caves.

I mean, players can create them because they can alter the surface of the world, but buildings are dropped from orbit, so any kind of overhang prevents structural construction. There might be some way to use overhangs to help generate resources (or you could encase a building after the fact), but the downsides would all be severe enough to make it a curiosity instead of a primary method. It's just too much of a pain to implement the complexities of caves.

Cliffs, on the other hand, have an important role to play. In addition to looking cool, cliffs offer shade and protection from storms. Unlike in a cave, you can still use solar power and transmit radio signals into orbit when you're up against a cliff. So cliffs are useful, especially in areas where the sun is harsh or there is an atmosphere. In addition, some kinds of life will prefer to form between layers of rock, so cliffs would be ideal for them. Another kind of resource husbandry system.

Aside from the raw terraforming, there's also seasons and days. Every planetoid has seasons and days - many of them unreasonably long or short. The flow of husbanded resources (such as shade, ice, life, etc) will change over the seasons, or even from day to night. This means that a building which relies on ice might be robbed of ice for long stretches of time, essentially useless for much of the year. Perhaps building the walls up higher will extend that lifespan...

All of this is fine, but it doesn't change the fact that right now my prototype uses ugly square bricks. A big part of what makes the Godus terrain so inviting is that it is gently curved.

It's actually not too hard to do that same thing with my terrain, but it is worth mentioning that the UV mapping might be really annoying, especially when one layer has several different kinds of bricks. Also, I don't think Godus simply uses rounded square terrain. I haven't really looked into it in detail, but it looks like it either uses hex terrain or square terrain with alternately-weighted columns/rows.

Well, I should be able to design something vaguely decent on that front.

Hm. This was a lot more rambly than anticipated.

I'm never sure whether to publish these rambling essays or not. They're mostly me thinking to myself.

Well, I guess there's no limited page count, so I'll publish.

Fun in the Mech-Moment

One of the things I've always struggled with is that I really like making games where you can build things, but I also really like making games where you get a really interesting moment-to-moment feel. The two don't really intersect.

As an example of moment-to-moment feel, think about Crackdown (or Saints Row IV). Moving your character around is fun. Think about a good racing game. Think about Pilotwings. Spider-Man 2. There's a simple joy in moving around that comes from a combination of very tight controls mixed with skill challenges. It's fun to move around AND there's an interesting place to move around in, basically.

I made Astrophobia with that kind of thing in mind, although it wasn't "fun" so much as "atmospheric". But... I was having a really hard time enthusing myself to actually turn it into a game, because there's no construction involved.

So I started to think about construction and movement in the same moment. And I started thinking about mecha. Mecha are actually far more suited to construction than combat, and they're large enough to give you a range of view that allows you to build things.

In terms of construction, I have some fun thoughts on that involving a slightly bizarre combination of Minecraft's crafting bench and Populus' land-clearing... but in order to make it worth playing, the mech has to be fun to pilot.

In oldschool mech games, the piloting was an ongoing strategic challenge rather than actually being fun in and of itself. Nobody played Mechwarrior because they enjoyed slowly slouching behind a hill. They slowly slouched behind the hill because they liked playing Mechwarrior.

Newer mech games tend to have mechs that move like first person shooter heroes, blitzing around the game map like crazed weasels. But speed doesn't make piloting them fun, it just reshapes the combat. Piloting the mech is occasionally fun, but more often than not it's still just an ongoing strategic challenge, just like movement in Quake 3 or Left For Dead or whatever.

I was considering, then, how to make a mech fun to pilot. How do you make the player go "HOLY MOLY I JUST WANT TO RUN AROUND AND LOOK AT STUFF IN THIS MECH"?

A lot of the fun in games like Crackdown come from a striking verticality and a lot of collectibles. The collectibles pull you to the next building, while the verticality provides a roughness to the motion that requires you to be vaguely skilled and strategic, switching between climbing, running, jumping, and gliding.

While we could try to make our planets more vertical, that's not really a great idea because our verticality would be broken terrain, which wouldn't be all that fun to navigate. We do want some verticality, especially in specific challenging areas (mountains), but in general verticality will have to play a much smaller role due to our lack of structured surfaces.

To replace it, I plan to use surface type.

Think about a typical airless rock like our moon. Its surface is shaped primarily by meteor hits. Craters on top of craters.

While it may not be perfectly accurate, we can model these surfaces as having different textures. The bottom of the bowl of the crater has been blasted flat down to the rock, so it's a hard, relatively smooth surface. The lip of the crater is where the heavy debris fall, so it's got a kind of heavy dirt-like texture. Outside of the crater is where the light debris (dust and sand) land. The rays radiating from the impact are where large pieces of debris skidded along the surface, clearing a swath clean of dust and leaving bare rock.

As a mech, you would navigate these different areas in different ways. The flat, hard surfaces can be simply walked/dashed across, and you can land or leap without damaging them (unless you're a really heavy mech). The dirt-like slopes are generally amenable to you, especially if you're a lighter mech, but they are slopes and you do leave footprints as you pack down the dirt, even perhaps sliding down the slope. It'd be better to switch to whatever high-traction mode you have, perhaps even using your hands if the slope is severe.

The dust areas... well, dust is basically a liquid to something like a mech. You can walk through it, of course, but you'll sink in it. Throw up huge clouds of dust if you're moving quick or landing, reshaping the dust fields into dust dunes. Drowning in dust is hard on your joints and/or intakes, of course.

But navigating dust doesn't have to be a pain. You just have to change your mindset. You can leap across dust fields - landing in the dust with jets a-blazin will drive it away, then you can jump again before you get swallowed in it. Or have a ski mode where you have jets propel you along on skis. You'll kick up dust, yeah, but it'll all be behind you. Just remember to change back into foot mode when you reach rock... you might even have to jump over that ray where there's exposed rock.

Planets with atmospheres have a different jumble of terrains, but it's still the same kind of deal where you switch stances or navigation methods.

I'm thinking that controlling a mech will be something like this: WASD and mouse camera, just like Lara Croft, right? Shift runs. Space fires jets. If you are holding shift, the jets fire to help you accelerate along the ground (horizontally). Otherwise, that's a jump. You can hold space to keep firing jets, whether to make your jump longer or continue your jet-assisted sprint (especially useful on soft terrains where you want to move fast and not get stuck). Jets will automatically fire to prevent you from cratering after a fall.

Holding control switches your gait to its secondary mode, whatever your design has made that. It might be your feet changing to skis, your hips extending for a lower center of gravity, wings popping out of your back, scrambling on all fours, and so on. That's all up to how you build your mech.

Navigating the world can be done just by walking everywhere, if you want to suck - you can navigate all of Saints Row IV's city without jumping or sprinting, too. But in general, you'll be switching out between jumping, dashing, sprinting, and clutching (whatever your secondary mode is) to help you keep a good speed across varying terrain types. This is more important than your average game, because it takes a considerable amount of effort to get up to speed, but there's really no maximum speed. You can cover vast distances if you have a good lane and a suitable mode to keep your speed high. Skidding is obviously a big factor here, as is ploughing into a terrain type while you're in the wrong mode (or just slamming into a cliff).

Now we need a reason for the player to want to navigate through this world.

One reason - a big one - is the construction half of the game. Different parts of the planet have different resources, and are amenable to different kinds of buildings. So you're likely to have outposts quite removed from one another. You could use jets (if atmosphere) or rockets (if not), but that wastes a lot of fuel and you have to maintain them - and they can really only go between outposts with landing strips/pads. Railways and roads are handy, but you have to build them.

For much of the time, the easiest way to get between settlements across the rocky, blasted landscape will be by mech. This is why a good top speed is often important: you might be trying to cover hundreds of kilometers.

In "overseer" mode you can simply switch between settlements, but if you want to transfer people or resources you'll need to actually have something physical move from A to B. NPCs can use mechs, rovers, trains, or trucks to transfer resources, and you'll be relying on that a lot. But there's also times when you want to transfer something faster, or something that can't be automated. For example, crew cycling to keep people from going stir-crazy. Cables for an emergency repair. And so on.

But just wandering the planet is also fun, because you're in a mech. The things that interest a mech are not the same as the things that interest a human, and this is where collectibles come into play. Forming a "chain" is the basis of any movement-oriented game, whether we're talking about Crackdown's collectible skill orbs, Pilotwing's floating rings, Mirror's Edge's next glowing red structure... the idea is you have to make the player want to go to a place, and the easiest way to do that is to put up a marker of some kind that they want to reach.

In our case, we'll be using the construction half of the game to support this.

Various survey points will be indicated - typically the center of craters and the highest peaks. Reaching one of these does a quick (zero-time) survey of the surroundings. This does a few things.

1) It improves your general knowledge of the planet, slightly increasing the performance of people who work there.

2) It reveals anchorpoints.

3) It reveals, after a day has passed and people have analyzed it in detail, hidden resources.

Anchorpoints are simply places where the underlying rock or ice is unusually solid and reliable. Buildings on anchorpoints will be the "tall" variant, significantly better than the "short" variant normally deployed. Hidden resources are similar: resource tiles are part of what allow you to build buildings (playing the role of a "slot" in a minecraftlike "crafting surface"), so uncovering a small resource deposit means that you may have gained the ability to place an unusual building in that area and can therefore build a more robust base.

Your mech can reshape the earth and designate drop points for buildings at any time, so these aren't simply collectibles. You may find yourself reaching an anchorpoint and stopping, looking around, stamping a flat spot and dropping a building marker on it. It's a combination of exploring and base building.

You may also want to do this groundskeeping near already existing bases, because your mech is good at carrying cables and rails and so on, so you can build the infrastructure of the base if you want. Just be careful: heavy mechs will stamp down dirt and crush rock as they move. Actually, you'll probably leave a trail of destruction in the landscape even in a light mech, if you're moving fast. It's part of the fun.

Another factor unrelated to this is weather.

Even on airless rocks, there is something akin to weather. Plumes of dust you've kicked up, the heavy beat of the sun, even asteroid impacts. In places with weather, wind, rain, sandstorms - even just clouds blocking out the sun.

One aspect of this is the heat or cold. I like the idea of mechs having to worry about hot and cold. You can build your mech with heaters or coolers to blunt the effect somewhat, but in general you'll have to blow coolant (a limited resource) or spend energy (making you unable to move your limbs for a moment).

I like the idea of making your run take these into consideration even while you try to keep your speed up. Run through dark areas, because coolant is 3x more effective when the sun doesn't vaporize the mist. Heat yourself while you're arcing through the air in the middle of a jump - you don't need your legs right that moment... but be careful not to tip over in midair!

I also like the idea of wind, especially with vision-obscuring rain or dust. I like the idea that you can see a given range, and beyond that it's just wireframe or IR-reconstruction or something. This means you can "see" from the point of view of not careening off an edge, but you can't see what kind of terrain it is. You'll have to deduce it from context or play it safe...

Heavy winds can buffet even a mech, and I like having to take them into consideration when you jump. I think the ideal solution would be to have a constant wind gauge, but also a "wind in five seconds" gauge that you can use to either avoid getting swept off your feet... or jump into the air and let it take you in the direction you want to go in a sudden gust. Mind the dust in your joints, of course.

Unrelated to everything, I like the idea of this psuedo-voxel system because it can highlight the trail that mecha leave. If you're trying to track a mech, or find a fallen meteor, or figure out what buildings were damaged, the game can simply compare the map you had to the real map and, if your map has an incorrect tile, it'll fix that tile and flash a little spire of light. So tracking a mech means moving in the same direction and watching for which particular stamped-down areas weren't stamped down last time you were here. They'll flash.

Anyway, that's my idea.

Techtris

Construction is a skill, and that's why construction games are usually very interesting to me. Whether you're building a bridge or a space ship or a castle, you are relating these objects in a complex space and then testing their fitness.

Something like Kerbal has more staying power because it has a lot of different kinds of tests of fitness, especially with mods. If you're doing a bridge-building game, the only test is to have a bridge that things can go over. You can build a lot of random fun stuff, but the game doesn't particularly care. On the other hand, in Kerbal the primary fitness test is launch survival... but then the world opens up and you can choose what kind of challenges you want to take on, and it offers you feedback based on those specific challenges. Successful mission to Eve? There's about a dozen possible approaches to that, and your design can therefore be rated in a dozen different ways. Lots of open-ended design.

That in mind, there are pretty basic restrictions on how you build things - in Kerbal and in everything else. There's a particular primary concern that everything arises from. In a bridge-building game, it's the bridge's ability to resist weight via supports. In Kerbal it's the ship's ability to survive thrust. The specifics of the vehicles/thrust change the fitness test, but it's still the same basic category.

Changing Kerbal or a bridge game to subvert that test weakens the game dramatically. For example, in Kerbal there are mods to help you set up base on the moon and launch from there. This sounds really cool - and it is - but the stresses of launching from the moon are microscopic. The challenge is slack as hell - as slack as if you set all the cars and trains to weigh 0 kilos in a bridge game. This isn't necessarily deadly - if there's another fitness test waiting to be applied, it can still be fun. But there generally isn't.

I was thinking: what other kinds of core fitness challenges could you create for a constructive space game?

Well, I've talked about aging: taking into account how durable things are and how they will break down. Then it's more about balancing time instead of balancing rigid mass. There's also the ever-popular option of combat as a fitness test, but that's boring.

I was watching a few videos about people putting together rockets and the CMS, light techno playing as they painstakingly assemble all the pieces. Here's one short example: CMS install.

And I thought, hey, there's an idea. What if the final structure of the device/station/ship isn't the main fitness test, but instead it's the actual construction?

For example, in the last essay I talked about using chemicals in an alien atmosphere to create drinking water. You'd just slot in the various conversion nodes - air intake, CO2 filter, CO2->O2 converter, O2->H2O converter... while it might be weighty or power-hungry, it's not really part of the core fitness test, because there's nothing particularly interesting about the physical layout of the nodes.

On the other hand, what if you had to ship them into space all disassembled, and then assemble the unit in space? These aren't structural modules you're slotting in. You've got some kind of structural frame, and you're embedding racks, wiring up connectors - all in a confined space, in zero gravity.

Now it's a topological puzzle. You're in space. Can you get the chemical processor into the area you're assembling it in? Can you rotate it to the right orientation? Can you fit it into the right spot, past whatever other things might be in the way? Can you get to the connectors and screws and tubes to actually connect it?

You might think "Oh, just assemble everything in an easy-to-get-to tower..." but you can say the same things about all construction games. "Just connect every part of the bridge to every anchor" "just surround every part of the castle with garrisoned walls".

The question is: what pressures the player to try and cram more and more stuff into less and less space? In most construction games, they limit the number of things you can have by putting price tags on everything. In our game, we would need to find a way to limit the space you are allowed to fill. The obvious answer is to have the containment structures/frameworks have specific sizes and shapes. You certainly can just put one thing in each framework and leave yourself a lot of space... but the framework is the heavy part of the space vessel, so that's going to make it hard to accelerate and turn.

I think it'd be a fun challenge to make the assembly process feel right - feel controllable and not too pat. The player might make a kind of "record" of how to do it while designing the ship in the first place, then NPCs could assemble any number of them in game days. You could even watch them assemble in the background of whatever else you're doing, perhaps with light techno playing in the background.

There are a few key areas to balance:

1) How the shape of the object fits into the chassis is obviously critical, and you might need to make it adaptive or have a variety of each part to support different fundamental shapes of chassis.

2) The connectors between objects are just as important, because you have to connect whatever you put in to whatever else relies on it. This makes the order of construction really matter, because a clever designer will put connectors to object A and B behind object C for space concerns, and then just be sure to add object C after adding and connecting A and B.

3) Mechanical structures matter, because racks which slide out, lids which open, spaces which expand and contract, legs that swing away and then back... these let you get at spaces that will be locked back down, or provide access in ways you would have a hard time with. This means that the chassis variety can be extraordinary: not just spatial configuration.

4) Secondary effects such as vibration and heat matter. If you have something that vibrates butting up against something that's taking pictures, you'll get crappy pictures.

Hm!

Sort of "techtris", if you will.

Challenge Stacking

I wrote a longggg post on how to get players to prefer elegance in their constructions instead of "bigger = better". But it got out of hand and was much too long, so let's take a whack at one of the central ideas:

One kind of elegance, and the easiest kind to implement for a game, is suitability.

For example, you want to land on an atmospheric planet, like Earth.

One solution is to get a big rocket with heavy landing struts. Use the rocket's thrust to decelerate safely to subsonic speeds and continue thrusting all the way to the surface before landing a huge, empty fuel tank on heavy struts wherever you decided to land.

The other option is to drop a teardrop-shaped probe. The bottom of the teardrop is a heat shield, which safely absorbs the re-entry burn and lets friction take you down from supersonic speeds. Then the parachute deploys, slowing you further. The heat shield drops away and spindly little lander legs deploy - tiny, because they don't need to weather re-entry and don't have to support an entire fuel tank. In the end, you safely land without expending any fuel at all.

It's obvious which of these solutions is more elegant. The question is: how do you reward a player for coming up with the second one instead of the first one?

Giving the player limited resources is one option: you choose the elegant solution because it is cheaper or lighter. However, I'm okay with expensive elegant solutions, with large elegant solutions. So I don't like the idea of limited resources, at least not in the construction phase.

I think what makes the fuel-less probe more elegant is that it deals with the challenges of the mission in an appropriate matter, instead of spending a staggering amount of resources in a sub-par workaround.

By understanding the challenges along the mission path, you can use them as opportunities instead of hazards. The rocket-rocket-rocket approach treats all of the challenges as hazards. The passive-teardrop approach treats the challenges as opportunities to get free acceleration. It's an elegant approach, even though it has a lot more moving parts than a rocket-rocket-rocket approach might.

This same approach can be generalized to all kinds of challenges. For example, you want to build a buggy to drive over the lunar surface. The low gravity is a challenge, because it means your grip on the surface is really poor.

Well, in reality a wheel is a very elegant solution on its own. Wheels use gravity to help you propel yourself efficiently, even if the maximum propulsion is pretty low and gets worse on low-gravity worlds. You could improve things a bit by simply making bigger wheels, but let's consider alternatives.

One option is to make a legged "jumper". Low gravity means that the joints can be much lower-powered and still pace across the surface quite quickly. There are a lot of considerations here, though: unless you're quite practiced in building legged robots, you're probably going to find yourself facing challenges such as dust in the joints, poor balance, slipping on sandy slopes, and so on. These are the same considerations you'd be facing with wheels, but we've got wheels down pat.

Another option is to use a hybrid of wheels and climbing legs. The slow progress on wheels is fine, but it's the rough terrain that prevents you from driving that's the problem. For those situations, hooked "climbing" legs can grip onto slopes or large rocks and help to haul you over. They also serve double duty as devices which can flip you back over if you tip. Of course, these are probably not ideal for climbing up proper cliffs, but they would allow you to navigate broken terrain.

Putting aside mobility, the low gravity offers many opportunities for a rover not related to moving. For example, the rover could have a spring-loaded tether which it fires a hundred feet into the "air" to give a good view of the surroundings. The camera falls back to the ground, but it's durable enough to survive the much lower impact trauma than it would have in high gravity, and the rover can reel it in and reset the spring. There are obviously dust and impact considerations to be made, but the ability to get a panoramic view might be worth it.

You could even use a similar system to fire a hook forward, grip the ground, and then drag yourself towards the hook. The low gravity makes dragging quite easy, if you can get the hook to stick.

Another benefit of low gravity (accompanied by low ground speed) is that you can have very fragile unfolding systems - solar panels, long sampling arms, and so on. In fact, you could even put the wheels on spindly extending mounts to give your rover a much higher added stability, although if that speeds up your rover then it will increase the impact and vibration forces on itself and any other devices you've mounted.

Someone who creates a rover with these kinds of utilities for taking advantage of lower gravity will be creating vastly more interesting rovers - and also performing at a higher skill level than someone who just creates yet another generic rover. These are the sorts of opportunities we want to provide, especially in coordination with soft space/weight constraints.

To do this, we need to provide the player with two things.

1) Construction tools adaptable enough to allow the player to misuse them.

2) Challenges that act as both hazards and opportunities.

This is a little more difficult than it sounds, because in order to make challenges that are both hazards and opportunities, we need to have quite a lot of different play systems in effect. Gravity and atmosphere are easy targets for space games, but what other systems might work?

Some are external. Dust and weather are big examples that generally go unused. Atmospheric chemistry is another example, especially if we allow for chemical reactions that can turn one chemical into another. Minerals that perhaps could be mined. These are all challenges - some are more hazard than opportunity, some are more opportunity than hazard, but there's no need to nitpick.

Other play systems are internal. For example, let's say that NPCs can control vehicles to do automatic exploring and scanning. It doesn't matter the type of vehicle - telescopes, probes, mining ships, comm sats, rovers - all vehicles can be automatically controlled by NPCs to optimize their performance. However, NPCs will hesitate and move very deliberately, making their optimization pretty crap.

Gathering information would help to improve NPC performance (and player performance, if they take the helm and can see the information). For example, if you have a good map of Mars near your rover, then you can plan your rover's movements in advance. Maybe you deploy a satellite that passes over your rover and takes pictures. A camera on the rover would be an obvious requirement, giving you detailed feedback as to how you're doing. The formula for how much a camera improves performance is based on the camera's distance from/height over the target. The satellite is quite far away so its information has some value, but not a whole lot, and it's only taken once per orbit. The on-board camera provides very good feedback, but it's actually too close to the target (the ground), limiting its view.

This is when people start coming up with different solutions, like the launched panorama cam. Optimize the cameras.

This basic "line of scanning" formula can be used more abstractly to allow for dozens of different kinds of scanning in the same way that a weather algorithm allows for dozens of different kinds of atmospheres. We can use the same basic formula to calculate out the scientific value of a scan, whether you detected valuable minerals, whether the people on your hab think they have a nice view, whether your space construction facility can safely construct things with all its spindly arms...

Similarly, the ability to convert chemicals into other chemicals (for example CO2 -> O2 -> H2O) can be implemented for a much wider variety of things. For example, you can model the human crew as eating packaged food, which is then converted into waste and plastic packaging, each of which can be converted into other things or ditched as you prefer.

Now, you shouldn't force the player to deal with every challenge all the time. These challenges should be strictly player's choice. If the player wants to use a precreated hab module that handles the waste and packaging quietly, that's fine. But if the player wants to tackle optimizing things and connecting systems, they should also be allowed to do that. Tackle challenges as you like. The player will, at some point, realize that tacking on 50 more tons of food is less effective than setting up a clever, elegant way to recycle waste.

Hm. Now the primary issue with creating such a game is how you would handle the construction/realtime control side of things without falling into the same pitfalls as Kerbal, but without dumbing it down.

The biggest issue there is that not all of these are physically challenging systems. If you want to take in carbon dioxide and output water, the construction involved is just to slap down three or four modules on top of each other and call it a day. Slapping together units doesn't require any particular skill, so it's not a good match for our physical construction skill-based play.

One alternate option is to make the required skill one of long-term prediction. You can connect things up, but you have to know how well your supplies will last, your chances of breaking, and so on.

Another option is to recast things like chemical conversion and cameras into physical constructions that have strict restrictions. For example, converting chemical A into chemical B is just a node you slap in, but the node puts out a massive amount of heat. Another node puts out vibration. This one, radiation. The physical construction you build will then have to not simply resist the stresses of gravity, thrust, and atmosphere, but also the stresses you cause with your own systems.

That would probably work best with inflatable, unfolding systems...

Hm!

Ikebana

So, I talked about noncombat starbases and starships a lot for the past few weeks, but one thing I didn't cover were the visual characteristics of these games.

It may sound unimportant, but it can be very important. A big part of the draw of science fiction games is the feel of the world. That grandeur and mystery - sensawunda, if you prefer - is very important. The very first thing that helps to establish it are the core visuals of the ships and stations. Especially if a player can custom-build things, they'll want to custom-build something wonderful.

There are a lot of details about this that really change how everything feels. For example, how customizable are the ships? Are we talking about swapping out the nacelles on a Star Trek vessel, or about sticking together modules, or about arbitrary mesh placement and deformation? Each has its own strengths and weaknesses both in terms of visuals and gameplay restrictions, and each also has constraints in terms of the resulting visual design.

For example, freeform node placement allows you to put ship components like nacelles, hab bubbles, and so on anywhere you like, overlapping with other components and tilted and scaled in whatever way you think looks cool. However, if the components actually have functions (like weapons, engines, etc) this arbitrary placement can make it feel very awkward when someone places them in a manner that should logically prevent them from working properly. It also makes it difficult to internally connect the components, so it's not really possible to have module A clearly connected to module B - they're all just part of the same mishmash.

On the other hand, a hardpoint component system allows you to place components on the hardpoints of other components. This system is extremely good at relating modules to other modules, and therefore you can create resource chains, interiors, and so on that make sense. Visually, however, the locked-in-place modules are quite restrictive, and you have to be careful to design your module components such that they result in a visually interesting result. It's a lot more limited, and typically the result is a very boxy, militaristic style, because that goes well with the aggressively locked-in orientations and edges.

Those are far from the only options, though.

In my case, I really got to thinking about more organic-looking designs. I got interested in the joins between the modules. In most games, the modules just bump into each other or arbitrarily overlap, but there is value in having a very clear joint or clamp. It looks cool and you can make it highly functional. I was examining some examples when I realized that there was no reason for a space station to have to be ship-shaped.

A space station has no real thrust requirements, so it doesn't have to be shaped like a brick. In fact, it makes a lot more sense for a space station to be sprawled over a vast amount of space: more room for solar panels, less collateral damage if one part is destroyed, a wider separation between living areas and loud, possibly radioactive industrial areas...

So my design today is actually inspired by a sprig of flowers. That's why it's named after flower arranging.

The idea is that a space station "seed" is flung from earth out into space at something like 0.3c. It then spends the next few decades slowly decelerating into orbit around a nearby star.

Over the course of the journey, the seed blooms, growing out a branching, bud-heavy space station. When the distant star is reached, everything begins to unfold and bloom with the energy of that star.

This approach has a few strong points.

1) It's very visually distinct. As far as I know, the "unfolding flower" visual is still very rare in science fiction, and I've never seen it as part of a long 'branch' of flowers.

2) It works well with multiple identical modules. Most science fiction visuals start to look bad if you have dozens of the same module attached - for example, dozens of living areas. That's why they have different sizes of living area modules for different sizes of ship. But with my visuals, having dozens of identical modules just makes your space station look more beautiful and lively, because each one is a bud that unfolds into a flower.

3) It creates a very distinct resource chain. Resources flow up or down branches. This is a bit different from having connected modules, because you can have dozens of modules connected to the same branch. But it's also not the overly-simplistic "global resources" approach many designs take, which means you can have pretty complex localization if you want to start designing trickily.

For example, you might want to do a heavy industrial starbase that squeaks by with minimal actual humans. Therefore, to optimize performance, you might have two industrial branches. One is on, one is off - and you can toggle it. So one branch gathers resources, using up all available workers. When your resources are full, you switch to the other branch and turn off this one, temporarily stopping the resource gathering so you can fire mass packets home. Then turn that off and go back to gathering resources.

4) It creates a very easy modularization: you can save branches, and later on if you want to create those branches again, just poke them into the same seed base. Like Japanese flower arrangement - hence the language chosen for our title.

5) Every flower withers, every journey ends. The visual is a good way to communicate to the player that whatever they've built is mission-specific and is not terribly permanent. This impermanence pushes the player to keep launching, and therefore also pushes the player to keep refining their designs. The network of relays, resource-gathering, and seed-launching is ever-changing.

It also gives us a lot of opportunities to design for longevity. For example, if you wanted a really long-lasting signal relay, the problem isn't the signal dish. It lasts hundreds of years. The problem is the humans. Human habs are medium-duration blossoms and therefore they'll die out long before the relay does. Nobody dies due to the the blossoms wilting, but they do go back into cryo sleep and stop working. Which means you have no workers to work the relay dishes.

You could use an expensive multi-generation mega-blossom, but that's incredibly pricey. Instead, maybe you build dozens of normal habs, but you only activate one at a time. You set up your station to automatically activate the next blossom when the current one is fading using a set of resource barricades on the branch itself.

This has the side effect of also forming a very nice "thermometer". The easiest and most robust design for resource blocking steadily works along the branch, so whenever you pop over for a look at your space station, you can quickly count how long it has left by looking at how many colorful buds remain unopened at the end of the branch.

Similarly, you can use it for rolling out in phases. Mining ships require a fair number of resources to build, and if there are several of them on a branch they will share the incoming resources evenly. This can lead to extreme delays in actually getting ships out: it may be better to use resource blocking to grow just one or two at a time and roll the fleet out in waves - otherwise your other blossoms will age pointlessly until you roll some ships out.

Anyway, I rather like this idea.

Space Battles Undone

So, I complained a bit about all the gorgeous, fun-looking spaceship games crawling up from the woodwork. They're all - ALL - about shooting at other space ships using your pew-pew lasers. That was my complaint. We're reducing an amazing, interesting future to the oldest, most base kind of interaction we can.

Is it possible to make a spaceship game without combat in it?

Well, sure. You can build a cargo-hauling game, or a space-station-management game, or a...

But I want a game where the design of your space ship matters, where you put it together out of modules and then fly around and use it.

The problem is that the combat system is deep and integrates well with ship design. It's all about complex, layered play full of tradeoffs. Do you go in for the attack? Do you hold back to regenerate shields a bit? Do you flank because there's lots of them? Do you use a limited-ammo missile now, or later? Do you put power to the engines or the shields or the weapons? Tradeofftradeofftradeoff, and they all link together.

Feeding parameters into this tradeoff machine is the design of your ship. How many engines? Shielding units? Type of armor? Scanners? Chaff? Which of the kajillion types of weapons are equipped?

This is a very fluid way to integrate the physical design of your ship into the very nice combat system.

If we remove combat, we have to find another complex but fluid core gameplay system. I mean, we could just reskin combat, but let's not.

There are a lot of options, but in the end they come down to two possibilities. See, the gameplay has to relate you to the rest of the universe. It has to give your design context. So the core play can't just be the operations of the ship: it has to be the ship interacting with the universe.

So the two possibilities are therefore the ship interacting with planets, and the ship interacting with other groups of people.

Now, can you build a layered gameplay loop out of those?

Sure. Let's go ahead and give it a whirl.

Ship interacting with planets is kind of fun because we can actually keep being physics-centric. The ship's chassis is what we're actually centered around, as we change orbits and land and weather the atmosphere and whatever. Because of this, we can keep a lot of the standard ship design concepts: engines, shields, scanners, generators... and also add in some extra complexity because of the changing conditions. For example, shields which protect against radiation from the sun can be limited to a specific angle, and then you can always keep your ship tilted so the sun is at that angle. Wings, vectored thrusters, air brakes, fins - those can all be useful when attempting to pass through an atmosphere.

And you can design quite a complex ship out of that sort of component jenga. Maybe you build a ship that can do everything... or maybe you go with a mothership design, where the mothership can't land, but has several more special-purpose subships that can detach and go do their thing, each specializing in a different environment, a different kind of challenge.

And what would the challenge be for planetary exploration? Scanning, sure. Let's build on that. A reason to land? Scanning different kinds of things requires you to be on the surface. Something besides scanning, you lazy bum? How about terraforming? Collecting samples? How about stamping down ready-made facilities for colonists coming in later? How about just flagging various regions as belonging to various factions? How about laying out roads and spaceports? Flagging points for drone miners to visit?

The idea of not simply scanning the planet, but also defining how it will grow, gives us a lot of depth. But in terms of organic, layered feedback loops that takes ship design into consideration... that's not so easy.

I think in our case the real solution is to put in harsh resource limits, rather than trying for some kind of real-time challenge. For example, you only carry a certain number of base seeds, a certain number of mining flags, a certain number of landing pads. And these have to last you until you go in for resupply, so you probably want them to last several planetoids, perhaps even several star systems. But here's the key: almost more important than what you lay down is how they are connected. You aren't simply putting down two mining bases: you have to plan for how they will support each other or conflict with each other as the bases grow. Do you put in a colony seed with a high-speed rail running to the mining colonies, to help them grow faster? Do you put it closer to one mining colony than the other? Is it so close that the mining will ash up their skies and make them depressed? How long until the mining base expands to the point where it is close enough to pollute the colony? The topology and weather on the planet will also play into what works how well where, as do whether the bases are from the same faction or different factions.

These are simple challenges, not so complex that they merit being the focus of the game. They exist solely to make deploying resources more interesting and agonized than "three mining bases on this planet". Also, when you come back to visit the planet later, what sort of resources they'll have available to you will depend on how well they've grown.

The way it plays out from the player's perspective is a bit more physical, though. They come into the star system and scan for planets and significant mass deposits such as asteroid belts. They can target scanners more precisely, allowing them to scan specific planets even while quite far away, although they'll obviously want to go in close to get good readings with other, more detailed sensors. I don't think there's any reason to force the player to manually scan the planet by moving the mouse around or whatever, but I do think that there should be certain types of scanning which require them to choose specific points on the planet surface because of the high cost of scanning (either in terms of energy, expended scan-probes, or landing the ship).

Then the player can simply choose where to place things. Some things might require the player to land on that spot, while others can be placed from orbit. Some, like the railway you can lay down wherever you like, require you to actually fly along a path, dropping adaptive rail in a long strand. Obviously a bit of an involved process on larger, atmosphere-rich planets where flying along the surface may take considerable time.

When you design your ship, there's a lot of considerations. The obvious ones are what sort of things you can place on the planets, and how good your scanners are. This is in addition to things like engines, landing capabilities, aerospace capabilities, shielding, and so on. There's crew to consider, and power generation: I would consider both to be a resource that gets used up temporarily as you scan, fix, place, and so on.

Is that enough? Can that be an interesting game?

Probably. It's a bit dry.

Let's talk about the other idea: interacting with people.

When you find another ship, or land on an inhabited planet, or dock on a space station, you aren't just opening a trade window and ferrying things across. Instead, it's all about an exchange of culture and socialization, because space is big and empty and you get pretty lonely flying around all the time.

Our inhabited hull sections (crew quarters, malls, gardens, entertainment sectors, libraries, etc) all have a meter on them - a culture meter. As you fly through space, your crew consumes culture pretty rapidly from the sectors they live in. Don't worry: you never run out. The lower the culture in a section, the larger the percentage of culture the crew recycles and puts back into the culture bank, until at the lowest point they recycle 100% of their culture.

Of course, recycling culture is not free: it builds up some memetic mutation, a red bar that occupies the same space as the culture bar. As the red bar fills up the culture meter more and more, the locals get weirder and less reliable, which can cause problems. But it's a slow-moving system, so there's plenty of time to monitor the situation and head out to a space station or planet for some shore leave before things get out of hand.

Interacting with other groups of people allows you to turn your memetic mutation into culture and "restock", but it's a delicate balance between that and losing crew to the planet or other ship as they "go native".

How does this actually work in terms of fun play that integrates with starship design?

Well, I'm thinking of pressure management, like steam engines or party balloons.

All your crew-inhabited "social" hull elements can be connected to each other depending on how you lay out your ship. People flow along those connections, and out the airlocks. By opening airlocks, you let your people out and their people in, "inflating" and raising the pressure. By closing the airlocks, you stop raising the pressure, the visitors steadily drift home, and the people on leave steadily drift back. You can even do more complex management by having the same contiguous set of social hulls connected to more than one airlock, and twiddle each one to perfectly balance your pressure as you see fit.

So I'm thinking you might land and open an airlock. PSsshsht, in comes a steady stream of visitors (and out go a steady stream of your own crew to do the same to the person you're docking with). They initially congregate mostly in the zone nearest the airlock, which quickly "swells" to a dangerous level of pressure, such that you're starting to lose crew as they decide they want to stay with these interesting people. So you close the airlock, and the flow stops. The "bulge" of people steadily smooths out as they filter down the connected chain of social hull elements, and then slowly drift home. You might pop open the airlock again once in a while, to let in another breath of fresh air, then close it so it can filter through your ship well.

The higher the pressure, the more efficiently your memetic mutation is converted into culture - but the more crew you lose as they go native. Working at low pressure might seem nice, but you'll barely eke out any culture "profit" - you'll just lose your mutation. That'll last you a little while, but you'll build up mutation again far too rapidly. Also, the higher the amount of culture generated by your target from your people abroad, the more stuff they'll be willing to give you, so it's good to keep your pressure up specifically so you can keep their pressure up. Of course, if you can overload their social areas and get their people to "go native" to your ship, hey, that's nothing but good.

Each social hull element has particular characteristics which make it useful in specific ways. A library, for example, houses a massive amount of culture but very few crew. The idea is that the drain on the library is very, very low, and it automatically pumps culture out to connected sections. This allows you to optimize your culture use: the library itself generates almost no memetic mutation, even when mostly empty, because its population is so low. So you can use it to keep other areas "topped off" and really reduce your overall mutation rate. On the downside, because of its super-high max size and super-low mutation levels, a library is hard to recharge - typically you'll need to spend money on culture modules to refill it, rather than using the social intermingling system.

You might think you can just rely on a library and buying culture modules to handle all your cultural recharging, since the library can distribute culture. However, this is not recommended: not only will you have to pay through the nose for culture, but mutation is added to the top of the culture in stock, and the weirdity of the crew is related to how close it gets to maxing out the bar - not how much mutation there actually is. So even with only a tiny amount of mutation, if you refill the library without dealing with the mutation, you'll end up with crazed librarians.

On the other side would be areas with very high max pressure tolerance, or areas which gather mutation in from their neighbors, and so on. There's a lot of actual functionality you can pack into the idea of "contiguous zones", and in this case some zones are more about how your ship operates in deep space, and others are about how your ship operates in social encounters. Some will have limited specials or conditions that come up rarely that can help you maximize how well you do in social encounters. And, of course, how well you do in social encounters can radically change how well the involved faction thinks of you.

Things can get a lot more confusing when there's multiple targets - for example, a space station with two other docked ships is actually three distinct social targets. This is complex not just because each offers a different set of targets for you to try and culturally overload, but also because they are often from different factions and courting one more than the others might lead to other factions getting annoyed. You can target one target at a time for your excursions, but you can't control which people are targeting you. So when you open an airlock you might be letting in three factions swamping you at once, or you might find that nobody is interested in coming aboard - it's just your outgoing pressure.

You might also deal more complexly with the size of whatever you're docking with. An advanced space station might have cheap culture modules for you to purchase, but their inhabitants are kind of boring and familiar, so they don't convert mutation into culture very well. On the other hand, landing at a remote settlement - they might not have any culture modules for sale, but they are very good at turning mutation into culture. Encountering a ship in the depths of space is sort of midway - their crew is somewhat odd, and they might be willing to sell you second-hand culture modules which are, in their eyes, all used up... but in your eyes, still mostly full.

This is an unusual mechanic, and I don't know that it's actually a great one, but it is one way to do a rather deep spaceship-construction game without any violence.

If we really wanted to bite off a lot, we could implement both the planet-marking and the socializing mechanics into one game. They would mesh well, especially because you could have social elements that act as "storage" for faction designators. IE, you might have a political element that can store up to 5 "colony" designators, and those are what you would put on a planet to mark that spot for a colony from a specific faction.

Whew.

Well, that was long, but I really wanted to try to do something noncombat with spaceships, and still retain the awesome feeling of building a space ship out of components. This would do, I think, but it's not something I've really polished. I'm sure there are other compelling ideas I haven't thought of.

Polishing the Mad Science

In the last post I made, I talked about how you might be able to create a mad science game. The approach is that you create experimental apparatuses that allow you to run variations on the same experiment over and over, and you get insight points based on the observations you make while doing so.

The gameplay is about designing progressions which create variations.

As an example: you start with a sample group "combustible matter", which contains samples of things like wood chips, dung, oil, charcoal, and so on. By simply placing a sample dish on the experiment table and linking it to that sample group, you are creating an apparatus where each variety is placed there and examined in turn.

Of course, you can't learn that much by just looking at and smelling the various samples, so you might add in a process so you can observe something more interesting. So you add a match to the apparatus, meaning that you put each sample on the table and then burn it, observing the different ways they burn.

The first key to constructing experiments is multiplying variations. So you have the fundamental variation of the different kinds of combustible matter, sure. But if you really want to spike up the variations in the experiments, you can add another factor. For example, let's put the same in a small vacuum chamber. Now we can ignite it with different levels of air pressure. So not only do we have the 50 or so samples of combustible matter we start with, but for each of those we have maybe 10 different levels of air pressure to test. These 500 trials will tell us a lot about the different properties of our samples, and the way in which atmosphere affects combustion.

From the player's perspective, the specifics don't matter. The player doesn't need to know precisely how well oak bark burns in various pressures. The scientist in the game just makes some notes on his imaginary science-notebook and the player watches the insight points tick in.

Of course, 500 variations is a fair amount, and time will tick by as the scientist does the testing. Even if you can accelerate time, it's generally better to pack more punch into fewer variations. For example, you could choose to put the combustable things into water of varying depths. While there is some to be learned on the interactions of water and combustion, the difference between putting the sample in an inch of water and a foot of water won't give you any significant information.

Inspiration comes from measurements that differ, see. So if your experiment wastes a lot of time doing things that result in precisely the same results, you're just wasting time. Similarly, choosing what kind of measurements to take at what points in the experiment matters, because those are the things that will vary and therefore the things that will give you the inspiration.

For the burning tests, a sensitive thermometer would be a valuable measurement to take, and that's an instrument you start with. Carefully weighing the sample before and after would also be valuable - another instrument you start with. Obviously, analyzing the resulting atmosphere for various kinds of chemical and particulate matter would be extremely insight-producing, but that sort of measurement tool is not something you start with. Measurements take time as much as anything else does, so useless measurements actually make the whole thing go slower.

So a new player might play around with a bunch of different measurements before starting to realize which measurements would be useful, and in time would be building pretty polished apparatuses to maximize insight.

An example of a complex apparatus you can make with just starting materials?

You could use those combustible samples, but create two inputs instead of just one. Grind each sample into a powder (at several different levels of fineness), then mix the two ground samples together, light them up in a variety of air pressures. The end result is something like 50 * 5 * 50 * 5 * 10 different experiments (625,000), so it'll take a while to run through them. Simple heat, speed of burn, particulate exhaust, and mass measurements would probably be enough to get a ton of insight.

Some of the samples will fail out of this test, though, because not all of the samples can be ground up. Wet samples such as oil cannot be ground into powder. So you could make your experiment a bit more complex by adding in either a drying system (to dry all the samples) or a gating system (to treat wet samples along a slightly different path that ends up in the same final process chamber). You can see how your apparatus is beginning to grow.

Want more? Instead of burning the powders, mix them into water, then harvest the three kinds of results (sediment, scum at the top, and the tainted fluid) and do experiments on that. You can even try more advanced methods, such as spinning the flasks, heating them, treating them with acid, whatever.

Want more? 625,000 experiments will take a long time, especially if we're using a drying chamber. We can accelerate that significantly by automating most of the process and/or setting it up to run several parts in parallel. For example, having 10 vacuum flasks, each set to one particular pressure level, means you can do 10 of those variations at once. Of course, monitoring all ten for heat, length of burn, brightness, particulate exhaust... that's not something one human can do. So you either need to assign ten scientists to the task, or you need to automate the sampling using things like photosensitive film, sticky tape (to catch particulate exhaust), and a temperature blotter which draws a line to the hottest temperature reached.

So... just to be clear, this is a machine with a dozen scientists working in tandem. They are drying, grinding, blending, measuring - FLASH FLASH FLASH the samples go up and someone hurries in to take the various slips of paper and film used to record the results, while another one removes the remnants, cleans the chambers, and resets them...

Yeah, I kinda like this idea.

Mad Science Gameplay

One of the most compelling ideas for a game is getting to play a mad scientist. Who doesn't want to design a massive experimental machine and watch it run, laughing all the while?

But there aren't very many mad science computer games. There are some where you play as a mad scientist, but they're not about doing mad science. They're about managing empires or something.

The reason is because it's hard to make mad science into compelling gameplay. It is both too open and too closed. The outcomes are excessively diverse (monsters, weather control devices, teleporters, de-aging drugs, mind control lasers) and the process of creating them is therefore overly simplistic (throw points at the laser gun until you get it made).

There are some mad science tabletop games. They revolve around allowing players to just name their own creations as they see fit in a sort of freeform "generate your own karmic death" engine.

But I want to make a computer game. About mad science. How can I do that?

When we look at mad scientists in fiction, we normally focus on the end result. But the end result isn't the mad science part - it's the karmic death part. Behind every monster, every bizarre contraption there are hundreds of other experiments. Failures and explorations on the subject. Gathering data.

I was thinking about core play in construction games, and about how there is usually a focus, a spine to which everything else is attached. For example, in Kerbal there is a core rocket column, and everything is either integrated into it or attached. That structure resists the stresses of liftoff better than any other. In Sim City, money is what matters, and you tend to have a few high-producing areas of city backed up by power plants, police stations, suburbs, and other support areas that are probably actually costing you money.

What is the focal element of mad science? What does mad science want to accomplish?

If you look at it from a super-long view, there are a massive variety of final goals. But the actual science part? It is all about generating insight.

How can we make our core experiment construction about generating insight?

How about we make the experiments about measuring variations?

Science is about repeatable results. More specifically, if you can repeat a result than you can use that as a foundation to detect variations in other aspects of the situation. If you know that electricity flows through wires and makes them hot, you can try a million different types of wire until you find a filament that allows you to create a light bulb.

When you build an experimental apparatus in my mad science game, you are not building an experiment. You are building an apparatus that supports repeat experiments - variations that attempt to nail down the precise vagaries in subtly different materials or methods. Obviously, the player doesn't weigh in on each variant. Instead, variants are tried automatically, each variant generating a little more insight into the domain, depending on how well you're monitoring it, to an asymptotic maximum.

Let's say you're just starting out as a mad scientist, so you're doing chemical analysis on common air. Your apparatus lets you burn small things in a contained volume of air, so that you can see how different things burn differently in the same volume of the same air. An inverted glass cup is all you need for this apparatus: light something on fire, then quickly put the cup over it. Wait until the smoldering stops, then lift the cup. Smell the contained atmosphere. Poke through the ashes.

This apparatus can be used extensively - it's quite a durable and straightforward system. However, the amount of insight you'll get is pretty low. Even if you run hundreds of samples, all you're really doing is smelling some air and looking as some ash. To get better insight, you'd need better measurement tools. You might create an attached apparatus for analyzing the ash samples (for alkalinity or something), or you might retrofit the cup to give you more controlled smell access, or you might put a thermometer in there to check exothermic levels, or you might add in a camera to look for tint differences in gaseous emanations...

Now when your scientists run variations, there's more meat to be had and they can generate a lot more insight into the nature of combustion. As you can see, the experiment can be built rather freeform out of just a few basic elements, sometimes mixed into one object, sometimes not:

1) Devices which perform a specific process on varied inputs (sometimes requiring human assistance)
2) Devices which separate and contain the outputs (often requiring human assistance)
3) And the monitoring tools that plug into those devices (often requiring humans to note down the values)
4) And, lastly, support devices to generate whatever generic resources (electricity, heat) is required

These can, in turn, be piped in lots of complex and even recursive ways. For example, you're researching magnets. You might expose a magnet to a high-powered electrical arc, then analyze its field strength, then zap it again, then analyze it again... or you might analyze water, boil it, analyze it again, boil it again...

Now the question is: who cares?

Generating insight is a laudable goal in reality, but in the game world, what does it get you?

Well, obviously, it gets you MAD SCIENCE. Once you generate enough insight into various realms of science, you can perform "demonstrations". For example, creating a ray gun. Hypnotizing people en masse. Stopping time. These will get you into the annals of mad science, earning you respect and new resources to use in your experiments. The better your demonstrations, the more of those limited resources you get.

This may seem like a dull goal, but it should be enough. After all, the goal in Kerbal is to land on planets. There's literally no reward for doing so, except that you can plant a flag. The existence of various science journals posting "wanted" ads for various demonstrations is enough to get you to fill them.

There is a question as to how you build demonstrations. To be honest, I think just slapping down a lump sum of insight would be fine. The mechanics of insight need to be carefully worked out: an experiment generates insight, but rather than adding to your insight total, it simply raises your total if it exceeds your total. So you want to have the best experiments you can, rather than running crap experiments a lot. Similarly, having insight on hand lets you use more complex monitoring devices. Spending insight on a demonstration will actually limit your ability to use those complex monitoring devices, which means you probably can't just run that last experiment again to regain the insight you lost...

This is a very simple gating system, but it should allow people to craft experiments not simply to some ideal, but to their particular situation. The potential complexity of experiments also skyrockets dramatically when you start getting into the true mad science areas - unlife, ghosts, time manipulation, weather manipulation, psychic powers... all of them have very different sorts of characteristics which require very different experimental approaches... but it's not really clearly delineated. There is no specific "ghost bottle": the same apparatus elements you might use to test for psychic powers or magic or dimensional flux might be used to look for ghosts. The various elements overlap, and therefore your experiments involve different progressions and mixed from the same base set of items.

Similarly, it's possible to make these elements vary randomly from universe to universe, if you wanted to play a multiverse version where you can travel through dimensions. But that's going a bit too far for the basic design...

The basic design involves applying processes to samples, then moving the samples around. As mentioned, the experiments are about performing the same thing in hundreds of variants - obviously, the player doesn't do it, but the player sets up the in-world scientists to do it, and hits play. Add in monitoring devices and strange magical physics, a respect system based around scientific journals, and a wide variety of scanning devices... and that sounds like a fun game!

Maybe.

I might try making it. There aren't any decent mad science games.

Time-Allocation Play

One of the things I've been flirting with a bit is the concept of time allocation as play.

There's a lot of games where time allocation is a big part of the play, but it's usually slightly hidden behind a pile of other kinds of play. I've been thinking about bringing it out into the open. To make it less clear: I'm not talking about scheduling or waiting. I'm talking about time allocation. Manually turning things on and off, basically.

Imagine you run a space ship, and you basically have a bunch of switches you can flip on and off. Warp drive, research, repairing, harvesting space particles, partying, biofood labs... whatever we can come up with. Could you make flipping those switches into a compelling game?

I think you can. I think the heart of it lies in making the switches have complex inter-relations and time delays.

For example, you have a battery with X energy in it. You have a starship generator which generates a small amount of energy, but not a whole lot. And you have a fuel amount that the generator burns to produce energy.

You're running low on energy. So you flip the switch to harvest particles from space, knowing that it'll refuel you steadily. While there is definitely a net gain, this does drain energy faster than the generator can provide it... and it has a slow start as the mag-sails slowwwwwwly deploy. So you flip the switch only to realize that you don't actually have enough juice in the battery to get past the early stages, and you're not going to make a profit before the energy runs out.

So you shut off the biofood labs to reduce the draw on the battery, so hopefully it'll last long enough. However, this shuts off all the secondary effects of the biofood labs, such as air purification and good food - putting increased strain on both your life support and your morale. Still, it works out, you get some fuel, and you switch off the particle gatherer. You switch the biofood labs back on, but it'll be quite some time before they regain full potency. So you also turn on relaxed scheduling, raising moral but lowering work hours. And you have to turn on the backup scrubbers to get the air filtered well again, but they are degrading rapidly because the maintenance staff are on R&R...

This kind of play takes advantage of the way delays and limitations play against each other, forcing you to weigh both timing and duration. In addition, you can add in a lot of long-arc play.

For example, you decide you want to research black holes for the healthy science prize, and find you can harvest plenty of fuel from the accretion disk as well... now if you can only keep your ship from disintegrating from the heat and radiation. So after a while of that, maybe you (and your full fuel tank) pop over to a friendly space station for some drydock repairs from all that damage. You notice they have a new module on sale that will increase your energy output with only a modest increase in fuel cost, so you go back to the black hole to get a few more science points, get the cash prize, and then go back to pick up the module...

And the long-term goals are a big part of what makes the short-term ship management important. For example, maybe when your crew is happy you earn culture points. There's a "combo"-type thing going, so the longer you go with a happy crew, the more points you get per day. But the instant the crew drops below "happy", the combo is broken.

Now you have an important, self-imposed constraint. Much of the time you aren't going to give a shit about how happy your crew is, so shutting off the biofood system will be a no-brainer if you need the extra power. But if you're going for a culture chain, it might be better to eat the fuel penalty for a failed harvest rather than break that combo.

Add in random events and every location having limited resources, and now you have a game. You choose how fast to burn through whatever resources aren't easily available. You choose your own goals - a larger ship? High culture ratings for the luxury items? high science to improve the modules you have? Cash to buy better modules?

A very basic game, but I think it'd be interesting.

Mods and Modules and Content

One of the big problems facing the next generation of games is ordering and categorizing content. The amount of content in these games is growing, as is the variation of content from player to player.

Examples abound. Back in the day, you had The Sims - everyone would create individuals and houses. A lot of people also created clothes, household items, skins, and other customized pieces. Organizing these was not easy, and if you were a very explorative player you might find yourself paging through a hundred options before getting the one you actually wanted.

Spore was similar, and if the modding scene had ever really taken off it would have been very difficult to handle the variations available to you. They actually gave up and simply hid away the vast majority of the content, just randomly spamming it into your universe most of the time.

Saints Row III & IV have the ability to mod in clothes pretty easily, but the result is an ever-longer list of clothes you can buy at every store (or just have available in your wardrobe). The number of clothes right now is pretty pathetic, but if they take off, you may find yourself drowning in options. There are some built-in categories, but the biggest built-in category goes unused: clothes could be available in only one of the particular stores, rather than all of them. Then you could add clothes to Let's Pretend but not to Planet Saints, and you'd be able to handle the explosion of options a little better.

Kerbal has a swamping problem as well, as the number of parts grows astronomically and there's no easy way to find them. Even with Spore-like tiny menu icons, I still page through half a dozen screens before I find the part I'm looking for.

And, folks, this is just the tip. This is the very earliest sign of what's to come: a massive proliferation of player-created content. Games will live or die based on how well they can harness player content.

I was thinking about this for my Astrophobia game (and any other games I make), trying to come up with a decent solution.

What I decided on for Astrophobia was to use catalogs. Since the design phase is supposed to feel like the sixties or seventies, hunched over graph paper, scribbling away at your blueprints, I figured catalogs made good sense.

So you mouse up to the top of the screen and it pans up so you can see your bookshelf (essentially a pull-down menu). Each shelf is designated with a category. A shelf for finished module designs, for module core components, for add-on items, for astronaut gear, for complex system mods, for misc... each has books on it, with a spine clearly labeled. The game, of course, comes stocked with several catalogs full of the various vanilla parts. You can also make your own catalogs out of the modules and astronaut packs you create while playing the game, and even send them to friends.

Your book gets added to the shelf - "Doug's Capsules" or whatever you name it. The subtitle can even have a version number, if you think you'll be releasing it ongoing.

If you download a mod or a content pack or whatever, it gets added to the shelf. "Bio research pack", "ADVENTURE INC PARTS", etc.

The basic idea is simple enough. Most of the content you get is going to have a context. Not just a role the various included pieces play, but a context. If you download an aerospace pack, you're probably going to want to use a lot of those parts in tandem - even if the parts are technically different menu categories. The context of the pack is actually more important than the category of the pieces within the pack.

Most of the old approaches to letting a player handle content come from the perspective that all content has the same context: it's general game content. And our menus and lists are built with that assumption. But that assumption is wrong, and makes it difficult to handle content which depends on other content.

If the only thing in the content pack is a shirt with a particular logo, then sure, put it in the "shirts" category. But if you've built a "NASA uniform pack", we want to be able to select all the various pieces easily and quickly. Instead of looking for the NASA hat and the blue NASA one-piece and the NASA shoes all in separate categories, you just want the NASA content pack floating there for you to click on.

That is what I'm doing. Technically, many of the components in these books have completely different roles and cannot be selected at certain times. For example, if you want to put stuff in your capsule, then having a capsule hull material or a hardpoint machine in your list of selectable things is useless. But here's the key: it's less useless than having five hundred selectable things that having nothing to do with what you're trying to accomplish, especially when the unselectable things are on a different page of the menu. And when you switch modes, the content you're likely to need in the new mode is right there, in the open book, ready to be clicked on.

Obviously, you want to be able to switch over to a combined mode where you just look through everything, but that should be a rare situation where you're searching for something you can't quite remember. In the day-to-day playing of the game, this approach should leave you "closer" to the items you're looking for than a big list, even a categorized big list.

And that's the concept.