Tuesday, November 07, 2017

Building More With Less

In a "building" game, I always want to use fewer types of parts to build a wider variety of results.

I want the game to feel expressive, like the player can make a bunch of different things with a bunch of different goals.

For example, do you have a "gatling gun" component? Even if I am making a war ship, a "gatling gun" is an inexpressive element. It's going to be the same for everyone, take up the same space, do the same things in the same way.

Which is why you also have a "laser gun" and a "missile launcher" and a "sniper gun" and whatever other weapons you can think of... that's expensive. It takes effort to make them, space to have them in your game, and visual clutter to make them all selectable. Even after all that, they're still not terribly expressive.

Adaptive Elements

How about a system where you have a "gun" module, and then you can tweak the settings?

Change the accuracy, the range, the rate of fire, the ammunition type. To keep it balanced, you could use a points system - extra points in accuracy means less points for rate of fire!

If you allow for this, then players can change their weapon loadout to fit the role they want the weapon to fill... and use a lot of fine grain knobs to do it. As long as combat actually interacts with those stats, you've created a method for players to specialize in different combat roles using a very fluid, adaptive system. Depending on the metagame, players might start using unusual combos that canned one-off weapons would never have though of, like sniper missiles or hyper-accurate micro-range burst lasers.

If the settings reflect suitability for different roles in the greater game environment, they'll be great fun! Just makes sure your UI reflects their settings so the player doesn't forget what is what.

Soft Constraints and Constraint Systems

Rather than using a "points" system like above, it's better to use a soft constraint that ties into the greater game environment.

For example, each shot generates heat - the better the shot, the more heat. This is conceptually the same as a points limit, but since it leans into the rest of the world, other kinds of game concerns can affect it. For example, what about firing in short bursts and letting the weapon cool off manually? What about attaching extra coolant systems to cool the weapon faster?

In this case, the greater game system we're leaning into is heat management. This makes heat management a "constraint system", and those have to tie into as many different things as possible to make innovative and interesting builds possible.

For example, attaching "coolant modules" to the gun is extremely dull. It doesn't integrate with anything else. But if you have to actually pump coolant, now you have a topology constraint with a lot of possibilities. For example, maybe you want to run colder coolant? Now you need to build coolers. Is your coolant heating up as it moves between the ten things you're cooling? Hm! What do you do afterwards - vent the heated coolant out of the ship where it's likely to be spotted by enemies, or perhaps use it to pressurize living quarters? Run it around the perimeter of your ship to cool it and de-ice your wings? Use it as a low-grade propellant?

Depending on the scenario, the external parameters and concerns will vary - and the player's own ideas and goals will also cause parameters and concerns to vary.

You do need to make sure your UI can handle players grappling with these systems.

Carry and Produce

A related concept is 'carry and produce'. What we did in the last example was turn "heat" from a fungible number into a tangible good. Tangible goods offer a much more interesting challenge with more opportunities for fun constructions. This is especially true if two systems combine into a single tangible good - for example, heat combining with a specific kind of coolant into a single good.

While "heat" is simply a number, once we transform it into a complex good, it becomes both a challenge and an opportunity. Is it hot water? Glycol? Cool air? Liquid hydrogen boiling off? Each of these offers different specific challenges, but uses the same fundamental 'piping' mechanic. That same mechanic could allow them to be used in any other situation where either heat or that substrate is used: hot air becomes life support supply. Boiling liquid hydrogen becomes propellant.

This can be done with almost anything. For example, instead of generating "science points", what if you turn that into a tangible good - a science paper which is only converted to science points upon export? Now the science paper can be manipulated in tons of ways to make it more valuable.

Some players might specialize in quick-and-easy science papers for a trickle of science. Others might specialize in massive databanks to hold the papers until they are at the maximum possible size. Others might use supercomputers to refine the data until the science paper is small, but potent. Others might choose to generate science in different ways - often tied into other kinds of systems.

