Wednesday, August 31, 2016

Compound Grinding Engines

I've been thinking about how some games are compelling even when in barely alpha states, and others don't become compelling until nearly the whole game is complete. And I think I know the answer: compound grinding engines.

Most games burn content for play. An RPG, for example, requires the devs to create characters, monsters, maps, equipment, stats, skills, scenes, all this content. This is essentially a steam boiler: throw content in the hopper and the player bubbles.

In order to keep the engine going, you have to keep burning content.

But in the beginning, the devs don't have much fuel. They haven't created much content, and most of their content is placeholder assets. There's not really any point to bringing players in right now, so the devs usually show off their art instead of releasing demos.

There's nothing wrong with this, but clearly the game isn't playable out of the gate. Players would just be disappointed.

On the other hand, some games are substantially more playable even in primitive states. Simulation games, mostly. Physics sims, life sims, empire sims, any kind of sim game seems to have some kind of pull that makes it fun even when it's very primitive. What is it?

Well, "simulation" is the key word. The player sets something up and then watches it unfold. The player is creating content out of the initial content. We can extract a lot more heat out of this content because it forms secondary content, maybe even tertiary content.

Rather than just a single steam boiler, we're building a compound steam engine.

This isn't quite as straightforward as putting together an RPG. It requires less content, but the content needs to be carefully fitted together because a leak in the first "chamber" will make the other chambers break. Right now, it feels like most games that get it right are either accidents or instinct, so let's take a closer look.

Games like Besiege are basically double chamber engines. The devs provide some physics content, the players arrange it and have fun going to town with it.

It requires some care. For starters, allowing the players to build whatever they want with no guidance is not going to work, at least not as an initial play style. You need to give the players something to strive for. Something that a beginner can figure out how to do and an expert can hook additional constraints to. IE, "knock over the tower" can turn into "with a giant mech" or "using only sheep" when the expert players decide to try.

There's the core fitness test - the fundamental constraints. These should vary so that the players can explore different variations. In Besiege, that's the various levels. This has the advantage of being something that can be churned out in huge quantities later on. In Space Engineers, the constraints can be fine-tuned during world creation. In Kerbal, the constraints vary across a huge map and you can choose different destinations to engage different constraints.

There's also the self-challenge constraints. These typically arise from the components you allow players to build with.

Usually, physics simulations have a variety of parts that have different physical characteristics. By playing this up both statistically and visually, you can easily create self-challenge constraints. These typically arise from either holding back (banning specific systems such as liquid fuel rockets, explosives, pilots) or hilarious overstretching (mecha out of a joint block, using extendable landing gear to flap wings, using stacked explosives to drill out a five hundred meter shaft, making an 8-bit processor out of redstone). Both of these approaches can be predicted based on the components, the way they interact, the way they interact with constraints, and how clearly they are demarcated visually and systemically.

That's worth talking about, but we're going to instead move on to a much more straightforward example of multi-chamber systems: NON-physics simulations. For example, life sims, empire sims, farm sims, etc.

That is... grinding.

Today we'll defining grinding as designing a system that takes some player time in order to change a parameter in some way.

The first half of the equation is taking player time. Typically this is done via a static constraint: the game simply takes some time to interact with. Making selections, moving from place to place, etc. However, in some games specific tasks have an additional time cost, typically paired up with stat costs. IE, watering each plant takes a small amount of energy and plays a two second animation, or boxing someone requires you to play a minigame for thirty seconds.

Anyway, to me the second half is important: parameter change.

This is the "content". This is what the player pays attention to. However, without context, it's useless.

These stats often carry some context over from their real-world implication to start. For example, in Cookie Clicker, there's the initial context of "hah hah cookies how funny". Then additional context is overlaid based on the way systems interact with that 'stat'.

Similarly, in a life sim you might grind your sports stat or your intelligence or something. The initial context of "I'm sporty" or "I'm brainy" is decent, but you absolutely must layer systems on top of it in order for it to pull the player in.

It's tempting to just add "things that happen when you reach N points of stat". This is popular in dating games: to date the jock you need N sports points, to date the nerd you need N intelligence. But this is "single boiler" content, the same way marching through a dungeon or buying a new sword is content in an RPG.

To get a "multiple boiler" setup, we need to have compression and decompression cycles. I know, I know, stretching the damn metaphor.

Most of the compelling prototypes I've played feature only a small amount of "real content". Whether it's a composite VN with only one character or whether it's a space empire game with undifferentiated planets, the key is that our grinding gets "spent".

IE, we don't just get research points and have ever more of them: we gain research points in order to spend them on a technology.

The technology is the content, but the whole point is that you're going to have to go back to the previous chamber and grind there again in order to get the next technology. This means that each research grinding is done with a purpose: you're grinding specifically
to get tech A or B, not to just get a higher research rating. Mid-term goals built right in.

MMORPGs use a grinding system based around "fonts" and "sinks": kill monsters for cash, that cash drains away to upgrades, shops, etc. But that's not what we're talking about.

