Tuesday, June 26, 2018

Background Mechanics

For the past few weeks I've been working on a new prototype which allows players to quickly "sketch" space ships into existence.

However, in order for the sketched ships to mean anything, there needs to be a world they exist within. A framework in which they can be judged. A set of rewards for doing well. A progression in the types of devices and hulls, and so on.

Any kind of stat-heavy core gameplay loop (repeatedly designing space ships, for example) needs a larger context.

Now, you could create a story. "The Earth Empire is expanding into deep space and oh no the Brikklebats from Klonor 5 are attacking!"

Or you could create a simple board-game-like set of mechanics. "The ship you created will manage to map sector 3 in 8 years, then you can build a colony ship..."

But both of those are missing the point.

See, when the player builds something, the point of the game is to glorify the thing they built. Whether it's good or bad, you want to make those good and bad aspects shine.

Games where you can fly the ship after you build it are good at this, because you can really feel that the engines you installed work well, or that the guns really aren't good enough, or whatever. But I don't want to make a game solely about ships that shoot at each other. The player is far more likely to build a freighter or a science vessel, and I need to glorify those... and there's not many games which do that.

I think the main feeling I want is that moment in a science fiction show where you see a ship type you're familiar with doing something in some episode. It could be a squad of Galaxy-classes struggling to fight off a Borg cube, or it could be something as simple as a rebel B-wing sliding into a docking bay alongside Luke's X-wing.

These ships are things you recognize, and they exist in the universe. Hell, they make up the universe. They have an ongoing role not just in one story, but in dozens of stories. They don't stop existing once you've rated them, and the fabric of the universe is woven out of these threads.

To make this something that works in a game environment where the players make the ships, we need to be able to tell those kinds of stories.

So... what if we make a star map that is entirely about creating story hooks?

Instead of placing facilities that make numbers go up, you place facilities that create stories.

For example, instead of placing a lunar mining facility to make your minerals increase, you might place a "mining concern" that overlaps the planet and the moon. This would create stories of strife between the lunar miners and the planetside miners. To place it, you would need to build some kind of freighter or mining ship. Then there would be an "episode" - a simple story where the emergency performance of your ship helps miners survive... or die. The core performance of your ship would determine how long the mining concern remains a mining concern: at the end of that duration, it would transition into established and peaceful infrastructure.

Basically, each turn the player might choose to place a concern on the map, and then either build a new ship class or assign an existing ship class to it. The simple, generated story it tells highlights the ship's emergency performance and livability, while the numbers attached to it at the end are determined by the ship's core mission functionality. The story can easily include arbitrary existing elements: interference from nearby concerns, ships inherited from old concerns in the area, named characters and ships from other episodes.

The amount of player control over these episodes is limited, perhaps even nonexistent, and the story quality is not important. I mean, they play the same role as an arbitrary random encounter in a combat game, they don't have to be genius.

They exist solely to take what the player has created and show it back to them in full glory. "You made this", the game says, "look how it works in this universe!"

With a side plate of "oh, remember this stuff from before? What a definitely-existing-and-not-at-all-completely-bullshit universe we have!"

... I think it might work.

What do you think?

Friday, June 08, 2018

Voxels and Architecture

A lot of games use voxels to allow players to build whatever they want.

But the key in that sentence is "they want".

What do they want? What will they want?

Obviously, players will come into the game with some ideas from outside. People are always going to try to build familiar things. But your design of the voxels and the rules of the game will influence what they want to build later on, when they start getting used to the game and wanting to push their limits.

Most voxel construction games have cubic meter voxels, which is a good size to allow people to build personal-scale architecture. It's a good balance of personal freedom of expression vs complexity.

With this scale of voxel, most construction voxels are simple bricks, then further decorated with detail blocks such as stairs, chairs, paintings, and so on. While those decorative elements do matter, the fundamental construction of the walls, floors, roof, garden - these are almost always done with simple cubes of various textures and colors.

Despite this, you can have quite a complexity of structural results. With just simple cubes, you can model anything from an ancient cave to a modern home to a huge castle to a mighty bridge. There are some constraints, though: it is quite difficult to model things like roundhouses, or anything else that is deeply non-orthogonal. Despite that, the variety of things you can build is pretty amazing, and you can do quite a few complicated architectural things like drop ceilings, natural light control, and so on.

