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.

Friday, April 28, 2017

Obsessive Worldbuilding

I regularly see people talk about worldbuilding best-practices, typically with a warning against simulationist or overly detailed worlds.

The idea is to have interesting stories to tell in that world, right? So focus on that, rather than endlessly detailing how many centuries ago the elven court left for the high hills.

There's a few things to talk about here. The first is:

Yes. That is good practice. To me, the most critical thing about a world is how well it supports on-theme stories. That said...

Obsessive, detailed worldbuilding is fine.

We're talking about worldbuilding as the process an author goes through, not as the world is revealed to an audience in the final product. Obviously, including lots of dumb details in the final product is bad writing... but those details aren't necessarily bad worldbuilding.

One reason to worldbuild is to experiment with the boundaries of what's possible in the world. When developing a world, it's often unclear what the unique elements of the world allow. If you have a special kind of magic, or an unusual technology, or even something as simple as just a slightly deep dive on a particular social issue, it's often unclear where it will lead.

So you explore it. You detail out all the things that seem interesting and unique about this world. In the process, you realize there's something unique about the way this culture evolves, or an interesting take on the theme of family, or whatever else you can dig up while you're rooting around.

Filling the stories you tell with details nobody cares about is bad writing. Similarly, sticking to a fiction you've invented when you can replace it with something more powerful is bad writing. But those are bad writing, not bad worldbuilding.

When some obsessive worldbuilder shows you a ream of notes on the world they've invented, they're not showing you a finished story.

Maybe that's not how you work. Maybe you don't need to explore those ideas, because you already know where you're going to go 100%. It's a different process, but one doesn't invalidate the other.

Like a cartoonist with three pens talking to a painter: the cartoonist doesn't rag on the painter for their endless paint supplies and brush variants. It's understood that the two have completely different approaches.

Sure, the painter might suck.

The cartoonist might suck, too.

Another reason to worldbuild is to fill up the author's "working imagination": to make the world feel real to them. Some make the mistake of thinking that the notes they take can give someone else the same "working imagination", and then they get yelled at for misunderstanding how writing works.

... That's not writing. That's worldbuilding. I'm sure they regret bringing you into their process.

The next time you see someone excitedly building a world in a way you don't like, consider that they're searching their world for new ideas, new variants, and trying to leave a vivid impression in their own minds.

Tuesday, April 18, 2017

Wondrous Random

One of the problems with generating content for games is that it always feels prosaic and dull.

So generative games are seeded with wondrous details. The generative content is used as endless filler.

Let's talk about wonder.

It's certainly possible to generate wondrous things. Here's a twitter bot that generates endlessly wondrous planets.

But these aren't suitable to put in video games. The biggest issue is the lack of interaction: a video game's strength is interactivity, right?

Let's consider sci fi, since I'm a sci fi nerd. So let's talk about a few wondrous moments, whether they're interactive, and whether these moments could be generative.

When I considered wondrous moments, I realized they are all either introducing us or bidding us farewell. They are transitions. They are exclamation points. They are a hello or a goodbye.

For example, a rocket launch is amazing. It's wondrous to launch a rocket.

But if we show every rocket launch in a game, the player will get truly bored no matter how pretty it is. See Mass Effect: Andromeda for details.

Instead, we would focus on the rocket launches that take place during notable transitions. When we are saying goodbye to a beloved planet and hello to the stars, that's when we put in a loving shot of the rocket launch. Even though the player has undoubtedly seen a million rocket launches in their life, this moment is wondrous because it comes at the right moment. Just when we're saying goodbye, just when we're saying hello.

Obviously, there are also things that are rarer. Ancient obelisks. Forgotten planets. Derelict space ships. Strange aliens. The sight of your ship being split in half while you're inside it.

These also have the most impact if they happen when the player is saying hello or goodbye. Timed poorly, these amazing things will feel as mundane as having to shut off your alarm and get up for work.

As an example of this, in Mass Effect you spend a lot of time discovering new planets. It's incredibly boring. Discovering new planets is boring! ... because it's part of your daily tedium.

On the other hand, in Stellaris you inevitably discover another alien star nation. This feels surprisingly powerful, because the game leads up to it with popups about how there's no intelligent life even though you're searching for it. Things are just starting to slow down for your star nation, you're ready for a change, and then BAM - a new civilization calls. And then another and another!

There's not much fanfare in terms of selling the illusion. A few lines of text before, one extra line of text afterwards. But because it happens at the right time it feels thrilling. Say hello to a new era!

Well, half the time the pacing is off. It's not a perfect game. But when it works, it works - even without the majesty of long edits and low camera angles.

Later on, discovering a new species feels dull and pedestrian. You're already in that era, and there's no transition happening, so it's dull and pedestrian.

So... let's discuss some techniques we can use to make this stuff shine.

Understanding the Phases of your Game
Rather than discussing how to generate wondrous things, the critical thing is when to generate them. By guiding the player through distinct chunks of game, you create moments where wondrous things fit, and even mediocre wonders will play well in those moments.

The difficulty is in making the chunks feel sharp and clear. For example, in Mass Effect you might go visit the Citadel and spend three hours doing side quests. This is a phase. But there's no "punch" to the beginning or ending of the phase. Mass Effect does play a little video of you pulling out of space dock, but it's perfunctory. It has to be, because the staging isn't heavy enough for the player to put up with more.

How can we build up these phase as things that feel real and heavy?

There are two factors here: the construction of the phase and the transition moment.

Constructing the Phase
The biggest things that add weight are events and characters tied to the specific phase, with a focus on them being left behind when the phase changes.