Ours is more of a piston-based approach. The player focuses on injecting high-pressure gas into the chamber expecting a single "pump" of the cylinder. It's true, you are gaining research points, but the intent is for that single sweep of the piston: BAM, you have a new tech and that chamber is now spent.

Whew, that metaphor is stretching pretty thin. Let's leave it behind.

The point is to create a series of asynchronous, parallel, interlocking grinding systems that the player will use to obtain specific results which will then reset that system.

The player isn't just grinding to improve tech points or gain intellect, they're grinding to spend those points on something.

This can easily be interwoven and daisy-chained. The player grinds industry to build a bigger city that they can use to grind tech more efficiently so they can unlock a new mining rig to let them grind industry more efficiently...

You're going to have long-term state. That's how the player knows they're making progress. But the point is that the long-term state feeds back into the grinding most of the time, rather than simply being a content reward. Content rewards are expensive and don't chain well, so I think of them as the final link in the chain.

A fun thing to do is to make the long-term state conflict, so you can only optimize in one direction and then need to un-optimize to go another route. Alternately, you can add in states that cause unusual mutations in the flow of grinding. For example, if the player builds a police state, then half of all research points become spy points. Yeah, the citizen unhappiness that results is not great, but if you are pumping out a lot of research, you can power through to the spy expenditures you want to achieve and then dismantle the state...

Another fun thing to do is "soft limiting". For example, you have a max research cap of 50 points of research, regardless of how you grind. But unlike a hard limit, this is a soft limit. Even without upgrading your facilities to get a higher cap, you can exceed that limit in a specific, limited way. Maybe the cap is applied at the end of each month, or you lose 50% of that overage each day, or you pay $10/day upkeep for each additional point, or each point requires an additional scientist. Each soft constraint will inspire the player to create a plan to exceed it in a different way, so think it through.

These kinds of capabilities are what separate a powerful compound grinding engine from just another newbie sim game. A relatively small amount of content can have vast effects and keep a player coming back hour after hour before you've even added art.

In theory.

I have a lot of thoughts on this, especially in regards to setting up and maintaining flow at the same time, but this is more than long enough. What do you all think?

Tuesday, August 30, 2016

Concrete Analogies

In films and novels, every element of the story generally exists to reinforce the story. This is so obvious that when you see something that doesn't lock into the narrative of the movie, you immediately think that the narrative is not what you thought it was.

But what's obvious to movies and books isn't so obvious to games.

Most games are thrown together out of genre standards and whatever sounds cool. The many elements of a Deus Ex game do not all support the personal journey of JC Denton or whoever the lead is. Instead, they struggle to create an immersive mood while providing gameplay. At best they support the same theme. Normally, not even that much.

For example, think of a typical RPG. Volcano level, ice level, forest level, village, town, capital city, etc, etc. Goblin, wolf, troll, fire elemental, thief, etc, etc.

But what's the actual story of the RPG? How does a volcano level support that story?

Typically, it doesn't. It's just a genre convention.

It could, though. Volcano levels have a lot of characteristics, any or all of them could match up. They're chokingly toxic and hot, bubbling with something deadly. It could represent a time when the main characters are bitter and rage-filled. It could represent the world's opinion of the main characters, at a time when they are being blamed for troubles. It could represent a journey into your bitter dreams, or into your hate-filled past. It could host a particularly sinister group of people, or represent the uncaring brutality of the planet itself.

Thinking like this is a bit different from simply trying to make an interesting volcano level. It requires you to understand the overall arc of the story and use the volcano level as a reinforcing element at the right time. But it should also give you a lot of ideas on how to make the volcano level suit your story even more.

For example, few RPGs have a cloud of ash, or a violent volcanic explosion, or toxic smoke. However, your story could benefit from these events. As a simple and heavy-handed example, if the main character's husband dies, a cloud of ash could envelop the whole village. The villagers could desperately plea for the main character's help, and going into the volcano filled with magma and toxic smoke could very easily represent the main character's grief mixed with the unending pull of duty. People are depending on you! Do your job even if you want to die!

There's nothing wrong with being heavy-handed, so that would probably be a pretty solid sequence.

Hopefully, you can clearly see how using the volcano level to support the main character's personal arc can strengthen the entire experience. Not only can it lead to stronger design, but it can also keep the player on target, feeling the right things at the right time. Just don't forget to let the player enjoy the game, too.

This kind of basic approach is really under-used. Devs don't tend to think like this, probably because genre conventions are so heavy in their mind. It may also be because game writing is rarely very sturdy early on, so devs are worried about having to completely change the story element to a level, or because of the difficulty of synching up so many level designers.

But, anyway, that's a really basic approach. Basically stealing straight from the movie industry.

Is that the best we can do?

Nope!

Video games are interactive. Our analogies can also be interactive.

The simplest example: that lava level represents our main character's struggle with her grief and sense of duty. But unlike a movie, we can play through this level. Each thing within the level can theoretically be tied into the story - every hallway, every enemy, every treasure, every puzzle.

