Monday, July 20, 2015

Life in a Game

So, after Space Engineer's recent disastrous update, I switched back to Rimworld for a while.

Rimworld is coming along nicely. You can build complex bases, set up your citizens in complex ways. There's a lot of fun to be had, especially when you start laying on the mods. But there is a big weakness. I can't blame it on Rimworld: it's a weakness in all base-building games.

The problem with these games is that nobody lives in your bases.

OK, I know there's, like, 30 people living in the base according to the game. They wander around, have their little tasks. In Rimworld they even goof off or chat. Still, none of them actually feel alive. They don't form relationships. They don't have hobbies. They don't do things with each other, have friends, have enemies. They don't have lifestyles or emotions, at least none that are differentiated in any significant way from anyone else. They have a lot of stats, but who cares?

As the number of people in your team goes up, their individual stats matter less and less. Instead, how they contribute to the operation of the team is what matters. It doesn't matter whether person A is marginally better or worse at farming, it matters whether they can play the farming role, and whether they should be a focused farmer or someone who helps farm when the workload gets rough but has other jobs the rest of the time.

What's the alternative?

There's a reason the Sims was popular: it allowed players to feel like their little avatars were living a life. The tools used to do this were simple: a familiar scenario (working and cohabitating) with clearly defined roles, lifestyles, relationships, optional goals (having kids, ranking up, collecting meteors, etc), attention retention (everyone needs to be clicked on sometimes), and personality proxies (appearance, clothing sets, certain personality traits).

Let's talk about each of the techniques individually, and then let's talk about how to shape your game to allow for them.

Personality proxies are the most problematic, because they bring in the most from outside the game world. We'll have to talk about them in detail later, but the short version is that you have to be able to tell who is who. If you have more than four team members, having slightly different names and icons isn't going to cut it: you need a dense representation of who is who, along as many axes as possible. Not just physical appearance, but voice, animations, fashion, mannerisms, personal possessions, and room decoration.

Lifestyles are technically a personality proxie, but it's worth mentioning them as a distinct group because these interact with the world, or at least the timing of things. Lifestyles are specific habits, inhibitions, and judgments not shared by the rest of the group - for example, one person might obsessively collect statues, one person might be the only person on base that smokes weed, one person might only work at night, one person might dress in finery get offended if someone else looks shlubby.

Lifestyles are powerful because they are behavioral elements. However, these should not be chosen willy-nilly. When we talk about how to do personality proxies, we'll be bringing these up again.

Evocative scenario: A familiar scenario is a way to allow the player to hook into the game world. Almost everyone has struggled to work a day job, had roomies, eaten pizza, invited people over, etc. This familiar setting can have any characters inserted into it, since living with Spock and Captain Kirk in a tiny apartment is hilarious.

But, again, this brings in a lot from outside: "familiar" scenario assumes it is familiar. Similarly, while it allows the player to import characters they already have an attachment to, it isn't very good at differentiating random characters. Everyone has to live, eat, participate in daily life. You can put Spock into an apartment, but someone as interesting and evocative as Spock cannot arise from an apartment. There's no room for his characterization.

Because of that, if we're focusing on random characters, we need the exact opposite. Rather than a familiar scenario, we need an evocative, unfamiliar scenario that will allow characters to establish and continually re-establish a strong personality.

Clearly defined roles are important to allow people to distinguish themselves at the most fundamental level. The wider the disparity of roles, the wider the variation between the characters. In The Sims, you have the breadwinner, the housemaker, the children, the skeezy roomie, and so on. You also have all the details you drag in from your expectations: the annoying roomie, the tidy roomie, the control-freak roomie. It's two axes of roles: one aligned with the core gameplay (time/money), one aligned with personal interactions with shared resources.

If we're generating characters randomly, we need to have roles that offer us powerful differentiation. We slot the character into a role and suddenly they come alive. The green thumb luddite is facility manager? We suddenly have an explosion of expectations about how the facility will function and how they will interact with other characters even if none of that actually happens in the game.