For example, if it's a visit to The Citadel, you can have the player solve various problems... but have the characters wait on the way to the docks to wave goodbye and say thank you. This doesn't interfere with the player - the player can just run right past - but it does make the player realize they're leaving a place that they've affected.

There are plenty of other, heavier ways. For example, the player knowing they'll never return makes those goodbyes more intense. The player knowing the place is about to sink into a fiery magma pit also punches things up.

Adding play on the exit is also valid: in order to get off-world, the players have to fight through the local thugs and decouple the dock lock-down locks. When considering where to put these kinds of fights, the answer is "before the wondrous thing" - so if our wondrous thing is the launch, then we want the fight to happen before launch, not in space.

If you're creating a linear game, this can all be added in manually. If we're talking about generating content, it's clear we have to generate these heavy elements. The wondrous launch isn't the thing we have to generate: we have to generate the thugs and the teary children waving goodbye and the battered old robots throwing flowers.

We have to generate the context. The meaning.

This is something people talk about a lot, but I think they generally discuss how to create long chains of content. Our focus is different: we don't need complex, evolving narratives. We need short, punchy narratives that fit within this phase of the game and have a clear "goodbye" state.

You Say Goodbye, I Say Hello
Transition moments can be on the "goodbye" side or the "hello" side, and there can be scenes between those sides.

For example, when we leave The Citadel we can linger on our ship going through the relay and let the weight of our passing slowly roll through us. Orrrrr we can show an exciting shot of us approaching a new planet, slamming aside the purple clouds as we burn down on a re-entry.

But we can't show both.

I mean, we do show both. But only one will count as wondrous. The other will count as just a long shot.

Which one do we focus on? Well, which phase is heavier? Is the phase part of a longer chain of similar phases?

For example, leaving The Citadel is usually not a huge deal, because it's a hub world and you visit it a lot. In general, goodbyes are going to be weak from places you're revisiting... unless it's the last time you'll ever visit them. The last goodbye from a hub world is extremely strong.

Similarly, if you are leaving a world exploration phase and immediately entering another world exploration phase, the goodbye is going to be weak and you'll want to play up the new elements with a strong hello.

In theory.

Either way, it's probably best to pad some time between the goodbye and the hello. In a video game, this usually consists of world map navigation, although that's less than ideal. Useful non-phase activities such as party chatter, inventory management, and so on are probably better.

Repeated Majesties
Whether you're generating them or seeding carefully-created content, you're going to have some kind of amazing thing in your universe. You'd like it to not get boring.

An example of this is the relays in Mass Effect. Ancient technology that lets the folks travel great distances without much effort! Amazing!

But in Mass Effect they quickly become so mundane you just want to skip any scene involving them.

Why? Because they are mundane. They are part of the ordinary play of the game. They are not at a start point or an end point. They do not say hello or goodbye. They just happen over the course of your day-to-day affairs.

That's fine, to an extent. Not every encounter with them has to feel magical. But we want the player to be aware that they're playing with something potent every day. So we should try to tie our transitions to them whenever we can. Rather than showing a rocket launch, we would show a relay launch.

They become a "staple wonder", used whenever we need a wonder but don't have any specific wonder in mind.

The issue is that you only have so much space for these. For example, our ship is, itself, a staple wonder. Loving shots of our ship are also a major repeated theme. But is there room for both the ship and the relay? It'd dilute the shots if you played up both the ship and the relay in the same scene: wonders need to be punchy.

There are plenty of times when the ship can be used and the relay can't... but are there any times when the relay can be used but the ship can't?

These are the questions I want writers and devs to ask themselves when they're designing their universe. Not "are relays cool/plot-important", but "when we show cool stuff with relays, are we getting in the way of showing other, more important cool stuff?"

Please note, generative elements can work here just fine. For example, the "deep monsters" in Dwarf Fortress could easily be re-used in different games rather than regenerated from scratch each time - until you defeat this one, you won't get a different one.

Epic Generation
OK, OK, what about actually generating epic, wondrous stuff?

Well, there's a few categories of epic stuff, and presumably they'd be generated with different systems.

For recurring touchstones such as "your awesome ship" or "the bloodthirst armies of Throckwoodle", those are likely to be specified by the dev, then slotted in as appropriate. As discussed, "generating" those is more like generating a reason for you to use them.

The idea of generating some amazing scenario is also appealing. How do you generate an amazing scenario?

Well, that's a book on its own, but in general you have to remember to make the "hello" connect to the play. The deeper the connection, the better.

In general: the hello needs to tell the player why they're here.

For example, let's say you roll the dice and come up with a pirate base on a mist-covered moon. The wonder is the mist-covered moon - it feels still and epic. But the players aren't here for a mist-covered moon. They're here to tangle with the pirates.

How do you set that up? Well, you can show a shot of the pirate base within the mist, or pirates on motorcycles in the mist, or whatever. You can have an event where the pirates burst out of the mist to capture or ground the players. There's a lot of options: a battered merchant ship half-lost in fog, for example.

These are not too hard to generate, because you can largely just use category matches. The fact that it's a foggy moon is not important to the algorithm: it's just considered "MASK category GRAVITY FIELD category", and so it would have the same set of options as if you were on a smokey volcanic planet, an acidic Venus, a snowy ice moon, even an artificial-gravity planetoid covered in silver clouds.