This could be done very simply - each victory clears a point of grief or gives a point of duty. This is an iffy design since it's fundamentally going to push the player into completionist fits, but you can avoid that if you take some care when designing.

Instead, we could tie the various locations into memories the main character has. This could be done very obviously with flashbacks, but it can also be done subtly - the dungeon layout is identical to the town layout with monsters where the people were, etc.

We could also tie it to the real world in more concrete ways - people who know you and want to help show up over the course of the dungeon to pull you along or make things worse. Equipment shatters as you use it against the monsters, except perhaps the dagger your husband made.

There's almost an unlimited number of ways to embed the character arc not just into the concept of the volcano level, but into the challenges it contains. This can be done passively, to lure the player deeper into the arc. But it can also be done actively, giving the player some control over the outcome of the arc. Not necessarily the emotional outcome for the main character, but how it affects everyone around them.

Now let's talk about space ships.

Space ships are an extremely versatile thing in fiction. The play a lot of roles, but it's not unusual for a space ship to represent the overall arc of the movie or book. For example, Serenity from Firefly physically represents the characters' struggle for independence and life. It gets torn up or filled with compromises, but it still flies free.

Or it may represent the foundation of the series, like the Enterprise embodies all the ideals of the Federation in one tidy package. Or it could represent a mission even as it facilitates it, such as the makeshift shelter in The Martian.

Space ships are very flexible because they do so many things. They are vehicles, homes, cities, tribes, regiments, factories, workplaces, governments, and anything else they need to be - often several at once. Moreover, they are flexible because they are fundamentally made out of parts and the parts can be revealed or changed as the story demands.

From a game design perspective, space ships are also flexible because they can be created by the player or by the dev or any mix of the two. The player can be inside them, outside them, or embodying them. They can be working, broken, or need maintenance. They can be echoingly empty or packed with people. They can have a future and a past embodied in the state of their systems. They can have specific missions, or be built for a specific person's personal use. They can have distinct cultures, distinct puzzles, distinct costs, distinct payouts, distinct performance.

With all those things in mind, there's no reason we can't incorporate those elements into the stories we're trying to tell. Easy example, same as the volcano level example: the space ship falls apart as the main character's husband dies, and duty calls.

There are a lot of little things hidden in this idea. For example, a space ship that the player makes could play this role, in which case the specifics of the ship would vary wildly depending on the player. Which means the specifics of the arc the main character goes through would be different.

What if the player made a space ship that was too good, too self-repairing, too durable? When things go wrong for our PC, things don't really go wrong on the ship. This lack of an emotional resonance leads the player to underestimate the internal conflict of the PC, or leads the PC to have less internal conflict. Either way, this blunting would weaken the story. But we could make it so that if the ship doesn't echo the conflict well enough, the character doesn't recover from their trauma.

Or the other side of the spectrum: the ship is too badly designed and when it falls apart, everything falls apart forever.

We've been using a pretty dark and personal story for our examples, but there are lots of other stories. A space ship can just as easily represent wanderlust, or parenting, or your memories of a day at the beach, or the struggle to leave a mark on the world, or star-crossed lovers, or whatever.

In fact, the same ship can represent those things. Or, at least, ships built in the same game engine.

There's a lot of question in my mind as to how blatant this should be. I mentioned "grief and duty points", and that's one way to deal with it. But I think it's pretty easy to make it a bit more subtle.

Fundamentally, the components and experiences of the ship represent the emotions and interactions of the main story, whether that's personal or something bigger. It could simply be that stories only advance when there's an opportunity to advance it. IE, the main character stays in mourning until there are half a dozen opportunities to struggle through it using duty as a crutch, culminating in a dedicated final act. Your ship design, your chosen missions, and even how well you do on those missions could change when those opportunities arise.

Same for the others. Star-crossed lovers only advance by alternating between demonstrations of lovey-doveyness and star-crossedness, featuring the crew, the ship components, the missions the ship is on, the worlds the ship visits, etc.

The problem is how these arcs form. Generating stories is tough to make feel real.

Well, let's talk about that some other day.

Sunday, August 28, 2016

Multi-Material Mesh Merge Snippet

For this video