The difficulty is getting a breadth of roles. You can't simply use social status, because a simple numeric rank isn't evocative enough. Instead, think of each role as "which core task do they do, when?"

In The Sims, you don't really have "breadwinner A, B, and C", you have one person that wastes their life working in an office, another one that does arts from home, and maybe a third that works part-time at night but still keeps their days largely free. These roles each interact with the core scenario in a different way, at a different place and time. In addition, the people that don't work aren't simply "not working". Each has a role within the function of the house and life in general. One is a child, one is raising children, one is studying for college, one is a housekeeper, one is a social climber, etc, etc.

It's not that the breadwinner has a higher social rank. It's that everyone has their own approach to some set of core tasks.

If we can somehow break the core tasks into two completely distinct groups, it gives everyone two roles, which is even better.

Optional goals are a powerful tool to pull the player into the game world. These are things which take quite a while to accomplish in full, but have numerous small steps you can take along the way. By choosing to dedicate characters to these goals, the player can set up their own story arc and create numerous opportunities for the other characters to get involved peripherally.

The Sims is full of these. You're always working towards something. Whether it's ranking up your day job, improving your skills, or raising your kid, there's always a task you've chosen to do and it's working towards a long-term goal you've chosen to aim for.

Optional goals are incredibly important for distinguishing randomized characters, because they give the characters a Want. When a character wants something, they come alive. In a randomly-generated team, every character having a Want would get confusing and muddled, which is why I think it's best to allow the player to assign these wants by aiming for specific end goals. Even if the character doesn't understand that they are aiming for a specific end goal, they will continue to perform the step-by-step actions towards that goal at the player's command, and therefore act as if they do understand and are aiming for the end goal.

Relationships are also valuable, but, again, they should be used to help the player differentiate the characters. Rather than randomly forming relationships, it is generally better to allow the player to choose which characters get along in which ways, because the player is forming a personal memory of these characters and relating them on purpose.

Not all relationships are simple vanilla romances. Ideally, a flexible relationship engine will allow the player to create the range of complex human relationships. The game doesn't have to understand exactly what a "rival" is or exactly how a "love triangle" works, but it should allow the player to drive these defined relationships around while creating a pretty reliable framework to hang them on.

A fun option is to create optional complications in exchange for some kind of bonus. Rather than forcing person A to fall in love with person B, you can give the player the option of allowing it in exchange for a level boost to those characters. Let the player choose whether to let that interfere with their carefully-laid plans or not.

Attention Retention is a trick used to keep characters in the player's memory. Once you have more than about four characters, some of them will necessarily become background characters. To prevent them from fading out of the player's mind and become cogs in the game's machinery, you need to draw the player's attention back to them once in a while.

There are a lot of ways to do this, but my favorite is to add a "token" to each player every time period. When a player activates a character for some kind of social interaction, the tokens can be used to level up. Therefore, background characters will sometimes jump into the foreground and level up dramatically, which is a fun way to do it.


Now. Let's talk about the first and most important way to make generated characters interesting: personality proxies and lifestyles.

This needs special attention for a lot of reasons, but let's start with the basics.

When we build a character in a game with defined characters, we design the characters to reflect their personalities. Every aspect of their appearance, voice, mannerisms, fashion, animations, possessions, and even room decorations reflect their personality.

However, random characters do not usually have that setup. That's because if you try it, you'll end up with incredibly offensive and limited stereotypes. Instead, most devs use personality traits that aren't related to your physical appearance or fashion choices. It's less limited, but it's also much harder to distinguish your characters. Moreover, the "colorblind" approach is not a whole lot better, as it assumes the universal culture is your own.

The thing to consider is that most games with defined characters have those characters resonate with their life situation. That is, they are who they are because of their own culture. For example, Tali is a really bad stereotype, but she constantly interacts with and resonates with her situation. You are asked to understand why she is who she is, rather than just treating her as a given. Even the blue bisexuals that want to bang you have a lot of culture and society and general baggage that tries to make them more interesting than their stereotype.