Unlike those games, Medieval Engineers and Space Engineers have massive, 10 cubic meter voxels. These voxels are scaled way up because the things the players are supposed to build are not personal-scale: you're supposed to build huge battleships and massive castles.

However, because of the large scale of these blocks, they are usually not simple cubes. The players want more control than that.

In Space Engineers, the blocks are frequently angled or rounded, to allow for the common hull shapes you see in fiction. Because of this, rather than having many block types and varying between them, most space ship hulls are built out of only one or two block types. The player's efforts are spent entirely on switching the shapes of the blocks, and perhaps painting them afterwards.

Similarly, in Medieval Engineers, almost no construction voxels are simple cubes. Instead, they are common medieval castle shapes crammed into a 10m3 package. A curved wall. A gateway. Thick or thin stone battlements.

A very tightly-themed game, Medieval Engineers is focused almost entirely on castle construction. The voxels have been limited to specific kinds of evocative, themed shapes to help the audience build variants on the accepted theme.

In both cases, the theme is much tighter than in a game with smaller voxels. Nobody in Space Engineers is interested in building a medieval castle, and nobody in Medieval Engineers is interested in building a space ship... but in Minecraft, people frequently build both in the same world.

I'm not saying that these themed large blocks are "worse" than the unthemed small blocks. Once you get used to the system, it's easy to build huge, beautiful things in those games.

What I'm saying is that constraints matter.

When you put together a construction system, you're not putting together something in a void. You're building something that exists specifically to help players build stuff. The methods and the constraints are critical.

Even if you're doing standard small blocks, constraints and construction methods will radically change the outcomes.

For example, in Eco, roof tiles automatically form into slanted roof elements to make convincing roofs. This happens to have an edge case where, if you have a 45-degree roof, you end up with a stepped roof with a wonderful gap to let light in. Just this small foible is enough to create a whole slew of architectural possibilities. It influences what players want to build... even though it's just a small visual idiosyncrasy!

A more obvious example would be monsters. If you are playing on a monster-filled Minecraft server, your homes will have various ledges and overhangs to prevent spiders or creepers from being a problem. This creates a distinctive feel to many survival-mode houses.

This isn't really an ideal constraint, though, because it's not integrated into the game very well. For example, there's nothing preventing you from simply building a floating house. Going in the other direction, there's no real way to use the attackers in a more interesting way - they just randomly wander up. You can build traps for them, but the traps are usually coffinlike underground pits, not any kind of interesting architecture.

Redstone is also a missed opportunity in Minecraft, because it does not attempt to create any sort of architectural opportunity. You can see hints of what could be when you look at vertical redstone torch elements and such, but architects have to try really hard to force redstone into an interesting architecture.

Imagine if redstone had more interesting topological constraints. For example, what if a vertical stripe inverted the charge? What if parallel, horizontal redstone trails would damp each other, making both null unless both were active? What if redstone healed people nearby? What if it had to be regularly repaired by direct access? What if a redstone "window" generated charge by harvesting sunlight, instead of using a torch?

With a rethinking of how redstone works, you could easily see integrating redstone into your living space, or at the very least having a redstone system be architecture.

If you want less fanciful architecture, you could also include less fanciful constraints. Heating is not hard to simulate at that level, and including a heating system would inspire players to create lots of different heating and cooling arrangements that would be similar to the real world. Moreover, each biome has different patterns of hot and cold ambient temperatures, meaning more variation in houses!

Well... adding all these complexities naturally raises the complexity of the construction.

Space Engineers has a way to calculate whether a space is pressurized. However, because it's very hard to figure out why an area is failing to pressurize, this remains one of the most annoying parts of the game. Similarly, it allows for rotors and pistons, but because they are so buggy and unreliable, trying to use them is just an exercise in aggravation.

Adding complexity constraints is not always the right idea, but it becomes the right idea more often if you "work up to it". That is, if an ordinary construction by a newbie wouldn't encounter any problems due to it.

For example, if you have a structural integrity simulation, but it's gentle enough that an ordinary player house in an ordinary biome wouldn't be at risk. It's only when the player begins to try to build that megacastle on Mars that they have to start worrying about it. Or, similarly, if active redstone slightly healed anyone nearby, players could use it for that without having to try and delve into computation.

These sort of things are great fun to think of, and would definitely be more interesting to more players!