public void AdvancedMerge()
 {
  // All our children (and us)
  MeshFilter[] filters = GetComponentsInChildren (false);

  // All the meshes in our children (just a big list)
  List materials = new List();
  MeshRenderer[] renderers = GetComponentsInChildren (false); // <-- you can optimize this
  foreach (MeshRenderer renderer in renderers)
  {
   if (renderer.transform == transform)
    continue;
   Material[] localMats = renderer.sharedMaterials;
   foreach (Material localMat in localMats)
    if (!materials.Contains (localMat))
     materials.Add (localMat);
  }

  // Each material will have a mesh for it.
  List submeshes = new List();
  foreach (Material material in materials)
  {
   // Make a combiner for each (sub)mesh that is mapped to the right material.
   List combiners = new List ();
   foreach (MeshFilter filter in filters)
   {
    if (filter.transform == transform) continue;
    // The filter doesn't know what materials are involved, get the renderer.
    MeshRenderer renderer = filter.GetComponent ();  // <-- (Easy optimization is possible here, give it a try!)
    if (renderer == null)
    {
     Debug.LogError (filter.name + " has no MeshRenderer");
     continue;
    }

    // Let's see if their materials are the one we want right now.
    Material[] localMaterials = renderer.sharedMaterials;
    for (int materialIndex = 0; materialIndex < localMaterials.Length; materialIndex++)
    {
     if (localMaterials [materialIndex] != material)
      continue;
     // This submesh is the material we're looking for right now.
     CombineInstance ci = new CombineInstance();
     ci.mesh = filter.sharedMesh;
     ci.subMeshIndex = materialIndex;
     ci.transform = Matrix4x4.identity;
     combiners.Add (ci);
    }
   }
   // Flatten into a single mesh.
   Mesh mesh = new Mesh ();
   mesh.CombineMeshes (combiners.ToArray(), true);
   submeshes.Add (mesh);
  }

  // The final mesh: combine all the material-specific meshes as independent submeshes.
  List finalCombiners = new List ();
  foreach (Mesh mesh in submeshes)
  {
   CombineInstance ci = new CombineInstance ();
   ci.mesh = mesh;
   ci.subMeshIndex = 0;
   ci.transform = Matrix4x4.identity;
   finalCombiners.Add (ci);
  }
  Mesh finalMesh = new Mesh();
  finalMesh.CombineMeshes (finalCombiners.ToArray(), false);
  myMeshFilter.sharedMesh = finalMesh;
  Debug.Log ("Final mesh has " + submeshes.Count + " materials.");
 }

Friday, August 19, 2016

World Weaving

In the past few days I've been writing a lot about getting players to engage with procedurally generated or tool-assisted worlds.

The basic idea is that you have to get the player to actually engage with the content. That's the idea of the mining/survival gameplay in most of these games: mining resources and shooting monsters involves engaging with the randomized hills, sprayed plants and rocks, random monsters, etc.

I posted a lot of tips about how to improve that engagement, but then I read this tweet and something became obvious: you can make players engage with your content in a much deeper way by making gameplay that pushes them along a specific physical path. IE, a golf course.

An open-world golf game. Randomly generated golf courses make up the world. You can wander the world as you like, and if you feel like playing a hole, you can. The structure of the world matters because you have to painstakingly cross that terrain to get from the tee to the hole. Every variation will be felt. Every plant that can get in the way, every animal that will chase your ball, every boulder with a tunnel through it.

There are some other things I can think of that work like this: hunting, hang-gliding, racing, even grand-scale base-building. But when I started to prototype these things, I found only the golf version felt right. Why?

Well, only the golf game had underlying structure. The racing, hunting, base-building stuff was a layer that gave context to the world, but the world itself still felt unstructured and arbitrary. On the other hand, the golf courses created a fundamental pattern that could be sussed out, and you could feel that there was a structure you could embrace or ignore.

After experimenting with the paper prototype a bit more, I realized that this was not just an illusion: creating the world out of crisscrossing golf courses was fundamentally creating a world with rigorous overlapping patterns. I created a world where the green of each hole is placed in a simple grid pattern, but the rest of the course goes off whichever way it wants, twisting and turning, until you place a tee wherever you end up. They cross each other wildly!

This can be played up even further by scaling the courses - these are minigolf, these are short holes, these are long holes, these are giant courses that you play in a mech. Even the generation is easy - you can just make every course a simple path edged with local debris (trees, rocks, sand), but have overlapping zones turned into hazards. So two courses crossing over each other have a sand pit or waterway in the middle.

As I expanded on this concept, I quickly found that I could tweak parameters and overlap rules and suddenly I had a planet with rivers and oceans (megamaid-size golf hazards), mountains and valleys (courses at different altitudes), and so on. Moreover, basic rules allowed me to place houses, cities, etc (wherever there are a number of tees near each other).

By using structured challenges in my procedural generation, I could weave those challenges together to generate a complex, meaningful world full of a variety of golf challenges.

...

Well, this isn't about golf.

This same idea can be extended. We can build a world out of crisscrossing race courses - some for high-speed drifting, some for off-roading, etc. We can build a world about hunting as long as we make "hunting paths" where the player stalks a target that is taking a specific path. We can make it about hang-gliding where we define expected launch positions and paths of descending height...

As long as we generate our world out of paths, we can weave them like a tapestry. They don't even need to be individually complex at all, because their overlaps create the complexity.

So... we can generate a world out of paths!

The player can choose which paths to engage with, but they'll be affected by (engage) nearby paths as well when they do. Moreover, even if they just wander, they'll see natural flow and charming obstacles!

Neat!

We can...

...

Hey, we don't have to build physical worlds.

What if we wanted to generate NPCs?

We have to drop the idea of "quests". Those are points, we need lines. So each NPC has a variety of "directions" they want to "go".