Most of the time, rather than having each species stand in for a kind of human, we've started to have each species stand in for a kind of lifestyle or situation. It would have been easy to make the Krogan a literal stand-in for native Americans, and the Qunari as stand-ins for Russians. Instead, they went the other way and carefully made them not stand-ins. Mostly.

It's not a flawless approach, but it's generally pretty good. The idea is to create artificial situations, artificial cultures and societies. Each one represents some core concern in your universe's fiction.

An easy example is Dragon Age, which chose to make its elves a destitute amalgam of every oppressed minority they could think up. The elves don't represent a specific human culture, but they do resonate with the idea of oppression. Dragon Age has a lot to say about oppression and the nature of power, so having a tentpole species represent one corner of that idea was a pretty good idea. We can argue about how it fell short, but it is fundamentally a pretty good idea.

Rimworld doesn't have any deep fiction to it, but the game mechanics suggest specific human concerns. People within a few hundred miles of each other can have radically different technologies and resource levels, meaning that disparity is tremendous. You have the technology to build a fully self-sufficient base in just a few months, except for the waves of attackers that come to steal your things. So disparity is tremendous and violence is common. Life is cheap, technology is cheap, everything is cheap.

It would be relatively easy to come up with cultures that anchor these concepts. Your crew could easily come from those cultures, which would allow them to have a lot of baseline opinions and an easy-to-understand personality. Moreover, you could have each culture be visually distinct.

Not as in "these guys are brown, those guys are pink". Differentiation should be chosen more carefully. If everyone is human, differentiate mostly on things any human could choose to do: fashion, accent, behavior, tattoos, hair dye/cut, equipment, room clutter, etc. The idea is to give the player strong audiovisual clues as to the situation and personality of the characters without implying anything horrible on accident.

Rimworld would have a particularly difficult time of it, though, because the characters are so tiny and indistinct. I would probably add larger portraits to help with that, but another option is to allow the characters to alter their surroundings. For example, a character might have a dominant color scheme, and everything they own (including the things they wear) is automatically recolored to it. They might leave specific kinds of clutter in the places they hang out. They could even have flavored footsteps - different timbre to represent how they move. There are a lot of ways to make the characters more distinct, and you should try them all.

Of course, not all of them should be about distinguishing which fake culture the person is from. A lot of them should be related to that person's personality, instead.

Now, about lifestyles.

Lifestyles are an extension of this idea, but are active. They are habits, inhibitions, and judgments. These allow a character to interact with other characters and with the operation of the group in general.

Personality proxies as discussed above are largely passive, and are intended mostly to help players remember who is who. But lifestyles push. This is when the characters start to come alive a bit: by interacting with things and people in specific ways, you can get a resonance.

Someone's personality is largely defined by how it resonates with their situation. A lot of that will happen in the player's head or in the lore of the universe - "people from faction A have been oppressed for centuries by-" done, we know the basis for their behavior. But sometimes we want to see that resonance come into existence in the game world proper.

This is extra powerful in a base-building game, because you can arrange the base to cause different kinds of situations depending on the lifestyles of the people within it. If someone insists on always wearing the best finery, a dusty, overheated base will be a nightmare for them.

The critical thing about lifestyles to remember is that it is for the player's benefit, not the characters'. Every lifestyle exists to resonate with something else the player controls, whether it's another character or the base itself. Because of that, lifestyles should only resonate with what the character can control, and they should resonate on-camera.

For example, in Rimworld there is a trait that makes a character annoying, and anyone that talks with them gets annoyed. However, there is really no way for the player to control who socializes with who, so it takes a lot of effort to mitigate that lifestyle. If there were more tools for controlling socialization, it would be a more interesting trait.

Ideally, each lifestyle should interact with something the player can control. The more nuanced and constructive that control is, the better. A dusty, hot base can be mitigated with air conditioning, filters, and a dedicated janitor, so it's a pretty good trait... if you allow the player to do those things. But each of those things comes with another side effect, and that's the heart of this.

