Friday, March 25, 2016

Making NPCs Into Feedback

Yesterday I wrote a cluttered essay about making construction games that have NPCs in them. The basic idea is that construction games generally have bad/nonexistent feedback on player activities, which means they have no real traction. However, if we put NPCs in the game, they can react to the player's actions. They can react to the things the player constructs, react to the actions the player takes outside of construction, and react to how the player's constructions fare as the world weighs down on them.

It's easy to think of this as "creating a game where NPCs live their lives in the player's constructions" - think The Sims. However, that's the opposite of how we should think of it.

Normally, we use smoke and mirrors to make convincing NPCs. Now we will use the NPCs as smoke and mirrors to make a convincing game.

Let's consider some methods.

First, when the player installs something new, it needs to be acknowledged by the NPC population. One way to do this is the Sims' method: NPCs walk over and admire or disdain the new purchase. This is too small and shallow, although it's probably worth implementing. The real response needs to be deeper: NPCs need to adopt the new purchase as part of their lives or work.

This is more flexible and immersive than it sounds, but it requires us to make every component of our construction human-centric rather than intersystem-centric. That is, we can build a power station, but it has to be something a person works with or at, not just a passive device that adds N power to the ship/base.

We have some wonderful opportunities here.

A) The NPCs can openly discuss who should have control over the new system (or how they should share it). Someone says their job needs the new computer, or decides they maintain the engines, or that this is their new quarters.

B) The player can manually assign those duties instead of allowing them to be automatic, changing the dynamics of the NPC's lifestyles manually.

At a low level, this means that the most critical thing you'll need is workers. As you build stuff in your base, you'll need to have enough workers to use/maintain it. There's a natural tendency to make that a serious constraint, so that you'll need hundreds of workers to manage any decently-sized base. However, the human brain can't really keep track of that many people at once, and therefore their responses will start to feel random and arbitrary instead of purposeful. We need to keep the number of workers manageable. That's more complicated than it sounds, but at this stage it simply means that NPCs should be allowed to take on a truly staggering number of duties without suffering.

Instead of requiring more NPCs, the NPCs can take on more duties. This will shape their lifestyle and prominence in the facility: someone responsible for more things is busier, but is also respected more and has a lot more social clout. Not all duties are considered equal, though, and there's a lot of complexity we can add in as we please. For example, some jobs give you social prominence, others give you happiness, others give you cash, others increase your stats...

Working out the NPC response to a newly installed segment is an opportunity for us to make a fun and details bloom out of our game, but it's only the first step. We also need to consider non-constructive gameplay such as damage/degredation, missions, daily life, etc.

How we make our NPCs react to these other systems will further shape our game, but first we need to figure out what kind of systems we're talking about.

I rather like the idea of having multiple concurrent missions at all times. For example, your science team could be searching for allergens in the local flora, your political time might be trying to learn the Xargiblot language, your political team might ALSO be struggling to keep a neutral peace going until they finish learning the language, your exploration team might be collecting rare samples from the artic poles, your engineering team might be optimizing the atmospheric thrusters to work best in this atmosphere, etc.

All of these missions take different amounts of time to complete, and have different drivers that push them forward. The idea is that the player can focus on any given mission for a short amount of time, optimizing things and polishing and manually setting things up, but the missions also proceed automatically in the background. This allows the player to choose which missions they want to focus on, and switch missions if they ever get bored.

This also means our NPCs are split into teams. This is good, because it's an excellent way to "chunk" our NPCs. Characters with no structured relationships are hard to remember, but if we split them into teams, the player can partition them up and remember them relative to the team rather than to N other NPCs.

Teams can have high or low status to other teams just like NPCs can have high or low status compared to other NPCs. Most of an NPC's relationships will be within the team - interteam relationships are hard to remember, so they should only happen when specified by the player.

Chunking teams is a big, easy thing to do in order to make our bases or starships more interesting. For example, your instinct might be to have a big dorm room for all your workers, but team cohesion suffers. It's better to have different dorm rooms for each team, especially since you can then decorate the room or have nearby rooms that enhance that team's performance but wouldn't benefit teams with other priorities.