It's critical that the UI supports this - supports the player immediately knowing what is being carried and how it is being massaged. But if you can do that, you can create a wonderful opportunity for depth and expressiveness.

Changing Conditions and Triggers

One overlooked element in most construction games is changing conditions. Normally you just optimize for whatever the current situation is and that's that. About the only construction games with changing conditions are ones where you have to survive the winter, and that's often not pushed very far.

To keep using heat as an example: heat in an ice-cold winter is very different from heat under a baking desert sun is very different from heat at the bottom of the ocean or in outer space. Your initial instinct might be to simply make each base have a specific heat condition - this is an artic base, this is a deep-sea base - but that's something only beginners will find challenging.

Increasing difficulty is much more about the swing, rather than the baseline. Optimizing heating systems is more interesting when sometimes it'll be very hot and sometimes it'll be very cold. Designing a space ship that can fly through the atmosphere as well is more fascinating than simply saying "this is a space ship, that is an airplane".

In general, I think of three kinds of changing parameters, each of which increases in swing as difficulty increases.

1) Routine changes. For example, people going home for the night to sleep, or solar power only being available during the day. Combining routine changes can make for very fun results - for example, solar power is only available during the day AND at night a punishing dust storm rushes by, leaving an opaque layer of dust on everything. Now you have to have a setup that cleans solar panels or hides them at night!

2) Catastrophes. These are things outside of your control (although for game reasons the player may be able to trigger them). Fights. Plagues. Crashes. Winter. Holiday shoppers. Typically these are tests for how "disaster-proof" your design is.

3) Scheduled changes. These are things the player causes as their plans advance. For example, holding an election. Traveling to a new planet. Choosing to land. Giving crew leave. Refurbishing the facility.

In order for these situations to be fun, two considerations must be handled.

1) Soft failure. If the player falls short, they should be able to pull through with damage. This is also where beginners will start, so adjusting for failure should be something players can do manually, while panicking. For example, if a storm hits, players have to be able to order people back inside in order to weather it, and the storms should (at least at normal difficulty levels) not instantly kill anything caught out in them.

2) Programmable responses. The players should be able to trigger responses automatically using in-game objects. For example, allowing the player to lower landing gear when a particular sensor registers there's ground below, or automatically ordering people inside and barricading windows when a storm hits. These can be used by midlevel players to handle changes automatically, and by advanced players to create absurdly complex contraptions.

By the way, I am a big fan of moving parts - whole sections of facility that can move around. Normally this is implemented as full-scale facility elements being rolled around, and that's not a great solution because it's extraordinarily bulky. Instead, I recommend parts can fold up and unfold, allowing things to take up much less space when not in use.

An easy example of this: if you need to charge your laser using a big power cable, but also cool your laser with a coolant pipe, each can be folded away into a wall tile. Both can be folded away at the same time if you need to walk past. Then they unfold and fill the space as needed.

Anyway, those are my thoughts on base building. Use fewer parts for more expressive results by keeping these things in mind.

Let me know if you have any opinions.

Thursday, October 05, 2017

Difficulty

There's been a week-long explosion about people tweeting about difficulty. People seem to come down in one of a few camps, none of which is even vaguely similar to my own opinions. So let me make a big essay about it.

Difficulty is a very messy term with a lot of tangled-up components.

For example, some people say that some games can't let you skip difficult parts or make them easier because those difficult parts are teaching you some aspect of the gameplay you will need. The part you're having a hard time with is hard because you haven't actually learned how to use the double-jump or balance your theme park budget or something.

My rebuttal to that is: who cares? Who cares if a player doesn't get some aspect of your game?

The answer is: the problem with "cheating" (or super-easy difficulty modes) is that most players will end up sliding through your game without enough friction. They won't have fun, because there's no traction to engage with. Super Mario is a lot less fun when you can just fly through every level as Shinypants Mario. Subnautica is a lot less engaging if you have all the modules at the start and can just build anything and dive as deep as you like. These games aren't designed to really be played that way, so there's no player engagement if the player tries to engage that way.