There are a lot of things I want to try to put into a construction game! But... even the smallest ones feel like they could make a game all by themselves.

For example, what about a construction game where you want birds to nest in your house? What about a game where views matter, either because people like them or because systems can only respond to threats they can see? What about a game where you whittle your starship hull instead of voxel-build it? What about a game where natural lighting is the most precious resource? What about a game where annoying extended family members are constantly visiting and you need to keep them impressed while also driving them away?

What I'm saying is: you can sculpt what you want players to want.

Tuesday, April 17, 2018

A Simple Game about Huge Space Nations

Like everyone else, I love and hate 4X games.

Hearing the epic story of an entire species as they romp through the galaxy weaving their ten-thousand-year story in with friends, enemies, and supernovas? Yes please!

But the actual gameplay is so bland. It always goes in one of two ways. It's either "fun at first but now we've done the same thing 50 times" or "that thing is polished away, so it's not even fun at first".

I like the stories of interstellar civilizations!

Much like I like the stories of the families in The Sims.

4X games have some elements to create a foundation for these stories. Tech trees, alien races with reliable personalities, planets with different characteristics, and so on. However, the pattern falls apart in the midgame, as playing well becomes more important than having a story.

The Sims takes the opposite approach: after you've gained a few job levels, you probably have some breathing room. You can focus entirely on leveling up your skills and jobs in The Sims, but there's no real pressure to do so. The midgame allows you to develop the stories as you see fit. In short: the beginning of the game forces you to choose an approach, and then it gets easier so you can see what kind of stories arise from the approach you've chosen.

I've been brainstorming to see if I can think of a cool 4X-like design that does something similar, and here's one I like.

One of the big issues is that fungible resources like cash are disconnected from the continuity of your story. When you spend money to do something, you're not connecting it to a previous story beat. Therefore, instead of using space cash, how about constructing chains of assets?

For example, you have a garden planet. It has four slots: two industry, two evolution.

You might choose to mount a "mining" industry onto your planet. Rather than producing cash, it has some more specific slots: materials, orbital, metropolis. You can then start to slot in things like advanced armor, orbital construction yards, and a cultural center. In turn those have slots, and you can continue to build out a chain of Things Your Species Has.

This chain allows for context to be preserved. Your space fleet was built at the orbital construction yards supported by the mining industry of your home planet. This not only gives the player cues for their internal story, but it also gives the game opportunities to create interesting challenges: if the mines run out, it's not just a matter of losing a random facility on a random planet. Within a few years your construction yard will turn into a ghost town, and a few years after that, your fleet will start to fall apart.

That's an interesting situation from every perspective... especially if we punch it up with characters that are part of this. We can seed them all ahead of time: the mine foreman, the construction foreman, the admiral. In the beginning, you meet them, and the admiral doesn't care about the mine foreman's problems... as time passes, you can see the changing situations written on the characters, as the mine foreman becomes destitute and the admiral starts bickering with the construction foreman about why his ships can't be properly maintained.

You don't have to go that far, of course. I'm just doing whatifs.

Replacing that mining industry would be a priority. The easiest solution might be to put a "fossil fuels" asset on the planet. It takes up and evolution slot and has an industry mounting slot, which you could then move the mining industry onto. Bang, everything's solved. Right?


A big part of this is that the chain of assets is not simply a chain of fungible things. The space fleet isn't simply "the same as every other space fleet but from a specific planet". Instead, the space fleet inherits all the "side effects" of its parent cards. Side effects are always passed down. Some are good, like "advanced armor". But some are bad.

The mining industry might have a side effect of "exploited underclass". This means that the docks, the space fleet, the cultural center: all would have an exploited underclass. Adding in the fossil fuel cards also creates a "toxic" side effect. Now the docks, the space fleet, and the cultural center have both an exploited underclass and a toxic side effect.

In addition to providing more materials for the implicit and explicit story we're weaving, they also provide a hook for an entire game mechanic: stories made out of the side effects rather than only the assets. The toxic + underclass combo is rife for a "black lung outbreak" story, where millions of underpaid workers are dying of toxic fumes and the corporations are trying to conceal it. This kind of story is great for allowing the player to explicitly specify what kind of space nation they're running. How far will the player go to help the underclass? To help the economy? After all, any choice they make will send a shockwave down the chain: if they spend a lot of effort on helping the miners, then the mining industry will suffer a temporary (20-year?) penalty. Halfway through that, the penalty will propagate to the dockyards and cultural center. Halfway through that, it'll hit the space fleet.

