Thursday, May 21, 2015

Sloppy Scaffolds

Sloppy scaffolds is a way to construct in-game objects, similar to the "voxel" grid method used by Space Engineers, Minecraft, etc.

But while voxels are optimized for terrain, sloppy scaffolds are optimized for functional objects such as bases, starships, plants, and equipment.

The key to this system is mesh distortion. Using relatively simple math, you can scale and bend any mesh. This is what bone animations do, it's really straightforward.

Let's say we're building a base using sloppy scaffolds. The constraint is that we don't build using walls or floor tiles or other basic components: we build using a defined "interior space" form. It's a tube, and we paint it onto the ground with our mouse. The tube becomes a line of connected nodes which can be independently manipulated to create larger and smaller areas, bend the tube in various ways, and so on. Although it is logically a "tube", in this case it is a boxy shape, a wide one-story building.

The tube is actually a pair of meshes. One fairly narrow "rigid" mesh, which contains hardpoints. This can be scaled and rotated, but not bent. Between the rigid meshes is the "flexible" mesh. This creates a fluid curve between rigid mesh elements, and can repeat itself if the gap between the rigid meshes is quite long. Depending on the tube, it may have several sets of rigid meshes that alternate or change on demand, and it may have distinct outward-facing and inward-facing rigid meshes.

The hardpoints are where we put our doors, windows, and walls. We fill the inside of our tube with all the things that either break up the tube (interior walls) or allow access (doors/windows). The hardpoints can also have "logical sets" mounted on to them, which allows us to create internal rooms of various sizes and shapes, and those rooms have furniture mounting points on them. In this way, you can decorate your tube.

Of course, one tube is not enough to make a base with.

For example, let's say you're building a base. Your instinct might be to create a really wide spot in your tube for a complex area - like you want a dorm with bathrooms and a lounge and it's all got to fit in this spot. But there's no interior rooms that break up the space right, since they're all quite simple. What do you do?

Well, you paint another tube. But instead of painting it onto the ground, you paint it onto the exterior hardpoints of the first tube. The new tube automatically configures itself to match the first tube. The hardpoints aren't taken up, either: your doors and windows now go from one tube into the other.

The new tube might be constricted. If you have an arc on the outer tube, the inner tube will be compressed down. If there's still space between the hardpoints for the flexible mesh to connect them, it's fine. But if the hard points collide or are shifted too dramatically, you suffer a "break". A break means that a hard point is deleted, and the connective mesh fills the gap. This will fluidly reduce the number of hardpoints as you paint on more tunnels. Similarly, if you're on the outside of the curve, you'll be stretched. This will never cause a break, but you can add in a new hardpoint that isn't reflected to the other tunnels.

Basically, this is not a rigid grid. The curves do not march lockstep, since the tubes can be expanded and contracted. The curves do not necessarily have the same number of hardpoints.

Now, all of this might not matter if all you're creating is a floor plan. Why add all this complexity for a floor plan?

Let's take it into space. Your interior spaces are now pressurized spaces. You can mount engines and reactors onto those external hardpoints, and there's and "engineering" tube which can have tanks, reactors, and heavy engines mounted within it. What's good about this approach?

First off, by scaling the tunnel you can very nimbly scale the interior mounts. If you need more fuel, make the engineering shaft wider or pull the hardpoints further apart. More thrust? scale up the spot where you put the engine. Want optimal exterior mounting? Shrink the engineering space down and stick on some exterior stuff like solar panels or batteries.

Let's say your core tunnel is a spent on shared spaces and cockpits, and then the central shaft becomes engineering. You want to add in habitation space, gardens, etc, so you paint a tube onto the core shaft, and mirror it for good measure. You could just leave it aligned, but the engines produce a tremendous amount of heat and vibration. So you pull the habitation tube off of the main engineering tube at the back, and then curve it out and away into a fishbone shape. It's still connected at the front, integrated into your shared space, but then it strikes off on its own.

This is the heart of the "sloppy scaffold": the scaffolds stick together when it makes sense, but can also be pulled apart. They can be split up and rejoined and all sorts of combinations.

This is only possible because each scaffold element is "walled". You are never asked to put down A Wall Block or A Roof Block. Instead, you put down bounded areas. So attempting to figure out contiguous space, pathing, and pressurized area is really easy. Each segment is much more expensive than a voxel, but since it covers a lot more logical space than a voxel, it's fine.

Collision detection seems like an issue initially, since a grid is a lot easier to detect collisions on. But it's really not so bad, since the scaffolds break into a bunch of simple bounding boxes. And since the scaffolds only interact at merged hard points, the exact nature of nearby elements is unimportant.

The last piece of the engine is the wiring system. You have scaffolds. You have modules such as engines, solar panels, and chairs. And then you have cables.

Cables run between hardpoints much more freeform, and can spiral off into space or whatever else you need them to do. They are always 1-1, no splitting or splicing, so it's pretty easy to keep track of them. And their whole point is to connect two things in different places together. Maybe this is a pathway, like running hand rails along the outside of the ship. Maybe it's a water supply pipe, providing living spaces with liquid. Maybe it's a data line, piping data from one place to another. These are important to allow us to create connectivity, since our constraints reduce connectivity dramatically.

Now you know the basic idea, but you're probably not sold on why it's better than voxel. It's probably not worth that much effort just to get smoother lines, right?

Well, there's a big power hiding inside this concept. See, since the scaffolds can flex... the ship can flex.

Let's say we built that wishbone-shaped ship. However, that's the configuration we want it in during travel. When it's parked and the engine is off, we'd like those wishbones to come together around the engine. This protects the engine from micro-impacts and also allows us to travel easily between the two wings.

In a voxel system, you'd have to do some noxious hinge crap, break the ship into several different voxel grids, and then suffer through physics simulations. Even then, it wouldn't be very fluid: the pieces would all be broken apart logically, no connections allowed.

In our case, we can simply recalculate all the meshes. Connectivity is maintained: the whole scaffold bends organically, like an octopus limb. Rooms may distort, but assuming there is no breaking due to compression, nothing would really change. Connectivity is maintained outside of the mesh as well, with the cables remaining connected, no complaints. Connectivity on attached scaffolds works as well: attached scaffolds are also recalculated and fluidly reshaped.

Tweening between the two states is also very easy, meaning that it's not a huge problem to animate the shift.

This same operation can be applied to the girth of the scaffold, increasing or decreasing its size. For example, if you want an inflatable habitat, or perhaps you have a docking area and you want to open wide to receive a ship then close down to keep it safe.

The shape of the ship matters, and the ideal shape changes depending on exactly what phase of what mission the ship is on. We might close around engines when we aren't using them. We might extend a spiral of solar panels if we are near a sun. We might move habitable areas away from a radioactive reactor before we turn it on.

Changing the shapes of these ships is normally done on a mission basis, rather than a physics basis. This system is not optimized for physics. So the flex of the pieces as you crash into an asteroid? That'd be expensive to calculate. But switching everything over into "asteroid drilling" mode? Simple!