If an RPG is too easy, the battles still consume time but don't have any depth or payoff.

This is a valid concern. Your game is designed to be played a certain way. Some players might be better or worse at that kind of play, but how can you pull them up to the difficulty level where they'll enjoy your game? Is it possible? Maybe this player will never learn to double-jump or balance a theme park budget. Maybe they literally can't for some reason. What should you do then? Just sneer and say 'git gud'?

Rather than sneering, some people try to solve this with adaptive difficulty. If the player fails too much, the game becomes easier. If they succeed too much, the game becomes harder. The problem with this approach is that players have different concepts of what 'too much' is, and if the game interrupts their flow at the wrong time, it's considerably worse than simply being too hard or too easy.

The New Super Mario games are a good example of that. I like having a hard time with these games, which is good, because I suck at them. I tend to die a few times before I come even close to beating a level.

Just when I'm getting into the groove, the game goes "BLOIP!" and pops up a bright, shiny thing that follows me around begging me to use it to beat the level as Shinypants Mario. It's "optional", in that I can keep trying without it. But it's there, and it's the game telling me that it has decided it was mistaken in asking me to beat that level, it's clear I can't beat that level, and I should just skip it.

That's incredibly deflating. The game judged me, and it decided I shouldn't be playing the game like everyone else. I should just skip it.

So I did.

After the third time it appeared, I put the game away and never played another New Super Mario game. I couldn't keep interested when it kept derailing my groove just when I was getting into it.

That's a pretty clear example, but I'll constantly adjust difficulty on my own, regardless of what any game thinks. I might decide to take suboptimal characters into battle because I think it'd be fun to win with them, specifically. I might decide to play as a pacifist. I might decide to climb that clearly-unclimbable mountain. I might throw pebbles at an enemy until it falls over instead of shooting it just because it's fun. I might beat Lavos with a mop.

How will the game interpret this? How will it auto-adjust my difficulty?

I can tell you: it gets scrambled and completely drops the ball. I haven't played an "auto-adjusting difficulty" game that didn't actively annoy me by adjusting it wrong, and the first mod I install is one to change how that works.

Phew.

So what's my opinion, in the end?

I think most people's concept of "difficulty" makes a big assumption: it assumes that you, the developer, should dictate how players play your game.

I understand that you, the developer, have built the game with the intention that it should be played in specific ways. And I understand that there are limits to how far that can stretch. Your puzzle game can't be made easier, because the puzzles are the point. Your score attack arcade game can't have a 'tourist' mode, because that makes no sense.

... Except puzzles are not the point, and tourist modes make sense.

What if a YouTuber wants to put together game footage? What if someone wants to play it with their toddler? What if an expert just wants to try one particular thing over and over? What if my controller broke and I'm stuck trying to control it with a keyboard? What if I'm testing a mod? What if I'm teaching a friend?

I think it's fine to let players play however they want.

Recommend specific difficulties, sure. Your intended play style is probably the best one, in that it's balanced and has good pacing. But if I want to short-circuit your game and play it in a dumb way... why not let me?

The games I keep coming back to are the ones with the best options menu. Kerbal, Space Engineers, Skyrim (via mods). Sometimes I completely disable core systems. Some days I play them one way, some days another way... and sometimes the game isn't balanced and the pacing is screwed up. That's OK.

I made it that way on purpose.

Because now it's my game.

Monday, July 24, 2017

The Most Fundamental Fundamental of Game Design

Over the past few weeks I've thrown out dozens of prototypes and agonized over some my current projects. The problem? They're not fun.

There's a lot of talk about what makes for good game design and bad game design, but let's get down to what a game fundamentally is.

In concrete design terms, what are most games?

They're a bundle of systems we've all seen before.

You can boil down any game to a few simple basics that get reused over and over. This reductive analysis comes in waves, each time a slightly new view on the medium, a slightly different reductive take. Games are about learning skills. Games are Skinner boxes. Games are slot machines. Games enforce a magic circle.