Combining and splitting teams is also a ripe fruit. For example, the political team needs to talk to the natives of this planet. However, you don't know their language. So you split the team into two: a xenolinguistics team to research the language, and a social team to try and mime their way towards peaceful coexistence. One team, one mission. Once the language is learned, you can merge the teams back together.

Not everything is a mission. You don't split the engineering team into an engine maintenance team, a life support maintenance team, etc. Those are simply duties that happen in the background. The mission would be optimizing engines or something similar. Something that has an end state.

Because the missions move at different rates, each team is under a different amount of stress and a different phase of their work. As missions get near completion the stress is at its peak, so the players will naturally tend to focus on missions near the end of their run as they have to step in to massage stress problems.

We can also have personal missions, resource allocation challenges, etc.

All of this leverages the player's ability to choose missions. While some games are completely open, allowing the player to flat-out make up missions, my approach does require explicit missions. But since there are so many missions and so much flexibility about assigning them, it should feel pretty open. There's nothing that requires you to learn the alien language, or even to negotiate with them. You can create an overall mission profile based on your own personal approach.

The combination of NPCs working on the mission and the devices supporting them gives you strong feedback about your design and whether it works well to support the NPCs. Should be pretty clear and rewarding.

Anyway, that's my concrete thoughts on using NPCs to provide feedback. What are yours?

Thursday, March 24, 2016

Multiplayer and Fake Multiplayer Nonviolent Games

As you may know, I do a lot of prototypes of nonviolent games, especially construction games. However, they don't tend to make it past the prototyping stage, because they never pass my "is it fun" test.

The biggest problem with nonviolent games is providing juicy feedback. Violence is very juicy: you can immediately tell how things are going and what effect you're having on the game world. It's not inherently more or less complex than any other kind of gameplay, but it is very clear and easy to see. Puzzle games can also be made juicy: pieces appear, merge, etc. You can tell the effect you're having and get a strong feedback with each action.

But construction games are not inherently juicy. They almost can't be, because there's no clear goal. Violence has a clear set of objectives - defeat the other guy. Racing? Clear objectives. You can immediately tell if you're doing well or poorly based on whether your car is zooming along or stuck in a ditch. Puzzle games? Clear objectives, although the feedback may or may not be clear.

Construction games are open-ended. If I want to build an artic base, what sort of objective do I have? How do my objectives break into goalposts? How do I get feedback?

It's possible to engineer all of this into a juicy system. City building games do this: while they are open-ended, you are led by the nose to fulfill the statistical requirements of the system. First you need residential and roads. Then you need to add in commercial and industrial. More residental. Now you need schools. Police stations. Fire stations. Sewage. Happiness. Pollution control. As your city grows, the game gives you more and more statistical requirements to fill, so your objectives are always pretty clear.

As a result, those city building games don't really pack much punch. If you look at a hundred cities and compare that to a hundred cities doodled on paper with no constraints, the paper maps will have more breadth, be more interesting, and represent the author's personal interests and choices more clearly. By introducing clear objectives, city building games make it more difficult for a player to build an interesting, unique city.

That isn't a universal rule, though. Sometimes, objectives and constraints can lead to more creativity rather than less. A good example of this would be Minecraft's ugly voxel construction system. It's clunky and raw, archaic-looking, but working within those constraints has led players to build whole cities, reproductions of real-life areas, massive computers, and so on. Each of these is a work of art within the context of the game, and many of them are easily recognizable as works of art in general. When you look at a redstone contraption the size of a football field and it plays a song, you can admire the work and cleverness that went into it even if you've never played the game.

One of the keys to this is simple: the goals are self-chosen and self-judged. Unlike Sim City's popups telling you to add more residential, more fire safety, more schools, you are responsible for your own goals.

The problem with this is that self-chosen and self-judged goals are not reinforced by the game.

In a shooter, every time you fire a gun you get a game-provided satisfying feedback. The crack of the muzzle, the flash, the ammo counter draining, the explosion in the distance, even trying to manage the kickback and drift. The game tells you very clearly that this gun feels like this and that gun feels like that. It tells you whether you hit an enemy or wasted your ammo on a wall. It tells you a lot in a constant stream, because the game knows precisely what each weapon is and how it works and how it should feel to use.