You ask the player to consider the characters, to work the characters into their core concerns. To choose how far to go for each character. It's a promising approach.

Anyway, those are my thoughts.

Tuesday, July 14, 2015

Characterization in Games

There's some talk about Mass Effect 4.

I remember really liking the first three, although they got worse with each release. I remember liking the characters and the feel of the universe, although it had some transparent flaws that got more glaring with each iteration. The big draw was the characters.

But now, looking back, I don't remember the characters much. I mean, I remember them - Tali and Wrex and Liara and so on - but I don't have any fond memories of them. The only characters I remember well are Chakwas and Garrus.

Why them?

Because they hung out with me.

Hell, I remember the nameless meat-head marine in the last game better than most of the characters I actually liked, because his first major scene was him hanging out with me. Sure, he was annoying, but we interacted socially.

Game designers are typically worried about bang for the buck, so the scenes they write are usually A) exposition, B) entertainment, and/or C) rewards. For example, Mordin was written for "entertaining" exposition, and even had a few purely entertainment scenes, such as his famous song. On the other hand, Liara is basically the same character written for "rewarding" exposition - she's nice to look at for the target audience, has an attractive voice, wants to date you instantly, and spouts exposition.

All of these options are aimed at the "unnamed player" - the person pushing through the game. Although in theory Liara and Mordin are interacting in-world with Commander Shepard, they're really aiming at the person holding the controller. You can clearly see that by how your responses are framed: Shepard doesn't have any strong or nuanced reactions, just a basic binary response you select from the generic menu. The scenes are aimed at the "unnamed player", not at Shepard, your version of Shepard, or you playing Shepard.

Easy way to tell? Shephard never laughs, grunts, or sighs until you say she should.

By removing Shepard from the equation, it's easy to make generic, highly acceptable events. Shepard has no nuanced response because that maximizes acceptability: if a player finds Mordin's canned, West-Wingish dialog annoying, or hates blue space babes, that's okay. Shepard can hate them, too, just select it from the drop-down list.

That said, it's no mistake that the most memorable scenes in the game don't ask you to judge anything at all. When you're shooting with Garrus, it never asks for your opinion on Garrus or on shooting or whatever. It just asks you whether you want to hit or miss. Shepard is allowed to react as Garrus' friend, and they get some very pleasant and rewarding patter going without the "unnamed player" ever stepping in to pass judgment.

That's why the scene is so powerful: it builds up an easy, rolling pace. The characters are in the right world, behaving as they really would, and it doesn't interrupt itself to ask the player what they think. At this point, if you aren't friends with Garrus, you can screw off.

It worked.

I don't know if that scene is the thing everyone remembers most from ME3. But after time has passed, it is the first thing I remember about all three games. And I replayed ME1 after ME3.

The Chakwas scene is similar. You aren't asked to judge whether you like Chakwas or not, or what you think of her talking about the old days. Instead, it's allowed to unfold gently, organically, from the two characters. The player is not involved, but because the scene is honest, they'll remember it for a long time. I can't even remember which game the scene was in, but I remember the scene.


Stop making generic protagonists. Stop asking the player what they think.

Let the player choose by doing. If the player keeps approaching Garrus, assume they like him. Give the player choice by giving them physical choice: hit or miss. Drink or leave. Hug or pat. Then let the scenes work out based on the characters. People will remember it longer, I think.

Tuesday, June 30, 2015

Medieval Misstep

A while back I tried to write about Medieval Engineers, and I don't think I quite managed it. I put it off for later.

Well, there is no later, they just ruined it. So let's talk about what was.

Medieval Engineers had no inventory system.

A construction game with no inventory system!

It felt like a good match. The medieval setting combines well with every component having a physical presence. The weight of all the stone and lumber exists in the real world, and it felt real, it felt right. Building a house requires a houseload of lumber!