And why not toss in which things are turned on or off or have their settings changed in this mode? Then you can calculate all the performance of all the ship's pieces, and know exactly how much the engine vibration will affect the crew's downtime, or how slowly the ship has to travel to avoid sending a docked ship crashing through the back wall.

This combines well with overall world optimization. If you have ships where you know the configurations it can be set up into, and you know the stats associated with each configuration... then just load that. You don't need to simulate the ship, you just need to know its performance. Similarly, if you know its performance, you know how fast various resources are changing, and you can set up events to happen when certain amounts are reached. You don't need to simulate the systems every round, you just need to set an event to happen at a certain time, when a resource meets a specific threshold. Some of those can be automatic - running out of fuel, for example. Some can be player-created - customized missions that happen without the player's direct control. Some might be best-guesses based on the crew's default behavior.

Anyway, you can tell that this system is optimized for systems rather than physics. While there might be some physics simulation involved, primarily this responds to environmental threats or direct damage rather than things like flexing or detecting collisions. It's not really any worse at those things than a voxel system, but voxel systems are really bad at them, too. Instead, I'd like to focus on having dozens or hundreds of active objects running at all times with no slowdown. So it's all about the ops: bake the physical layouts into operational details, and use those to quickly block out performance on missions. Basically: turn the physical ship into a spreadsheet.

And if the player can define configurations and missions... they can define stories. They can define an explosion on deck 3 happening at a specific time. They can define a surprise message. They can define a crewmember getting sick, or how crewmembers file in and out of the crew quarters each day. Big or small, this allows players to craft and share scenarios.


Well, that was talking about ships. But sloppy scaffolding is useful for more than just ships.

Let's say we're defining alien life forms. It's super-easy to use sloppy scaffolds.

A tree is just a hard wood scaffold with more hard wood scaffolds springing off of it, and twigs attached to those hardpoints, and leaves attached to those. Defining how it is exactly laid out and changes over time is annoying, but it can be done: the life cycle of the average tree, defined in the same way you define a ship transforming into "idle" mode or whatever.

Things that want to animate are a bit more difficult, because computing meshes on the fly is expensive. For example, a mammal would be easy to define using sloppy scaffolds, and it'd be easy to make them vary by simply changing the exact scale of various scaffold elements. But a mammal wants to run around and stuff.

The only realistic way to approach that is to have a core skeleton and then map the scaffold elements to it. This would be similar to Spore's approach, and it'd require a lot of work. But...

What about gear?

Let's say you want to let someone design their own exosuit for missions to distant worlds. You already have a base shape that is mapped to various bones and has various animations. Now it becomes relatively easy to animate: when you paint a scaffold onto the surface of the character, it maps to the bones the nearby mesh verts map to. And if you paint a scaffold onto that scaffold, it maps to the scaffold's map. This creates a simple, fluid way to create (puffy, mechanical) gear. And, as with ships, the scaffolding comes with functionality and hardpoints - meaning you could vary its purpose wildly depending on exactly how you build it.

Now, if your gear has multiple modes, it can shift between those modes exactly like a space ship... while remaining tied to the same bone animations. This means you could shift between different preset configurations while animating the base character. Want a fold-out jet pack? Sure!


Anyway, I really wanted to come up with something that wasn't as rigid as voxels. Allowing things to remain connected while moving gracefully was a big concern.

I don't see any huge issues with the core idea. Some of the advanced stuff has some hurdles - especially designing clothes - but overall it seems relatively promising!

Monday, May 18, 2015

Mission-Based Iteration vs Survival-Mode

Construction games!

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

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

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

AKA, the "survival mode".

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

That way you can learn to build a better design.

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

That's the heart of the problem.

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

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

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

At least, that's my plan.

Friday, May 15, 2015

Story, Storied, Have Stored

I love player-created content. I love it so much, I don't even want to call it "mods". I want it so flawlessly integrated into the core game that it's just how you play.

From a technical standpoint, this isn't as difficult as you might think. Just pipe player creations into other players' worlds. Sure, there's issues with quality or suitability, but the technical act of taking a player's constructed content and showing it to another player is pretty straightforward.

For me, the problem isn't the quality of the content or the technical aspect of sharing it. The problem is the disconnect between the players. The context of the content is lost.

Players are happy to create content, but a lot of the time, they create a context for the content that doesn't exist inside of the game world. For example, I'm playing Space Engineers. Sometimes I just want to create a functional ship - hey, look, this drills really well. But a lot of the time, I have a fiction in my head: this ship is a cryo scout ship with a crew of 10, this station is for several alien species that can't breath the same atmosphere, etc. These fictions are interesting to design for and, in theory, could give rise to a lot of interesting things happening with them.

If the ships and space stations are simply injected into another player's game, the context is lost and they are reduced to a jumble of parts ripe for the harvesting.

The context is removed, but it can be rediscovered. It can be hunted for. I see this a lot with Let's Players doing community showcases, exploring ships with only a bit of a text blurb to tell them what's up. This mystery has power - perhaps especially because there is little validation. You'll never know whether your guesses are right. Maybe you guess the station is a hospital for contagious diseases instead of a multispecies diplomatic station. In some ways, that doesn't matter: as long as your guess was interesting to you, you're having fun with the content I built, and that's the key.

In some ways, it matters a lot.

If the context is solid, it can live on and grow as the game progresses - and the new player can even be invited to participate.

If a new player understands that my station is a multispecies diplomatic base, they can quickly realize that the other ships in the area belong to these species. Suddenly, the fact that none of the nearby ships have weapons makes sense, and it's a reason for that player to design a weaponless diplomatic ship themselves. If one of the species is fronting a battleship, suddenly the player knows that there's an overly warlike species disrupting the negotiations. This steadily unfolds into a web of contexts and small scenarios.

We're talking solely through space ships existing in a specific place. All of that context can be built and explored without any combat modeling, or diplomatic modeling, or even any concept of time moving forward.

The core gameplay of most of these space ship building games is combat, or perhaps resource wrangling. What if, instead, the core gameplay was about creating and relating scenarios?

One way to do this would be to have the core gameplay be about designing ships for various groups and then watching them grow or shrink as your ship performs well or poorly. It is possible to make this complex enough to avoid dominant design strategies.

Another way to do this would be to rely entirely on player contextualization.

Players can present challenges. These might be blurbs such as "the nearby stars are highly radioactive, but colonization proceeds" or "a disease is spreading through the Traxican people, turning them into violent zombies!" Optionally, it can include worlds, stations, ships, people - as much as they want to put in.

Other players can attempt to approach these challenges by designing a ship and giving a blurb back. So players might design a colony ship to colonize those radioactive stars. They might design a medical ship to cure the disease, or an anti-personnel ship to kill the zombies.

The player that presented the challenge is required to use at least one player-submitted ship as part of their next challenge. So they find a colony ship they like and the next blurb is "in orbit around the planet, the radiation shields give out and the crew crash-land. They have to cobble together a base!" Or they use both the medical and anti-personnel ship and write a story about how the two clashed - and now the species are at war...

