Tuesday, August 13, 2019

Topological Construction Play With Scenarios

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Tuesday, July 23, 2019

Making Things Seem Bigger

One thing I love about video games is that I can make things as big as I want.

However, I've quickly learned that bigger isn't always bigger.

The human brain uses a lot of specific techniques to "feel" how big something is, and those are not the same techniques a game uses to render bigger things.

As a result, a lot of indie content is overly huge... but doesn't feel big. It just feels boring.

So my focus now is on how to make content feel bigger without actually making it that big.

This shares a lot of techniques with various architecture, theme park, and interior design practices, but it's distinct from them because we're working with something that doesn't actually exist.

With that in mind, here's some half-formed ideas I had about it. Feel free to chime in.


One thing is to "clutter" the right amount.

Say you have a 10mx10m area. That's about the footprint of a small house. How do you make it feel big?

Well, one way is to declutter. If the area is wide open, flat, and brightly lit... it'll feel bigger. But it'll also feel empty and pointless when you move through it.

Another way is to clutter. For example, if we put in islands of furniture, maybe add some pillars... we can add a lot of density to the space. In this case it will feel smaller to the eye, but it'll feel much larger and more interesting when you actually move through it.

We can probably get the best of both worlds by using "zoning" tactics instead of simple clutter tactics. For example, using different flooring types to cut the room into areas, adding a raised or lowered section, creating drop ceiling elements, using ceiling topology to create complexity up high, adding lights that create patterns or focal points in the corners... these keep the room feeling large to the eye, but still make it feel detailed as you move through it.

If I was creating a complex level, I might focus on decluttering on neighboring spaces the player won't travel to much, so I can make them physically smaller but feel like they are quite large when glimpsed by the player. Spaces with dense gameplay, I might use clutter to reduce travel times and create overlapping concerns. Spaces with a moderate combination of both gameplay and travel might focus more on zoning...

This is a really basic example, but I wanted to show that what I'm thinking about is not simply "how to make things look bigger", but "how to make things feel bigger as you move through them". After all, video games are interactive.


If you are walking up to a space ship, how can you make it seem like a really big space ship?

How about if you're flying up to one? Swimming? Teleporting?

Controlling the kind of movement the player is using is critical, because that's how you amplify the size of a ship.

For example, if the player is walking on the outside of a ship, the ship is basically terrain, very close to the player's face. Even small ships like fightercraft can feel very large if you're clomping across their wings in magnetic boots! They'll feel even bigger if you're going hand-over-hand along a guide rail, your helmet a mere foot from that same wing surface...

If the player is coming in from a distance, it's important to allow them to feel the distance of the ship by giving them nearby motion. For example, walking through gates, or passing through a cloud of debris, or walking past parked cars. To amplify this, the nearby motion does not have to be parallax: as you approach the ship, cars drive past you away from the ship. Barriers lift in front of you. The wind kicks up a dust storm. These motions will help to give the ship a sense of scale, even though they're not technically parallax.

The ship itself is also optimizable.

One thing you can do is simply add elements of scale to the ship, like a heavy crane loading up cargo, or a worker squatting on the wing, touching up the paint. These are things that we think we understand the size of, so our brain will naturally get a feel for how large the ship is. If they're slightly undersized as compared to what we expect, then the ship will feel oversized: workers should be crouching or kneeling to reduce their apparent size, cranes can be built with "heavy industrial" feel even when they're medium industrial size, etc.

The ship itself has a particular layout that can be optimized to create parallax. Smaller ships should have protrusions and/or limbs: head, wings, engine nacelles, antennae or cannons that stick out. These need to stick out in directions that create parallax: having an antenna stick up is good to create a sense of presence, but it doesn't create any parallax unless it's sticking outward. Things like antennae should have lights at the tip: this will make the parallax clearly visible and also make the ship feel larger at greater distances since the lights will define a perimeter.

Larger ships can be thought of as places rather than things. For them, it's more important to create an approach vector that creates nice views, rather than having protrusions. If the player is moving towards a large ship on a curved approach to dock or enter on a specific spot, that will allow the player plenty of time to see the parallax grow as they get close. However, if the player is approaching on a direct path, the parallax will be minimized.

Entryways like docking bays and gangways should be nestled into concave areas. The surrounding protrusions will create a sense of parallax as you move towards or away from the entrance. So... overhangs, side braces, giant clamps, whatever you can do.

You can also use "bristles" on ships, large or small. Any kind of semitransparent lattice will work, with the idea being that regardless of your approach vector, these will have noticeable parallax. Lighting concave areas and areas behind the "bristles" will also produce a lot of changes as those regions become more or less visible due to parallax.

If the ship has large topologically uninteresting zones, add lighting or paint elements to create demarcations. They don't have to be visible at large ranges, they're specifically to break it up when the player gets close, so faint greebling or motion-sensor lights are plausible.

In addition to parallax tricks, you can use a million other tricks. Small ships can "bulk up" when parked by raising their wings, opening their canopies or fueling covers, half-ejecting fuel rods. How heavy they feel is also a factor: do the feet sink into the ground? Does the howling wind knock their antennae around but leave them unbudged?

