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-

Stop!

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.

Bridgebuilding

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.

Final

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.

Monday, March 30, 2015

RPG Characters: The Obsidian Method

I played some of Obsidian's new game: Pillars of Eternity. Obviously, I haven't finished it. I only spent about 40 hours on it.

It's good, but I'd like to talk about design a bit. I am vaguely creating an RPG engine, so it's good to think about these things, have tools ready to help people do them.

So let's talk about the Obsidian NPC method, AKA the Bioware NPC method. I first ran into it in KotOR, so it's Obsidian's method to me. It was also used in Dragon Age, Mass Effect, and of course, Pillars of Eternity.

This is a very polished formula, and if you follow it, you'll produce good results. That said, it's not applicable everywhere and has its flaws. Well, let's learn it!

Step 1: Pick stereotypes
Your characters are based on stereotypes. You want to pick a variety, because every player will have different preferences and therefore feel happy with certain stereotypes and annoyed by others.

For example, in Mass Effect, Liara is the sexy nerd stereotype, Ashley is the no-nonsense career woman stereotype, Kaiden is the earnest man, Garrus is the brash man, Tali is young Romani, Wrex is the jaded warrior.

The stereotypes can be quite niche ("young Romani" is a pretty rare one, as is "fast-talking uber-nerd"), but they're still stereotypes.

Step 2: Pick facets
Each character has two things that they explain about the universe. Normally, one of these things is their species or culture, and the other is how their job is related to how the universe works. These should hopefully gel well with their stereotypes.

For example, Liara embodies her species (sexy) and the search for the precursors (nerd). Garrus embodies his species (manly) and the lawlessness of the Spectres (brash). Wrex embodies his species (jaded warrior) and explains the non-earth, non-citadel militaries (jaded warror). Ashley embodies earth military but also the racism endemic to the earth military. Etc.

The characters serve as windows, introducing the player to their concepts and, in turn, the concepts that make the universe tick. As the game progresses, they will continue to weigh in on these topics and offer side quests related to them.

It can be difficult to balance these facets. Liara represents her species, and her species is a constant background hum to the game, popping up frequently. So that's a good facet. But her other facet - investigating the precursors - is not a good choice. The precursors aren't ambient noise and don't pop up a lot in the course of play. Instead, they are critical plot points. That means she has to do a lot of exposition and cannot really express herself as a character.

Tali is a really good combination. Her species aren't as common as Liara's, but she has a lot to say about them and it strongly affects her design, so they are present through her. It also supports her being able to comment on the opulence of your civilization. Her second facet of Geth obsession seems like it'd run its course and stop, but it segues nicely into her having things to say about the Reapers as a whole. It also supports her having things to say about technologies in general. She is rarely required to be exposition, because the things she has to say are rarely required to understand the situation. So she is free to comment from her personal standpoint, which makes her seem alive.

Looking at KotOR characters, you can see the same kinds of designs. The Force-sensitive characters have things to say about the nature of the Force instead of their species, and it works pretty well.

Step 3: Audiovisual Design
Each character needs to have a distinct audiovisual design which makes their character unique and appealing while reinforcing their stereotype. If they are another species, then their species design needs to also support their stereotype.

Visual design is important, of course. Color and costume shouldn't be overlooked, either. Audio is often overlooked, but it shouldn't be: Garrus and Tali were popular largely because of their modulated voices and memorable voice acting.

The problem with the first Mass Effect game was that 99% of the unique design came from the species rather than the characters. This really showed in the human characters, which were so blandly designed that nobody could remember them.

In the later games, the human characters were designed to be a bit more memorable - largely through costume choices. It's tough. You get a stark breadth of possibility when you're using different species. Trying to distinguish within a species is always going to be more difficult.

Step 4: Integration into Game World
In order for the NPC to be memorable, they have to make an impact on the player's mind. The best time to do this is during their intro segment - they will typically join up during a particular mission and you will be more or less forced to use them until the mission is complete. During this time, they need to shine.

After that time, it can be difficult to guarantee that they will be in the player's party. If they are in the player's party, they are going to be able to comment on things - even just simple shouting during combat can make a big impression. But if they aren't in the player's party, they might tend to fade out of the player's mind pretty quick.

Performing "impact in absentia" is therefore very important. The way to do this is to have the facets the character represents keep coming up. The player will remember that the representative character exists, and perhaps switch them in so they can get their ambient opinion on things. You can also have them call in with comments, or even be hanging out in the game world when they aren't in your party.