The obvious answer is stats: what if each NPC has an "arc" of stats they want? She wants to gain 20 armorsmithing points and then gain 15 strength. You need to build her up using the least number of resources (moves, political energy, days, cash, goodwill, whatever). Trying to build strength first would be "hitting into the rough", although if you could find a way to gain both at once that'd be fastest.

But the key to this whole affair is that the paths cross each other. Unless another NPC interacts with her stat growth along the way, there's not much depth to this.

I think there are a lot of ways to do this, but one way is to tie matching stats. She wants to increase armorsmithing from 10 to 30, but there are NPCs with armorsmithing of 19 and 23. So on her way up, she'll run into them and have to work around them - either by defeating them in armorsmithing, winning a seasonal competition, charming them, frightening them, or pushing their skill up to 30+ as well.

An extremely simple algorithm can "carry" these collisions along, so that these same people continue to engage her as they automatically try to raise their skill to higher than hers, which naturally creates events where she's pulled into conflicts with her own recurring set of rivals.

Moreover, it's very easy to simply allocate a new arc at any time, and if we detect no NPC collisions (too skilled/population too low) we can either spawn new NPCs with the required stats or require that character to move to a new location with more skilled NPCs (making it in town/the big city/the capital/the celestial palace/valhalla).

This is a very simple algorithm but, as you can see, it creates a fairly compelling environment with recurring character conflicts, inherent drama, contests of skill, and so on. Adding in more details such as relationships, families, memory, and so on can make it even more compelling, but even at the basic level it's already more compelling than just randomly generating NPCs.

Because we can put the skill gain locations into the world (training halls, for example), this also links our NPCs to the world. While you can increase your armorsmithing stat in the armory, that's not the only place you'll go. In addition to always needing to increase another stat somewhere else, the conflicts that arise with other characters have solutions that involve going to other places. IE, who can make the best silver breastplate for the prince's seventh birthday? Well, meet the prince -> gather silver -> talk to the jeweler -> bribe the jeweler with wine from the coast -> gather gems -> meet prince again -> forge breastplate -> party & final judging.

This kind of setup could involve playing as those characters, but the strength of this approach is that it's "open world". Switching characters is valuable.

You can have a bunch of different games based on this.

For example, you play a helpful newcomer trying to earn their place in a new city. Or you play a ghost. Or you play Dumbledore. Or you play the floating head that recruits Power Rangers. Or you're the manager of a gym. Or you're collecting Pokemon.

...

Right now, we generate 'points'. Our worlds are filled with plants and animals and buildings and people, but they stand alone.

By finding ways to create "paths" the player can follow, we can weave those paths into a world. Whether that's a physical world or a social world or some other world. It creates engagement, creates meaningful patterns and variations, and allows the fundamental variations in the content (such as size, stats, or personality) to matter more.

That's my thinking this week.

What do you think?

Wednesday, August 17, 2016

Exploration Changeups

One of the problems in exploration games is that the player always comes in from "on high".

That is, the player has full control over their movement and can see quite far. Not only can they choose whether to engage or not, they have extremely fine control over their engagement at all times, and can change their mind as they like.

Two problems with this.

1) It negates the impact of most content.
When you can see the content at range and keep an eye on it the whole time you close, it doesn't hold much mystique. This is especially true if you're relying on variants, because variations don't matter at range. They usually aren't even noticeable.

2) It negates the engagement of the content.
When the player has such precise control and good vision, it is difficult for the content to reach out and engage the player. This means that the content will just be a visual unless the player chooses to allow it to engage. Even if your content is brilliant and engages in many nuanced ways, that is painfully blunted if the player has this much control over its vector.

To fix these problems, we need to adjust both the player and the content. Not to a new normal, though: we're not looking to simply reduce the control and vision. We want to vary it wildly, because then the player will engage the content in a variety of ways at a variety of times, which will give the content a lot of life.

Here are some methods:

A) Vary the player's vision
We can reduce the player's vision. This can mean things like day/night. It can mean things like fog, rain, etc. But in addition to global changes, we can also use local arrangements - forests, caves, interiors, and other topologies that get in the way. Add additional complexity such as flashlights, flares, different vision modes, and even spotlights from space ships or something... all of these will vary the player's vision and make the same content affect them in different ways. Limited resources in certain vision modes are another way to add stress to this equation.

We can also increase the player's vision in a variety of ways, such as "hunter sense", or sonar, or a number of other ways of overlaying added data onto the normal audio/visual experience. Completely non-visual inputs such as audio should be considered as well: a heavy rain can make it impossible to hear a growling mountain lion hunting you.

Suddenly changing the player's sensory ranges is also fun. The player opens a door or window and suddenly they can see quite far... and something five feet away can see you just as well. This can be more terrifying than stumbling into that thing, because it seems that much closer due to your long vision. Letting the player trigger these events is very rewarding.