Besides making the hello introduce the play, it's also valuable to have the play reference the hello. For example, the pirates can explain that they set up base here because the mists are an excellent cover, or they can have tactics derived from the mists, or they can have problems and keep getting lost because of the mist, or maybe they have mutant winged wolves that the mist has created... again, these aspects don't have to make too much sense, as long as they're not actively nonsensical.

The other kind of wondrous event I tend to want to create are the action-packed transition scenes where things turn. For example, your ship takes direct laser fire from the megacannon and is ripped in half with you aboard, now you're staring over a spiraling debris field struggling to get to the megacannon before you run out of air. Or there's a chase in the jungle as speeder bikes race for safety. Or you have to trick the zorgblat to smash down the walls of the alien zoo so you can escape...

These moments are dangerously close to talking about "generative plots", so we'll leave them mostly in the background for now except for one important fact:

These are transition scenes.

This is a moment when you say goodbye to where you were and hello to someplace new.

And that's considerably more important than whether they are simulated correctly or whatever.

...

Anyway, them's my thoughts. Tell me what you think.

Tuesday, April 04, 2017

Intense Gameplay Balance

Let's talk about unscripted, intense moments in a game.

Something that happens organically, as you play.

A lot of games are good at this, and it's the reason why roguelikes are still so popular. It's why Kerbal and Space Engineers have such a long-lasting following as well.

There's an adage: "failing is fun". These games rely on trying, failing, and trying again as a tight iteration loop.

I think this mixes two things. There's the tight iteration loop you get from failing and trying again, but there's also the fascinating and fun loop where you struggle to work through the realities of a situation not going quite according to plan. AKA, "plans-awry" play.

I don't think plans-awry play needs to fail in order to be fun. Struggling and succeeding is often more powerful, because it means your efforts were good enough.

For example, these days I build my Kerbal Space Program landers to survive hard landings. Those would have been failures when I was starting out, but now my landers survive because my planning has improved. That's a potent feeling: "uh oh oh noooo- whew, good thing I planned for that possibility."

I turned a failure into a success.

Fundamentally, this is about a learning curve. A player steadily plans better, sets things up better.

The "failing is fun" theory arises from a learning cliff that the devs sprinkle with glitter. It seems to me that self-directed missions can offer lower bars for success and turn this cliff into a slope. Allowing for smaller final goals, and allowing them to degrade gracefully can make failures into at least partial successes.

Thinking a while, I came up with seven factors I think turn learning cliffs into learning curves. Seven factors that make plans-awry play work.

1) Design refinement/mission arrangement. You need to be able to choose a mission and prepare for any mission you feel like doing in enough detail that you'd prepare differently for the same mission once you know more. For example, choosing different loadouts in Kerbal depending on your comfort in getting to orbit and landing on the moon efficiently.

2) Skill play. As the game unfolds, use your steadily improving skills to navigate challenges to your plan. This might be better ship handling in Kerbal, or knowing how to identify potions in Rogue, etc.

3) World state recognition. As your vision expands, you learn to plan further ahead and understand the world state at greater ranges. For example, orbital exchange windows in Kerbal, or understanding how long you have until a boss fight in the Binding of Isaac.

4) Composite/recursive planning. Allow the player to challenge themselves by trying several missions at once, or help themselves by planning a support mission ahead of time. This allows a player to adjust their plans to serve their skills: if they feel like visiting every Juul moon in one go, they can do that. If they aren't that good at fuel planning, let them send a tanker to Juul first to make it easier. Their choice.

5) Exploits/cheats. In single-player games (or friendly multiplayer), exploits and cheats are a core part of the fun. Exploits and cheats frequently turn into fun high-level challenges and opportunities. For example, the understanding that a torch holds up sand in Minecraft: torches can be washed away by water. Water can be blocked with sand. This is a basic setup which allows people to build a switch! Before redstone, it was the only way to build mechanisms, and even now, it's still used.

6) Cool factor. Allow players to do things that are cool because they are cool. Not everything has to be driven by mechanics. To this end, make missions much more open-ended than you ever expected, especially the low-level missions. For example, in Kerbal the lowest-level mission is theoretically "reach space", but it's so unenforced that people happily build slingshots and see how far they can fling Kerbals. Having a soft, unenforced fail state is a powerful tool.

7) Share-ability. Make it easy for players to share with each other. This partly includes things like screenshots and video: make it easy for players to take good-looking footage. But it also includes things like resharing blueprints, packaging up mod lists so everyone can import things without struggle, and very easy imports of levels, challenges, etc. Perhaps even automatic content sharing within some parameters.

These seven things seem to be really good at giving the player something easy to nibble on at the beginning, when they barely understand anything... and then letting the player just stretch their legs forever as they get more and more skilled. 7) is questionable, I suppose, but I definitely argue that it's part of the same concern.

Now, this isn't just theory for theory's sake.

I'm making a game. How does The Galactic Line do these things?

1) Design refinement. This is probably the most challenging for any game, because you have to come up with gameplay that makes refining your designs deep enough to carry the whole game, but easy enough that a newbie can approach it.

For TGL, I plan to do this by focusing mostly on the crew. A newbie understands the idea of putting people on a ship, they can focus on who they want to put on. They'll just choose whichever stock ship they like best.

This will naturally lead to them understanding how the crews and ships work, as they watch their story unfold. Critically, complete failure is unlikely. While chunks of ship get shut down and people start tearing their hair out, the stock ships will be well-designed enough to limp home even after a disastrous starting mission.

They'll hopefully feel the natural impulse to make their own ships, try longer missions, larger crews, etc.