There's also things like atmospheric effects, depth of field, and converging lines to think about... placing a parked ship noticeably above or below the horizon will make it seem closer, while on the horizon it will feel further away. Therefore, small ships should park on the horizon line and large ships should park above or below it... keeping in mind that the player's horizon line is determined by camera height, not by eye height or walkway height, so approach vectors should have ceilings to force the player's camera into a predictable horizon line.

And that's just the exterior...


Making areas feel big on the interior is perhaps even more critical, because you don't want the player to have to walk long distances inside of a building or space ship. So things need to feel big without being big.

Level design conversations about this are not impossible to find, but here's some basic tips I'm eager to try:

Windows or overlooks onto interior spaces, not just exterior windows. Central spaces with complex traffic patterns, including multi-floor elements.

Clean straight paths through cluttered rooms with a clear view of the next room, curved paths through larger, uncluttered rooms...

Light the corners more aggressively than usual, but while remembering to break the cubey feel of corners. IE, stick well-lit furniture into corners.

Use cut-out alcoves to create workspaces, rather than putting workspaces into the main floor area.

Trying "false windows" instead of Jefferies Tubes: IE, a grate or transparent panel with a largish, lit area behind it.

Having screens default to scenery instead of black.

Using the wall lines common in sci fi to enhance the size of the room instead of just making it feel cluttered. This is easiest on scales larger than a small hallway: for example, in cargo bays. One critical part of this is to use lighting in any sci fi recesses: IE, if you have a head-height outwards bend, put lights in it.

Use furniture/functional elements that take the room's major axis into account. For example, if I want a hallway to feel shorter, I can use vertical banding (braces and bulwarks). If I want it to feel longer, I can use horizontal banding (stripes and shelves).

Using small rises and falls, both in large rooms and in chains of small rooms. The rising and falling can be floor, ceiling, or both.

Create centerpiece elements that aren't actually in the center of the room, since players shouldn't be using 100% of the room evenly. Centerpieces should make the room feel larger when you're passing by, and usually only one or two edges of a rectangular room are travel lanes.

Interrupt the flow of a room logically, but not visually. Using glass, transparent hologram, floor and ceiling patterns...

And I want to try adding things like diffusing drapes and frosted glass rather than just big heavy metal doors.


So that's what I've been thinking about this week.

Tuesday, June 18, 2019

Space Survival Gameplay

I was asked a little while ago how I would do a space survival game, since I've been ragging on them recently. I also mentioned it in a video or two. So let's talk.

Let's get started simple. Let's say I'm a Star Citizen dev, out to put survival mechanics into my pew pew shooty game. I already have gorgeous starship interiors, now it's time to leverage them. How do I do it?

Well, my goal is to turn survival into a yarnball. A soft, complicated challenge that interlaces with a lot of other things. I also want to make sure that it unfolds into a narrative according to the choices the player makes.

So I implement a The Simslike survival system. Every time you make a space jump, your various meters go up. Hunger and filth, for example.

Actually using kitchens and showers is a repetitive and uninteresting task, so rather than requiring you to use the facilities, we simply reduce the meter if you have them. If you have a kitchenette, your hunger goes up 90% slower. A full kitchen? It doesn't go up at all... until your food runs out.

We do want to push the player to exist in that space, so we do allow the player to use a facility for a temporary boost - until the end of the next jump. If we use the kitchen, we get a +20%, but it uses up a bit of food. If we use the shower, we get a +10%, but it doesn't use up anything. This bonus doesn't reduce your meters, it simply enhances your performance. It doesn't stack.

To make this into a more narratively cohesive experience, we have to decide on the narrative we want. And the narrative we want is how the pressures of space travel shape our life aboard a ship.

This is not simply about "life aboard a ship". The point is to turn challenges - the challenges of a human surviving in space - into narrative beats. The ship is our tool to do that, but the challenge it parses is the challenge of survival.

If we want a gritty feel, we could get things like life support involved. But the ships in Star Citizen are ridiculously high tech, so instead we're thinking more about the social narrative. How does the mind fail, rather than the body.

So we add a few more meters. Loneliness, claustrophobia, boredom.

When they go up, you have to bring them down. Find someone to talk to. Land on a planet or space station and step outside. Have some fun by daredevil flying or fighting or driving a different vehicle.


A new player buying a new ship finds it comes with a little pocket gym. The gym reduces the meter growth of those three stats by 50% each, maybe.

But the player knows they are playing solo, and are planning to go on long explorations. So the big threat here is loneliness. The others can be dealt with in the middle of nowhere by visiting any random rock, but finding a person will be tough.

So the player rips out the gym, replaces it with a media console that constantly blares news shows and comedies. She puts portraits of her family on the wall, or pinups maybe. She buys a wisecracking robot companion.

