Designing Inhabitant-Centric Games

This is an example game design for a person-centric base-building game. Sort of like Rimworld, except the people are the focus and their stories feel more solid, like in The Sims. See the previous post for details of the why and how.

One thing we need to do is abstract jobs more than Rimworld and other base-building games do. If jobs are simulated in the same space and time as the home, then duties won't be very isolated. This means it's difficult to control the way duties work and the events they cause, and it also makes the duty time 'permeable' - people can swing in and out as they see fit. Those are all bad things.

Therefore, our first goal is to create workspaces separate from our home spaces. The two obvious approaches are out-map and in-map jobs.

Out-map jobs are simply duties that take characters out of the densely simulated home area and off to somewhere else. For example, a farmer leaves to tend the fields, which are not part of the same map. Or a superhero leaves to patrol the city, which is obviously not inside the secret base. These remote areas can still be managed by the player - setting up exactly how many of what fields are where, or what the patrol route is - but they're not simulated in the same space and the workers are not available to the people still at home. Of course, out-map jobs are also good in that you can change the remote conditions without needing to change the local conditions, or visa-versa.

In-map jobs are when the worker is still in the home space, but not being simulated as part of the home experience. This could be something like a woodshop - the worker is technically still on the map, but they aren't wandering around or chatting or worrying about whether they need to go to the bathroom. In a superhero setting, this could be researchers or radio support or training - anything that can be done locally and allows us to lock them into a set pattern for the day. The difficulty with this approach is that it doesn't naturally give a schedule - you can train whenever, you can research whenever, etc. That makes it a little harder to create scheduling frission between different jobs.

Obviously jobs aren't the only thing that matter in our design, but with this in mind, we know that a big part of our design will be outside the map, or at least abstracted within the map.

Within our densely-simulated space, we need to design carefully. The purpose of this space is to help build personal stories both in gameplay and in the player's mind. Most of the base-building games that are popular these days are meter-by-meter designs. This has many advantages, allowing the player to express themselves freely while also locking the player into topological challenges presented by both the initial setup and the player's own previous base-building choices. It's a good way to create opportunities for the player to freely create a base with a lot of unusual elements both incidental and purposeful in an attempt to optimize performance.

But that's a base-centric approach. If we plan to be people-centric, we need our bases to support story and context, both with game mechanics and in the player's mind.

What can do that?

Well, if we want to create context, then we have to make the inhabitants relate to the space with context. That is, the people in the world have to want to use the space in specific ways that produce familiar or memorable stories.

In The Sims, examples of this would be the bathroom. There are rules about exclusivity in the bathroom - it's usually one person at a time, but perhaps family can use it at the same time. You can create different kinds of bathrooms to give the player funny stories about how the bathroom works - for example, sticking a window in it facing the living room. The exclusivity rules are in-game rules that are familiar to the player and create good context, while the funny design alternatives are mostly in the player's head, but still create good context.

Bedrooms are similar: is it one person's room? A big bed for the parents? A crowded row of beds for a bunkroom? There are in-game rules about the effects of these things, but even more important is how the player has expectations for these things and feels a heavy sense of context depending on how it's built and the people living in it.

Public spaces like living rooms are equally high-context. These are gathering places where people get together. Sometimes in passing, sometimes to cooperatively do something (eating, watching TV, etc), sometimes to do different things in the same area at the same time (one person cooking, one person dancing). Public spaces are further leveraged by scheduled events such as parties and family dinners. All of the various ways people can gather have context, and the space itself enables those contexts while simultaneously creating additional context in all the ways it doesn't quite fit. For example, if your party can't easily get food, you get more context: hungry guests moving into the kitchen instead of staying in a completely open space, now standing clumped together.

All that said, The Sims still uses a meter-by-meter construction system. Well, there are some differences.

The Sims construction focuses on walls to a great extent. Most base-building games have walls that are one tile thick: meter thick walls! But The Sims has paper-thin walls, and this allows the player to carve up map quite densely and with ease. This packs far more useable space into the same size map. This may sound unimportant, but it's critical. Not only can you fit more, larger characters onto the player's screen at one time, but the characters are also substantially closer together, allowing them to interact more regularly and freely. For example, someone in the kitchen can easily chat with someone in the living room, whereas if the walls were a meter thick, that would feel more like shouting range.

These seem like small details, but when it comes to creating human context, human details like that matter.

The Sims also has complex standing positions. Rather than "one tile per person", people in The Sims can stand in arbitrary places and in arbitrary groups. Although I don't think The Sims uses proximity as a reflection of intimacy, this is an obvious use: people who stand closely are more intimate than ones that stand meters apart. Similarly, people who sit on a couch together are in a different social situation than people sitting on random chairs.