This freeform contextualization can also be done solo - creating ships to solve your own problems and creating new challenges based on that. While it seems masturbatory, it can be used to do worldbuilding in an organic and interesting way. The result is a pile of content ready to be repurposed for another player's experience!

This simple mechanism automatically includes quality filtering, since all the content is judged and propagated or ignored by other players. But it has several downsides.

The first downside is gameplay. You need to carefully design your gameplay so that players can get a feel for the ships and worlds that they live in. That means, at a minimum, the ability to embed commentary into designs such that as a player moves through them they hear explanations or see examples. My first impression of that would be allowing the players to record "ghost logs" like from System Shock 2 - you walk into a room, and you see someone slip across the room and lie down in a bed. Micro-machinima for context. This requires some effort - animations, recording, etc.

More gameplay would be better - the ability to use the ships. Some kind of statistical propagation as I discussed last essay. It's all quite doable, but you need to be aware that these gameplay methods serve to give the player context, not to actually be core gameplay.

Another thing that is troubling is the tense of the stories.

Since every story is narrated by a player, fundamentally everything "happened". The players don't get to unfold stories in real time unless they happen to be the one writing them. If you see a cool ship, your exploration of it is to see where it was and what it did, not where it is and what it is doing.

In order to avoid this, you have to allow players to create a "race track" of a scenario. Our scenario about settling a radioactive star would have various distances to travel with various amounts of radiation hitting you, attempts to scan planets while boiling under the sun, and then dropping the colonist base to the surface unharmed. More race track elements could be injected if the player is creative: crew members going rogue, the planet having ancient defenses, etc. Players could attempt these challenges with their own ships, or with any other ship submitted.

The problem with this approach is that the required gameplay can be quite bizarre. Moving from spot to spot, processing resources, and shooting at things are all pretty typical, but what kind of gameplay is "a crew member goes rogue"?

You can invent a gameplay for it. You can come up with something, I'm sure. Can you come up with gameplay for literally everything anyone will ever think of? "Ancients give one crew member psychic powers". "There's shapeshifters on the planet, and they pretend to be the crew". "The crew runs out of clean clothes". Each of these can be modeled, but each one is another special case, and needs to be thought up before anyone decides to use that special case!

I think the best way to do this would be to have a bunch of viable generic tasks that can be customized, but if there are new tasks, they are handled using the same context system. Your ship is intended to colonize a radioactive star, and in the end the other player decides how much he likes your ship... why not have him decide how well your ship can handle the rogue crew member? Submit a blurb describing how your ship handles it, and he'll decide how it unfolds.

This does take the event "into the past" again, but it's only for things that can't be done live.


Anyway, thanks for listening. I have a lot more to say, but this is plenty long already.

Tuesday, May 12, 2015

Topological Play: Pull, Push, Connect, and Access

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

It sounds like a lot of fun!

Wednesday, April 15, 2015

Space Games and Physical Programming

Most space games take inspiration from pulp sci-fi. They are about exploring amazing new places, encountering strange new people.

Those pulp stories abstract out all the complexities NASA has to deal with. The spacefarers have a relatively easy time surviving the rigors of space, and are mostly challenged by the amazing new things they encounter instead of basic space travel. This simplification allows authors to tell a good story, fast.

But games require complexity.

Most space games introduce complexity from the standard genres. So you add in more guns, more engines. Sometimes more cargo space. You have a statistical challenges, fighting, trading. Complexity introduced from other genres.

But space has its own complexity. Obviously. Just surviving is a challenge. You don't need the artificial challenges of combat. Instead, just reintroduce a small amount of the natural complexity of space travel.

Physical programming is one way to do this.

Physical programming is the basic idea that various components can be connected in various ways and moderate their own behaviors accordingly. For example, you might have a heater attached to a thermometer, and the heater will turn on if the thermometer drops below a specific value. Pretty simple idea.

Physical programming is about having all that stuff reflected in physical systems. Ideally, systems that you can clearly see in the main world. So you would be able to look at the ship and see the heater, whether it's on or off. See the thermometer, how high or low it is. Even, ideally, see the target temperature we've set up.

This contrasts with a more common approach, where the heater would have a built-in thermometer and you'd be able to dial a number into the heater's configuration. Obviously, that's more efficient - but it's not physical. It's software. Digital. Integrated.

Using very primitive basic components is a good way to allow us to control exactly how much complexity we want to expose the players to at the start, and still allow the players infinite freedom to tackle more complexity if they want.

If you look at old space modules like the Vostok, you can see the kind of aesthetic this produces. It's also an opportunity to talk about a specific example of what you might have to build.

Let's say an astronaut is going up just a bit, then right back down. They might only need one air tank. You can leave it for the astronaut to control - they can turn a nozzle and get a burst of air on their own. You don't really need to "program" it, you can just trigger it with a hotkey. You might include a barometer so you know when to open the air.

But if the astronaut plans to stay up for long, they'll need more air. The Vostok has a ring of air tanks. In theory you could still do this manually - a different hotkey for each tank, personally keeping track of which ones are empty or full... but that's a lot of hotkeys, especially if you also need to do ventilation, electronics, etc.

The answer is to add automation. Physical programming requires that automation to be physical, to be visible.

You might start simply: you have a knob with calls for air, but it's connected to all the tanks - at each nozzle, it is broken by a mechanical switch. When you turn the knob, the pressure travels down the cable and hits the first mechanical switch. If it's open, the tank is opened and closed by the motions of the control knob. If the switch is closed, the pressure continues on to the next tank.

Now you have one button to control the air flow, and you can manually click on a switch when a tank runs out to move to the next tank.

Of course, that can be automated as well. Each tank has a pressure gauge on it, and you can use that to control whether the switch is open or closed. Now you have a knob to control the air, and it'll automatically fall through as the tanks run dry.

You can automate it even further by connecting the barometer to the knob and automating it - when pressure gets low, pump more air in. This might need to be made more complex in situations where there's no leakage, because then you're worried about oxygen running out rather than air pressure getting low.

It might seem odd to introduce painstaking mechanical solutions for basic things, but this allows us to precisely control how much complexity and challenge the player will encounter. The visibility of each component allows players to understand what they are looking at immediately, and also allows for us to do "topological programming".

Topological programming is a subset of physical programming where the size and placement of the pieces is extremely important. For example, in Space Engineers, the conveyor system is topological programming. But it's baby stuff.

An example more in-line with our earlier example would be the barometer. The barometer does not "read out a number" - you aren't transmitting a number over a cable. Instead, the barometer has a peg which moves up and down depending on the pressure. To make the compressed air activate at a specific pressure, you lay a switch over the barometer at the right physical point. It gets tripped when the peg moves. Variants allow for one-way activation, different kinds of activation depending on the direction, etc.

The barometer also isn't a specific "size". It's as long as you want to stretch it. Cords and cables can't run across it unless they are a switch. You can also add complexity by changing the fundamental shape we're attaching this to: if it's a tube, like most space capsules, then you can attach it vertically but not around the circumference. It's not a curvable object.