While developing a game, we also tend to fall into this reductive analysis. We see the game before it's polished and we're too familiar with it to feel the impact of the assets. Since we're not playing it in the same way a player does, our view of the pacing is going to be wrong, too.

Like a movie editor in the guts of a reel, wondering whether to cut from this to that. Cut on this frame or this frame? Now I can't even tell if this shot is any good, I've seen it too many times.

Every medium is like this. There are fundamentals. Everyone argues over what they are and how to use them. But any way you slice it, while you're neck deep in creating the project, you end up staring those fundamentals in the face and second-guessing yourself.

Your RPG is boring and bland, just an oatmeal mush of cities and dungeons and level progression. To you. While you're in it.

And maybe it's bland to everyone else. You can't tell.

Just as the problem is universal to all forms of art, the solutions and workarounds are also universal. Anything a movie editor does, a game dev can do. Anything a writer does, a game dev can do. From small things like stepping away for a few hours to big things like making four different versions and having random people try all four.

But the biggest thing to do - in all forms of media - is to be trying to do something.

Too many people agonize over whether their fundamentals are "on target" without even knowing where they're aiming in the first place!

When a movie editor agonizes over cut A or cut B, the solution is to know what fits the movie better. What fits the story, the pacing, the characters, this exact moment?

When a comic artist hesitates over a page, they stop and think. "Maybe I should try to focus on page flow here to pull the reader back in." "These three panels of this person's face need a cutaway to their hands to keep things flowing." "This page should be spikey and fractured because the hero is on the ropes." "Maybe I should draw a few thumbs and ask someone which one feels loneliest."

This is obvious and well-understood in other forms of media, but in games it is often overlooked.

Is part of your RPG boring to you?

Well, what are you trying to accomplish with the boring part?

It isn't just a matter of rebalancing or decorating. What is your RPG supposed to feel like here? Why? Are you using the wrong approach? The right approach, but too much or too little? What other facets affect this and might be souring it? Level design? Story progression? Character design? If you have design pillars, what went astray?

By considering what you're aiming for and what the player should be experiencing, you can figure out which approaches have promise. You can get a grip on what you think is "boring" and pull yourself out of a featureless plain of potential options.

... it's the same in any medium.

Friday, June 16, 2017

Level Design Theory

Mark Brown released a new Game Maker's Toolkit, which you can find here. This is largely a response to that video.

The basic premise is that the "Nintendo approach" to level design is to take one core challenge and follow the same set of progressive difficulty enhancements: safe introduction, slightly less safe thing, unsafe thing, then a few dozen twists to change the challenge somewhat.

He uses the design of Donkey Kong Country: Tropical Freeze to offer a counter-example, where ideas and themes are largely mixed together in clever ways. For example, sawblades don't just threaten you, they also carve out platforms. This level has leaves and horns, etc.

... Those are the same design philosophy.

There are differences in implementation, sure. Mostly because the mainline Super Mario games are extreeeeemely tired.

Tropical Freeze seems to be more creative in their theming, using a broader variety of themed challenges and better spectacle setpieces. This is probably because they A) have better technology and B) aren't exhausted and tired like the mainline Super Mario games. Other Mario games like Paper Mario, Mario Galaxy, and Mario Sunshine tend to have more creative levels with strong theming - comparing their best levels to Tropical Freeze's seems more evenly matched, with levels where island rise from the water, exploding volcanoes, collapsing buildings, and so on being far more common.

It may sound like I think the video is baseless, but I don't think that's true. I simply think he's comparing bad and good implementations of the same level design philosophy.

It's good to discuss pacing, and the limits of theming. Unfortunately, that's not how the video was pitched, at least not to my ears. It sounds like he's talking about things "Mario doesn't do". Mario doesn't do them in the mainline games because those are tired, not because they're not part of Nintendo's arsenal.

I'm not arguing that the basic idea of themed rising challenges mixed with spectacle is good or bad. It's one approach, and it's a fairly well-understood and robust approach. There are lots of other approaches with other priorities, and they're not mutually exclusive: an open-world game would have a hard time sticking to this formula, but they can certainly use the formula as a foundation to pace the player's entrance into a new area with its new themes and challenges.