2) Skill play. In TGL, the skill is mostly about optimizing for longevity by arranging the crew and ship modules. For example, when someone stresses out and something on the ship breaks, you have three options: leave it busted, repair it by salvaging another ship module, or dedicate crewmembers to massaging it into function 24/7. These options are about resource management and planning ahead.

If you do them well, you'll have "slack". You can use this to optimize hobby rooms and relationships, arrange for experience gains or career advancement, or optimizing ship modules for better performance in the next zone. This combined with the use of "redshirt" crew members gives players a lot of ways to manage things live in a skilled or unskilled way.

3&4) World state recognition/composite missions. The player will be faced with a lot of options as to what they want to do, but the most obvious pressure will be from "bounty" missions where people request specific resources from specific places. For example, "get me 30 points of astrophysics data from Beta Sirius". Those will be calibrated for the capabilities of the ship, but there's nothing stopping you from randomly gathering as much data as you want. It has some value.

Understanding how long those missions will take and what resources they'll require can allow you to do several missions at once, either in serial or parallel. If someone wants data from Beta Sirius and another person needs you to pick up five passengers from Gamma Draconis, maybe you can do them both in one run. If things go well.

4) Recursive missions. The game encourages the player to meddle with the affairs of non-space-ship folk using a simple colonization system. Hopefully this will not only allow the players to push through map choke points/extend missions, but also feel invested in the universe they're building.

5) Exploits and cheats. Not sure about this quite yet, but the plan is to make the game moddable and I'm not aiming to prevent them.

6) Cool factor. In addition to trying to let space ships look cool, a lot of the fun stuff is going to come from the way you can make custom crewmembers. As The Sims has shown, there is an impressive appetite for putting all sorts of random people in the stew-pot in different combinations. Want a ship crewed by your favorite band? Your friends? Vampires?

From the other side, colonies can also be made cool. Want to terraform a planet? Want to cover a moon in a huge city? Want to start from just one starving industrial colony on a barren world?

7) Share-ability. This one't a bit tough because it doesn't actually exist yet. The big challenge is that I'd need some kind of central database. Once I have that, automatically downloading ships, mods, stars, and world states is fairly straightforward. It's intended to be a "massively single-player" game.

In terms of making it fun to record/screenshot... I have to think about that some more.

At the end of the day, the plan for The Galactic Line is to focus on plans-awry play with a minimum of actual failing. We'll see how that theory works out in practice.

Anyway, those are my thoughts.

Wednesday, March 29, 2017

Modular Space Planes

So, in The Galactic Line, you build space ships out of modules. Therefore, I model and texture the modules, animate them as needed, and so on. It's reasonably decent.

It inevitably results in an "industrial" look. The modules get slapped together in whatever way seems best. Even though you're not locked to a grid like in many voxel space ship games, you're still working with parts that have a fixed size and shape, and their seams will always look heavy and industrial.

Moreover, repeated parts will always be the same size, so you tend to end up with straight lines and boxy profiles. This is especially noticeable with habitable areas, since you rely on door-to-door connections, and that typically means all your habitable areas have the same connection profile - leading to straight lines and flat profiles.

Most space ships that are properly designed have flowing lines, tapered elements. They feel almost organic.

That's a high bar for modular spacecraft. Flowing lines and tapers are tough to do in modules, because baking them into the modules means the modules can only be assembled in one order, and with no missing parts. No reason to make it modular, then!

I've been struggling with this as I try to make a spaceplane set, so let's talk about a few methods to make modular ships have flowing lines.

1) Algorithmic tapering

It is possible to adjust the meshes of the modules to taper according to some algorithm. You can easily make a fuselage of modules into an organic tapered shape. This has some problems, though.

First, it can't mask the seams of the modules. This means most of the modules have to have identical connectors, which radically limits the overall look. It's always going to be a tapered fuselage, just with different surface greebles representing the different parts. More complex seams are possible, but the tapering won't mask them, so you'll need to be aware of that.

Second, if the modules have interiors, it's going to screw up the tapering. A room that shrinks or grows might become inaccessible or out of proportion. If the rooms are size-locked, now you have a problem where the windows need to stay attached to the outer hull, so now there are specific sub-elements of the mesh that must be scaled at different rates to get the final taper. Interior halls twist and grow, room ceilings rise while the rest of the room remains the same size... it's a mess.

Without R&D, tapering could only be applied to non-habitable elements such as engines, tanks, machinery, etc. I don't know if that's worth the effort.

2) Masking elements

Slipping coats on the outside or shims on the inside is perfectly possible. For example, if you want your straight fuselage to take on a triangular shape, slip on a triangular bit of armor around it. Any shape can be mimicked like this, and the flow of the ship profile can be built primarily out of these masking elements instead of their contents.

One problem is precisely that: the flow of the ship is mostly determined by specific masking elements, and is therefore pretty restricted.

Another problem is that the masking elements inherently conflict with the surfaces they mask. If you're turning a straight fuselage into a triangle, then the windows on the fuselage are now, at best, recessed several meters into a concave pit. This is substantially worse if your fuselage modules have significant surface elements, such as bay windows, solar panels, machinery, or inflatable areas. Masking elements constrain what you can put on your core modules and where, meaning that they may look 'unfinished' when not masked.

It is possible to do the opposite. If you have a split body rather than a fuselage, you can slowly move the elements apart or together and fill in the interior gaps. This is a fairly robust approach, but it means you'll have twice as many parts, twice as many halls. From a simplicity standpoint, it makes the most sense to "shim" with a hallway rather than a hull part, making the core hallway widen or narrow or have gathering points to change the flow of the profile. This can work, but care needs to be taken on how the attached rooms actually attach. Otherwise it will still end up looking very linear and dull.