So we can make it as limited and challenging as we like - or make it easier and simpler to work with. Whatever our target complexity is. We can even do all different kinds of complexity in the same game using various tech tiers.

Or tech which is good but fragile. For example, a barometer which outputs a digital number might be possible, but it malfunctions slightly in direct sunlight and gives erroneous readings.

Moreover, because these are programmed onto a physical space, you can cut and paste functional "programs" by literally cutting and pasting. If we have a great system for monitoring pressure and using air tanks, we can copy that meter of tube and put the exact same design on another ship. We could even define it as "stretching" - the air tanks are an array of repeating elements, and if we define them as such when we lay down the initial code, we can scale the system to larger or smaller tubes by simply increasing or decreasing the number of repeating elements.

In this way even beginners can use advanced systems. This is a great way to let people play without forcing them to wade through a bog of details. It's also a great way to allow the systems to scale up to incredible complexity, since people can creatively combine subroutines.

Simulating these systems might seem annoying - it might seem like there's too many moving parts to do it reasonably. But very few of these mechanical bits need physics simulation, or even frame-to-frame simulation. The vast majority of them are event-based rather than simulation-based, which means that 99% of the time they are as lightweight as their models. LOD can even fix that, and in extreme cases you could unload their physical piece completely, just leaving their event response intact.

Physics simulation is, after all, not the point. Neither is damage simulation. The idea is to draw "game-level" complexity out of actual space travel issues.

Start with air. Heat. Ventilation. Keep moving up. Water. Food. Waste. Radiation. Keep moving up. Fitness, sleep, play, socializing, training. Keep moving up.

You can also do the other half of the equation. Rocket engines. Vernier thrusters. SAS. Docking ports. Electricity constraints. Solar panels. Combine them: socializing with visitors, maybe.

The point here is to stop playing up the complexity of combat or trading. Unlike Kerbal, we're also not reveling in the complexity of orbital mechanics. Instead, we're reveling in the complexity of humans surviving in extreme conditions thanks to these wonderful machines we've built.

Our simulation should make it fun to try to get your astronauts to flourish in space.

Or underwater, maybe. That could be awesome, too.

Anyway, this was a tough essay to pin down, I hope you enjoyed it.

Thursday, April 09, 2015

How to Sci Fi

Using "deep sci fi" elements makes your stories more powerful, more memorable, and more easy to write. I think the only reason people avoid using deep sci fi in their games and comics is because they've never really known a good way to do it. So.

Deep sci fi. By the numbers.

What is Deep Sci Fi

A huge numbers of games and comics use sci fi trappings. Robots, cybernetics, space ships. And that's fine. Those are fun.

Deep sci fi is what gave science fiction its original staying power. It's what created those sci fi trappings. And it's pretty easy to tap for your own purposes!

Fundamentally, sci fi is about people living in very unusual situations. Sometimes those situations might be completely fanciful. Other times, those situations reflect a piece of our culture, refined and amplified. Normally, the latter is considered more powerful, and sci fi trappings are built specifically to allow us to easily move our current society into a future where pieces of it can be examined individually.

For example, the concept of robots and androids are a powerful way to discuss race, immigration, economy, and the nature of work. Space ships can offer some similar discussions on other concepts, but are more about allowing us to easily compartmentalize our world - we can simply say that all the pieces of our culture we don't want to examine are someplace other than the space ship.

These tools allow us to quickly and easily put people into compelling situations.

Deep sci fi is about exploring what those lives are like. It is about exploring the limits of the human condition by putting humans in weird conditions.

Setting Up Sci Fi

At this stage, you probably have some idea about the kind of sci fi world you want to build. Is it some kind of cyborgs-in-cities adventure, like Deus Ex? Is it a tale of huge starships at war? Or a small crew of people trapped on the moon? Or engineered monsters fighting against fridge-wearing supersoldiers?

Even if you aren't thinking in terms of deep sci fi, those seeds already exist. When you choose the kind of situation you want your audience to experience, you have already chosen a deep sci fi topic. You just need to make it clear to yourself.

There's no need to be clever or unique or savvy. Just find what you're focusing on.

In a world like Deus Ex, where the people have become cyborgs and work for huge corporations, you're probably trying to focus on the nature of the daily grind and how people coexist with large corporations. This sounds like an overly simple foundation for the sprawling, epic gun-adventure you might want to build, but it provides a strong foundation for your writing.

Understanding that this is about how people coexist with large corporations allows you to easily build your key characters by simply designating them as in different kinds of relationships with the corporation and having different kinds of reactions to that.

Your main character is bound to the corporation not wholly by choice, having signed a contract that brought her in deeper than she thought. Now she finds herself a tool of the corporation in a literal sense, flesh replaced by mechanisms.

Then keep up the brainstorming.

Another character is bound in the same way, but the corporation saved their life and they are happy with the situation. Another character is seemingly bound to the corporation, but has such a high rank that it is her tool rather than the other way around. Another person is a chair on the corporate board but has no implants and is not bound to it. Another is working on implants and is bound to the corporation through high-security zones and reams of red tape rather than required maintenance. Others are not bound to corporation, and find themselves struggling to stay unfettered in a world where corporations are almost a requirement to get work, health care, money. And yet others are bound to the corporation by their need for maintenance, but do not work for the corporation - wealthy ones that can afford the best, poor ones that suffer greatly when they fail to make this month's payments, and ones that are bound up in the system and are "covered"... as long as they can keep their job, which is strongly pushing for them to turn themselves into tools and therefore be bound ever more deeply...

These simple relationships aren't hard to brainstorm. While some of the scenario is written into these assumptions - for example, we're assuming the corporation is not terribly ethical - there is no "plot" here. But you can already see how the plot might evolve as these characters and their activities bounce into each other. Each character is also written as a shadow of a character. We don't know exactly what their job is, or exactly what their feelings are. Those things, too, will evolve when things start to move.

You can easily repeat this process for every kind of setting you might be interested in.

Are you making an epic space military game, something like Homeworld or Mechwarrior? You're probably exploring the nature of war, or examining pieces of our current militaries. There's a lot of easy characters there, as well. Simply defining someone as "an admiral" is already more meaningful than before, because you know this is an admiral that exists to help explore the nature of war. So you know that, in the end, he's going to weigh in on topics like civilian casualties, the weight of soldier's lives, and how politics/money enters the equation. He's not simply going to be "good" or "bad". He's not simply going to come up with masterful strategies. He has more important things to talk about as well.

All of these kinds of thoughts do come with a price tag.

They make your writing easier, more compelling, and more memorable... but they do require you to show some opinions. You don't need to try to hammer your opinions home - that'd be counterproductive - but your opinions will naturally shine through. You might think this is problematic, but take a look at the best selling big games. They tend to have opinions. It's okay. You're allowed to reveal some part of yourself through your art. It's kind of what makes it art.

Building With Sci Fi

Well, you're brainstorming your setting. You're thinking about writing standards. What's your first act? Your second? What's the twist? What's the arc? What's the-