You would have to hew the lumber, then put it in a cart, then drag the cart - perhaps along a road. Then unload the lumber. It was a chore, but one that felt real, and could probably have been mitigated using NPC workers (which already exist).

Moreover, staging the construction became a major, interesting challenge. Those logs and stones have to be within a few meters of the thing you're building. So if you're building a five-story-high stone wall, you need to create a scaffold, haul the stones up, and put them near the next floor.

It really felt like medieval engineering. It was a hint of a powerful idea that could have been absolutely unique.

Well, I don't know if people complained or what, but they removed that idea. Now you have an inventory.

Even at its smallest, in the demo, it shows you being able to carry around 20 sledgehammers. So, yeah, stuff your pockets full of boulders and logs, who needs staging? Who needs carts? Who needs cranes or roads or quarries?


In any engineering game, the question is: what are you engineering around? What challenges are you trying to solve?

For two weeks, Medieval Engineers had a new challenge. One I've never seen before. You were trying to engineer around your own engineering. It was a wonderful seed of an idea, and it felt so promising, matched the setting so well.

But it is important to be generic. If you're unique, some players might complain that you're not exactly like the last game they played, and you wouldn't want that. It's got to be exactly the same, down to the exact flat-slot inventory model.

Monday, June 29, 2015

Abusing the Pipeline

One of the things I've done a lot of work on is allowing player content - whether through mods or in-game creation tools. More and more, I've come to think that in-game creation tools are not an efficient way to do it. I mean, if you can manage it, sure, but there are a lot of reasons to avoid in-game creation tools.

First, they are effectively duplicating tools. If you use Unity or Unreal, those come with powerful content and scene editors. Creating an in-game editor literally duplicates that functionality. It's far more efficient to allow players to create their content in Unity or Unreal, and then distribute those packages. Giving your players a subset of the game that they can open in Unity or Unreal is a powerful idea.

You have to adjust your pipeline, teach modders to pipe output to an import-friendly asset pack. Unity makes that pretty easy. Not sure about Unreal. But compared to recreating the entire editor and save system, creating a runtime compiler, bugtesting... well, it's much easier to teach a modder to create asset packs than all that!

But that got me to thinking. Once you think about using Unity or Unreal as a mod creation platform, you start thinking about the asset pipeline into them. And out from them.

There's a lot of potential here, I'm just starting to wrap my head around it. Let's start with the basic act of creation.

We're creating star ships. We create them in the Unity editor. As a player, we use the Unity editor. We find the various prefab starship components we want - engines, generators, chairs, beds, landing gear. We put them in the scene, tie them together as a new prefab, maybe rig the system to point to itself in various ways so that, for example, the turrets can't turn on if the landing gear is down.

Export the resulting prefab (or pack of prefabs, maybe you built a fleet) into an asset pack. Share the asset pack with whomever you like, and suddenly it's in our game, Space Ranger Example Game 2000. Your ship is in the game, performing quite well. The turrets only turn on when the landing gear is up, the engines draw power from the reactors and push the ship around, it's all great.

This allows players to build starships without a grid. They use Unity's powerful tools (including optional grid-snap or vert-snap) to lay their ship out with incredible freedom. Collision boxes are automatically computed.

This allows players to build custom variants. New materials. Different animations. Just swap that stuff out and the custom variants will get included in your asset pack, free from any chance of collision with other animations and materials from other star ships.

It also allows players to build custom code or UI, easily packing it into the asset pack. If you want to use AntiSpaceRanger's Cool-Ass-Holographic-Ship-UI, just throw it in and it'll be included into the prefab, whether or not the next player down the line downloaded ASR's CAHS-UI on their own. Create your own UI, if you like.

But... this is not the limit. Not even vaguely.

See, since you're using Unity or Unreal, you can import new assets. A new Blender file. New sounds. New video clips. New textures. Let's focus on Blender.