Monday, June 12, 2017

Base-Building Games and Worlds

Let's talk about fairly advanced game design topics for base-building games. Games like Rimworld or Dwarf Fortress or Evil Genius or Minecraft or - in this case - Oxygen Not Included.

Nearly every base-building game has some kind of progression. You start with the lowest-level stuff, and unlock higher-level stuff over the course of the game. For example, you typically unlock better methods of heating and cooling your building, or better crops, or advanced building materials, or all three.

The question is: how do you unlock them?

There are a few basic unlocking methods, and we can show them by example.

You want to build a fridge/food storage room in Oxygen Not Included. At the beginning of the game, there's nothing like that. So what do you do?

1) Research a fridge.

2) Build your fridge room in a part of the map that's cold.

3) Scout around for cold-creating plants and replant them back at your base.

4) Use the physics of gases to create a carbon dioxide trap, which is considered a sterile environment by the game.

5) Evade the question and micromanage your food production/create pickled foods that can be stored on a shelf.

There is no "right" solution: which tactic you'll take will depend on your goals, your resources, and your world map. This makes for a very flexible, deep game, so it's worth examining these in detail.

1) Point-centric solutions involve spending time and resources on generic "points" to unlock a new method. This is almost always a research desk, often one with multiple tiers. For example, a fridge requires a tier 2 research desk in ONI. This is a very typical approach and pushes the player to make a "high functioning" base that has enough spare effort to build up those points. Unfortunately, this can backfire: once a base is high-functioning enough to spend time on research, you will need to introduce new challenges and complexities to keep the player struggling. Typically this is done through ever-increasing supply chain complexity with ever-increasing manpower demands. All told, this approach focuses on building a base that can function smoothly and efficiently.

2) World-centric solutions involve building facilities in parts of the world that fit your needs. This is often a random biome situation, which means that the player will examine the regions around each new base and figure out what biomes can be exploited. In other situations, this might be non-random biomes - for example, if you build mines at a certain depth in Minecraft, you know you'll get slimes. In some cases it's sort of halfway between the two - for example, it's technically random whether you have an aquifer below you in Dwarf Fortress, but you're told up front and it's extremely common. Anyway, world-centric solutions push the player to expand their base and create satellite facilities, and make rapid transit/cargo systems valuable.

3) Scout-centric solutions involve going out into the world in search of small amounts of specific resources. In terms of gameplay pressures, this is similar to a points-centric approach: is your base running efficiently enough to send people away? A few notable differences: points-centric is predictable and not random at all. Preparing resources for those that will go scouting is often more expensive than feeding the researchers. Monitoring the explorers and clearing their path eats more player attention than letting researchers research. Also, the resources found in the world are typically limited but cheap to deploy, unlike the unlimited but expensive unlocks from a research base. Having both a scout- and points-centric solution to core problems means players can weigh a variety of tradeoffs and make a choice unique to their current base instead of always having a best solution.

4) Physics-centric solutions involve constructing things such that the base generates a solution based on its layout. For example, in ONI, carbon dioxide sinks below oxygen. It's relatively easy to create a carbon dioxide trap by simply laying your base out properly. This is more commonly seen in "dungeon-builder" games, where various monsters can cause various effects and you can level them up or get better monsters based on what neighbors they have. These are typically "high skill" solutions, but it's risky: be careful not to allow them to become the dominant strategy, or advanced players will not need to take any other approaches.

5) Evasion solutions allow the player to simply not take that path by having a build that doesn't require it. You can play almost any base-building game without a fridge if you orient your food chain around not needing one. This allows players to develop radically different kinds of bases, and is a highly recommended option to include.

These five approaches, used in tandem, allow for amazingly deep gameplay that never repeats. When I saw the tech tree in ONI was so sparse, I got a little annoyed... until I realized how diverse the alternate approaches were. I don't think ONI's balance is quite right, but the ideas are all there: competing methods to get the same result, meaning each base has new and unique tradeoffs.