You can also force or strongly insist the player take specific characters - for example, if you go to Wrex's homeworld, taking Wrex just makes sense.

Ongoing updates/unfolding backstory are also a good way to do this. Chatting in the safe zone, getting quests, unlocking new costumes or powers, pursuing a relationship, etc. Just keep in mind that if a character isn't in the party, the player probably doesn't like them very much, so you have to write with that possibility in mind.

Note: Things Not Included

A lot of typical character design concerns are simply not important in this scaffold.

First off, you don't have to worry about character arcs.

The player is probably going to want to earn the NPC's trust and allegiance. This is normally done through some dialog options and side quests, and while you can make that a character arc, it's not necessary. The character's important change is in how they interact with the player, not what their fundamental personality is. If you do decide to make it a character arc, be careful not to alienate the player with the "before" half of the arc, as with "Ashley the Space Racist".

Second, you don't have to worry about softening or hardening their stereotype.

They are integrated into the world through their facets, so they should feel like they exist already. Their personality should feel like it naturally arises from their situation, so you don't need to go out of your way to alter their personality. The stereotype will soften naturally because of the nature of the structure.

Conversely, don't try to play up their stereotype. Liara and Tali are borderline offensive stereotypes, and if either one had been played up even an inch, it would have been obnoxious. Because their personalities seemed to flow from their situation and didn't feel forced, they were largely accepted.

If a character seems iffy when you don't try to adjust them, their core stereotype is probably bad. Don't use it at all. Don't try to "soften" an offensive or ill-fitting stereotype. Just don't use it.

The Numbers Game
As you might guess, not all characters appeal to everyone. Because of this, there is one last piece of the puzzle: having the right number of characters.

The Obsidian/Bioware approach is to have 5-7 NPCs, but only have a party of three people total. That is, two NPCs. You need to choose two out of the seven.

This percentage is good: there are going to be two stereotypes you can generally get along with. But there are also going to be at least that many that the player can't stand, because they hit sore spots. And then the rest will probably strike them as too bland to bother with.

You need to carefully balance your combat/skills to allow for flexibility. If the player ever feels forced to take a specific NPC due to a skill or combat role requirement, they're going to be annoyed. Being forced to take an NPC because the NPC is actually involved in the situation is a lot less obnoxious.

Fundamentally, playing the numbers game is actually a numbers game: you need to be sure that every given player will feel comfortable and happy with at least two of the characters, and not so offended by any of them that they stop playing immediately.

This shouldn't be considered "weakening your vision". Considering your characters from a variety of diverse viewpoints is pretty reasonable, and the result should feel like your universe is full of people with a lot of different viewpoints.

IE, realistic.

Final Thoughts
This NPC method is not always the best. There are a lot of times this fails. In fact, I think it fails in the new Obsidian game. But it's worth understanding and it's a pretty good formula if you don't know where to start.

Tuesday, March 17, 2015

Optional Things Exist

I had a bit of a conversation about Nintendo today. One of the things we talked a bit about were the gold suits in the new Mario games. These are the suits you get when you die a lot in a level. They basically make you an immortal godling.

We came at this topic from very different angles. Obviously, the gold suits are a boon to unskilled or young players. But they are the reason I stopped playing.

I know they were optional. Sure, they're optional. A lot of devs seem to think optional things don't exist as long as you decide not to use them.

The opposite is true.



Let's talk about in-app purchases, which is how the whole thing got started.

The most common kind of in-app purchase is a gameplay helper. Whether it's a stat bonus, a rare item, free gold, more moves, whatever. It's always "optional". You can keep playing without them.

But they wage war on you just by existing. Every time you make a move and that glowing icon tells you that you could be doing it better, it's psychological war. It wears on you. You aren't playing the REAL game. You're playing a shadow of it.

Now, the golden suit is not asking for your money. It's free.

That doesn't mean it's any different.

The intent of the developer is almost unimportant. The thing that matters is what the player sees. And, to me, the glowing golden suit is exactly the same as a glowing shop button. More powerful, if anything, because I know it is provided out of kindness.

Sure, I can struggle to ignore it, but just by existing it cuts the foundation away. Why am I struggling through these levels? Even the developer doesn't give a shit how I beat them. It's especially bad because the developer gives up far before I do. They actively cut off my struggles before I'm done - "yeah, I can see you're trying, but your efforts are doomed and worthless."