These keep her company. And she can use them to boost: give the family a kiss, get +30%. Watch a TV show, get +40%, but use up a media slot - she'll need to buy the next season of Game of Space Thrones or trade SpaceYouTube caches with someone else to get those slots filled up with new stuff. Better to keep that cache intact, so it burns at the slower default rate and lasts longer.

And sure, she gets twitchy from the claustrophobia and the boredom. But that's why canyon racing was invented.


On the other hand, someone else might be playing on a team. They know loneliness won't be an issue, because there's another player around here. So they max out the others. They buy giant 3D landscapes for their walls - radically reducing claustrophobia, but actually increasing loneliness. They replace their gym with a video game console.

They can go for a long ways without having to land or play around, but they have to chat with someone every two jumps to stay happy.

No problem, they're sitting next to you.


We can see how the player's construction choices change the narrative. The player is choosing what narrative beats to include, which ones to play up or limit. One of those players is having a long, lonely journey hopping from planet to planet. The other is on a road trip with friends.

Those are very different narratives. We didn't write those narratives: we allow the challenges to be faced in a way that turns them into narratives.

We can push this in a lot of ways. For example, if we make it so that talking to a specific person works worse every time you do it, then those long journeys get more challenging because you have to find new people to talk to. If you burn media to keep your boredom under control, maybe you change one of those "size three hardpoints" from a gun to a giant subspace antenna that lets you transfer media from space stations a hundred light years away. Need food? There's a variety of greenhouses both internal and external...

These ramifications are polish on a core concept. If we didn't have the core progression, they'd be pointless. Most of this would be pointless if the player had to return to a station every time they logged off, for example: long journeys would be limited by a player's capacity to sit at their desk and play. But since you can log off in midjourney and come back, we can assume many players will go on very long journeys.

The question becomes: what of the players that don't?

What about the players that are short-haul? Players that specialize in fighting or shipping people or freight over shorter distances?

It's a common thing. A lot of players want to sit and do A Mission Now, and be done in half an hour. They don't want to log off midmission and come back to the same thing.

Can we make our survival systems create their narratives, too?

Well... no. It's not survival. But we can use the same core mechanics.


We could try to add stats like paperwork that go up as you dock... but what sort of narrative unfolds with that?

Not much of one. How can we make it messier and more entangled?

Well, most short-haul specialists will have specific hub stations - or, at least, specific preferred factions.

This is where it can't be Star Citizen, because their faction system has a ceiling. But if we throw that away, we can allow the player to build their contacts with the faction.

Rather than focusing entirely on the ship, we can allow the player-generated content to include people. Both NPC crewmembers aboard your ship and people you have agreements with on various space stations.

I would do it using a similar modular setup to the one used for ships and interiors:

As you rank up, you get a better "dossier" for that faction.

Like a ship, a dossier has specialties and hardpoints. This dossier specializes in freight permissions. This one improves insurance and rates on being a passenger liner. This one's exploration-based.

The hardpoints are people. This one's a tier 3 diplomat hard point, and you can slot in any NPC diplomat that rank or lower to act as your "weapon", giving you access to more options, more goods, more security, more sites. Reduce the rank by one just like you'd do for hardpoint turrets, and hire that person as a crewmember on your ship instead of being specific to their home space station...

Because the dossiers are essentially ships, we can offload our survival mechanics onto them.

As time passes and things happen, you might gain criminality, or disinterest, or distrust. These can be reduced if you equip the right kind of person on your hardpoints, but otherwise you'll have to do faction missions to clean them up.

And now, again, we've turned a challenge into a narrative.

Building small dossiers is easy, but you quickly learn you need to tweak it to suit your style. Do you do some... not so legal missions? You'll want a lawyer and a fence installed. Do you do a lot of business with other factions? You'll want a politician, to keep the distrust low. You go on long journeys? You'll want a reporter, to keep disinterest under control. You trade with a lot of different systems from that faction? Buy a one-rank-lower trader as a crewmember, so you get that advantage in every system.

These could even be tweaked per-faction. Both by the player, depending on their interactions with the faction... and by the devs.

Your Vulcan-ish faction might never gain disinterest, but gives bonus distrust if you sell science data to other factions. Your Klingon-ish faction loses interest extremely rapidly but never gives out criminality...

This has an extremely high ceiling. At upper levels, you might be adding the president of a space station to your dossier, or using a cross-contact politician to transfer stats to another faction's dossier.

And you can go negative. You're disliked by the Vulcan-ish faction? Add specific nemesis to your unhappy dossier. It's got a few good hard points - contacts from other factions or even turncoats from this faction - but you have to fill all your negative hardpoints first, adding in suspicious cops, angry politicians, and persistent bounty hunters.

Again: build your own narrative out of the challenge. *You choose* how your story of banditry or war unfolds.


Hopefully this has been a fun exploration of how to make player-created content that can turn simple things (survival, faction rank) into more robust, soft, complex mechanics that create a narrative.

To be clear: I think you could create an entire game around these concepts, rather than the shooty pew pew gameplay that I find so dreary.