This is especially critical when there are timers involved. If you have infinite time, a sub-par approach will just take a little longer. The timers are necessary to produce stresses, although obviously it's best if they can be tweaked for different kinds of players.

As an example of where I don't think ONI does it quite as well, let's talk about the most brutal timer I've seen in a while: the oxygen in Oxygen Not Included.

Your people breath a lot of oxygen. Huge amounts. The main method of creating oxygen involves burning algae, a substance which seems common when you get started... but as your rate of consumption increases, you'll suddenly find you've run out. This scales with the number of people in your base, obviously, which means as your base expands oxygen becomes more of a pressure.

1) Technology. Since this highlights a smoothly-functioning base, you'd expect this to be a "set up oxygen with your algae, then research a replacement while you can still run smoothly". However, the technological solutions are pretty rough. One involves inefficiently burning a rare resource (slime) to get algae. Another involves burning a limited resource (water) to directly get oxygen. Another involves generating large amounts of poison oxygen, then converting it into regular oxygen. These are all a bit complex and wonky, but that's part of the fun.

2) World-centric: there are slime/algae-rich biomes. Most bases start with one nearby. However, there is no biome which actually generates algae or oxygen, so those locations will get mined out. Technology levels unlock more options, but they feel anemic. There are areas of the map which have oxygen in them, but none have enough oxygen to matter. There are special stones which emit oxygen, but it seems they are never fully contained, so within a few days they have all burned out everywhere in the world.

3) Scout-centric: about the only oxygen-related things you can scout for are slime puffers. These (slowly) cycle poison into slime. Normally, that slime re-emits the poison, forming a permanent cycle. You can painstakingly herd them into farms and use alternate poison sources to create slime, but herding them is extremely laborious and each one doesn't even seem to support a single person's breath after all the conversions are factored in.

4) Physics-centric: because your team can hold their breath and will walk to where there is oxygen to breath, it is possible to save on oxygen generation by only filling the top layer of your base with oxygen, reducing the loss of oxygen through secondary costs such as being absorbed into rock or lost through an airlock. This is, however, marginal. I would love to have a physics-based solution for creating algae, or even directly creating oxygen.

5) Avoiding it: your crew can breath poison, at least in this update. They really don't like to, but they can. Poison sources are extremely easy to find, to the point where avoiding them is a big part of the game. Instead, embrace the filth and you don't even have to worry about it.

I hesitate to offer "solutions" to what I consider to be a weak game element. After all, this weak game element is the core timer for the entire game, and there are a number of interesting routes you can take... it may be that small balance tweaks would be enough to satisfy me. But with that said, let's talk about how I might have chosen to set this challenge up.

In my magical imaginary version of ONI.

1) At higher tech levels, I think we would be able to exchange time, space, work, and condition management to create an alternate algae or oxygen source. For example, what about an "algae box"? Needs irrigation, a dense carbon dioxide atmosphere, and a high temperature. With effort, you can now grow algae - but it takes carefully building your base to do so. How about an even more advanced science for creating oxylite out of massive quantities of hydrogen or natural gas or something?

2) World-centric. I would like a biome that generates oxygen, water, algae, or slime in quantities high enough to live off of. Right now we do have steam geysers, and water can be turned into oxygen, but it requires very advanced tech. We also have slime biomes, but they don't produce slime. Puffers live in them, which can give the illusion of slime production, but no slime is actually being created. Perhaps a coral biome which slowly emits oxygen? Cutting the coral destroys the oxygen-emitting elements, so you just have to live there, or perhaps create a long gas pump.

3) Scout-centric. I like the puffers. I want to be able to tie a rope to them, or maybe stuff them in a sack, so they can be moved into farms more easily. I also think the puffer's rate of poison-eating should depend on the density of the poison in a very big way - if I can get them into dense clouds of poison, I want one puffer to support at least three people's breaths.