In short, a dense space that can be used by people standing in a wide variety of configurations. A dense space with variable publicness and utility.

Combined with our off-map jobs, this clearly reflects a focus on someone's home, rather than the more widely-scoped mixed spaces of most base-building games.

Classically base-building games have avoided being solely about someone's home. Statistically, the other aspects of the base are more interesting. But statistically interesting is not what we're interested in. Topologically interesting, yes. But we're simplifying the statistical aspect, and a very easy way to do that is to chop off all the job-related base-building stuff.

From here, deciding a genre is probably critical, since 'home' has a different meaning depending on the genre.

If we set it in the modern era, it'll be very Simslike, because we've basically reverse engineered the core features of that game.

A superhero genre would work well. A team tower or secret base would be our home. Our characters could have night patrols, daytime rescue missions, media reachouts, school, day jobs, investigations - those would be off-site. On-site abstracted jobs could involve training, radio support, research, crafting, etc. This would no doubt be an interesting setup, but there is a weakness in that superhero bases tend to be attacked. This isn't as bad as in most base-building games, because 90% of your assets are locked into your inhabitants, not your facility. Rebuilding or moving is cheap enough. But players would still focus on defenses, and that may be hard to make feel just interesting enough without taking over the game entirely.

A fantasy setting could go rural or adventurous. A rural setting would allow people to go off map for things like farming, crafting, etc. It would also allow for interesting long-term setups, since sending children away for years would not be uncommon. However, I'm not sure that the feel of rural fantasy life would make much of an impact on the player.

An adventuring setting could be fun, though. You could run a guildhouse. It would have a lot of similarities with the superhero idea, but missions would often take several days, and managing funds would probably be more important. The medieval lifestyle simplifies the living space considerably, and characters would be far more likely to have to spend their leisure time together instead of separately watching TV or whatever.

A sci fi setting might be fun. You could create a Mars base or something, with dome bubbles for inhabitable areas. Within each dome, only thin walls would be used for weight and air permeability, allowing for very dense space. The lifestyle of science fiction might not have much impact on the player, but sci fi is more flexible than fantasy, so it's possible to just make their lifestyles more familiar even if it doesn't really make too much sense in the setting.

Well, you could also do something like Firefly, where it's aboard a space ship. The problem with this is that space ships often have very heavy, environmentally-sealed areas. In addition, there's not really any "off map" to go to, meaning that our job management might be hard.

A fantasy sailing ship might be fun, too. Job management might be hard due to the lack of 'off map', but I think it could be managed.

There are a lot of possibilities. I don't really feel the need to push further down any given road right now, though. I'll just let my brain rest a bit.

What do you think?

The Sims vs Rimworld

There's a new genre hiding in plain sight. A genre about people.

Base building games are including more and more "personal simulations" about the people in those bases. For example, in Rimworld each member of your crew is simulated in great detail. Not only their stats and skills, but also their moods, personalities, traits, and so on.

But it's difficult to feel the "story" of these people. Despite getting sad over losing their dog, or having a bad case of the plague, or dating someone, the character stories don't really have a strong impact on the player.

This is because those events are framed in terms of how they affect the facility rather than how they affect the person.

If someone loses a pet and goes into a long mourning slump, the player has to try and keep them from going berserk or spending days just wandering around. It doesn't even really feel like "the story of that person", it just feels like one of the cogs in your machine is wobbly.

Because it is.

A base building game like Rimworld is about building bases. It's about creating an ever-more-complex self-sufficient machine. The inhabitants, no matter how diligently simulated, are cogs in that machine.

In contrast, consider The Sims.

It's a different setting, but The Sims has most of the same kind of setup as Rimworld when it comes to people. Each sim has specific traits and skills and goals, they tend to have specific jobs, things can go wrong - it's very similar to Rimworld in that regard.

But the house they live in is not a complex machine.

Although you can build your house with astonishing attention to detail, it is not self-sufficient and doesn't need to be. As long as there's some source of money, everything else is optional, and there's no real need to optimize your performance.

The role of "day job" is less about optimally making money and more about providing a scaffold for life experiences - it shapes both the character that goes to work and everyone they share the house with. If things go wrong or get delayed, the house will not collapse just because the day job person is being suboptimal.

Compare this to Rimworld, where it's very likely that half your base will catch sleeping sickness and then whoever is awake will get too moody and start lighting things on fire, at which point a crowd of monsters will attack. Rimworld is about creating a base that can survive all these bumps in the road, even if they pile up. So anything that goes wrong is a bump to your base, even if on paper it's the story of how Anna is depressed and Bob is sick.

The Sims is just the opposite. If something in the house goes wrong, like a sink exploding, the player will naturally contextualize it as part of Anna's crappy day rather than a systemic setback. Even death isn't a sign that the house is doing badly, it's a sign that someone's particular story has come to an end. That may be very upsetting, but it's contextualized as that person dying, not your overall facility degrading.