Now, the real secret of this approach is that it's only half of the system. That's the physical half, covering things and physical technologies.

The other half is the social half, covering rules, governments, cultures, social technologies, and so on.

The two sides interact. Assets for the social half are provided both by physical assets and by the vignettes inspired by physical side effects. Assets for the physical half are provided both by social assets and the vignettes inspired by social side effects.

So if you side with the miners, in addition to a physical penalty, you'll get a social card. Perhaps "worker's unions". Siding for the corporations has a physical bonus, but also gives you the social card "monstrous corporations". If you don't play them, you'll hit your hand limit and you won't get any more physical-side vignettes until you do.

You can add any additional complexity you like in terms of things like maps and factions and battle mechanics, but the heart of the system is simply a physical and social chain, where you try to manage the fallout of your older choices, especially as side effect build up.

I think it'd be fun! I prototyped it a bit, but it requires a lot more assets to work, so I'd have to put in a lot more effort to make a playable.

What do you think?

Tuesday, March 06, 2018

Methods of Topological Constraints in Base Building

I love base building games, and I love it when the base building is a challenge.

Most base building games are spreadsheet games where the checkboxes happen to be on a map somewhere. There's rarely much in the way of topological challenges - it's mostly a matter of building the right things in the right order and dealing with whatever semirandom challenges the game throws at you.

But I like topological challenges. So here's some methods to introduce topological challenges and constraints.

Time compression is by far the most common method. Most base-building games feature inhabitants which walk around your world, and they only do their jobs when they're at the right place. Since time is dramatically accelerated, this means that the time they spend going from A to B is a major part of their day. You can see this in games like The Sims, Dwarf Fortress, and any base building game with people that walk around and time that passes.

Personally, I don't much like this constraint. It is overused. It's especially bad in games where the worker AI is semiautonomous: you can't really optimize the worker's habits and instead just have to dully crowd things together and hope it works out.

Connective constraints are also quite common. This is when base component A has to be within X distance of base component B, or you need a physical wire, or some other method of constraining the shape of the base by requiring things to be within certain ranges of other things. Often this only applies to specific types of facilities - typically electrical. For example, in Fallout 4 and Rimworld you need to wire up your bases for electricity.

Some games are much more constrictive. For example, in MewnBase you have to have every pressurized unit connected directly to another pressurized unit. In Space Engineers, booster elements have to be directly attached to boostable components.

Some connective constraints are so common and natural that we don't even think about it. For example, every base-building game where you can build vertically requires the next story to be built on top of the previous story. This kind of "crushing constraint" we'll talk more about later.

Simple topological constraints is when you can only build in specific places, and the explanation is very bluntly "you can't". For example, in Dune you can only build on concrete, and extending your concrete is a major factor. In fantasy citybuilder, you might only be able to build on the valley tiles, and not on the mountain tiles. You can't build over there because you can't build over there. Simple.

This is typically a level-bound constraint - that is, the player is challenged to make their facility work within the constraints of the level. The connective constraints we discussed before are module-bound constraints instead - that is, these modules have the same constraints regardless of the level you're on. The two typically work in conjunction to put a lot of pressure on a player. These two constraints working together have produced some of my favorite base-building games.

Perimeter constraints are when there is a fitness test waged against your base in a topologically consistent way. For example, a windstorm blows through every month, always from the same direction. Invaders spawn at the edge of the map and march towards you. Space lasers hit your battleship from predictable directions while you're in battle.

While there are many kinds of fitness tests, these perimeter constraints deserve special attention because they are topologically enforced. This isn't you running out of gold or whatever: there's something producing stress on your topological perimeter, and you have to build your perimeter specifically to deal with the threat. Extending your base is often expensive simply because you have to start with your defenses!

Some perimeter constraints are more brutal. For example, if the island is constantly sinking, so after a while all your perimeter buildings are simply erased.

Topological stress constraints are similar to perimeter constraints, except they're not based around your perimeter. This is commonly used as a secondary enemy type in enemy-centric games. For example, teleporting troops pop up in the middle of your base, or there's lightning strikes that hit randomly somewhere in your facility.