There's also a lot to talk about in regards to things like resource tiering and keeping inflation under control, and it's tightly related. But... I think this is long enough.

Tuesday, June 11, 2019

Boiling the Yarnball

I've been thinking about why I like the construction games I like.

I'm including things like The Sims into this category. Whether you're constructing vehicles or facilities or people, there is one specific feel I like, and a bunch I don't.

I think it's yarnballs.

Big, soft, messy challenges that can be approached in a lot of different ways with a lot of different entanglements to the rest of the game.

For example, you're playing a space game. The rules are: you must have one point of life support per astronaut.

This is a small, hard constraint. There's no softness, no flexibility, no entanglement... no mess.

But in Oxygen Not Included, that rule is turned into a yarn ball thanks to the physics sim. I can create drafts of carbon dioxide, let rooms sort themselves into bands of gases and keep people in the oxygen zone, let them breath diseased oxygen, use pressure gates to optimize pressure for ideal algae conversion...

A combination of complex approaches (scrubbers, cleaners, algae, natural oxygen sources, etc) combined with complex topological possibilities (pressure, natural air sorting, air filtering, wind, etc) creates a lot of possibilities, a lot of bizarre, fun approaches that affect everything else in my facility.

It's not me balancing a spreadsheet. It's me building a facility, with all the complexity that entails.

One thing that makes this yarnball approach shine is how it ties into the rest of the construction, and how it turns a challenge into a narrative.

Challenge: you need to provide air.

Narrative: "the third and fourth floors of our Mars base are pressurized. Whenever we venture down to the first floor to change out the algae, we hold our breaths and work fast. Sandra got real sick when she couldn't hold her breath long enough."

The thing about yarnballs is that you do, eventually, sort them. Maybe not to some perfect standard, but you develop a method that works for you, and you'll usually stick with it.

That's why it's so important that the construction game is a huge pile of yarnballs.

If I sort one, there's another behind it.

More importantly, as I sort that one, I realize it's tied to the first one, and I didn't sort it well enough!

This creates an endless chain of narratives as I watch my facilities struggle with challenge after challenge, all their difficulties largely being my fault.

Another example of a yarnball is having children in The Sims.

Not only are the children themselves fairly complex, but caring for them is a convoluted, messy yarnball. You may think you have it solved, but then you realize your stay at home parent this time is a neat freak or something, and your timetable falls apart.

Or how about building a defensive entrance in Dwarf Fortress?

You have to deal with the threat of invaders, so you build a defensive gate. But how big is it? How do people get through it on their daily lives? How many resources can you afford to spend on it? What traps can you build? When you need to upgrade it, how will that work out?

And when the invasion happens, the gate helps turn the rather blunt narrative of "you lose, everyone dies" into a more nuanced narrative: "Bjornblatt lost an arm fighting off the goblins that got through the traps, and Hjornol is now responsible for rebuilding those traps into something more effective..."

I think yarnballs require a certain presentation to catch my attention.

I call it "boiling the yarnball".

This is a technique where nearly all of the game is incremental. In The Sims, your skills slowly go up, money slowly trickles in, you slowly do better at your job. In DF, you slowly farm, slowly build another bunkroom. It's all incremental.

Except then it's not. There's a challenge you're working towards.

In The Sims, is it time for a kid? Time to move? Time to get a promotion? Maybe just time to throw a big party?

In DF, is it time to build a defensive gate? Internal waterways? A magma forge? Maybe just time to rearrange who sleeps where?

What the player considers to be "a big thing" will vary depending on skill and interest. But you're usually working towards at least one big thing. You're playing the game to push the edge of what you can do, what you understand.

If the goblins trashed you last time, this time you're playing to build goblin defenses. If your sim died old and alone last time, this time you're playing to make a family. You build towards those challenges, and some part of your construction is difficult and challenging... because you haven't mastered that yarnball yet.

So the premise here is that the yarnball isn't thrown at you. It's something you walk up to. Something you explore.

The challenge that creates the yarnball might not be so gentle. The goblins will eventually attack. You will eventually get old and die. But you have some leeway before then.

Otherwise, there's not enough time to try and detangle the yarnball.

So I like to "boil the yarnball". You let the challenge that defines the yarnball simply sit there and simmer. When the player's ready, they can begin pulling at it... at which point, the narrative becomes more concrete.

To make it more concrete, I think there are four phases to this. I'm just getting started with my thoughts on this matter, but here's what I've come up with so far.

1) Planning
What challenge does the yarnball address? How will that challenge affect your facility? How will different levels of addressing it change that? How much space do you have to build in? How many resources do you have? How many workers can you divert, for how long, before things get risky?

Tie the planning into the overall flow of your facility, so it becomes part of the narrative: "in fall of 392, we began to defend ourselves. As harvest season ended, the farmers turned their hands to construction..."

2) Construction
Did you plan it right? What goes well? Poorly? What opportunities do you seize, or threats do you face that affect your construction efforts? Again, the construction is part of the narrative of the facility: "The great iron gates in the plan were changed to wood, at the request of the lord of the land, whose brother owns a lumberyard..."