3) Adaptive sizing

It's possible to set up the individual elements with blend shapes or bone animations to slightly change their shape. This is fairly adaptable, since it is per-part, but it does require that the linking areas remain interconnectable. So you can't go too off-the-wall.

This can be used to taper elements, but they would all have to have the same basic taper characteristics in order to connect without big chunky seams. Perhaps more feasibly, it would allow you to raise or lower the exits, which would break up the linearity without feeling too forced and without any complex interconnectivity requirements.

Of course, you could also just make some parts have a rise or fall inherently, which would accomplish the same thing. This would force players to accept specific patterns of shapes, but it's much cheaper.

4) Painted hulls

Another option is to let the players place the rooms/modules, then adaptively generate the flowing hull. This wouldn't be too hard - a convex mesh calculation with some holes cut for the windows and panels you want to expose. However, since I haven't done it, I don't know how good the result would really be. "Shrink-wrapped space ship" seems like it might be a bad look, and you'd need a lot of smart texturing algorithms.

Even with that approach, you'd still need to use offsets to keep the habitable areas from going excessively flat.

A subset might be possible. "Adaptive surfaces" are less difficult that fully generated ones, and it might be possible to create masking elements that "melt" into the existing objects, including making way for elements that need exposing. This is a bit of a challenge, but not as excessive as generating the full hull. Also, it'd allow for a lot more control over what the ship ends up looking like

A super-easy subset would be adaptive surfaces that have shapekeys built in. The various shapekeys align with various shared shapes among the modules, allowing you to adjust the hull to fit properly. This is a big step up from simply allowing the meshes to overlap, but it does mean you'd need to have only a few, very common shared shapes.

...

Anyway, that was my very technical essay on a specific thing I'm doing.

Tuesday, March 28, 2017

What Plot Would You Write?

I'm playing Mass Effect: Andromeda, and I've been slightly disappointed by the writing. Putting aside the dialog, I'd like to talk about the wider elements.

Spoilers, but only vague ones.

The game is about a large group of colonists leaping from the Milky Way to Andromeda in vast arks, targeting a few specific worlds that seem inhabitable. They cryosleep for 600 years, and awake when they arrive.

There are some holes here that need some Unobtainium patching, but it's not a bad idea. It sets up a massive project, seals the path backwards, and isolates us from the extensive (and problematic) pre-existing lore.

However, that's not the full setup. There's a million things going on, and they all need to be explained before the story can even get started. That's not a great idea: any one of the setup elements could easily have supported the whole game without making it super-complex, and that would have made the writing easier.

Talking about how writing can be "made easier" might seem a little odd, but the simple truth is that if the scenario is set up well, writing flows well and needs less forcing. This is especially true of characters.

In a game where the player can do a huge number of different sub-plots in a variety of orders, it's critical that they feel some connection to the places and things going on. The easiest way to do this is to have the party members have some connection to nearly every subplot.

If they care, we'll care.

This is a pretty typical approach. In fact, it's the classic Mass Effect approach: in ME1 and ME2, that's how it was done. The characters resonated with nearly every scenario.

For example, Garrus was all about the nature of vigilantism. Well, so was the plot of Mass Effect! The subplots naturally had the concept come up all the time, and therefore Garrus always had something to do or say. Naturally this culminated in him trying to clean up that hellhole asteroid as Archangel, a microcosm of your whole adventure.

Wrex was the same, but about war instead of vigilantism. War was a core theme, and kept coming up. When was it good? Bad? Necessary? Out of control? Tired? Heroic? Desperate? What are we willing to fight for - no, not just fight, but go to war for? And when do we stop?

Both war and vigilantism were threaded into nearly every scenario in the game because the game was built on a single foundation, a simple setup that allowed the writers to easily explore those concepts in a lot of different ways. Although simpler, the setup for the earlier Mass Effect games was not smaller. It could support just as much play, story, and depth... just focused on deeply exploring a few themes instead of shallowly exploring a lot of them.

To put it another way: it's impossible to tell where Garrus ends and the story begins.

A good character flows everywhere they need to be, naturally, unforced.

A bad character stands to the side and watched the story go by. Even if they have good writing or voice acting or are compelling, if they just stand there, they're bad.

This is a big failure in Mass Effect: Andromeda's writing.

For example, Cora. She's a human psychic that worked as an Asari commando. This is a really interesting idea that has really powerful themes.

The actual in-game writing of Cora is clearly "Asari ark contact + conflicts with Peebee". She doesn't flow into the wider story - she's simply wedged into "her place" as a representative of a specific story element. This is probably because there's a lot of specific story elements and they don't have much thematic connection.

Cora's history working with a group of weird alien commandos and desperately trying to earn their trust? Well, that's literally what you do with the Angara. You literally work with Angaran commandos and try to earn their trust. But Cora has nothing to say about it. She's not involved.

The fact that Cora cannot live long enough to complete Asari commando training? That's fascinating, and could easily connect to things like our 600 year cryosleep, or to the Angaran elders that cannot seem to find any fresh new students. Again, Cora has no comment.

This is easily explained: the Angaran stuff is Jaal's place. Jaal does that stuff. Cora isn't involved, except for some minor flavor commentary.

This goes for every character. Jaal's thing is imposter syndrome, but he has no connection to Nexus and its leaders? Even though the thematic connection is clear? Jaal doesn't even have any connection to an Angaran port world conquered by pirates!

The lines drawn around what each character is involved in are sharp and clear.