These produce topological stresses, but at semirandom locations. For example, in Evil Genius, one kind of hero would dig through the walls of your base and pop up inside. The places they can arrive are predictable, but typically well inside your defense perimeter.

Building your base to withstand these arbitrary pressures is quite a challenge, and typically these sorts of threats are considered advanced or high-level, since building a functioning base in the first place is the main challenge.

There are other kinds of topological stress constraints:

Self-induced topological stresses are similar, but these are topological stresses you create with your own engineering. In a space ship game, this might be heat: you can't fire your lasers for long because you didn't put in enough nearby cooling. In a fantasy game, it could be height: building a skyscraper in Medieval Engineers is challenging because of the physics of building tall stone structures.

Personally, I think self-induced topological stresses are the most fun. I like to change connective constraints into self-induced topological constraints by adding in concepts of quantity, speed, and gravity. For example, many base-building games allow you to pipe water. In most games this is a simple connective constraint - pipes must connect to pipes. But if we introduce some basic physics, we create a lot of interesting new challenges.

At lower levels, piping water would be basically the same as if we were just doing connective piping, because that's how the physics is weighted. But when we try to bring in a lot of water, or water under high speed, or lava instead of water, we have to get really clever. Imagine trying to build a medieval castle and figuring out how to pipe in lava, or maybe using high water pressure to create a defensive cannon.

Moving constraints are rarely seen, but they are simply topological constraints coming about because you can move portions of your base. At the most basic level, this can simply mean locking the doors or raising a drawbridge when enemies attack. At more complex levels, it might involve sliding ladders, moving staircases, inflating rooms, tuck-away furniture... but I think this concept can be pushed far, far harder. We just generally don't think about it much.

Constraint Result Types
While we've talked about the kinds of constraints we might see, it's also worth talking about what happens when the constraint hits a fail state.

"Hard" constraints aren't ones that are difficult, they're ones which literally cannot be failed. You can't build on mountain tiles. You can build levitating buildings. If you somehow manage to get into an illegal state, the facility is erased - it collapses, explodes, etc.

A medium-hard constraint is one where you can get into an illegal state, but if you do, the facility doesn't immediately vanish. Instead, it is simply nonoperational or begins a countdown to death. This is often found with things like not wiring up your power-hog modules: the player is allowed to realize their mistake (or plan ahead by building illegally), then fix it up afterwards. This is also often found with things like structural stresses: the overstressed pipe doesn't immediately explode, first it springs a leak.

A soft constraint is where there's not really an "illegal" state, it's just that the state gets worse the more stress you put on it. For example, as you route more electricity through a wire, it gets hotter and hotter and you have to deal with the heat output. Or the taller your building, the thicker the lower story walls get, until they're so cramped that people can't even get through.

Anyway, those are some of my thoughts, mostly to myself. Let me know if you have any opinions on the matter.

Friday, February 23, 2018

Constructive Difficulty

As you know, I like construction games. I like building things.

But nearly all construction games make construction too easy!

I don't think the games are too easy. I think the construction is too easy. I don't need goblins attacking in waves or plague or economic challenges. I'm here for the building! Give me a construction challenge!

A long time ago, I fell in love with Medieval Engineers, because construction was a real challenge. At the time, there was no inventory: if you needed ten stone to build a wall, you had to get the ten stone within a few meters of the wall. If you were building a tower, you had to build a scaffold first, so you'd have a place for stone vertically close enough to the wall. In turn, the mechanical elements - carts and pulleys and stuff - were actually useful, because you didn't want to lug those stones up yourself, one by one!

In short order they added a magic inventory. Also, they made the buildings more structurally forgiving, because they decided to focus on warfare, and the idea was to see how well your building could survive bombardment instead of if your building could stand at all.

This ruined the game for me.

The problem is that Medieval Engineers is actually more about siege combat than anything else. With that focus, simplifying the construction and focusing on how the buildings survive sieges makes sense. It allows players to get to the meat - the sieges - faster and more robustly.

Of course, I don't give a single crap about sieges, so to me the game is now pointless. But I can't really blame the game devs for not having the same priorities as me.

I want to build. I want to have to figure out how to make a three-story building and use buttresses to keep it from falling over. I want to see how high I can build a tower, and what clever things I can do with internal supports to eke out a few more stories. I want to build a castle on a cliff and have to figure out how to wire it into the cliff so it doesn't go sliding down the mountain. These are the challenges I like.