There should be no real randomness in the mechanisms of construction. The randomness comes from outside: "oh, there's a gold seam where I wanted to put a wall. Oh, my workers are throwing tantrums because of the rain..."

3) Daily life
How does your construction affect things that aren't that challenge? The 'daily life'? What new opportunities does it create? What troubles? How does it integrate into your normal daily narrative?

For example, "The gate lay open, guarded by a single lookout. The lookout became very good friends with the hunters and lumberjacks, as they passed by nearly every day..."

4) Spotlight
How does your construction actually do its job? Specifically, how does it change a challenge into a narrative?

For example, "When goblins attacked, our lookout was slacking. Several got through the gate before it could be closed. Fjornblatt is fighting the intruders while, outside, torches are being lit..."

Each of these four phases of a yarnball helps to cement the narrative of the overall facility. The yarnball is positioned specifically to turn a challenge into a narrative, not just in the moment that the challenge arrives, but in an unbroken chain throughout the course of planning, construction, and daily life.

If you turn this idea towards other genres, you can see hints of it in other games. Coincidentally, those tend to be the games I like.

In an open world RPG? Building a character is several yarnballs. Watching the character face the challenges I intend them to face is great fun, as is watching that build struggle through challenges not related to their specialty. That's the part of an open world game I like.

Contrarily, without boiling yarnballs, even games in genres I like aren't very interesting to me.

For example, most "factory builders" where you assemble cars or medicines or whatever don't hold my interest. Either because the optimizations are all very cut and dry, or because the yarnball isn't presented in a way that helps me digest it.

How about you? Any of this fit into your idea of what's fun and what's not?

Friday, April 19, 2019


I love mods, and people are talking a lot about mods, so let's do more talking about mods.

A lot of people are annoyed that Unity and Unreal don't make modding easy... but modding has never been "easy".

Flash, CryEngine, IdTech, RPGMaker... none of them are "moddable" right from the ground up. Modding has always been something the devs decide to include.

With that in mind, we can talk about mods in two ways. From the perspective of the person installing the mod ("player"), and from the perspective of the person making the mod ("creator").


From the player's perspective, there are probably three kinds of mods:

1) Piecemeal Content
This is content that will almost never conflict with other piecemeal content, except in the most trivial ways. Piecemeal content is probably the most popular kind of mod, including things like recruiting other players' characters, sharing messages about sun-praising, downloading vehicles from the workshop, adding new skins, etc.

2) Local Content
This is content which will conflict with any other content in the same locale. For example, if you install a mod to turn you into Bayonetta and a mod to turn you into Link, they won't get along. Similarly, you can't be in two levels at once, two missions at once, etc.

Local content can be turned into piecemeal content if you add a tool to help the player manage this kind of conflict - for example, Bayonetta and Link can both be "skin options" instead of simply overriding your appearance.

3) Core/Process
Some mods change fundamental rules of the game. For example, Skyrim mods that make character progression different, or change how weather works, or make you need to eat and sleep, or make the shaders work better.

Sometimes the mods are completely invisible, such as mods which allow other mods to work, or mods that clean up memory usage.

Frequently, core/process mods are part of a chain of required mods, like 'install the event mod, then the silent talking mod, then the progression revamped mod, and only then you can install the custom skill pack'.


The reason to think of mods like this is simple: it helps us to think about how mods work within our game. Can our game support piecemeal content additions? If the gameplay allows for certain kinds of piecemeal content, what is required to surface that and allow the players to load it in? If the game can support local content, can we change the way our game presents it to turn that into piecemeal content?

Can our gameplay support core/process mods? Can our game architecture? Can we revamp it? Can we create a tagging system so that we can have mods say what other mods they require, at what version?

The answer is rarely a flat yes. This kind of thing is a bit difficult to engineer, and it may damage your core gameplay. But even a small amount of moddability is a good thing, and you can leverage it to either make your game more appealing or make your game stickier.

For example, in Guacamelee, the only kind of moddable content is custom skins. However, they sent out custom skins to popular YouTubers, enticing them to play the game and be more positive about the experience. The modding made for great outreach.


The other half of the equation is how the creator of the mod thinks about the mod. This is equally important.

1) Diegetic assembly
When the creator never leaves the game to create the content. In the best case, the content is created simply by playing the game, but nearly all of the time this is an in-game editor. For example, you create your character, build your ship, assemble your house - all using an in-game editor.

The key here is that diegetic assembly happens in the course of normal play. A character builder counts because every player will use it at least once and consider it part of their playthrough, their experience. A mission editor generally doesn't count, because it's never used in the course of playing the game.

There is a challenge to keep the editor simple enough for everyone to use but powerful enough to let players create complex or nuanced results. There is also a challenge to leverage the editor: a character editor for a game where you only create one character is not as well-leveraged as a game where you create multiple characters over the course of the game.

Compare The Sims' character editing to Fallout 4's.