I think nearly all of the difference in this contextualization is simply because the 'facility' in The Sims is not a high-stress facility. You don't have to worry about droughts or animal attacks or hurricanes. It's pretty easy to establish a baseline habitability, and then everything else is just improving things more or having fun with side tasks.

The lifestyle options for Sims characters are all side options. Some are very dense, some are not, but they are all optional. They provide a stable, steadily-progressing scaffold for the characters' life stories while also providing a steady diet of life events. For example, gardening: you don't have to garden, but if you choose to, it's a steady task that moves forward day after day. Your garden will never be attacked, and even if your whole garden was destroyed, your sims would not die: the baseline habitability would not degrade that far.

If we want to make a game that focuses on the lives of the characters, it's critical that their support system is straightforward and robust, so that setbacks can be judged as affecting the characters rather than the support system. Similarly, the progression system needs to be character-centric rather than facility-centric.

As an example, Rimworld's research system unlocks construction options for the whole base once someone researches how to build it. A character-centric approach would be to allow only that character to build it.

In addition to being character-centric, a character's chosen lifestyle/career/hobby needs to provide a stable, steadily-advancing scaffold, needs to exert pressure on their life and the life of those around them, needs to provide small random events and schedule burps, and needs to respond to a character's own personality/pressure/situation outside of the lifestyle.

For example, rather than the farming system Rimworld currently has (identical to other games such as Dwarf Fortress and Minecraft), we would instead have the farmer work fields on a schedule. The more fields, the more hours of the day are required, and time spikes at harvest and planting. The result is a nice, predictable, slowly-changing curve as to how much time they have to work and how much time is available for other pursuits. Their early-morning schedule would bump up nicely against someone who gets up later - for example, a researcher or carpenter.

In theory, the fully-simulated fields work this way. But in practice, there are too many variables. For example, just walking from point A to point B can take a lot of extra time. Also, the characters aren't great at schedules, and frequently get distracted by their overwhelming need to pick up a meal halfway across the map or whatever.

By reducing the simulation fidelity, we can allow for a more 'readable' character lifestyle. This will help the player to 'feel' the character's life, personality, needs, and so on.

And I think that is where a genre is hiding.

Right in there.

Generating Screen Time

The most underestimated element of characterization is screen time. How much time a character has in front of audience eyeballs.

The reason it's underestimated is because it's usually mostly automatic. You write characters for a story, you give them traits to help tell the story, you let them help tell the story. Even a first draft will have a fairly suitable amount of screen time for the various characters.

When generating characters randomly, this doesn't happen.

There's an urge to generate characters similar to the ones you might write. Similar traits, visual features, and so on. But this is 'cargo cult' character design: you're emulating the sizzle of a character without understanding the meat.

The meat is screen time. You have to generate screen time.

In fact, I'd wager generating screen time is cheaper and more powerful than generating characters. I bet you can radically extend and punch up a game by adding in generative screen time without any generative characters.

Let's show some quick examples:

In Mass Effect, all of the characters are designed to support the fiction of the universe. As such, even if they aren't chosen to be in your party, their plot arcs still play out. Their roles in the universe are distinct (at least in ME1 & 2), and therefore it's easy to remember who someone is even if you don't pay any attention to them after their introduction. In addition, they are frequently given 'tidbits' of screen time even when not in the main party.

We can break these methods into a few specific types, each of which can be generated algorithmically. I'll use Liara T'soni from Mass Effect One as an example: she's not a very good character but lots of people love her anyway. Thanks to screen time.

Concerns
The first, biggest mistake is to think about character traits.

Traits are not what you need, and never have been. Instead, you need concerns that create screen time.

The two are very similar, but thinking about "concerns" instead of "traits" should help to drive your planning. Concerns can be things the character is concerned about or things the universe is concerned about, or both.

For example, Liara has a lot of very dull, stereotypical traits: she's cute, inexperienced, has a crush on you, likes Benezia, Spocky, a pureblood Asari, is clumsy, etc.

Converting these traits over into 'concerns' instantly helps us give her screen time related to them.

The concern version of that list might be: doesn't realize she's cute, very nervous about her inexperience, nervous about her crush, respects Benezia, wants to use logic to help, is both proud of and ashamed of being pureblood Asari, gets stuck in a lot of awkward physical situations.

By restating her traits in this way, we can quickly see a lot of scenes suggesting themselves. You can inject 'very nervous about her inexperience' into almost any scene she's in, turning her from a background character into a foreground character - giving her screen time. Any scene. You could be fighting monsters, and you could find some way to use it. "I've... I've never seen mufflebats in person before! They didn't seem quite so... vicious... in the holotapes!"