Secondary inputs such as sensors, remote monitors, and so on are a big factor in some kinds of games - for example, using a satellite to observe the surface of a planet. Another thing to remember is that you can increase vision while decreasing control using glass windows, raised platforms, wire fences, and so on. Anything you can see through/across, but not easily move through/across. Giving the player an option to scan ahead at the cost of time/resource can be valuable as well.

B) Vary the player's control
Reduce the player's control. This can be accomplished with things like vertical arrangements - climbing, sliding, and so on definitely reduce your control while also screwing with your vision. Things like thermals, flowing water, and currents can actively drag the player along, which can be fun if your game is designed for it. In addition, trampolines, intermittent vents, rope, bungee jumps, and zip-lines can give the player the option to move in an unusual fashion if they like, which works well as long as that unusual fashion offers advantages but also forces content engagement (IE, a bungee jump into a pit with a huge, hungry squid at the bottom, or a zip-line to the crumbling tower at the top of an ancient facility).

Those are just the start. We can also offer fundamental movement modes that have restrictions built in, such as parachuting, gliding, sinking, skiing, etc. In order for them to remain explorative, the constraints on these are usually going to be that you can't go backwards, or that it costs resources to go backwards. That way you can still explore, you just can't explore freely. Alternately, these alternate modes could be non-exploration parts of the game while still exposing you to explore-mode content in a new and very constrained way.

There are also some ways to do optional control, where the player is allowed to do things, but knows there will be repercussions. For example, they can fly their space ship into the ancient ruins, but it's going to damage them and make the wildlife hostile. Or they can unlock all the doors at a security station... but anything on the other side will be able to get out!

Lastly, you can flat-out take fine control away from the player. For example, if the player accepts a mission, you can cut to them being on the quest location. This requires your game to have that as part of the core experience, to avoid making it feel overly forced, but the idea of being able to simply put the player in any situation you want is fantastic from a content engagement perspective.

C) Create content that varies/reacts to the player's vision
The content itself can play with the player's vision. An easy example is a building: no matter how close you get to the outside of the building, there's an interior you can't see, or can only see through specific windows. Something which physically blocks the player's line of sight but also guarantees some content within that blocking thing. Things like pop-up walls are also useful, as long as the algorithm placing them specifically guarantees something worth finding as well.

The content can fuss with the vision in other ways. Animals might have stealth capabilities or be flat-out invisible (at least to some wavelengths). Alternately, plants might glow and actually improve your vision. Glowing frogs, mist-spitting plants, and so on. A plant may explode with a blinding flash of light or a huge cloud of smoke. Vision is also not just vision: animals that growl, plants that chime, a facility might whine so loudly it makes you deaf, etc.

The content can also move to protect itself from or expose itself to visuals - digging into the ground, coming out during the day, only flying in the fog, etc. This requires some AI, but it can be very interesting, especially if the player can take advantage of those changes by lying in wait or planting sensors.

The last option is to have content that reacts to what the player can see. For example, monsters that freeze when you look at them, or take damage as you look at them. Plants that grow if you watch them. Animals that panic and run if you can see them.

D) Create content that varies/reacts to the player's control
The most obvious way to have content vary player control is to have content be big, so that the player has to navigate it. Buildings are the easiest example - not only will the player have to walk around if they don't want to engage, but if they do engage, you'll be in a set of rooms with closed doors. So that varies both control and vision.

Also, content can do any of the things talked about a few bits ago - trampolines, ziplines, current generators, gravity cages, and other things can be part of content. Plants that blast air at you to drive you away, animals you can ride, and so on. It's best if these things have both upsides and downsides and can be either useful or hazards depending on the situation. That creates a lot of good emergent situations.

Indirectly, content can affect a player's control by adjusting global parameters. For example, you can't fly through dangerous fog (fog is content), you can only ski on snow, you can gather jetpack power on atmospheric planets but not on airless ones.

There's also the seriously meta options, such as having a plant that sings and will make you fall asleep if you don't keep wobbling the control stick.

E) Engage
After all that, you still need to have the content matter to the player. The way the content interacts with movement and vision is only one facet of how it can engage with the player.

Most exploration game content "engages" with the player by waiting for the player to come up and harvest it. There are a lot of better options, but you need to keep in mind the feel of your exploration game: being too forceful with your engagement is generally not great. This is why the idea of hostile content is annoying: I don't want to suddenly be in a battle with a giant monster or a military drone. Changing the gameplay mode without warning is just annoying.

The trick is to simply give plenty of warning. Animals don't just attack, and even hunting animals can be detected in advance by the player, who will see them in the bushes or hear them growling. Let the player choose whether to engage, push past, or route away. Of course, the player's exact situation will determine their choices. A player that ziplines into the middle of an angry hornet nest is in trouble... but they chose to zipline in!

Other than that, I would recommend you make most engagement systems adjustments, sinks, or fonts instead of forcing you to change game modes. Adjustments are things that affect your play - for example, a gravity ball that draws you in, or a wall of glowing lichen in a deep cave.