2) Tool-assisted assembly
The creator uses a separate tool to assemble the content. This tool may be in-game, such as a mission editor. It may be out-of-game, such as photoshop or visual studio or even just notepad. Either way, this is a thing the player has to go and do, separate from playing the game.

This is quite a hurdle. Few players will go and use a tool that is not required over the course of play. Because of this, it's usually ideal if you can leverage a tool in both the main gameplay and as an asset creator. Normally this is done by using the same tool, but having a creative mode where the player's specific play constraints are relaxed.

Done well enough, this turns into diegetic assembly.

Core/process mods are a good example of mods that are almost always created with tool assists. It is exceedingly rare for a game to allow its own rules and progressions to be overwritten in the course of play. Normally these mods are created with visual studio or notepad, the code then injected back into the game.

3) Hacked assembly
If the creator has no way to add their mod to the game, they may hack the game to force it to accept the new content.

You might consider this similar to a tool-assisted mod at first glance, but a tool-assisted assembly uses an injection method the developers intended for modders. That text you edited, that DLL you compiled, the game goes out to look in that directory for those things because the dev decided to support those kinds of mods in that way.

Hacked mods usually take advantage of things the dev accidentally left available instead of intended for mods. For example, they might be "trainers", hacking the game's memory space to give you infinite health or cash. Or they might overwrite the game's core assets with new assets.

As a game dev, hacked assembly is something to avoid. Mods assembled via hacking almost always conflict with other mods just due to how they work, so it's best to try and create a proper interface for mod injection.


When I think about mods, that is how I think.

What kinds of content can be injected? What kinds of tools can I use to make that injection easier, more useful, more potent?

What methods of creating content are there? What kinds of interfaces can I create to help modders create mod packs and chains of mods that don't conflict?

Unfortunately, no game engine natively supports this kind of thinking, because it's part of every individual game's unique design. There's not really any low-hanging fruit here: you have to design your game to be modded.

Wednesday, February 20, 2019

Adaptive Modules in Construction Games

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

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

Non-adaptive modules.

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

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

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

1) Folding modules.

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

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

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

2) Expensive timing elements.

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

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

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

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

3) Incompatibilities.

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

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

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

4) Service requirements.

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

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

5) Stacked modules.

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

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

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

6) Careful design of multipurpose baseline elements.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Monday, September 10, 2018

Character-Driven Game Design

Well, another day, another trailer.

These days, a lot of video game teasers and trailers are animated shorts with no relation to the gameplay. Today, League of Legends posted a teaser about an energetic, funny space ship crew and asked you to join up.

Of course, it's not an energetic, funny space ship crew game. It's League of Legends, meaning it's a MOBA - a plodding arena combat genre known mostly for toxic team play. In short, not energetic, not funny, not character-driven.

This is not a one-off. Virtually every major action game has been releasing character-driven shorts of extremely high quality and pretending it has something to do with the game in question.

It reminds me of the old days, when the cover art sold the video game. Except, of course, the cover art would be some Vallejo painting and the game would be eight pixel high sprites jumping from platform to platform.

Given the response I and many others have to these teasers, it's clear there is an interest in high-energy, cinematic, character-driven experiences.

But no games like that ever seem to come out.

Let's talk about it!

Hangin' Out, Havin' Ourselves a Parrrrtaaay

There are games with strong characters. For example, Telltale-style adventures. However, you can't really "hang out" in those games. The narratives are character-driven, but the games are narrative-driven. This is a bad fit for me: I care a whole lot about the characters I'm hanging out with, and the distraction of being told to uncover some ancient secret while fighting off invading ninjas just weakens the experience.

There are games where you can hang out. For example, open world RPGs. However, while you can hang out in the world, you can't really hang out with the characters. They're programmed to only really respond to specific world events. Worse, semi-open RPGs like FFXV or Dragon Age often ruin the hangingoutness with dull filler and melodrama in equal measure.

But I mod games. A lot.

A modded party member has the disadvantage of not being in the core event structure. They aren't introduced in some blazing cinematic, and they don't have loyalty quests.

This means that the modded party member has to make their presence known during normal play.

A lot of modded party members tell stories, crack jokes, sing songs, and randomly comment on anything and everything the game has to offer. This ends up making them feel more real than the core party members, at least if you're the kind of player that randomly wanders the world and never bothers progressing the plot.

We script characters to respond to world events. When we have control over the world events, we script them to perfectly match the specific events we've created... but that's a flaw. We need to get out of that habit if we want to let the player hang out with them. Because hanging out isn't specific.

There are lots of games with "specific hangouts". For example, chatting at the camp fire in Dragon Age, or private actions in Star Ocean. But these are tightly scripted events that are a facsimile of hanging out rather than actual hanging out. They're expensive to make and limited to play, and I think we can do better.

Structural Issues

We think about hanging out as being unstructured, but the truth is that it is very structured.

In order to interact with a character, you need a medium of interaction. A task, basically. Most tasks have a set of progressions that can be used to move the hangout along a fun path.