Unfortunately, that means that for 99% of the story, Cora and Jaal just stand there. They aren't involved.

This is true of all the characters in ME:A, and I think it's why we just don't feel as much connection to them as we did to ME1 and ME2 characters. Those characters went through an adventure with us. These characters just stand nearby while we go through an adventure.

It also makes it difficult for us to care about our adventure!

In ME2, visiting the hellhole asteroid was interesting because two of our characters were deeply involved in trying to fix the place in their own way.

But in ME:A, visiting a similar hellhole is dull. There's no major characters with any significant ties to the world. They don't even get involved in local affairs - just some flavor text. Instead, your contact is some boring smuggler and a woman with a dirty face, neither of whom anyone cares about.

Even characters that should have a history with either the smuggler or the pirate queen... don't. Vetra apparently has no comment on this smuggler, despite using smugglers extensively. Peebee has no particular comment on the pirate queen, despite them both living through the same civil war on the same tiny space station!

This is because Vetra's story is Vetra's story and doesn't interact with the rest of the world. And so neither does Vetra. Peebee, too: lock her up in her own little room, no contact with the rest of the world.

Unfortunately, this means that I don't care about the pirate base. Moreover, the writers missed a chance to make me care more about the crewmembers. If Vetra was the smuggler trying to fix up the pirate world, Vetra would have a chance to impress me and spend meaningful time with me, as well as giving me a reason to care about the pirate world. But... nope. Some boring Han Solo wannabee that is also nicely cordoned off into his own little room.

Writing characters that thread through the game is not terribly hard. The fact that the ME:A characters don't even try makes me think that the writers came up with a plan to partition these elements specifically to reduce complexity - otherwise, they would have written some involvement on accident, I would think.

Whether on purpose or on accident, ME:A's partitioned storylines are a huge disservice to the world and the characters. It starves our critical crewmembers of screentime, and leaves each world feeling uninteresting and pointless.

On a writing level, there are some techniques you can use to make it easier to make the characters flow through your scenarios. A key factor is choosing a simple foundation so you have more repeating themes. IE, vigilantism explored in a hundred variations means a hundred chances for Garrus to have something to do/say.

If ME:A didn't have such a complex setup, a lot of these things would have flowed naturally as the writers searched for interesting ideas in the simpler story space.

But... the fact that they didn't do it at all, not even on accident, implies they wrote it like this on purpose. In which case simplifying the setup would not have helped.

At least, that's my theory. What's yours?

Wednesday, March 22, 2017

Character Checklist

I'd like to talk about how to write characters, especially for sci fi. There will be very mild spoilers for Mass Effect: Andromeda's first hours.

It's clear that the Mass Effect team wanted to up the representation in this game. The characters are more diverse, both major and minor. For starters, there are a number of alien lizard women that don't have breasts, pretty much a first in the genre.

Care was taken to try and slot people into "nonstereotypical" roles. For example, the religious zealot is your scientist. The butch lady is straight. It's clear they were really trying to make this feel inclusive while avoiding stereotypes.

Unnnnfortunately, they're not very good at it.

In science fiction, we're currently walking a new path. The concept of representation in sci fi is thorny, because sci fi was built around representing other cultures and ideals with aliens. When sci fi is aimed at a single group of people, that works well enough - your target demographic is the baseline, and everyone else is an alien.

This may sound reductive, but that's how it's generally been. This allows sci fi to take how the target audience treats those people, those ideas, those policies... and show it separate from the complex intertangling of the real world.

Even Star Trek, a sterling example of inclusion, did this. Although the crew had minority crewmembers, they did not represent the struggle of minorities: Star Trek was portrayed as being past that. They were representations without the real-world baggage.

Rather than include any racial tensions on the starship, the writers would put the racial tensions into a representative race. For example, making a species that is half white and half black get into racial wars over whether they where white on the left, black on the right... or visa-versa.

This works reasonably well when sci fi stories are aimed at a specific audience. But once the audience expands, it becomes clear that being represented in that way doesn't work so well. The tribulations of the Mass Effect devs have made it clear that people want to see themselves properly represented. Not as a weird alien or a paint job on a default character, but as someone with similar concerns and goals.

Basically, everyone wants a power fantasy about them.

Nobody is monolithic. Each person cares about a lot of things. This is why Mass Effect found itself with fans that weren't really represented. It has anemic racial commentary and somewhat regressive gender representation, but those people also found things they liked. Space ships, cool adventures, an epic battle, hot folks you could date...

Mass Effect clearly decided those people deserved better representation, and struggled to work in a more diverse cast. This seems to have backfired with Andromeda, whose representations are painful tokens that mostly highlight a clumsy writer rather than making people feel welcome.

To me, the problem is clear:

Representation is not one thing.

In sci fi, representation can mean "oh, we're past all the problems you're struggling with", or it can mean "oh, let's explore that concept, free from the complexities of the real world", or it can mean "oh, let's explore that with all the complexities of the real world in a new context".

Moreover, in a video game, does an NPC even count as representation? Can we say that we are represented if we are not allowed to control ourselves? Does a background character going through a personal crisis represent us if we also went through that personal crisis?

Or does it only count if we actually have control?

Whatever you think the answer is, I think it can be argued that we should try to "centralize" representation. It should be part of the player's experience, not just part of the background noise.

The obvious problem with this is that there are more experiences we want to represent than we can cram into one timeline, and many of them are contradictory. Our hero can't be everyone. They will always be an outsider to some group just by their inclusion in another group.

... none of this is new.