Sinks and fonts adjust the player's resources over time, usually getting more severe the closer you get. Draining or regenerating health and power are obvious. If you arrange you game to facilitate this sort of thing, you can do a lot more - for example, signal boosts or interference. Frying your pikmin. Covering you in ever-more goo so you move slower and slide down slopes...

F) Vary and Hook
Once you have players engaging with your content, you can extend that by creating nuances. For example, modular cat-predators: they always skulk around hunting prey, but as you swap out their various limbs, you get different specifics. This kind of variation only matters if the players are engaging: varying the content is worthless if the player chooses to not engage.

State changes are great as well, since you can layer content states. For example, the player might be able to restore power to a building. The nature of the building and its content might change when you do this - but there's also an opportunity for other content to change/pop into existence as well. Animals notice the lights. Sentry bots wake up. The elevator into the depths starts working. A radio signal broadcasts and someone hears it.

Layering and varying content adds much more life to the same amount of content.

You can also add in hooks by adding story elements, NPC commentary, and construction opportunities.

The easiest hook is safe zones: if there is some resource the player needs to regenerate (electricity, fatigue, etc), you can make specific content locations the only ways to get those. The specifics and the surroundings really start to matter!

Finale
Whether you're manually laying the content out or you're using an algorithm, a bit more care has to be taken in order to do these things properly. How you arrange them matters quite a lot: the meat of this experience involves how various content and constraints combine.

IE, a building alone is going to be dull. However, a building at the top of a rock spire surrounded by air-blasting plants that push you away... that's more interesting. Partly, the player has to figure out how to navigate the challenge. Kill the plants? Throw rocks to pre-trigger them? Using a jetpack? Land on the top of the spire with your amazing skill? Or all of those options one after the other!

In addition to the challenge, the player is being affected by the mystique. The limited navigation and vision means the building at the top remains interesting and engaging until the player reaches the top. At that point, the building's variations (windows, locked/unlocked doors, content contained, outlying modules) immediately matter to the player and they have to soak that up all at once at short range.

Anyway, that's what I've been thinking about recently. If you have any opinions, let me know.

Monday, August 15, 2016

Exploration Play

For the past twenty or so years, I've been thinking about exploration games. I've created hundreds of prototypes and several tabletop games about exploration, so it still irks me to see video games that drop the ball.

Let's talk about specific techniques to make exploration gameplay fun.

For starters, flow is absolutely critical in this kind of game. Your goal is not to reward the player or keep them interested, but to keep them in their flow. Unfortunately, flow varies over time and all players are a bit different.

So 1) establish flow and 2) keep the flow flowing.

1) Establish Flow
Establishing flow is tricky, but to me a big part of it is letting the player smoothly adopt a variety of short- and medium-term goals, discarding and rearranging as they see fit. The problem is that most exploration games start off with "here's a three hour tutorial".

Well, here's three hours where there's no flow state.

Every time you interrupt the player unexpectedly, every time you tell them what to do, you're resetting their "flow counter". On the other hand, if they don't see enough implicit short- and medium-term goals, they can't start their "flow counter". So both are bad.

My focus when I create exploration prototypes is to create a lot of easy-to-grab short-term goals that lead into medium-term goals quite naturally. New players will grab at the obvious short-term goals and, in the process, learn medium-term goals.

For example, if you start up No Man's Sky, the first thing you'll notice is that there's a space ship. This is an extremely obvious short-term goal. The sparking engines also clearly show a medium-term goal: fix the engines. Debris, tall plants, glowing plants - these all give the player short-term goals and, in the process, they learn about resources and loot.

Unfortunately, No Man's Sky falls short in a number of ways aside from that. It takes a long time to figure out how to use resources, and it's easy to run out of power before you figure out how to restore your power. Inventory management is obnoxious and opaque. This isn't a tutorial failure: it's a fundamental design failure.

It'd be fun to talk about How I Would Have Designed No Man's Sky, but in the end the point is simple: don't have popups. Don't have a tutorial, don't have early-game achievements, don't have an integrated crafting menu or complicated fuel management.

Focus on having delightful short-term goals (glowing plants, chunky debris, space ship) and a variety of short-medium-term (mine-able obelisks, minute-long walks) and medium-term (ruins on a nearby continent, requiring 300 ore to upgrade) goals. Experienced players will automatically balance this stuff out with long-term goals, but newbies need this stuff to flow naturally and easily in layers.

2) Keep the flow flowing
"Flow state" isn't one permanent thing - players constantly shift gears, and all players shift at different times depending on their personal preferences and mood. Because of this, any game that focuses on keeping a flow state needs to allow the player to shift their play whenever they want to, and lower that barrier as much as possible.

The two pieces to this are opportunistic short-term goals and floating medium-term goals.

Opportunistic short-term goals are easy enough: while you're on a medium-term goal, there should be a variety of opportunities to do small things en route. For example, seeing and harvesting good resources while running along, or seeing a hazard in your way and having to route around it or endure it.