The thing about formulas is that they exist for the same reason we're developing right now. Formulas and scaffolds allow you to direct your efforts effectively, and write efficiently. It's hard to follow two formulas at once, so let's talk about a sci fi formula in specific.

The point is to give your story enough structure to make it compelling. We're not about ticking checkboxes - this won't make your story formulaic.

Finding Peace

Deep sci fi starts when someone is not at peace, and ends when they are. It doesn't matter whether it's a 1000-page book or a half-hour episode of an endless series. The easiest way to show how someone lives in a strange situation is to show them struggling to live in a strange situation. This is structurally similar to a heroes' journey, but it's easier to think of it in this way.

In Blade Runner, Deckard is called back to work for his old bosses. His peace is disturbed and he is sent out to do something dangerous and annoying. At the end of the movie, Deckard runs off with a beautiful robot, at peace with his choice and with the short time they will have together.

It's an extremely simple arc. Does Deckard "learn" anything? Does he change? Does he grow?

Maybe. Maybe not. It doesn't really matter: sci fi is not about the people growing or changing. It's about them living.

In Star Trek, every episode is about something disturbing the peace of the Enterprise - an SOS, a space wedgie, a sudden vacation, a nightmare, a warship. At the end of the episode, peace is achieved. In most episodes, twin arcs are used - an "A" and "B" plot, each of which is about striving for resolution in its own way.

In a cyborg game like Deus Ex, your peace is disturbed when you find yourself beholden to the corporation. What are some potential resolutions?

This is the easy part. Because sci fi is about exploring the human condition, "peace" is all about the kinds of peace people actually find. And there's not many options.

Death, falling, passing the torch, gaining a family, taking on an important job, or returning to old habits are the most common options.

In our cyborg game, death would mean the main character sacrifices herself or decides to leave the corporation even though she will die without its maintenance. Falling would be continuing to work for the corporation, or getting promoted. Passing the torch might be if she retires but a child she saved takes over. Gaining a family would be if she finds someone to love, adopts a kid, or remembers who her family was before the operation. Taking on an important job would be if she decides to fight to fix the system, or is promoted and decides to reform the company, or becomes a doctor, etc. Returning to old habits would require we establish old habits in the first place, but it's pretty straightforward.

Not all characters have to find peace. Only the main character. Others can take it or leave it, it really doesn't matter from a structural perspective. Similarly, they don't have to find a peace that somehow matches up to how they lost it: Deckard found peace in love, but his lost peace is contract work. You really have to squint to relate those.

So, when you are developing your story, figure out how their peace is lost, and figure out how they attain peace in the end.

The Engine

You have one or more main characters worked out, with their lost and found peace jotted down in pencil. Now you need something to give your story mass and shape.

The twist?

Thinking of a good twist is hard, and it's probably not worth it, because it'll be spoiled by the box art and the headline of the first review. Nope!

The engine.

What we need is an in-world conceit that shapes all our interactions. The key here is that the engine is not something which grants physical powers. It's something which grants specific relationships.

In our Deus-Exlike, the engine is the maintenance drug that only the corporation can provide. It binds everyone to the corporation, and instantly creates a ton of relationships. But - here's the kicker - it's a standin for ordinary corporate dependence.

The maintenance drug is a way to purify and amplify our real relationship to corporations. Our inability to choose another ISP or power provider. Our inability to leave our day job. Our inability to get away from our landlord. Our willingness to buy the next Apple product. Being forced to use Microsoft Word. Or, more darkly, being forced to obey increasingly aggressive policing, both physical and digital. Being forced to stay quiet despite the exploitation and destruction corporations cause. Otherwise, the company will take you to court and crucify you.

In Star Wars, the engine is the Force. It's basically magic, but the exact way it manifests forms the beating heart of the Star Wars universe. You can certainly argue that Star Wars isn't "proper sci fi", but it does have a good engine inside it. Like a moped with a rocket on the back. The Force allows us to amplify the concept of good and evil, of duty and personal responsibility.

In Star Trek, the engine is the starship itself. Starships occupy a very unusual place in that universe, because they are all large and owned by benevolent (or disinterested) governments. The Enterprise has a hilarious amount of freedom to do absolutely anything, and it's backed by the almost endless resources of the Federation. This allows us to build a setting in which benevolence can shine: good people are empowered as a default. Therefore, a lot of Star Trek is about exploring different definitions of "good".

The engine cannot be easily escaped. It forces people to do things, it gives some people power over others.

You may already have an idea for what your engine is. It can be anything that pushes people into new relationships. Anything that makes people band together and split apart. This will give you your cement, because it will guide your characters together and also tell you what kind of friction they will create.

... You can still put in a twist if you like, but it's just not as important.

Filling in the Stones

With an engine and a list of characters, we can start to see shapes form between the characters. "The corporation" never does anything. One of the characters with leverage over the corporation uses it as a tool. "An asteroid on route to earth" never does anything. Instead, it's the pressure and panic that causes the characters to do things.

Our main character works for the corporation, bound to it by reliance on the maintenance drug. This automatically creates friction between them and their bosses, between them and ordinary people. "Why are you doing these bad things?" some kid on the street asks her. She would stop if she could! She would stop. She tells herself.

The drug cannot be easily escaped. It gives your bosses power over you. And, in a way, it gives you power over everyone else - your advanced cyberware is only possible due to that drug.

In Star Trek, our space ships empower us. They give us the strength to push our concepts of "good", to resist or protect other people pushing their own versions. The Klingons think it is good for the strong to rule. The Vulcans think it is good for pure logic to win out. The Ferengi think that the greatest good is profit. Everyone is trying to be good, and our engine (ships/benevolent bureaucracy) give us all the power to push and shove and fight.

So, if we want to do an episode of Star Trek, we simply start with an A plot and a B plot. Let's say... Data's peace is lost when he installs an emotion chip. It is regained when he uninstalls it. The peace of the ship itself is lost when we fall for an ambush and find ourselves floating powerless in a nebula. It is restored when we defeat the Klingon and sail away. Very simple plot!

The stepping stones. Data's exploring the idea of "good" as an emotional response. This conflicts with the more nuanced and stable ideas of "good" put forth by the other members of the crew, but their concept of "good" does include the freedom to explore your own ideals. So Data moves through the episode conflicting with each character in turn, and each getting slightly more annoyed in turn. Each one gets to explain their idea of good, and how it conflicts with Data's idea.

So to do this, we just look at every combination and we write everything that comes to mind. Data's lower efficiency annoys Geordi, whose idea of "good" involves functioning well. Data's fear annoys Riker, whose idea of "good" involves bravery. Data's rage annoys the captain - no, wait, that's one option, but perhaps a better idea is if the captain represents the "good" of exploring your own ideals. So Data would attempt to remove the chip, and that would annoy the captain. Data's new emotions confuse him, so he sees Deanna, and she tries to cheer him up...