Your starship can be any shape using the prefab starship components. You can scale them, tilt them, place them in any way you like. But there's no reason to limit yourself to those prefabs, especially when it comes to interiors or complex, smoothed hull shapes.

Why not take to Blender (or Maya or whatever)? Use the library file included with the modder package, and you can import those prefabs into a new Blender file, arrange them in Blender, scale them in Blender. Save it, and in Unity, a finished ship will pop up. A minimal amount of processing can match the Blender objects to their identically-named prefabs and swap them out in the ship prefab - essentially translating your Blender file into the exact same ship you would have gotten by dragging and dropping Unity prefabs.


You can add more things in Blender. A hull that is any shape and texture you please. New animations. Skeletons. Unity understands all these things, and we can process some of them into game logic - for example, our custom hull elements can be correctly classified and prepared for damage effects.

How far the modder wants to go is up to them. A new animation controller. A ship that flexes and ripples like an organic creature. A ship that grows or shrinks on command. There's a lot of possibilities, limited only by how well the game code copes with weird-but-valid Unity objects.

The ability to shape your own hull really can't be overstated. Passive elements such as rails, running lights, steps, windows, and simple smoothed hull elements are incredibly valuable to the average person. Voxel-based approaches give you some freedom, but there is absolutely nothing like being able to arrange them freely. That requires us to be able to distort and reshape them - something that is easy in Blender and extremely annoying in Unity.

A long, curving hand rail is easy in Blender. Import the hand rail object, stretch it, and curve it. Fit it to your ship perfectly. Unity imports it and it's in your ship! Bang!

More than that, assuming your naming convention is good, Unity understands that it is a hand rail, and will use IK to have nearby astronauts automatically slide their hands along it. That's super-easy, I've done adaptive animations like that a lot. You just need to have the object properly tagged!

(Making custom spaces feel real is incredibly important - I would pay special attention to making adaptive character animations, including things like turning sideways to move through tight areas or stepping easily to the side as you approach furniture.)

Pretty neat, right?! RIGHT!?! yeah.


Oh, right, I forgot the other half.

It's possible to make game assets viable to import into any similar game. SREG2000 assets could be imported into Shooty-VR-Game-Ultra. The only limit are class and library dependencies built into the asset package.

It is possible to minimize library and class dependencies by having the ship focus internally. While it's unlikely the same asset pack would load up in both SREG2000 and SVRGU, it would be relatively easy to import SREG2000 content into the SVRGU mod editor (both Unity projects), then winnow out the dependency errors and re-rig the ship for SVRGU use. The core - the meshes, materials, animations, etc - would be the same.

It is possible to create a database of, say, complex space ships. Not simply models: high-functioning ships that contain dozens of internal logic objects. For example, a class that opens and closes a hatch when triggered. A class that runs a specific trigger name on someone's mecanim animator if activated by them. A class that displays the state of that hatch. Because these classes are internal to the ship, there's no real chance of them colliding with game logic. Therefore, these classes can be packaged with the prefab, or packaged with the core idea of the mod editing system for both games.

Sounds interesting!

And, more importantly, sounds viable. Even if you remove all of the advanced features, simply allowing players to create new prefabs out of stock prefabs is incredibly powerful, especially if you can wire components together with references and events and delegates.

Thursday, June 18, 2015

Heights of Engineering and the Soft Constraint

I've been thinking about the curve on construction games.

In nearly every construction game, there is a wall and a plateau, and they aren't very far apart. That is, it's hard to learn how to build, and once you've learned how to build, there's relatively little engineering skill to learn past that.

In Space Engineers this is particularly pronounced. You need to learn that you need to arrange all your thrusters, need gyros, need reactors, need assemblers, etc. That's the wall: you need to learn all the hard constraints before you can make anything that comes even close to working. You can pilot included ships, but that doesn't help you learn how to make them!

Once you've got the basic hard requirements down, there's nothing to push against. You can do small topological and mass optimizations, but there's not much reach. Really, the only place to explore is aesthetics, and few players will feel strongly enough about it to want to spend real time on it.