Be careful about getting too aggressive: the player should choose how deeply to engage with the short-term goal. Forcing them to fight or trapping them in a deep cave is just distracting. Those kinds of forced engagements can come at the end of a medium-term goal, though, as a finale.

The point is to let the players choose to do a few fast-cycle loops if they want to, because they may be wobbling towards the fast-cycle part of their flow.

Floating medium-term goals are the opposite. When the player finishes a medium-term goal, they'll choose the next medium-term goal based on a lot of criteria. One of those criteria is what they feel like doing next. So try to engineer it so they have a few very different medium-term goals. Basically, some that will push them to walk, some that will push them to fly, some that will push them to warp, some that will push them to build - whatever varied gameplay you have.

Coming up with a variety of classes of medium-term goal is critical to this. In general, I define a medium-term goal as something with several opportunities for short-term goals along the way. So you can set up your medium-term goals to allow the player to choose what kind of play mode they're going to enter and what kind of experiences they're going to have.

For example, many medium-term goals are about traveling for less than 10 minutes to a known destination. But others might be about hunting for a specific resource, one which can only be found in a particular play style. Other medium-term goals might involve setting things up properly to survive a new class of environment, or caring for a pet, or buying something from a distant shop, or anything else you can think of based on your available kinds of play.

As long as there's stuff to do along the way.

Allowing the player to fluidly "change bands" means the player can stay in their flow state for longer, since as their mood changes, they can change their play.

3) Long-Term Structure
Exploration games have a few fatal flaws, but one of the big ones is that they're typically crafting/base-building games. By default, neither of those styles of gameplay actually makes sense for exploration. Exploration features a random mishmash of results, while crafting requires specific inputs and base-building typically locks you down to a location.

Base-building is largely a solved problem: either allow the player to take their base along, or allow players to revisit their built bases quickly and easily.

But crafting is still an issue. NMS shows this flaw in spades.

Because launching into space requires about six different resources (worst case), that means every planet must have those six resources within walking distance at all times. This leads to planets all feeling the same, even if they have wildly different visuals.

There are some simple techniques you can use. First off, make basic movement rely on no more than one resource (perhaps zero resources). If the only thing required to get into space was hydrogen, great. Every planet can have hydrogen on it, perhaps in different forms. The rest of the resources can be radically more scattershot.

A fantasy exploration game might require you to eat once in a while, but you can eat almost anything. Every biome just needs to have something vaguely edible in it.

Another simple technique is to use categorized resources instead of specific resources. IE, rather than requiring iron specifically, you could use any structural resource. Rather than requiring plutonium, any energy resource will work. They can have different stats, but any of them can get your crafting off the ground. This means that rare resources can fill the same slot as common resources, just be substantially better in some way.

Moreover, this allows for transmutation recipes. For example, if you just need to have any structural resource, you can turn oil (a fuel resource) into plastic (a structural resource) using some kind of machine.

The idea here is that the player is almost never "stuck" on a particular resource. They may get themselves stuck by insisting on using a specific rare resource if they like, but the game never says "you can't build X because you didn't find any copper". You can substitute in a variety of materials instead, including converting unsuitable materials via some time-consuming process.

This means the player is free to explore. When they find Xenocite, sure, it's just another structural element, but the resulting stats are off the charts. Build an engine turbine out of this, it'll be able to withstand immense strain and therefore you can go ten times faster than the same turbine built out of iron. Same thing, radically different parameters.

This also means you can let the player be isolated. You don't need a universal market everywhere, you don't need every resource everywhere. Let the player feel like they're out in the boonies or someplace super rare and weird.

Construction is also easy to tie into this, if your game has more than simply crafting. Bases made out of many different materials will all feel radically different and have different parameters. Just remember to solve the "base is left behind" problem.

4) Create Meaning
Exploration needs to have meaning to the player in order to make it fun.

A) Make it gorgeous. If the player wants to take pictures, they'll want to explore. Don't forget the audio.

B) Connect it to existing meaning. NMS has dinosaurs and trees, both of which are familiar and carry meaning already. Their alien species also feel familiar, callbacks to things you've seen before. Similarly, many of the stories are vignettes that simply tug on existing meaning - IE, a terrified warrior asking if you'll help him run away.

C) Chains of content. You can create meaning by making pieces change over time. For example, helping person A will make person B attack you later, or whatever. This is easy to script, but randomly generated chains need to be done carefully because the player will quickly start to categorize them and their deeper meanings will vanish.

D) Personalization. Allow the player to customize things (recruit friends, build bases, etc), then subject them to a variety of threats that test fitness and pull the player into defending the weak elements. The player will automatically feel strongly about something they own, so threaten the things they own. Just... not on a timer. Timers will break their flow.

E) Multiplayer. Allow the player to share things with other players and make it seem amazing. For example, screenshots and videos should inherently vary from player to player so that any player should think they have something unique to bring to the table, even if they're a newbie. Of course, sharing blueprints or seeding other player's content are also good opportunities to draw players in. This creates a bevy of medium-term goals as players strive to create/replicate something amazing.

Anyway, those are my thoughts.