Why limit it to the crew? Data fights Klingons, who are impressed by his anger and prowess. Data talks to Klingons, and they are annoyed by his mechanical nature before he puts the chip in, and annoyed by his fear and weakness when he finally does put the chip in. Data gets into a fiery argument with a Klingon.

These are stones for one of the plots. Not everything is staunchly related to the engine of starships/benevolent bureaucracies. Not everything is related to the concept of "good". Those are simply underlying things which make it easy to come up with some of the stones.

There's not really an order to them, although there are some orders that make more sense than others.

You can come up with a similar set of stones for the plot about the ambush.

Enterprise tries to do its kind of good: rescuing people. Klingons try to do their kind of good: proving their strength and capturing trophies. Enterprise tries to be innovative and hold on. What are some specific encounters? Well, in this case it tends to come together rather more chronologically for me.

Enterprise tries to rescue "damaged" Klingon warbird. "Injured" Klingons beam aboard and try to take the ship. When that fails, there's a fight and the Enterprise is badly damaged. It runs into the nebula, where it loses power and drifts. Klingons try to hunt it down. Enterprise wins.

Coming up with things that can happen during the fight is kind of fun, although not very deep. Enterprise vents atmosphere to change course. Enterprise vents fuel and then blows it up. Someone - captured Klingons or crew - tries to build a radio and call for help using some other power source such as a phaser. Electrical storms cause damage to the Enterprise, but then become part of the critical final plan.

This method of brainstorming isn't anything new or impressive, but these scenarios look great tacked up on a wall.


Now it's simply a matter of putting the stones down in an order that makes sense, and linking them together. But this is also where deep sci fi shines.

Often, these mini-scenarios have an obvious order to them. The Klingons can't get annoyed by Data's cold-fish demeanor after he's put in the chip, so that has to come first. The ship can't drift into a the nebula before it gets attacked.

But frequently, the setpieces and events you come up with won't have any obvious order to them. Does it matter whether Riker or the Captain gets annoyed at Data first? Does it matter whether we suffer from a damaging electrical storm before or after Data talks to Deanna?

You can put them in some order, and it'll make sense.

But nobody will remember either event.

I'll give you three methods to link events up when there's no obvious order. This is not just a way to arbitrarily stack things: this is a way to make the themes and characters shine very brightly, because they all hold together.

Tick Tock

The first thing to do is to separate your ticking clocks. Ticking clocks are extremely powerful. Introduce them early, and resolve them late. A ticking clock adds a massive amount of tension, and every moment that happens within a ticking clock has more weight. Moreover, actions can be taken to try and resolve or extend the ticking clocking throughout its span, giving you an easy inspiration for additional events.

Our most obvious ticking clock is the electrical storm - the ship can only take so much zapping. Do we have any others?

Sure, how about when the Klingons invade the Enterprise to try and capture it? There's a struggle to find and contain them before they can damage the ship or hurt crew. Similarly, when the Enterprise takes a beating and warps into the nebula, we can make that a ticking clock to escape the weapons range of the Klingons. Whether a ticking clock is five seconds or five hours, it adds weight.

Ticking clocks are the "Dragonball charge-up scene" of sci fi.

Thematic Cause and Effect

The next thing you want to do is find the thematic links between events. For example, Data's steadily unraveling nerves are similar to the disintegrating ship. While Data's nerves are not a hard enough limit to be a good ticking clock, we can echo his mental state by using the grinding, sparking lightning storm. When Data says he's not sure how much more he can take, the ship judders and sparks fly out of a wall panel. You could even cut away to show the lightning storm from the outside, growing stronger.

Basic rule, though: don't cut away and then immediately cut back to where you were. That's a bit on-the-nose.

Echoes like this are very powerful. Cut between characters to contrast or support each. In our Deus-Exlike, our avatar is brought down by a debilitating lack of drug. We could cut away to show the loyal employee injecting himself, or we could not cut away, but instead have our avatar fall off the building and land in an alley full of discarded limbs.

Both work well - you don't have to worry about being too obvious, because too obvious is just about right.

In these situations, you have the opportunity to advance another thread during a cutaway. If we cut to the loyal guy injecting himself, then we should be advancing loyal guy's thread. On paper, whether that scene happens before or after your fall is unimportant. In the actual experience of the game, the thematic power of him advancing while you fall is very powerful. People will remember it: it's not simply that one came before the other. Thematically, your fall caused his ascent, even though the two were not related in any in-world causal way.

Ticking Callbacks

Most of your stuff should have a pretty concrete order at this point. Ticking clocks form strong bounding boxes, and within those boxes come the thematic cause-and-effect. And, of course, the fact that some things directly cause or predate others.

You may still have some floating bricks. You may be too sparse and need to come up with more detail. It's time for the Ticking Callback.

Ticking clocks are a call to action for everyone affected by them. As long as you have a ticking clock, you can show any scene of someone trying to fix it or delay it and it'll work perfectly. It's so easy, in fact, that you can also easily tie it into your themes, character progressions, and setpieces without raising the bar much.

You can embed events into the ticking clock by making them about the ticking clock. Geordi's annoyance at Data's new inefficiency is most powerful if it happens within a ticking clock, so it can be an event where Geordi is trying to reduce the damage from the lightning storm. Because there is a ticking clock, the scene fits in great, and now has a powerful explanation as to why Geordi is so annoyed.

But that's not the limit of our ticking clock integration. Oh, not even close.

See, whenever you create a scene to try and thwart the ticking clock, you have to create another scene where you use that exact same method for other purposes. This is absolutely required: a freefloating ticking clock scene is not very powerful, and sticks out badly.

If Geordi gets angry at Data as they attempt to armor the ship against lightning storms, good, that's scene one. But it's not very memorable on its own, and has no feeling of resolution. Geordi's little arc doesn't find peace.

So we come back to it. At the end of the encounter, the Klingons are getting close. How does the Enterprise defeat them? By turning the storm against them using the same technique that failed because Data was too confused and slow. Even if Data doesn't come up with the solution, it's fine: Geordi can say "hey, Data, remember when you made that storm worse?" And then the two of them can share face-splitting evil grins.

You can also set this up in the opposite order. If you think of a cool level or scene (the Enterprise vents fuel and lights it on fire!) you can set that up with a ticking clock action (someone discovers heat makes the lightning storms worse). However, keep in mind that the setup needs to be thematically linked in. In this case, we can link it in by having Data and Geordi have a spat about it.

This is just another way of setting up a Chekhov's Gun, but this method is powerful and easy.

For our Deus-Exlike example, we have a ticking clock of running out of drug. We attempt to resolve it by raiding a company warehouse, only to find that the inventory document was a lie: the warehouse is full of illegal robots that are far more dangerous and fun to shoot at. Later, we have the opportunity to unleash those robots on the corporation to create enough chaos and cause enough damage to let us accomplish a more important goal.


These approaches are built to help create a compelling story. They are flexible enough to accommodate the "cool setpieces" approach to sci fi writing, and also strong enough to let you link things together even when your boss dictates that level 2 and level 7 should be swapped.

To recap:

Figure out what aspect of today's society you are amplifying, and create characters that interact with that.