For example, if you're drinking in the bar with a fictional friend, what happens? Maybe they get drunk. Maybe you get drunk. Maybe they start a bar fight. Maybe someone at the bar recognizes them, and then something unfolds. Maybe they get hungry for real food and you change locations. Maybe someone else you know walks through the door and the dynamic changes. Maybe you look for dates.

Alternately, if you're playing video games, there's a lot of flexibility as to what game you play, whether you switch games, who tries hard or not, who wins or not, whether you start betting, whether people start getting way too into it, etc.

These progressions are at the heart of "hanging out", and they are also at the heart of how a character can express themselves.

Each character in the game can prefer different progressions. They don't need to be completely unique: a lot of characters can get drunk at the bar. But if the progressions go on for several elements, you'll see their uniqueness start to manifest: person A gets drunk and starts a fight, person B gets drunk and hits on everyone, etc. These are small, simple things to talk about, but this is the heart of how hanging out has to be approached: there's a task, and different characters want to progress or change the task depending on their personality, mood, etc.

This spectrum of progressions allows the characters to contextualize the event as they see fit, and to recontextualize a generic event ("at the bar") with a specific in-character event ("picking up guys" or "getting shit-faced") based on what progression they want to see.

Adapting to Existing Games

For example, in Skyrim you might be wandering the world map with Lydia, your dull, dutybound housecarl.

Skyrim has progressions built into its systems and maps. If you're wandering outside picking flowers, you'll run into options to fight monsters, go into dungeons, see wonders, change biomes, get rained on, go from day to night, find an ore resource, find a town... these are all perfectly valid progressions.

By understanding what progression Lydia wants to see while on the world map, she can make comments about what's going on. For example, if she sees a bear, she might say "that bear might threaten travelers, maybe we should drive it away."

This would be different if she saw a monster in a dungeon, where it's not a threat to a city. She might say "some skeletons ahead, I wonder if we can get around them." Or, if she sees a monster in a town, she might flat-out rush to attack, to protect the people of the city.

By allowing her to decide what the current context is, she can choose what progressions she'd like to see. This gives her dialog a lot more vitality than simply yelling "yahhh!" and charging at any monster you find.

However, this is still very shallow. Since Lydia has only dialog and the player has only action, it's a lopsided mess where it's difficult for the situation to progress in any meaningful way. In the end, it boils down to Lydia making comments on what the player chooses to do, just like in later games such as Dragon Age.

The simple fact of the matter is that hanging out is collaborative. Lydia can't really collaborate with the player in the gameplay as it exists.

Stop, Collaborate and Listen

One thing we can do to make this more collaborative is to let the player give dialog responses. However, I don't think that's a good approach, as it will lead to very repetitive interactions as you hang out over and over.

Instead, I would prefer to do the opposite: let the NPC offer action plans.

When Lydia says "that bear might threaten travelers..." two action plans might pop up and be selectable. "Take it out, I'll support you" and "let's ambush it, follow my lead" might be the two options (with the third 'ignore' option implicit). These are represented as dialog, but they're not simply dialog: they're functional plans. Not only do they determine Lydia's behavior, they can also embed bonuses: Lydia gets an attack boost if you tell her to take it out, and a stealth boost if you say you'll ambush it.

Moreover, these plans are excellent at advancing several progressions at once. Not only is Lydia advancing from "outdoors" to "defending the roadways", but she's also advancing along her "Lydia, stealthy supporter" or "Lydia, front line knight" character progressions. She may also progress on her personal opinion of you if you do particularly well or poorly, although remember that all such progressions are temporary. You'll hang out again some other time, and things will unfold differently.

These action plans can offer things the player literally can't do without the NPC, as well. For example, Lydia might say "oh, this is such a rich iron vein. Let's claim it for the city!" at which point you'll have the plan to claim it for the city: something you cannot do on your own, or with another character. Other housecarls might also be able to do it... but for other cities.

This combination of factors will hopefully make the player want to participate in these collaborative plans.

Save and Load Contexts

One technique that can help us add depth to the characters is to allow contexts to be shelved and readopted as necessary.

Our instinct might be that Lydia following us around is Lydia hanging out with us, and the whole day is one "hangout session". But that leads to problems, because the context might not progress at all. The player might literally gather plants for three hours straight, and Lydia's constant talk about what she'd like to do will get repetitive and futile.

Instead, she can simply shelve an intended progression when it falls through.

So if Lydia says "that bear might threaten travelers..." and the player doesn't engage, Lydia won't follow that up with "that skeleton might threaten travelers" and "that treant might threaten travelers". Instead, that progression is on hold.

However, if the player does engage an enemy on the world map - pretty much any enemy - Lydia will be able to instantly pick up the progression. "You'll never threaten another traveler!" she barks as you smash down a mudcrab or whatever. From there, she's in her "cleaning up the wilderness" context, which can be built any way the devs want. Maybe one progression is to attack stronger monsters. Another, less preferred branch is to attack weaker monsters. Monsters in another biome. Monsters marked as 'evil'.