4) Physics-centric. I would like physics methods for creating slime, algae, or oxygen. Perhaps something like "boil poison water to get slime" or "pure water flowing through dense natural gas turns into algae" or "plants turn carbon dioxide into oxygen". Not sure why that last one isn't a thing.

5) Avoiding it. Right now the only method for avoiding oxygen consumption is to breathe poison. I can think of three other ideas. A) Make building a base with a low headcount viable. B) Oxygen booths which don't emit oxygen, but can be visited when you need a breath. C) Breathing poison or some not-quite-oxygen mix simply causes their learning to shut off - no skill growth, no research, maybe a stat penalty.

In the end, I like ONI.

I don't think they used this "five approaches" technique on purpose, but it's worth thinking about the best base-building games you've played, and what you enjoyed about them. It's certainly worth expanding the options within your own base-building games: the cost is typically much lower than you think.

Anyway, those are my thoughts. What are yours?

Tuesday, June 06, 2017

Structured Open Worlds

I really like open worlds, and games that let you play them in lots of different ways.

A lot of people make fun of the idea, and talk about how bland these worlds are. Well, that's worth talking about, too: what makes those people think these worlds are bland? Can anything be done about it?

Let's focus on the structure of open worlds, because open worlds are the only things that have this structure.

What's so special about it?

Well, it's all about loose-weave challenges.

In a linear game, the challenges are all carefully braided together. You are swept along at the pace the game allows, in the directions the game allows. On the plus side, that gives you a much tighter experience, which is why a lot of people probably feel the open worlds are bland. The loose weave doesn't intrude as aggressively.

In a generated open-world game like Minecraft, the challenges are largely unwoven. They don't really lead anywhere or connect in any meaningful sense, it's just a bunch of random things near each other by chance. This is too loose for my taste, since it's impossible to plan out a mission profile. It always devolves into a resource hunt, at least for me.

With a loose weave, you get clusters of optional entanglements. They are similarly themed and connected in meaningful ways, so you can immerse yourself into the region, plan out a plan, and understand the sorts of experiences you're likely to get while you're here.

To be crystal clear, let's give an easy example: the starting town in Skyrim.

In a linear game, the starting town would be rigidly woven together. You would be drawn into the story of the shopkeeper and his sister, the blacksmith and his family and the survivor from the dragon attack. They would have meaningful dialog and some touching moments, and at the end of their arcs there would be strong resolutions before you moved along to Whiterun.

In a generated game, a town serving the same purpose might exist, but it would be occupied by randomly generated inhabitants. There wouldn't be a strong sense of theme or progression. Quests, if there are any, would be limited largely to fetch quests or kill quests. There would be no sense of community or feeling that these people actually live in a town together.

In a loose-weave game like Skyrim, the characters are all defined and feel like they live in the town, but their plot arcs are left loose and unresolved. If you do their missions, at the end they say "huh! Funny, it looks smaller than I remember!" and that's that.

Obviously, this isn't as emotionally affecting as if they were tightly written and had proper character arcs. But because it is loose, the player can engage in a lot of different ways. Instead of doing the main plot, the player can choose to rob or murder, settle down and smith for a while, sell wildflowers to the shopkeep. With mods, you can try to recruit or date the various villagers, change and upgrade their houses, see if they survive a monster attack, defend them from a monster attack, be regarded as a bandit by them, and many other kinds of interactions.

To me, the replayability of these worlds is key: you're not talking about things the player "might do", you're talking about things the player will definitely do as they replay the game over and over. Mods are very useful here, since the player can change which mods are installed, but the fundamental loose-weave framework supports those mods by providing a foundation of sensible world design.

...

There are a lot of details to discuss. For example, each piece of loose-weave content does have to be woven, linked to other content. They also have to be clustered by theme and pacing, so the player knows what to expect and can choose when and how to engage.