Sci fi has always been about including a lot of different experiences via abstraction. Normally, the experiences we want to include are coherent. They cohere around a core idea.

Our universe might revolve around the idea of right and wrong, like Star Wars. Experiences revolving around that concept naturally pop into the writer's heads and flow smoothly through the player's adventures.

For example, in the Knights of the Old Republic series, we can easily have an evil android, a 'gray' Jedi, adventures in balancing the needs of the many and the rights of the few, of balancing law and morality. These are issues which naturally arise from Star Wars' obsession with good and evil. They all integrate with the player's own story to some extent, usually through party members.

But it is more difficult to include things like race, religion, or gender. Since they are not hooked directly into good and evil, you have to force them to fit. Sure, it's evil to massacre people because of their race or religion, but there's not much to explore. It's just evil being evil because you need to send a message.

Thus the endless stream of bandits in so many games. Just evil for evil's sake. Can't think of any way to make them more interesting, because we didn't set up our universe right.

If we want to be more inclusive, we have to orient our universe around inclusive concepts. For example, the Federation is about all people coming together for a better future. Not just humans, but all sorts of aliens living their weird, extreme, exaggerated alien lifestyles.

That's not a very viable theme in this case, because there's not a lot of discussion. Race, religion, and gender in this kind of universe are just accepted. We're past the conflicts that arise from them: the answer is always "yeah, as you like, now let's go space exploring!" Or, alternately, "let's show the oppressor why he's wrong!"

This is not a situation I have answers for, but if I were writing a sci fi setting these days, I might base it around the idea of acceptance vs rebellion. Accepting people or things or situations - or fighting them. When do you side with who, and how much will you sacrifice to help people you'll never meet again and who aren't magical paragons?

When we want to add in representation here, it should flow relatively fluidly. There are endless nuances and complexities to explore - not just things like "evil people hate minorities", but things like systemic injustice, unstable societies, and the difference between accepting someone and fetishizing them.

We would be free to either lift situations wholly from our reality, or create abstracted situations that leave out the entanglements of the real world. Both would play well in this environment.

These situations would flow easily and naturally, and we would be able to write them without feeling forced or feeling like we have a checklist. I think you'd be surprised how often you would naturally write something that resonates with people Mass Effect has been struggling for years to even acknowledge.

Conversely, we would have a hard time talking about good vs evil. It'd feel very forced.

Even with this theoretical franchise, we are left with some complex questions. Can facets of humanity be represented by aliens? Do technological handwaves diminish the validity of real-world struggles? How much of our writing needs to be vetted and rearranged by people going through the real-world versions of our abstracted situations?

But I think it'd be a pretty good approach. Just need to figure out a reason why acceptance vs rebellion would be the founding principle of the universe: Star Wars has the Force, Star Trek has the Federation, dunno what I'd use.

Anyway, let me know what you think.

Wednesday, March 15, 2017

Inside-Up: Space Ship Floorplans

The Galactic Line is a game about crews aboard space ships. It has one particularly glaring challenge: the camera.

Looking at the crew of a space ship is typically done via a birds-eye view with the roof stripped away, just like how you see people in The Sims, or FTL. This approach is particularly useful in games where you also build things or manage complex facilities, because this kind of "map" view is a natural fit with arranging pieces and laying floorplans.

Originally, I had planned to have The Galactic Line feature several different cameras, including a first-person or close-third-person for realtime events. However, I think I've changed my mind. Let's talk about the drawbacks of the birds-eye view, my workarounds, and why I'm leaning in that direction again.

Floors
One of the biggest limitations of the birds-eye camera is when things are stacked. You can see this even in The Sims: when you're looking at the ground floor, you can't see people in the basement or upstairs. This keeps you from having a good overview, despite having a literal over view.

The Galactic Line uses modular construction, rather than tiled construction. You click prefab rooms and sections together. This means we can arrange our modules so that they naturally click together in a manner that doesn't have overlapping rooms.

1) Multi-layer modules (stairs, atriums, etc) give us a good control point for how ships can be arranged vertically. If these modules have doors on each floor offset from the floor beneath, then the attached modules will also be offset, allowing us to naturally stagger our layouts.

2) Use of "gray" space such as storage and life support means that a habitation module can have lots of areas we can simply leave unrendered, allowing for rooms above or below to naturally fill that space. Moreover, hallways themselves are low-priority and could be rendered softly, if at all, allowing us to stack halls over rooms without blocking the rooms.

3) Larger modules for larger ships may have a dozen rooms in one package. If we make each of those modules largely vertical, we can arrange the rooms so they don't block each other vertically. Additional ship modules will generally snap on horizontally, meaning our large modules rarely vertically overlap with other large modules.

4) Sparse modules. Using a variety of layout tricks such as arbitrary angles, slopes, and gentle curves, we can make it difficult to tightly pack our modules. These work well if the modules have a number of windows or other external-facing elements to give an excuse as to why you don't want to pack them tightly. This would be, visually, fairly unique: most settings have tightly-packed hab areas.

5) Subsystem filters rather than floor filters. Instead of looking at "deck 6", we can look at "off-duty rooms" or "engineering rooms" or "command rooms". By arranging these rooms using the aforementioned techniques, we can show a spiderweb of rooms on several floors, none overlapping. The focus on functionality means we can also see the operations of the sort we care about, rather than the arbitrary "nth floor" filter.

People
In The Sims, you can't see everyone all the time - they might be on a different floor, or just far enough to the side that they're not on screen. So there's a bunch of portraits on the screen which show their faces and needs, letting you keep track of them no matter what you're looking at.