This isn't limited to medieval stuff.

When I build space ships, I want to struggle to get them to work at all, so that when I make even small, functional rockets it feels great. Kerbal used to be quite good at this. However, as Kerbal came closer to release, they carefully dumbed down all the physics elements. It's now extremely difficult to get a rocket to fall apart: everything auto-welds and the forces have been much reduced. The game is much more focused on simple payload/fuel calculations, which isn't nearly as interesting to me.

Starship Corporation is a lot more my style, with intricate construction and extremely interesting testing phases. However, the game's difficulty doesn't revolve around engineering challenges, but around contractual obligations and research constraints. Once you understand the complex, nitpicky nature of things like power and oxygen, you can engineer a lot of interesting ships... except the game doesn't give you any additional parts or hulls until you've spent hours and hours and hours doing absolutely nothing. Again, the challenge isn't related to the construction, the challenge is based around some external measure of fitness that can't really be turned off.

There will always be some external measure of fitness, some external gating or rating system. Otherwise the game would be completely freeform. That wouldn't necessarily be bad, but it would fail to engage a lot of players. So the external ratings continue.

But these external ratings could be tied to the actual construction of stuff, instead of to how well you do things outside of construction, such as stabbing orcs or balancing a corporate checkbook.

A good example of this would be a skating game. The game is all about doing tricks and stunts. You earn scores based on your tricksiestuntness, but the scores are largely open ended.

The scoring is usually weighted to prefer long combos - meaning that you typically want to string tricks together rather than go for one ultimate mega-trick. This shapes the way you do tricks, but it's still fundamentally about your own stuntwork and allows for plenty of personal self-expression.

Alternate ratings systems - such as bonus points for being higher off the ground or moving at faster speeds - would result in different priorities for our tricks. Moreover, these would typically be just as easy to implement. It would be trivial to make it a toggle: join one team and get rated based on chained tricks. Another team, rated on speed. Another team, rated on height over the ground. Now the player has a ton of freedom to shape their own external ratings system to match their own stunt construction preference.

I want building something to feel the same way. I want my construction to feel like a neat trick chain in a skating game. Something I personally did, with my personal skill and priorities and artistry.

And that means it has to be hard to do, but also with enough slack that I can do a lot of different things for any reason I feel like.

Can that exist as a game people want to play?

I dunno.

Friday, January 12, 2018

Simple Mechanics for Compelling Games

Recently there's been a bout of compelling games using very simple mechanics. In particular, I'm going to use the mobile Marvel Puzzlequest game and Battle Chef Brigade as examples, because both create compelling and narratively-dense games using match-3 gameplay!

Using simple gameplay to make compelling games is far from a new idea. Every game does this. An RPG uses basic math. A shooter uses simple moving and shooting.

But what we're seeing these days is something a bit different. The play is more emergent than ever, and the emergent play is more narratively compelling than ever.

Everyone tells stories about that time something cool happened while they were playing a game. The ten-person raid that almost didn't work out. The time you drove a jeep into an exploding alien. When you did five no-scopes in a row. These emergent moments are extremely powerful draws, to the point where many games (like Overwatch) attempt to automatically highlight cool emergent moments.

But you don't need expensive content or complex mechanics to create those emergent moments.

For example, I just had a fight where Storm, The Thing, and Juggernaut fought Spider-Man and two of those Spider-Man variants or clones or whatever they are. It was an epic fight. Storm was about to die, but The Thing stepped in the way, took the blow, and went down himself. Even while unconscious, he shielded Storm as she called down a hailstorm. Finally she went down to a web-swinging kick, and it was just Juggernaut against them. The hailstorm helped take out two of them, but in the end, Juggernaut and the last standing Spider-man were going toe-to-toe. Juggernaut couldn't catch him, and was ready to fall over at any second. In a last, desperate attempt, Juggernaut slammed his helmeted head into Spider-Man and they both went down. A battlefield of fallen heroes. Well, the villains were stopped, and that counts as a victory for the heroes, even if they're all unconscious.

Here's the twist: that whole battle was a damn match-3 contest. There were very few visuals - just some particle effects and a few generic superhero poses flashed up from time to time.

Still, it felt properly epic in my head, and it was probably the best time I've ever had playing a match-3 game. Would it have been better with more graphics? Sure. But putting aside the juice, the fundamental play of the game allowed this story to emerge.