Figure out an "engine" to drive how people relate to each other, and who has power over who.

Figure out at least one main character: how do they lose their peace? What kind of peace do they attain in the end?

List a lot of cool interactions and setpieces and figure out how they interact with those ideas.

Find your ticking clocks. Start them early, end them late.

Figure out which scenes can thematically descend from or echo which scenes.

Fill out your roster with Checkov's Guns built inside the ticking clocks. Make sure the setups involve your original concerns, and the second half should be a turnaround.

Don't bother with a twist unless it's REALLY good.

Now you have a killer sci fi story that is both compelling and deep.

Tuesday, April 07, 2015

Pacing via Characters

Recently I watched this video. It's not even five minutes long, maybe go watch it first if you've never seen it.

Now, I'm not a huge fan of saying that comics and video games need to draw on cinema, but I don't think this is a cinema-only trait. It shows up in comics and games as well, we just don't have any good discussions of it.

We're talking about ways to move and maintain a story. In this case, the two ideas in specific are the way we connect story beats, and the idea of having several story threads running so we can switch between them. These are rather different concepts, although they tie together pretty well once you understand them.

Let's examine how they might work in a video game.

Story Threads

This is a common tactic in comics, often briefly switching over to show the villainous side of things whenever the heroic thread starts to flounder. Some comics switch between different sets of good guys. And nearly all of these comics have an omnipotent camera: we can see the thoughts of characters, the secret actions, it all plays out in front of us.

In video games, this technique is a bit rarer. Final Fantasy games tend to use this. Especially FF6, which had you play out each of the three main character arcs separately. However, even in FF6 the technique wasn't used to keep pacing sharp - you didn't switch between the branches, just played them in sequence. Instead of keeping the pace strong, this method was used to put spotlights on different groups and different parts of the world, allowing the player to have empathy with more people and places. Similar play elements such as the Laguna sequence are used in much the same way.

If a game wants to keep the pace up, they will use cutscenes - perhaps showing the enemy's board meetings or whatever. But this is not popular, perhaps because it's seen as a breech of point of view: most games have a definite main character, and seeing things they could absolutely never have even heard about is maybe a bit wobbly.

Some games get around this using inline second threads. A good example of this is System Shock 2's audio logs, where you would hear snippets of another thread that happened in the same place, but in the past. These audio logs served three purposes: pacing control, player investment, and exposition.

Exposition is obvious: you hear someone's audio log about toxic plants taking over the area, so you know what's going on and aren't totally confused.

Player investment is also pretty straightforward: you get attached to some of the characters as they continue to show up. Some of them are alive at the same time as you, and you can even seemingly interact with them in small ways, their later messages referencing things you did, or even talking about you directly. This leverage is not really used in the game except for once, but it's still there.

Pacing control is the most complex way it is used, because pacing control can be employed in a lot of ways. The audio logs are limited because they operate in tandem with the player's in-game actions. So the audio logs need to be placed in locations where the player won't immediately find themselves in a firefight, so the player can listen to the audio log in peace.

Well, with a few exceptions.

This means that all the audio logs are found during 'slow' moments. In movies, you generally switch to the second thread just when the first thread is beginning to slow, but in this case you interject the second thread to try and support the flagging pace of the first. Even if it contains no pacing elements in itself, its existence is a pacing element.

It can contain pacing elements as well. For example, hearing someone complain about psychic monkeys will put the player on edge, on the lookout for psychic monkeys.

Variant: Rashomon Rush

One interesting variant on this idea is closer to home. This is commonly found in sports manga. Instead of having multiple threads of story, you can really only have one thread: there is one contest, one race, one tournament, and you have to keep the audience interested throughout. Rather than cutting away to some other story thread, you simply show the tournament from the eyes of many characters.

For example, in Yowamushi Pedal, many of the chapters are entirely focused on a team bike race. From an absolute perspective, bike racing is just about the least interesting sport to focus on. It's not interesting to look at, it doesn't change very rapidly, it rarely has any unexpected interruptions. You can force some in - a crash here, a rainstorm there - but they are not really enough to make the comic feel dynamic.

What Yowamushi Pedal does instead is switch between the characters in the race. As the comic goes on the artist becomes more adept at this, often showing the viewpoints of two or three characters in quick sequence.

It's a bit like the "Dragonball Gasp" - the characteristic page full of reaction shots - except that each character has their own distinct thoughts and concerns rather than just contributing a dumbfounded expression.

This tool can be used both slowly and quickly. For example, in the Interhigh arc, there are three important teams. The "primary" team with the main character on it, a secondary team that they lost to last year, and a new team with a clear villain leading it. In this portion of the chapter, the primary team is out of position. Rather than focus on that, the comic takes half a chapter and focuses on a seemingly irrelevant contest between the villain and a sprinter from the secondary team who we've only seen in the background of a few shots.

Over a dozen or so pages, this fight unfolds. It involves flashbacks, half a dozen characters discussing the sprint without being able to see it, and, of course, the sprint itself. None of these characters are the main character. None of them is even a direct supporting character. It's a complex ballet happening without any of the most significant characters.

I guess how you feel about it might vary, but in the end we have created a solid new character (the sprinter), made the evil side look more evil, made both the rival teams look more virtuous, and also given the main team the time to enter back into the main story thread (front of the race) without needing to dedicate an entire chapter to it. Later on, the villain's villainry shines brighter and that particular sprinter gets to play a moving minor role near the end of the race.

It's a pretty good technique. It keeps the pace high without losing focus too much, it develops the main villain, and it develops a secondary character well enough to make us care about his performance later. Nevermind that his traits are dull and he could never take center stage for any extended period of time - he comes in just long enough to establish that the villain is truly bad and that the good guys are truly good.

Putting aside the flashbacks, we never "leave" the race. The race never skips forward or backwards. It's a contiguous event that continues happening throughout the chapter. Effectively, we're focusing on the elements of the race that are the most interesting, while also stockpiling reserves of good and ill will.

In a video game, game state is often quite complex. It's easy to lose track of the details between play sessions, or if you switch play modes. The ability to focus on a specific unfolding scenario while still changing out pacing and emotional investment systems is quite valuable.

It might be a little difficult to imagine what this would mean in a traditional computer game, but that's because traditional computer games are built to not use this system. Instead, imagine something like an MMORPG, where each player belongs to a faction and the power of the faction depends on their performance. The faction is part of a complex, unfolding scenario. The elves and the klingons are enemies, and war is slowly breaking out - planet by planet, treefort by treefort.

Some players log in for hours each day, and every detail of the conflict is always crystal-clear to them. But others only log in for an hour or two a week, maybe just casually, to hang out with friends. It's easy for the conflict to race ahead and leave them behind!

In the past, the question was how you could allow dedicated players to influence and enjoy the complex situation, while still making sure the casual players could enjoy themselves and not feel completely lost. So far, the only two approaches have been "screw the casuals" and "nothing ever changes".

This offers us a third option. Using "Rashomon Rush", we can