In more focused scenes, you'd probably want to use multiple concerns simultaneously - for example, she can be nervous about her crush on you and her inexperience at the same time. Or you can use contrasting concerns - she respects Benezia, but Benezia no longer respects anyone. She wants to use logic, but she has a crush on you. Etc.

Core Concerns
Notice I didn't mention Liara's core character trait: she's a nerd.

Core concerns are concerns like any other, but they're unique because they exist specifically to drive the story forward, to draw the player into the universe.

Liara's core concern is her obsession with the ancients. This is a many-pronged concern which allows her to help the player understand the ancient psychic visions, drive the player to explore new ruins, and just generally try to get the player enthusiastic about the plot by being enthusiastic about the plot.

Unlike more personal concerns, core concerns might be too hard to really generate or embed in scenes on the fly. They're too deeply tied to the story or the universe. It's probably best to simply assign them rather than generate them.

For example, if you randomly generate some royalty for your fantasy game, you can give them the core concern to pull the player into the world. King or queen, good or evil, old or young, they give the player an excuse to go various places and give the player an introductory letter to important locals. They drive the player's experience regardless of their other concerns.

Screen Time Types
Once you have concerns figured out, you need to convert them into screen time. Keep in mind that screen time requires that a character have the attention of the player. Being in a crowd shot doesn't count, nor does just randomly standing around in a room without having any interactability.

In-party commentary is probably the most subtle and reliable approach. The character simply has something to say over the course of the player's normal adventuring, without interrupting the player's normal adventuring. For example, they might comment on the place, or an enemy, or banter with another party member. These can be injected seamlessly or they can be queued up by interaction spots - for example, a nice view, or a burned-down house.

Radio commentary is a more aggressive version: the character has something to say about something, regardless of whether they're in the party or not. This is typically reserved for core concern stuff - Liara will chime in to tell you that the obelisk has been moved even if she's not in your party. Particularly good radio commentary might involve having the out-of-party NPCs doing their own, parallel thing, then radioing to report their own conclusions to their similarly-paced adventure.

Third-party commentary is when the character isn't necessarily around, but is being discussed anyway. It could be other NPCs talking about them, or a wanted poster of them, or an interview of them, or a note they left, or even just finding a relic and saying "hey, I bet Liara would like this."

Downtime commentary is a powerful and relatively new technique: between adventures, there's a base of operations, and the NPCs are scattered around in it. You can chat with any number of them before moving on with the story. This is a powerful approach because it allows you to remove most of the rest of the world's context: the chatting can progress the same way regardless of which sector of space you're in, regardless of which planet you just visited, regardless of who's in the party, regardless of who the player likes.

Fuzzy focus scenes are scenes where an NPC is obviously tangentially involved, but it's not really about them. For example, whenever you meet another Asari in ME1, it will remind you of Liara, since she was the representative of her race at the time. Or when you step in to help a doctor, Liara might step forward with good advice and back-pats, perhaps even have some scene-specific sub-branch such as manufacturing extra medicine. The focus is still on helping a doctor, but Liara is getting some screen time.

Focused scenes are when the NPC is the focus. Downtime commentary is the most common place to trigger these. It's not necessarily them solo, but they're the focus. For example, Liara might chat with you about your newfound psychic memories, or about her crush, or about the nature of the Asari... or maybe she has a scene where she and Tali are laughing at a technical joke nobody else understands, or she's helping Dr. Chakwas with some basic medical duties. As always, these scenes are built out of the concerns of the characters.

Arcs are when a series of interconnected events happen which focus on the character. Typically these are contiguous. Liara's introduction is an obvious example - most introductions are arcs. You spend some time chasing her around a facility while learning what's going on, and then you team up with her to finish the facility off. This extremely typical example is something that can be generated (or at least customized) for nearly any character, but make sure their concerns show.

Rogue Arcs are when an NPC switches sides, usually temporarily. For example, a hero might become a villain for a short while, or a villain could join the hero's side. Or maybe someone just takes some personal time and things get out of control. Because of the impact of this, the focus is usually on the rogue character. It has no other special features, though, and can be treated as an ordinary arc in every other regard.

Schedule Elements... well, a lot of generative games aren't so big on having a central plot arc, and instead focus on cyclic challenges. A character should have a distinct schedule during these cycles, making it possible to run into them in specific high-context ways. Also, they may choose to change their schedule to react to player activities. The two things to keep in mind are that their schedule should reflect their concerns, and participating in their schedule with them should result in progression, not just repetition.



Anyway, those are my thoughts:

When generating random characters, you should put a lot of effort into generating how they get in front of the player's eyeballs. Just giving them traits won't make the player care about them.

Your thoughts?

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.

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.

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.

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.