(You can do a lot of stuff with moving parts, but those aren't part of the core ship design loop.)

Both of these problems can be solved by adding one simple thing to our construction game: soft constraints.

Hard constraints are when something won't work unless X is met. For example, reactors don't work without uranium, engines don't fire without fuel.

Soft constraints, conversely, are about conditions that gently change how the systems work. For example, an engine will burn all the fuel you pass to it, so you can change how much thrust an engine produces by passing it different amounts of fuel. Maybe the efficiency is best at a particular rate, but it'll work with a trickle or torrent.

Perhaps your space jump system requires 100 gigawatt-hours of electricity to fire. But you don't have to pipe that in all at once: the system can absorb smaller amounts of energy until it reaches its requirement.

On the introduction side, this lets you start new players off in a battered, badly-designed ship. Rather than trying to build a new ship from scratch, players can spend their first few hours repairing and upgrading, allowing them to learn how a ship works before trying to build one. This is a good solution because they don't have to be perfect: the player doesn't have to understand how to make things work in order to repair things. He'll repair things in order to understand how to make things work.

On the advanced skills side, players now have a lot more options on how they want to engineer their ships.

Do you shut down all other systems to get that fast charge on your jump drive? Do you put in additional heavy reactors, slowing your ship down in realspace for the advantage of a faster jump time?

Do you use thin fuel pipes, which are easy to work with but can't pump much fuel to your engines... or do you use the thick, annoying fuel pipes to supply your thrusters with overdrive capacity?

Multiply these questions times a thousand. Every system has soft tradeoffs. It works better if you do this or that better, but that requires other resources or space and so on.

Engineering is all about balancing tradeoffs and finding opportunities in constraints. Soft constraints are better for this than hard constraints. They let us do a lot more engineering, a lot more flexibly!

Just off the top of my head, those system optimizations can involve topological configuration (larger pipes), mass considerations (more reactors), temporal considerations (long boot times), intermittent optimizations (changing how things are laid out/enabled over time depending on requirements), and more.

Put in some soft constraints today!

Tuesday, June 16, 2015

Machinima as Gameplay

I've been thinking about how to let players create context-conveying content. Obviously, players should build physical content - space ships, maps, etc. But it's hard to explain what is cool about a space ship or a map if that's all that gets shared. Players need another option, another kind of content: procedural.

Procedural is a bad word, because it normally means "algorithmic content" such as roguelike dungeons. In this case, however, I am talking about purposeful changes over time. Processes. Maybe I should call it routine..ual... routinual? Ritual content? Probably best to call it "behavioral content" or "operational content".

Machinima is already a big thing, but it's normally outside of the game. Even if you record it while playing the game, such as a Let's Play with a story, the content itself is outside of the game and cannot really be distributed inside the game. The closest we've gotten in the past is with The Sims, where you could share photo albums.

If we bring it into the game, we can allow players to record something, and then we can chop it up and play it back as content allows. Duplicate it, move it, alter it to fit a scenario.

As an example, let's say you're playing something like Space Engineers or Kerbal. You create a ship with dozens of docking bays, all identical. You can get in a fighter, hit "record", and then record yourself approaching and landing on a docking bay. Now, whenever you or the game wants, a similar fighter (same basic bounding box, same basic thrust capacities) can come in on the same vector and land in precisely the same way.

But because the game understands the context of the objects, the game can easily flag specific locations and relationships. The point where the ship touches the bay is automatically considered the critical element. Other bays with the same layout and flagged as being the same thing can therefore automatically adjust the flight profile to perfectly match their position and orientation. This means, with no extra work, any bay can have a fighter come in and land automatically. And, if you cut and paste the bays, however many more bays, all of them can have fighters come in for a landing.

I want you to really imagine how powerful this is. Imagine you're just playing Space Engineers for the first time. You build a space station with some landing bays, and then you shakily pilot your starter ship over to a bay and park it. Now the game will instantly be able to have any ship of roughly that size warp in and shakily pilot over to your other bays. Noticing this, you cut and paste your bays, creating a massive wall of bays.

And now, there are fleets of small ships scuttling in, eager to stop in. They all line up and slide into place, many so distant they're like a swarm of butterflies.

Moreover, this behavior automatically links into other behavior. You notice that sometimes huge motherships will warp in and disgorge shuttles of the proper size. That's because when you build a carrier, you record the behavior of the shuttles leaving. They then become their own entity and can therefore pick up behaviors related to shuttles. It's a simple logical chain: your station allows for shuttles to land, these motherships have shuttles, therefore these motherships can use your station.

On the other side, things keep chaining. Once they've landed, the ships can chain into new behaviors such as trading, repairing, refueling, passenger exchange. Each of these is fueled by whether you've recorded the process in the machinima engine. And if you haven't, you can always turn it to "request mode", where they will request you to do something, and you can record machinima of it right on the spot with them.

Suddenly, the universe is alive. You've tapped into the shared behavioral engine.

We're using machinima as gameplay.

It's not just floating in the ether, either. Exactly how you land will depend on the layout of your ship, the size of the docking bays, and other gameplay considerations. When you record the machinima, your max acceleration and bounding boxes will determine the kinds of ships that are considered fit for the same behavior. And you'll also want to rig the behavior into a smart system - for example, point small ships towards small bays, but allow them to fill larger bays if your small bays are full. Set trading prices so that you can adjust the price without rerecording the behavior, or even adjust prices automatically based on supply and demand.

Basically, we've gone from just creating a ship to also creating the space and time around the ship, and the operations of the ship. These allow us to tie everything together - everything from a lot of different players. We can even embed mods into this, if we frame mods in the right way.

Normally, machinima is used for narrative content. You tell the story of two dudes on a road trip using the Space Engineers engine. By adding context that doesn't exist within the framework of the game, you make the game seem larger.

By allowing machinima sharing and reproduction within the game engine, we also allow for that. Not all behavioral recordings result in a significant in-game statistical change.

Sure, landing a ship and trading are valuable in-game functions and the behavioral recordings for those are likely to be spartan and utilitarian. But you can do so much more: record crew wandering around your ship, going to bed, changing shifts, eating in the canteen, bullshitting in the halls. Record conversations and missions that have nothing to do with any statistical in-game thing, but give your crew and ship uniqueness: when someone contacts your ship, the captain will pop up and be a specific person asking about specific things and telling a specific story about a specific ambush in a specific place.

Moreover, behavioral recording can be modded just like normal content. If we forget to make medical treatment a thing, people can mod in some new animations and record themselves interacting with various medical blocks in various ways and - poof - we have a new block with new functions that NPCs can automatically interact with. Tie the statistical operations of the block into the machinima, and you can actually have real function. The medical bay has a function for treating illness, and you can trigger that function during your machinima, meaning that playing that behavioral tidbit will actually treat illness. Conversely, anyone with an illness can automatically search for behaviors to play and for blocks in the area that will allow them to perform the behavior.

I think this is an interesting idea.

Friday, June 12, 2015

Social NPCs and the Old Guard

I talk a lot about social NPCs, but I'm obviously not the only person who thinks game characters could be more alive and interactive. My approach is "world centric", but that's not the only approach.

One person who shaped some of my ideas is Chris Crawford, a game designer who was active mostly at the turn of the 90s. His books and essays were always interesting to me, and his approach was "character centric". That is, he focused on making the characters themselves more interesting and nuanced, rather than integrating them into a complex world.

The reason I'm talking about this now is because Crawford came out of the shadows and, like many of the old guard, launched a KickStarter campaign.

Obviously, I backed it. But it got me to thinking about that world/character dichotomy, and why I decided to go the exact opposite route: I want the exact opposite thing he wants.

I don't particularly want mysterious characters that you push against. I want a world full of people you live with.

That said, I wouldn't mind seeing what he can do with his approach.