This context is active, so Lydia won't say "that bear might threaten travelers..." because she's not in that context any more. Instead, she might see a bear and say "let's clean up this forest a bit!" in an attempt to progress along the biome path of her "cleaning up the wilderness" context.

Of course, once the hangout period ends (spending a certain amount of time in another major context, like in a city or a dungeon), the contexts can reset and she can start over.

This isn't an ideal solution, but it effectively allows you to script character events that unfold naturally and opportunistically as the player plays, rather than being segregated into their own quest lines.

Parties, not Companions

Probably the easiest way around the collaboration difficulties is to have more than one companion. If there are several NPCs, they can discuss and banter. This is something Dragon Age does well, but primarily by using random snippets.

We can choose to anchor the banter to contextualized progressions, instead. As an example, if you're wandering Fallout 4 accompanied by both Piper (reporter) and Curie (science robot), they'll both contextualize the wandering and have directions they want it to go. You get a sense of this in Fallout 4 as it stands: they have a variety of generic comments on situations you might encounter.

But by allowing them to comment to each other, you can build up a sense of progression even if the player ignores their preferences.

For example, if you find a few talkative ghouls, Piper might say "hey, we should get their story!"

If the player chooses not to do that and walks away, rather than something like "PIPER -2 FRIENDSHIP", Curie can disarm the situation with an excuse like "We cannot be distracted by such tings, we have important tings to do!"

Of course, the player avatar could theoretically also say that kind of dialog, but the player might not be thinking the same thing. The player might be thinking "sure, give me a second to raid this treasure chest first", which is very different from the dialog claiming it's something that won't happen.

If a third party says the dialog, being wrong is acceptable and can give rise to more complex lines of progression.

For example, if you do go back and talk to them, it's relatively easy to have remembered the original dialog, and now have different dialog. This can be quite generic. For example, as you approach, Curie might say "I remember zees people", then Piper can say "Now do we have time?" Or, if you're now just adventuring with Piper, she might say "hah, now that Curie's not around, we can do some snooping and scooping!" These are fairly generic dialog lines that can be deployed in a lot of different situations.

If we consider hanging out to be a task with a variety of progressions, then we can again run multiple contexts at the same time. We're progressing this specific subquest. We're progressing Piper's "search the wasteland for news" context, which may lead to her wanting to go home and write about it. We're progressing Piper and Curie's relationship with each other - again, it must be stressed that it's a hangout context, not a permanent progression. We're progressing Curie's "focus on the science" context.

By having many contexts which can be progressed, shelved, and activated at the same time, we can make the experience as character-cohesive as possible. From the player's perspective, it doesn't matter which context gets progressed next: they all have Piper acting like Piper or Curie acting like Curie, and for reasons that make sense.

It will require a bit of effort to create the engine to do this, though. You'll need to figure out the right generic dialog to switch or resurrect contexts, just for starters. It's not something I've seen done before.

New Hangouts

This is all about adapting the concept to existing games, but the truth is that we don't need to do that. We can make new games.

If they're intended to allow for this kind of thing right from the start, there's no struggle to make sure all the metadata you need exists or all the conversations have to work within some specific fiction: it's all designed from the ground up to work.

Moreover, it allows us to radically reduce the amount of content and gameplay we need to support, because this context-centric approach can use much smaller amounts of gameplay to accomplish the same thing. Rather than gameplay strongly relating us to the world, the gameplay is more about collaborating with a friend.

For example, you could decide to hang out with someone and spend the afternoon assembling ships in bottles. It's basically a minigame, but it's made much more interesting because there's a character-driven progression in play. The actions you take affect what the other people do, and what they want to have happen. Doing well at the minigame may be a bad idea... or, rather, doing well at the minigame may not involve actually building the ship in a bottle.

Hanging out and making ships in a bottle is not just about the progression of the task of ships in a bottle.

We've already talked about longer-term contexts like "Lydia's stealthy follower progression". Well, the whole point now is that the event progression is more about the personal contexts and progressions that our friends are going through. Rather than having one preferred contextual progression, the progression they want from this event is influenced by the progressions they want from their other, personal contexts.

You've going to have very different "ship in a bottle" minigames depending on whether your friend is drunk, angry at her parents, mourning the loss of a friend, nervous about a piloting test, or embarrassed that you found out she likes a terrible TV show. The progression of the minigame is not the point: the point is the progression of her personal contexts, as expressed through the progression of the minigame. Hell, she might even play the minigame without the player's input at all - the player can just watch.

We can spread this idea even further, into the world's overall state. Her personal context affects how well she can fly the ship, or how aggressively she fights. Whether or not there's actual gameplay involved with those or if it's just some flavor dialog, it will convince the player that there's a world and stuff happening.

One possible example leading towards this would be Dragon Age 3, just the parts where you decide who to send where, and for what purpose. You could hang out with someone, and then when you send them on a mission, they get better or worse results depending on how they feel. Their personal context will then be altered by the mission they just went on, so it's a good time to hang out with them again...

Anyway, those are some of my thoughts.

What do you think?