Our situation is a bit more complex. The Sims is about a few people, and the focus is on tending moods. In The Galactic Line, you could theoretically have a crew of thousands, and the focus is on the specific event that's unfolding rather than on moment-to-moment moods.

The good news is that the event focus means we are also able to focus on only a few of our potentially thousands of crew members: the ones involved in the event.

This means we can have a manageable number of portraits, but it also means we can have a manageable map presence. We can arrange our highlighted crewmembers to be in rooms with no overlap, so we'll always have a clear view of them. We can even build an adaptive interior view which highlights only the rooms they're in, making any potentially overlapping rooms invisible unless you manually walk into them for some reason.

Functionally, this means we don't need portraits. We can use portraits for a variety of things, especially when arranging or building the crew, but for the event scenes we don't need them. You can see everyone involved. You can see what they're involved with because they're standing at a specific place in a specific room. There's no need for floating heads to pump numbers into your eyes.

Faces
The reason I wanted to go with a more personal camera is easy: this is a game about people, so I wanted closeups of people. I planned to do some camera manipulation when you get near/start talking. Get a reasonable closeup of the face.

I need this because A) faces are distinct, and it's one of the important ways crew members are unique. B) The expressions they make are a critical part of empathizing with them and their situation.

However, we don't need to rely on the player camera. There's no reason we can't have a separate dialog system, like thousands of games of all sorts. A popup of some kind that shows their face up close.

There's loads of different approaches. For example, the full-screen dialog tree vs the chatroom-style messages with faces alongside. There are a fair number of distinct options - perhaps a sidebar element that folds out to show the ship's chat room would feel right... although the faces might be too small.

Any way I slice it, there's no big problem with having a separate dialog engine. It's common.

Advantages to the Bird
Birds-eye camera has a few distinct advantages. I've already mentioned that it fits well with the construction engine. It also shows a fair number of people and the state of the ship all at a glance, which is nice.

Another advantage is the low resolution required. Because the camera never gets too close, I can use relatively low-res assets for furniture, for bodies and rooms. I don't need to have high-res assets for books and posters.

The main problem I have with the camera angle is simply that it's not very personal. Moving a pawn around on a giant board game is not very immersive. Walking around inside the ship is a hugely immersive experience that I would love to focus on, especially because the experience of being stuck aboard the ship is the focus of the game.

Well, let me know what you think.

Monday, March 06, 2017

Glowing Open Worlds

I was following some Twitter thoughts by Jake Monahan, and it got me thinking. He was talking about how open world games are inherently built to be strip-mined, discarded once you've finished pillaging them. He points out that most of the things you do that change the world (such as resolving a gang war) actually make the world less fun to play in.

This is very interesting to me, so I thought I'd analyze it in way too much detail!

First, the constraint: we're specifically talking about designed open worlds, not randomized ones. Fallout and GTA, not Minecraft.

The most obvious reason why open world games are built like this is because that's the play we have gotten used to. Killing and collecting are our focus, and both of those remove your targets from the game.

A less obvious reason is that most games are about progressing through the game. If the world is steady-state and nothing you do changes anything, there's no reason to move to the next zone. And if you do decide to move on, there's no reason to actually grapple with the next zone, you might as well just skate through as fast as possible.

So the "strip mining" is not simply a side effect of the preferred play. It's a tactic that pushes the player to move through the game at a steady pace. Different players will engage at different depths - some might spend a lot of time hunting for every scrap in a given area, others might just hit the high notes. Either way, they are steadily lured into finishing this zone and moving into the next one.

It's possible to design a constructive open world, where your gameplay makes more gameplay. However, you would need a different mechanic to lure the player forwards, or they'll never get very far into your world. They'll just mine out all the play options in the first few areas and then get bored of your mechanics.

In short, if the player isn't lured into moving through your open world, it's not an open world.

Whether it's a linear game or an open world game, as we move through the game we discard levels behind us. In a linear game, those levels are simply gone. In an open world game we can physically return to those places, shrines dedicated to our past adventures, but they are no longer part of our path forward.

...

It's worth considering replay value. In the first play-through, players usually behave fairly predictably. This is definitely worthy of its own conversation, because 'predictably' doesn't mean 'exactly the same path through the game', but it does mean that you can typically use standard tricks and layouts to pull them into a few paths you consider to be ideal for new players.

For example, in Fallout 4 you aren't physically forced to get Preston and Sanctuary, but nearly all first-time players will. After that it appears to open up and tell you to go do anything you want, but the way the map and sidequests are laid out pushes you to find a few small farms to recruit and a few bandit hives to clear. In theory you can spend a lot of time farting around this open world, but in practice they limit your available play options so that you'll get a little bored of doing that and decide to start for the city. They city features a combination of physical funnels, golden paths, and meat walls to pressure you into finding Diamond City.

The design of this is "first run" open world design, and it's not too different from a linear game. But when we replay the game, we are more familiar with the world and take more advantage of the variations.

This isn't a proper "new game+" situation, because many people restart the game long before they've beaten it. For example, I've played the first five hours of Skyrim approximately 300 times, and I still haven't actually beaten the game. Trying new paths, or perfecting your abuse of paths your familiar with, or challenging yourself with a new constraint... these are powerful play elements!

What I'm leading up to is this:

The open world we strip mined? It doesn't stay stripped.

We return to the fresh, untrammeled world again and again, whenever we want.

To me, that is the truest power of an open world, and that is what I would like to focus on when building open world maps.

... maybe I'll talk about that for fifty hours some day soon.