The weave also has to be made of "playable thread" - these characters and buildings don't just exist to serve a plot element, but exist as physical and social objects in the game world. This allows the player to engage with them in any way they please. Ideally, the way the threads are arranged will produce lots of interesting challenges for a player that wants to try various kinds of play style. You have a hard time robbing the village shop because both the shopkeep and his sister are standing right there, as opposed to a shop in Whiterun where there's just one person and a shop full of corners you can abuse to hide from them.

The deep strength of this approach, to me, is that it creates a world I can be in. All the people and places make sense and are on-theme, from a bucolic little village to craggy abandoned forts on a mountainside to spider-infested swamps to an ancient town cut out of the rock itself.

This means that any thread I encounter leads to other, similarly-themed threads. If I find a bandit-infested ancient ruin, I know there will be other, similar challenges down the road. If I find a corrupt policeman, I know I'll face other corrupt individuals and those suffering from corruption if I keep moving forward. If I find an ancient barrow full of screeching skeletons, I know I'll find more of them. Moreover, for all of these things, I know I'll find some core element that "powers" them all.

This works both large and small. On a large scale, I get familiar with Whiterun and quickly learn that the "core" is the yarl. All of Whiterun's characters and buildings share a theme that is guided by and inspired by the yarl. On a smaller scale, I find a bandit encampment has a progression to it, too, ending with a bandit leader and their simple plan to rob travelers.

And it all makes sense. The yarl acts that way for a reason, so all his town acts that way for a reason. The bandit leader robs travelers because you're near a major road, and therefore that plan makes sense and all the bandits hanging around here make sense.

If you juggled the yarls around and put the corrupt boy yarl into Whiterun, it wouldn't make any sense. The center wouldn't hold. Similarly, if you stuck the bandits in a swamp, the player would raise an eyebrow at the supposed "heavy traffic" they're raiding.

This isn't simply an eyebrow-raise, though. Without the core, the player won't feel that the threads are all reliably on-theme. They won't want to go to place X, because it's just a bunch of random nonsense.

I can't overstate how important this context is. These are worlds which make sense, at least to some degree. They hold together, and as you drill down into them, you find some reasonable reason why things are where they are and do what they do. These reasons radiate out, so you know roughly what you're in for if you decide to chase down a random thread you've found.

...

I kind of rambled, here's the summary:

The loose weave of an open world allows me to approach it in any way I see fit, including ways that are not part of the main plot.

The weave is organized in patterns that make sense, and if I follow a thread I will find more, similar threads that all make sense together.

Replayability is key: the loose weave responds differently when you play with it in a different way, and a player will probably play it a dozen different ways.



Can this be generated randomly? I'm not sure, but replayability would go out the window just by definition.

Can it be made "flavorful" for the folks that think open worlds are bland? Probably, if you can make them adaptive: a lot of these worlds are very static, which I think is the heart of their complaint. If there were big events that permanently changed things on a really deep level, I think that would help. It would also be a lot harder to program.

Them's my thoughts!

Sunday, June 04, 2017

Green Energy and Actually Being Useful

There's a lot of noise about the Paris Agreement these days! Dozens of mayors across the US have pledged to adhere to the goals of the agreement anyway, and I figure a lot of them probably don't know some of the details of implementing a green energy solution.

Here's the three points I think a lot of people miss:

1) Green energy is getting cheaper all the time, but don't forget that you actually need to see if it's working. Unmetered systems are often installed wrong and are basically a waste of cash. Especially for large systems, make sure monitoring and emergency alerts are part of the spec!

2) A lot of people are upset that green energy doesn't produce on a perfect schedule. For now, there's plenty of low-hanging fruit: green systems can supplant normal power grids when they're working, and the grid can fill in when they aren't. Later on, when you have peak green energy above your power usage, you can start thinking about complicated things. That's not any time soon for most of you!

3) There's obviously no space for a ten-acre solar farm in the middle of New York City. Your green energy installations will have to work within the city footprint. That mostly means rooftop installations. Most rooftop installations are smaller, and therefore your incentives should be aimed towards small installs. Local cooperatives and programs already exist in every major city, look yours up and chat about their successes and failures.