This isn't the case with open-ended goals. Can Kerbal Space Program know what your goal is? Sure, there are implicit goals like "land on the Mun because it's there", but can KSP really tell if what you're doing is going well or poorly or entertainingly? Should it celebrate you landing on the Mun, even though you crashed, or landed in the wrong spot, or the main system didn't work out, or the ship is not going to function as intended and you're stranded on the Mun forever?

More importantly, the juice comes from celebrating progress towards, away from, or tangential to that goal. KSP gives a pretty juicy response when you jettison rocket stages, but it has no way of knowing if that was good, bad, funny, accidental, or intentional. It gives a good response when things explode but, again, no way of knowing the intention behind it.

On the other hand, there is a very easy source of juice. There is something that responds very accurately and powerfully to your progress, missteps, and intents:

Other players.

Other players provide running commentary on what they see, and can get excited about the smallest things. If you try a moon landing as a group, you'll invariably have a good time even if you crash and burn. If you invent an interesting new toy that the game doesn't know what to do with, other players will have a fun time interacting with it until it explodes. Right now, multiplayer games are focused on combat or PvP sporting games, but in truth cooperative or mixed-cooperative multiplayer is at least as powerful, if you can find the right kind of people to play with.

Here's the fun thing: there don't have to be any other players.

Think about The Sims.

99% of the people that play The Sims never played it multiplayer, and the last 1% played it by handing off control and snarking. But The Sims was very compelling because of its multiplayer elements.

One obvious multiplayer element is the sharing of content. All versions of The Sims allow you to share characters, clothes, houses, albums, videos, etc. This really helped to create a community and it's worth considering.

But the secret multiplayer element is also worth considering. Have you figured it out?

The Sims themselves.

Or, more accurately, the stories the player makes up from their point of view.

When you put friends, celebrities, or famous characters into a Sims house, you immediately and automatically start imagining how they feel about the situations they find themselves in. It's great fun to mock your friends for their behavior in your video game, or to imagine your own little fanfic about Snape shacking up with Dumbledore.

Because you have a clear feel for how these characters should and would act, you get a clear feeling of how they would feel about any given situation in the game world. It's very juicy.

It's powered by the frission between the expectations you bring (self-directed goals) and the constraints of the game (processes and interactions). Bringing Wolverine and Captain Kirk into the game world brings in your expectations of what they would do and how they would act. The game's interference as it pilots the two around creates an opportunity for you to take inspiration from the new actions, laugh at how off-base they are, or explain why they would do that given their personalities. In only a short while, you suddenly have "your" Wolverine and "your" Captain Kirk, and now you're inventing objectives and goalposts for them.

The game has no idea about any of this, of course. The game doesn't know who Captain Kirk or Wolverine are. It doesn't know your friends, it doesn't know Dumbledore or Snape. At best, it has a vague impression of things like age, profession, and fundamental personality traits.

The player does all the heavy lifting on their own. Along with the player's self-directed goals and constraints, we now have self-directed multiplayer. Multiplayer that happens in a single player's head.

The Sims had a number of other features to it, of course. They put in a variety of treadmills to give you something to do while the characters got traction on your brain. All told, it was an extremely powerful and successful series.

I think it might be possible to use this same idea in other kinds of construction games.

By convincing the player to feel what the characters should feel, it should be possible to allow for juicy feedback on construction. This requires tying construction into the lives of the characters, which can be tough. If you're building a space ship, you need to be able to feel what characters would think about a new engine or a new life support module or whatever.

This sounds weird, but it's no more weird than buying your sims a bigger TV or building a pool for them.

Fundamentally, sims are interesting mostly because of the lives they lead. Big chunks of that are how they interact with other sims, but equally big chunks are how they interact with the environment. Is Wolverine forced to work at a day care? Does Dumbledore burn his breakfast and leave dishes everywhere? Is your buddy slacking off on the couch AGAIN?

Doing this intentionally for a different kind of game shouldn't be impossible. The level of character customization required is a hurdle, but not insurmountable. It's worth trying.

Just remember the treadmills and asynch multiplayer. Those are still critical elements of the puzzle.

Anyway, that's my first essay in a few months. Let me know if you have any opinions on the matter.