It's not simply that the opportunity to bypass the levels exists. It's that it is pushed upon me so aggressively. The developer isn't saying "oh, here's an out if you need it", they're saying "you're playing wrong." If the suit could be turned off in an options menu, I wouldn't feel cut off at all. I would enjoy myself, knowing that there is a safety net cached away in an options menu I never have to look at.

What I'm getting at is that "optional" things exist. They have a weight and a presence. Even if a player chooses not to use them, the player still chooses in regards to them. And every time you offer the optional thing, you force the player to choose again, to take that optional thing into consideration, to consider the intent of the developer and weigh their own plans.

This isn't always bad. Many RPGs offer you optional things you can choose to do or not do. To be good or evil. To steal or not. To kill or not. To use magic or sword.

We choose what to do and what not to do, and that's the heart of our experience. Done badly, it can be repetitive, sure. But it never feels like the game is short-circuiting itself for the sake of offering those options.

Maybe it's because those options exist within the game world, rather than being inexplicably imposed onto it like the golden suit or the IAP shop. Maybe it's because the options are gameplay-centric rather than gameplay-avoidant. Maybe the lines vary from player to player.

There's lots to discuss. Quicksaves and quickloads become a part of this discussion. Permadeath. Multiplayer. They all exert pressures, put options in front of the player. And even if the player chooses never to use an option, that's still an active choice that the player must make every time the option is presented.

And I chose to stop playing, because the gold suit made the game feel pointless.

The developer kept telling me that trying to beat the levels was pointless, so I finally agreed with him.

Wednesday, March 04, 2015

Best Laid Plans of Mice and Mods

I'm finally wading into the guts of the new modding system. Anyone who's made space for mods understands the tradeoffs: where do you leave space for modders? What is hardcoded, what is "softcoded" so modders can interject?

But this project is a bit different. It's intended to be open source, so nothing is truly hard-coded: the players can always edit the core code. Similarly, mods are created in the Unity project and exported from that space. It's not simply open source, it's a project where every modder is going to have the source code, even if they never really interact with it.

During this experiment, I've found myself developing in a strange way as a thought experiment. I've been trying to make absolutely every part of the gameplay a mod.

Some things are largely hardcoded. The way construction is handled, the way the basic menuing works, the light of the sun, the core existence of FacilityObjects and FacilityMOBs. In theory, these could be overridden, but they lay outside the modding infrastructure. A mod would need to aggressively intervene into the core systems in order to change those things. But... that's what most mods actually do in other games. The mod experiment has changed what I would consider "acceptable".

This morning I wrote electrical systems into the game. Power is a critical component of base management, so you can consider this a core feature. The vehicles you drive up in have solar panels attached to them, and can also generate electricity through their chemcell engines using some kind of liquid fuel. They have a specific amount of energy storage. These resources will last you some time, hopefully long enough to establish your base as an energy source instead of an energy sink. This is critical because it takes energy to build some things (for example, sintering sand requires energy, welding requires energy, etc). The more vehicles you build and take with you to your next location, the better off you'll be at the start.

There are a number of things the electrical system play requires. When you mouse over a car or a solar panel or whatever, the context popup needs to tell you how much energy is available/generated there. When you look at the facility overview, you need to know how much total energy is available, how much you're producing, how much you're using with standing facilities, how much you're using for construction or one-off activities. Moreover, it needs to continually update every time you build something new, do something new, toggle the behavior of an energy producing facility object, etc.

Sounds kinda... complicated and core, right? I mean, not complex in the grand scheme of things, but wired into a lot of the core game systems.

It's a mod.

Literally. "Core Electricity mod. Requires: Core Facility View mod. Priority 99"

A flip of a toggle, and the mod turns off. Nothing costs any energy. All the things that produce or consume energy stop caring about energy. Maybe some of them will stop being added to the list of available objects, when I care to bother dividing that stuff up.

Now, in a few small ways this is a cheat. Most of the core content is "integrated" with it, in terms of having an electrical cost to build. If you turn the mod off, that electrical cost stops mattering, but it's still part of the content. Similarly, most additional content later will probably also be integrated with the electrical mod. You can't really "not install" the mod, because it would involve not installing nearly every piece of content.

But you can "disable" the mod - all the content stays, but you are no longer limited by electricity and no longer receive reports about it.

All the reporting - the context popup, the facility overview, the build limitations - is part of the mod.

And this is how I've begun to think about my game systems.

Everything is core. Nothing is core. The systems are all stitched into the framework in the same way.

"Isn't that kind of a nightmare to develop?"