Regardless of anything else, we want our gameplay to allow for that kind of emergent narrative. How do we do that?

Well, first is contextual elements.

In the Marvel game, the context is really easy: the various characters on each side of the fight. We are familiar with most of the characters, or at least their templates, and therefore we can easily picture how things are unfolding. Even the assists have a character attached.

In Battle Chef Brigade, the characters on each side certainly have context, but since you're always playing the MC, that's not really a factor. Instead, it's the ingredients and judges you learn to identify. This takes more time than Marvel's context, because we aren't really familiar with the elements in BCB, but it's the same basic idea.

Context is mostly established at or near the beginning of a match. You know who's fighting, who the judges are, which ingredients are available, etc. Context can change over the course of a fight as well, but the starting context is critical. Here I think BCB does well: the various statistical effects are incorporated into high-context items like fun pots and strange knives. The Marvel game isn't quite as good, since they're just called things like "blue/green boost".

Endings are important, and not just statistically.

In the Marvel game, the end of the battle isn't just a win/lose. There's also how many resources you expended, and how long injured heroes will take to recover. But more than the statistical elements, there's the question of how the victory unrolled. Who gave the final blow? Who fell, when? I don't think that the Marvel game plays this up as much as they could, but it would probably hurt their monetization if they tried to push this any further.

In BCB, the ending also isn't simply win/lose. You are judged by several judges each. This not only gives a final win/lose, but teaches you more about the judges and what you should serve them next time. In addition to that, the dishes themselves are fun. You've created the dishes out of high-context ingredients, and seeing those transform is fun. Put in a lot of eyeball monsters, the final dish is an Eyeball Saute.

How things end is the capstone of your narrative experience. If the arches are in the right spot, the capstone holds everything together and you get a great result. If the arches aren't right, or the capstone isn't placed, the whole thing collapses into rubble.

Although Marvel's game can give us great fights with cool endings, that's not the norm. Normally fights fizzle out without much of an ending. This is made worse by the fact that the difficulty is front-loaded: the ending is almost always the easiest part of the fight, when you have the fewest enemies and the most resources to deal with them.

This isn't universally crappy, though. The statistical results of fighting mean that a battle's conclusion feels real and solid even if the ending was pedestrian. For example, if you win without taking a hit, you don't have to heal anyone and can immediately move forward, and that feels pretty great even if you were a set of level 100 heroes against a set of level 3 baddies.

BCB punches up the endings a bit better, because rather than constantly bickering with the enemy, it's a race against yourself, a race against the clock. You can feel the ending getting closer and closer, and the tension naturally rises as you move into various phases of play, judging for yourself how much time you can spend in each phase. On the downside, the enemy isn't really in your face as much. Trash-talk, interfering on the hunting grounds, and so on might help to alleviate that distance, but in the end it is an indirect conflict.

There are a variety of potential avenues towards making something like Marvel's game have better endings, and it all involves building mechanics that pace the ending better. Some of those mechanics might be in-match, such as enemies gaining resources or hitting harder as they get injured or lose team mates. Some of those mechanics might be meta elements, such as a penalty for taking overlevel characters into battle against weak enemies. Either way, they're just imaginary, there's no way to tell how well they would work without trying them out. There is a risk of locking the player into overly strict progressions, which would be just as bad as ending on a fizzle.

Midgame Management is another important element.

When you are playing a match-3, there's a lot of focus on the nature of match-3 play. Not only do you want to line up 3s, you'd like to line up 4s and 5s and double 3s and cause chains and so on. If there's no time pressure (like in Marvel's game) hunting for the best move can be as slow and careful as you like. For games with a timer (like BCB), the focus is typically on smaller grids and heuristic approaches.

Both games make "tending" the battlefield critical. In Marvel, enemy heroes get to take a turn, so it's important not to accidentally leave them with a good move. Done well, you can even trick them into destroying their own attack tiles! While there are only a set number of colors, the weights vary: some times you'll need to absolutely set up greens to insure you can stop rocket attacks, while other times you may want to hunt down that fist icon on that yellow tile. By layering effects on top of colors, the fundamental matching stays the same, but the weight of each color or region of the map changes dramatically.