A) Slow down the fast players by introducing them to interesting side characters and quests with different views on the same unfolding situation.

B) Speed up the slow players by hitting the high points of their roster of characters stories without slogging through every moment of it.

But and Therefore

The other aspect of that video is "but" and "therefore". Basically, we want to tie things together in a way where every step in the chain moves us.

In computer games, it is common to have an underlying theme and core plot progression bogged down in endless repetition. To avoid this, devs carefully write a progression - level by level they plot out an interesting story. This can certainly work, but it is also quite limiting. Every time a player plays, the levels are the same. A player cannot go off the rails - the closest they can get is going down a different set of rails that the devs also thought of.

Let's consider a different option. If we free ourselves from the idea that a player must absolutely play the same avatar the whole time, a world of possibilities opens up. Instead of switching from Snake to Raiden at a predetermined plot moment, imagine if we switch when the player has reached "peak Snake".

So a clumsy player gets Snake caught. Instead of "Snake? Snake! SNAAAAAAAAAAKE!" we just get a camera pan out and then pan in on Raiden. Same scenario, but now we're playing Raiden. What's Raiden doing?

Rescuing Snake, obviously. Snake was captured, therefore Raiden will rescue him.

Oh, did Raiden get captured, too? You really suck at this game! But it's okay. Pan back to Snake. He's halfway done escaping! Take over!

Functionally, Raiden and Snake will get tiresome because they have the same basic powers and play style. To use this method, we really need to have characters that have very different viewpoints and failure conditions.

Again, we can look to sports manga for an easy solution. Although the whole team is playing in the big game, each character is portrayed as having a different role and being interested in a different tiny piece of the game. While we are focused on one person, the other team members continue to operate in the background. We only give the lead to them when they have something to add to our story - something to react to.

Imagine something like Grand Theft Auto, except that you play three characters that aren't boring thugs. Each of your characters has very different and conflicting goals. As you try to accomplish those goals through a combination of open-world play and open quest lines, you will change the world around you. Whether it's blowing up a gas station or preventing a bank heist, these events can easily become a plot point for another character with a tangential set of interests.

You blow up the gas station? A minute later, you're playing a fireman getting harangued for not being able to put out the fire. You thwart a bank robbery? A minute later you're playing the robber, trying to escape from the police car.

This is pretty basic stuff from a script writing perspective.

In fact, it's so basic that you can automate it.

Theme Chain

There are a lot of things we want to automate. Let's discuss them.

1) Cut Away
We want to cut away from a player experience when they're about to go through pointless downtime. This is not as complex as it sounds: after a big battle or cataclysmic event, there is a rapid decline. We want to cut away while we're on that decline. Any point on that decline is fine.

We need to be aware that not every event is big enough to do this. In GTA, blowing up a gas station probably isn't significant enough. But there is one thing that is extremely clear: death. The simplest algorithm for this is to cut away when you die, and then 'therefore' using the largest thing that happened during your life (which may have been your death).

If you build from the ground up with intent to create rising-falling action curves, it's not hard to create the proper shapes in a more fluid, explicit way. But it can be crammed into standard game designs as well.

2) Thereforing with Themes
When we switch from character to character, it's not just a matter of choosing when to cut away. It's also choosing when and where to cut back in. We need to cut back in on a "therefore". If you burned down a warehouse, we need to cut back in on someone dealing with the fallout from that. We need a way to have logical connections between significant events such as major property damage and other characters that have to deal with them. It's not hard, but it has to be programmed in.

But here's the trick: character themes and gameplay are more important than strict continuity.

Gameplay should be obvious. You can't cut to a firefighter putting out the fire if there's no gameplay about putting out fires.

Character themes are a gateway into cutting properly as well as having a very strong, cohesive game.

If the overall theme of the game is "searching for sparks of hope in the ashes", each character would have a specific theme related to that. For example, our firefighter might be all about finding hope in the survivors of disaster - IE, rescuing people from burning buildings. This is an explicit theme. It's programmed into the game in an explicit way. The algorithm which determines what happens after significant events includes hooks for this exact theme.

If we burn down a building, the algorithm understands it needs to talk about survivors. So it spawns a "survivors" hook. There would be a variety of them - one where you are talking to someone you rescued, one where you are held back from rescuing people because it's too dangerous, one where your boss calls you in to berate you for not rescuing anyone, one where your boss berates you for letting things get out of control and you yell that at least you saved some people, etc.

Every character contains a batch of "flexible hooks" like these. When a significant event needs to be "therefored", you simply thumb through all the available characters and check for who has the strongest hooks available in response to that event. The specific hook will tell you when and where to cut back in, and the strong theming will naturally flow into the overall experience of the game.

3) Exposition
By skipping around, we are missing out on pieces of the puzzle. Moreover, we're always creating new pieces of the puzzle. In our effort to move from the person who blew up the warehouse to the fireman who failed to put it out, we have to make it clear what happened. If we're using a Rashomon Rush, we have to explain to slow players what has unfolded when they weren't watching. Etc.

There are three big ways to do exposition, and you may want to consider all three.

Cut Scene: when we cut from one character to another, we can start the new character's section on a cut scene or similar interaction. That can contain the data we need. Getting chewed out by your boss for failing to put out the warehouse fire clearly establishes when this is, who we are, and what happened. This exposition should be built into the hooks that allow us to cut in.

Background Chatter: audio logs, people talking, posters - we can say a lot by changing the ambient background stuff. If the elves and klingons are gearing up for war, put war propaganda posters on all the walls. People who have been logged out for a month can log in and immediately see the posters, immediately understand where society is at.

Job Change: if your avatar's role, priorities, or side missions have changed, it clearly indicates a changing situation. For example, you played a cop for a while but then were someone else for a few weeks. When you jump back into the cop, she's gearing up in black body armor and carrying an assault rifle - you know something has changed.

4) Emotional Investment
Normally, in order to get a player emotionally invested in a character, you have to have that character directly affect the player. For example, the villain has to stop by to kick your ass personally, or a heroic secondary character has to do something helpful for you.

By allowing ourselves the freedom to switch between characters, we can develop emotional investment without needing to tie it directly to the primary avatar. We can switch to the villain and be evil. We can switch to some arbitrary character that the villain is screwing over. Etc, etc.

Emotional investment is extra touchy when it comes to randomly generated characters. If all your characters are handcrafted, your hooks and scripted plot events will probably create plenty of emotional investment. But if your characters are arbitrary or random, there's nothing to grab ahold of.

Well, you can use random characters to generate extra emotional investment by having them struggle against another, more important character. One-off random characters can have relatively dull traits and, as long as they are constantly under pressure, it'll work out: it'll generate a lot of emotional investment for more important characters nearby, and also generate some investment in the dull random character themself. Later on, you can bring the minor character back for cameos and it'll feel great.

This is also a good way to keep pacing strong without needing to have a huge number of carefully themed main characters. Just occasionally throw in a random side character with a batch of random traits.

Anyway, I hope this was coherent: I'm just trying to say that we might want to explore switching our point of view a lot more often.