Well, I programmed the heart of the electrical systems before work this morning. In half an hour.

The key is the easy combination of ScriptableObject mod definition, the two GameObjects you specify as the overview menu item and the context menu item, and the UnityEvents that hook in automatically. It gives you an extremely easy "in" for hooking into the game world and running calculations.

"Isn't it painfully limited?"

Well, it's basically an API. The mod itself is fundamentally a way to interface with the game framework. But unlike a rigid mod API, this happens inside the Unity framework. In addition to the ease of integrating with UnityEvents and the inspector, you can use Unity's debugging capabilities and interact with the rest of the systems using actual code.

I've found that it produces extremely crisp results. Game systems tend to get complex and inter-related very fast and in very convoluted ways, at least when I program them. This keeps the systems so crisp you can actually turn them off.

This probably wouldn't work for every game. But in games which are largely statistical, this seems very powerful.

I'm sure I'll encounter drawbacks soon, because otherwise everyone would develop this way already. I'll keep everyone posted.

Monday, March 02, 2015

Mod Integration

So, it's one thing to talk about easily integrating mods into your game's content. But there is a more complex question: how do you integrate mods into the player experience?

Most mods simply add some content. No biggie. It shows up in the same lists as all the other content, the player experiences it the same way as any other content.

But many mods go further.

For example, in Kerbal there are mods which change how aerodynamics work. In Skyrim there are mods that change how you manage and use your NPC followers. In RimWorld there are mods which overhaul the nature of combat entirely.

In terms of code, all of these mods work. That is, they are coded and the code executes and the game simulation runs properly. But from a player perspective, these mods are clumsy and difficult to use. Even smaller mods such as adding in a new kind of stealth attack or a new kind of thermal simulation are often difficult for a player to understand, difficult to see running.

In Skyrim, this is solved via menus. Some of them are solved via conversation menus - talk to someone and you get a five-deep branching tree of options and possible commands. Others are solved via the mod menu mod, which lets mods put their parameters in a menu for tweaking. But neither of these options tells you how things work - it's just an interface for tweaking the mod. When you're done, the mod goes back to silently doing whatever it was doing.

In Kerbal it is also usually solved by a menu as well, but the menu is displayed right on the main game screen. The problem is that the menu is always in the way, and if you have eight mods, you have eight floating windows. There have been attempts to consolidate using a toolbar mod, but that has issues of its own.

In RimWorld mods really have no say in the interface at all, as far as I can tell. So all mods run silently, not even allowing for option tweaking.

I'm taking the opposite approach.

In my game, there are several spaces the player looks to find information.

One is the contextual popup. When you mouseover a tile or person, it reads out the details of what that is, whether it is navigable, whether it's friendly, what the temperature is, how much electricity it uses, etc. If you click on them, these contextual readouts become solid and interactable - perhaps giving out tooltips, perhaps becoming a button you can click to open a more powerful menu.

The key here is that a mod may, if it wishes, add a line to this context menu. In fact, the core features mentioned - electricity, nagivation, friendliness, etc - are all handled using the same methods as the mods use. So if you want to add a mod for sorted cabinet inventories, it's considered as "core" as the concept of electricity. You can even plant advanced functionality in your widget to draw on the game world for things like radius, heat mapping, etc.

This allows a player to see what the mod is "thinking" about the various objects in the game, and also provides an on-hand way to tweak the tweakable elements of the mod.

The other place a mod might want to talk to the player is in the facility overview tab. The electricity mod shows you total kWh available, total generated, total on-demand, etc. Friendliness might show you how many people of various factions are visiting. Etc. Moreover, these can be interactive. You can tweak things by clicking on the panel or, if there are too many options, you can even have a button which pops up a full-screen menu.

I'm not overselling this: Unity's core functionality is available, and both the context widget and the overview widget are simply considered GameObjects and spawned into the scene. There are a bunch of default hooks - onMenuOpen, onMenuClosed, etc - but you can also add in UI buttons and widgets of your own choosing and code them to do anything you want.

Not all mods need this. A mod that adds a new gun or a new person doesn't need a menu item. The basic mod management screen is plenty for that kind of mod - just allow the player to turn it on and off, no need for ongoing management as you play.

But I want players to build overhaul mods. I want players to turn off my shitty core electricity mod and replace it with their custom mod that does things better. I want players to create a mod to make the NPCs behave very differently, with a variety of context commands and AI cues. I'm happy if a player adds a new gun, but I want them to feel the urge to change the game as well.

That's what I'm working on these days.