In BCB, you add all the colors yourself, more or less. With a smaller battlefield and self-chosen colors, you'd think it'd be easier to manage. However, they take a Threes approach: blue isn't always blue. When you match some blues, they turn into a bigger blue that only matches with other tier-2 blues. And so on.

Suddenly the smaller battlefield is not "easier" but "more cramped". Every match you make leaves you worrying about how you'll fit in the next ingredient, and whether you can afford to temporarily knock those two tier 4 blues apart so you can make a tier 3 red... or will the pot overflow before you can recombine them?

These are very different approaches, but they both work. One creates midgame management by adding layers of meaning to various tiles or colors, whereas the other creates midgame management by steadily adding in more and more colors as you make matches.

Of course, neither is completely focused on their approach alone. In BCB specific colors do have different weights depending on the judges or the main ingredient, and in Marvel's game you do get special tiles like criticals that pop up from time to time.

Either way, adding depth to the core gameplay is an important part of keeping the player engaged. Both in terms of adding a difficulty curve and in terms of making context pop.

For example, when you are adding in your ingredients in BCB, you're thinking about whether you can get them to congeal correctly... but you're also thinking about them as Things That Exist. "Should I add more eyeball?" is a question that has both statistical and contextual meaning, and your decision will change how you think about your dish.

There are many ways of adding depth, too. For example, in addition to everything else, in Marvel's game, whoever has the best "attack value" with a given color makes an attack when you match that color. This also leaves them on the front line, and they'll take any damage thrown at your team. This makes managing high-power attackers with low health a fun challenge which evolves over the course of the game as health values fluctuate.

Mix-ins are a big part of making simple gameplay support complex contexts.

In Marvel, your heroes (very high context) are given additional context by their powers. As you make matches, you earn points of various colors, and the various heroes have powers that cost points or are affected by specific colors in various ways.

The diversity of powers is enormous. For example, The Thing has a power where he'll step in front of squishier characters and also create protection tokens, only moderately affected by board state. Kraven the Hunter will diminish enemy tiles and steal mana if there's a lot of enemy tiles. Hawkeye can create a critical, or wipe out a row of tiles. Storm and Juggernaut both have a green ability to smash tiles: Juggernaut smashes more tiles, but Storm earns mana from smashed tiles.

These modifications are not technically part of the match-3 game. They're another game layered on top - they affect each other, but are separate kinds of play. The link between the two is quite tight in this case, largely because there's no time pressure, so the player can just sit and think for a bit about the various options.

In BCB, the alternate game mode is much more distinct: you go out into the wilderness and hack apart monsters for ingredients. Since there's a lot of time pressure, the modes only loosely interlock. That way the player can stay focused - trying to stir your food pot while hacking up a wolf would be considerably more stressful and difficult.

In an RPG you sometimes think of these sorts of things as the other play loop. Like, you explore a dungeon, fight random monsters, get treasure, level up - and each of these are distinct elements.

However, in these simpler games we're seeing, the mix-ins are literally mixed in. They weave in and out of the normal play loop. It'd be like if you leveled up mid-fight and had to choose exactly what bonuses to take before the fight continued. In a classic RPG this would be a bit weird, because the battle system is engineered to keep your whole focus the whole time, so bopping off to do something else for a moment would break your groove.

But with these simpler games, you can wander in and out of the main play without really losing too much focus, since a glance at the board will remind you of where you stand. Moreover, this wandering can be used to radically increase the context of the play and provide additional story beats. When Storm summons hail, it's Storm summoning hail. It's not just a statistical effect: your board and play state is now coated in Storm's story beat. Similarly, killing an eye monster and bringing it back to throw in your pot adds a ton more context to your pot, much more than if you just had a giant stack of eyes on a shelf to throw in.


I used match-3 games as an example, but I think this can be done with any kind of gameplay. You can even dissect existing complex gameplay as two or three kinds of simple gameplay mixed in - running and gunning is [running] and [gunning]. RPG battles are [initiative] and [math]. It's a fun thought, although I'm not convinced it's a good universal framework.

But it can be fun to analyze that stuff with this new eye. If your game is [initiative] and [math] mixed together, can you use the lessons learned here to punch up the context, the ending, the midgame management, and the mixin? It might be really interesting to try to create an RPG that's been re-engineered from scratch to focus on in-battle emergent narratives.

Anyway, those are my thoughts. What do you think?

Thursday, January 11, 2018

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?