Good Bad Game Design Pt 2

Today, I'd like to talk about construction games. But I do need to revisit the last essay on RPGs, because that has direct bearing.

I discussed good bad RPGs. Basically, open-world RPGs are often considered "badly designed" - poor characters, weird pacing, 'dull' mechanics. However, judging them by more linear RPG standards is a mistake. Open world games have different specialties and their best kinds of play are different from what we have grown used to. You can't judge them by linear standards, and liking one genre doesn't mean you'll like the other.

One of the biggest features of a linear RPG is the main quest. It's right there in the name of the genre: "linear" RPG. So you have a central rail, a quest that the whole game is hung from. This affects everything about the linear RPG: how you fight, how you get and spend resources, how you level up, who you can interact with, what you can do. With a strong core, you can create a wonderful game.

In an open-world game, the main quest is typically something you do when you get bored of goofing off.

Instead, we choose our own path. There are many tiny quests scattered around the world, and we can pick them up whenever we want. Some of them might be multi-part and pretty epic, but in general they are smaller things. Moreover, the fundamental nature of progression in the game world allows us to improve along a path of our choosing even if we don't do any of those side quests. Combined, this gives us a huge amount of freedom to play as we like.

The slack built into that kind of design also allows us to easily include mods. Since there is no core quest constraining us, it doesn't matter if we include a mod that turns all the NPCs into zombies and adds a giant volcano right where you normally start the game. Everything still "works fine".

We could polish this! We could make open world games with that in mind from the start. An environment to carve a path through, rather than a train ride to enjoy.

...

This is exactly the same as construction games.

In the past, construction games were mostly linear. You had levels and challenges and you built to achieve those goals. There were some games that were more open, such as Sim City, but there was no content or systems in place to allow the player to truly forge their own path. The kinds of things you could do were quite limited, even if you had freedom to do anything the game could allow.

The ur-example of a linear construction game is The Incredible Machine. If linear vs open world is a spectrum, that's pretty far to the 'linear' side.

As time went on, we became better at allowing for any kind of construction.

However, we still aren't very good at it. Our "open construction" games are a lot like the early Final Fantasy games. FF6, FF7 - these allowed you to go a wide variety of places, do a lot of things. But they aren't truly "open world", because the structure doesn't reward you carving your own path.

Many other games are more truly open world. Sure, recent games like Fallout 3, Skyrim, etc. But also archaic games like Wasteland, Fallout 1, etc. The difference is not technology, it's design.

These games are structured to reward doing things however you want. The progression system is open enough that you can progress in any direction. The world is designed to offer quest fragments to you no matter where you wander. The world is structured "lumpily", so you can switch between different gameplay experiences by simply moving around - wandering the wilds, delving dungeons, or talking in towns. The player chooses which kinds of things they want to do when, and how they want to do them.

Although FF6 is a fantastic game, it isn't open like that. There is momentum built into the game, both in terms of how your stats progress and how the world quests progress. Although you can "go anywhere", there is no contiguous reward chain for going wherever you want, and there's not really much variety in the kinds of approaches you can take.

Anyway, that's where we are with open construction games.

Games like Minecraft are open construction games in the same way that FF6 is an open world RPG. You can go anywhere, build anything, but the universe isn't configured to reward you for it. Normally, the community is responsible for rewarding you for building things. That's a different topic for another day, but the point is that we can design the game itself to shoulder some of that responsibility.

Space Engineers is a bit more open than Minecraft, largely because it has more construction pressures that you can choose to optionally enable. You can choose exactly how much inventory space should be multiplied by. Whether guns need ammo. Whether power is unlimited. Whether you have to weld blocks, and how fast. Whether engines damage nearby blocks. Whether blocks can be damaged at all. Whether stations can be shaken free. Whether there are enemies, and how many, how often, how close. How safe the world is from natural catastrophes.

In addition to those environmental factors, the universe also allows you to tackle specific engineering challenges as you see fit, both large and small. Pressurized environments? Renewable energy? Docking allowances? Interior defenses? Cryo chambers? Medical bays - wired or unwired? Turrets? Mining? Refining? Natural gravity? Planets? Cars? Tools allowed or banned? Jetpacks allowed or banned? All of these can be tackled in any combination.

The way construction and use can be decoupled offer additional challenges. You can build something in creative, but intend it to be used in survival. Or perhaps it was planned in creative, and you use a blueprint to slowly manufacture it in survival. Or maybe it was created in survival right from the start, painstakingly assembled block by block. The resulting ship is just a ship, but the exact method of its design and construction radically changes the experience.

There is also room for your own personal ideas - recreating a popular starship, or making a starship that's actually a challenging adventure map, or trying to make a personal ship that suits a fictional character you created. A planetary base, a floating chair, and office building - things that make no sense in the context of the game, but make sense to the players.

The freedom to approach your construction in such a wide variety of ways, with such a wide variety of goals and such a wide variety of optional challenges is very "open".

Add in mods, and it all extends even further.

...

Space Engineers is a bad construction game. Compared even to something like Minecraft, it is needlessly complex without adding much of value. But those judgments don't apply very well, because Space Engineers is not a survival crafting game, nor is it a linear construction puzzle game.

Space Engineers has a survival crafting element in it, but only as an optional challenge. There is power in tackling that challenge - but the challenge is not a lump sum. You can challenge it piecemeal - create a mining ship in creative, build a refinery in survival, change the inventory rules, alter the assembler speed multiple, switch back into creative...

Space Engineers isn't structured "perfectly". I don't think it pushes things anywhere near far enough, and the bugs inherent to its multiplayer wall off at least a dozen kinds of play. But you can see hints of how things could go: a construction game where you tackle challenges with a huge amount of freedom.

One thing Space Engineers doesn't have that an open-world RPG does have is continuity. It's not easy to "chain" your constructions, so there's not much sense of history or progress between builds. I would like to see a game where designs were "chained". You build a mining vessel, and then there's some kind of reward or flow to building a refinery base that interfaces with it. You build a frigate and then there's some kind of flow or reward for building a fighter or a carrier or something that travels with it.

Space Engineers cannot do this because they have more technical debt than any other game I've ever seen, and are too creaky to implement something like that. But it's certainly possible.

Anyway, I originally had a lot more to say. I wanted to talk about Kerbal, and Dragon's Dogma, and some theoretical game designs, and adding human elements... but this is the fourth time I've written this essay, so I had better stop.

Hope you found it interesting!

Unbounded Construction: Construction Elements

Last post, I talked about the "unbounded construction" genre. Today I'd like to hammer out some of the nitty-gritty details.

The genre requires small, modular pieces that can be combined in a lot of ways. The constraints imposed on these pieces are partly from the game (engines require power) and partly from the player ("I'm building a luxury liner!") These constraints shape and are shaped by the player's vision, and different players will choose very different constraints.

The pieces and the interface are both critical in allowing the player to build their vision.

First, component size is critical. Humans are a specific size, and therefore most of the things we care about are a similar size. It varies from player to player, but most players have instincts in line with their life experiences and media habits. That is, most players want to build something between the size of a car and the size of a mansion. Larger or smaller things are generally reserved for advanced players.

The component size reflects this.

If we're talking about voxels, the ideal size seems to be about 2/3 a meter per side: roughly a 2x2x2 foot cube. Any smaller, and it becomes annoying to micromanage the shapes. Any larger, and it becomes difficult to get the result you envision.

But that's not an absolute. Most voxel-based games have objects larger or smaller than a voxel.

Moreover, the tool you use to lay down structure matters more than the size of the modules. When we're laying out chairs and windows and desks, we want to have control over things at a human scale. But if we're laying out the house or starship or a castle, we need control over the mass of the structure. Laying out the halls and rooms and walls and floors needs to be largely painless.

In Space Engineers, the large ships use a 2.5m voxel. This is great for laying out the ship - you can lay out a mansion in space with ease. However, you are then stuck using 2.5 blocks for interior layout, which is not ideal. Their small ships use an almost ideal size for interior layouts... but is it troublesome to lay out?

Not really. The UI allows you to put down lines and fields of blocks, so the only shape that is difficult is a slanted or filled area. A slightly more advanced UI could even polish that away.

It's no wonder that "overgrown small ships" have become popular. You can get really beautiful human-scale shapes with them. The downside is that they take a lot of processor speed due to the high voxel count, but that's not really a fundamental problem, it's just sloppy implementation.

Still, it's a bit difficult to lay out the structure of an overgrown small ship. It would be better if there were a different interface for laying out structure and laying out the interior.

Apparently Keen thought so as well, because their next game, Medieval Engineers, has just that. Using the same 2.5m blocks for structure, they allow you to lay out interiors using arbitrarily sized furniture elements.

This is a promising approach, but it also has some idiosyncracies.

The first one is that the game is built around structural integrity. This unfortunately means that if you are building in "physics mode", you can't simply tear out walls to replace them with windows: the building will collapse between those two actions. Moreover, the roof is quite hard to get right, meaning that even if you lay the space out properly, you will find a last-minute constraint has made it difficult to complete your construction.

You can argue that these are good things, that they make the game more interesting. Maybe. However, the average player will take substantially longer to learn the skills required to complete a basic house. Generally speaking, that's a bad barrier to entry.

If that issue is with the "engineers" in "Medieval Engineers", the other problem is with the "medieval".

Fundamentally, medieval buildings are not space ships. The inhabitants are largely integrated into the world around them, and medieval folks spent most of their time outside rather than slouching about in their huts. Conversely, a space ship is an integrated environment that has to take care of all the inhabitant's needs all the time.

When you build a space ship or space station, you are building someone's lifestyle. The interior is where the crew will spend every waking minute, and the systems you install are what keep the crew alive as they do their tasks. Their air comes from a known source, their entertainment from a known source, their food from a known source, their health care from a known source. If you think of it, you'll have a plan for how the space ship provides for every aspect of their life and lifestyle.

But if you build a medieval house, you are building only a small portion of someone's life. Basically, that's where they eat, sleep, and store their potatoes. Maybe they get stuck inside on rainy days.

They get food from the local shops staffed by hundreds of people. They get health care from a doctor on the other side of the town. They get their entertainment by gathering in public spots with other people.

The simple truth is that sci fi settings give you an excuse to package up people's lives into STUFF. Since you can place stuff, you can place lives. You know the sort of lives people will live on your star ship because you've placed all the aspects of that lifestyle as you created the ship.

Fantasy does not give you that leverage. If you build a house, you have built only a tiny fraction of someone's life. You need to build a whole village, or a whole farm, or a whole encampment. A building is only a tiny fraction of the puzzle.

This isn't too hard to understand once you start considering it. Most of the good Medieval Engineers shared worlds are villages, and as you wander through them you see all the same pieces you would have put in a star ship as a component. The forge is its own building. The grocer's, the butcher's, the doctor's, etc.

This has huge advantages over sci fi, too. You can create a village where the butcher is also the doctor, or a village where the town teacher is married to the town carpenter, etc. Rather than a machine that is always shaped a specific way and takes up a specific amount of space, the roles of people in your village are flexible and can adapt to your vision.

But...

Medieval engineers does not have even the smallest allowance for describing people. Only buildings.

Yes, you can build a village of hunters by creating all the buildings hunters need. But you can't put even one hunter in the game, let alone describe him as living in a specific building, doing specific tasks, having a specific lifestyle, having relationships with specific other villagers...

Unbounded construction in a fantasy setting needs to allow you to construct the one thing that gives it power: people.

Once you allow for that, there's really very little reason to do any kind of complex structural simulation. Buildings exist to support the people of the village, not on their own.

So... what's the UI for placing and relating people? Is each building and inhabitants a construction that can then be slotted easily into village frameworks, or do you build the whole village at the same time, like you build an entire starship?

So many questions.

Those are today's thoughts on Unbounded Construction.

Unbounded Construction: An Emerging Genre

The genre is outpacing the fore-runners.

Space Engineers, Kerbal, Medieval Engineers, Minecraft, and many similar games have started to create a pair of new genres. We're going to ignore the "survival crafting" genre, and instead focus on the "unbounded construction" genre.

Players have always wanted to build anything they please, and devs have always struggled to let them. But it requires three things, and only in the past few years have all three become widely available. The raw power to render and simulate large constructions. The fast, fluid UI to allow players to quickly build, refine, and import their constructions. The easy, integrated sharing of constructions.

These three recently came together to form a new genre.

It's becoming clear that the fore-runners of the genre aren't what the genre will look like in the long run. Let's see if we can talk about what the genre might become.

(Of course, maybe I'm the only one seeing this genre, but let's look at it anyway.)

The genre's name gives away what I consider the core concern: unbounded construction. But we've always tried to create unbounded construction. What makes something like Minecraft different from something like Sim City or Civilization?

Well, when I say "unbounded", I mean unbounded in the logical sense, not the logistical sense. I don't simply mean you have a limitless plain to plunk down physical blocks. I mean that you can invent your own purposes, build to meet your own goals and tell your own stories. Your visions can be pushed into the game, and the game can inform your vision.

In Sim City, you could build a big midwestern city. Just that. You couldn't build anything else you wanted. If you want to build a replica of ancient Greece, you can't: the buildings are clearly modern midwestern American. You want to make a Martian city? No dice. The pieces just don't match up.

But if you make the pieces small enough and the canvas large enough, you can get a lot closer to your vision. You can pack more customizable details into more space.

In Minecraft, you can build a replica of ancient Greece. Sure, the pillars are weird and square, but you can get pretty close. In Space Engineers, you can build a Martian city. Sure, the cargo pods look different than you would like, but you can get pretty close.

Each individual piece might not match perfectly, but you can choose where to place which pieces, and the result is pretty good. It's the Lego approach.

Moreover, modding is a lot more powerful at this scale. If you want to simulate ancient Greece in Sim City, you have to find an ancient Greek buildings pack, which is awfully specific. But in Minecraft, you can scrounge together a variety of generic medieval parts and come out with a pretty convincing Greece. Similarly, if the cargo pod in Space Engineers bothers you, you can replace it. You don't have to find a "Martian city" mod pack, you can just find a slew of random parts that are closer to your vision.

This "small parts" approach is very powerful for those reasons and more, but it requires some things that weren't available until recently: a massive amount of computational power, flexible UI, and integrated networking.

Computation allows us to combine the many small pieces into an integrated whole, including functional pieces such as doors and machines. Moreover, computation allows us to execute code on the fly, integrate new models and textures, and do other things that used to be too difficult to really allow. This allows modding to be plausible, allowing us to create new parts.

Computation also allows us to have much more intricate emergent scenarios. This is just starting to come out, because it requires a whole new class of play. You can see hints of it in Space Engineers when ships collide, or in Kerbal when you try to use 60 mods at the same time.

The flexible UI is absolutely necessary as well. When you have a lot of small parts and a big canvas to paint them into, you need average players to be able to do so without getting confused. Without a tutorial.

This is partly accomplished through a new class of UI controls involving flexible lists and adaptive spatial interactions, but it's also accomplished by simply evolving player familiarity with controls. Modern FPS controls are extremely complex and opaque, but because the audience has played so many of them, they quickly grasp whether this game allows for parkour, what the weapon switch button is, whether the reload has a timing event, etc, etc.

We're seeing the same thing here. Minecraft's clunky construction controls have given way to Space Engineer's more powerful, fluid interface. But even that is clunky compared to where we're going: the emergence of VR and AR will create a new class of immersive interfaces that will rapidly evolve. While unbounded construction probably won't be explicitly VR/AR, it will benefit from those UIs and steal them wholeheartedly.

The integrated networking is necessary in order for the game to have a powerful, flexible metagame. This is not simply a nice perk: it's a core part of the genre. You need to be able to show off your creations, and see where your creations fit into the grand scheme of things. You need to be able to see the wonders other people have created in order to be inspired to create your own. You need to be able to steal techniques. You need to be able to cooperate and compete in construction, not just in gunplay. You need to be able to get mods or even whole worlds to integrate into your vision.

At the moment, Space Engineers has the best integrated networking around - automatic mod sharing, quick and easy ship/world sharing, a place to chat and share pictures/vids, all built into a reasonably large existing user base (Steam users).

But, again, Space Engineers is already showings its age. The content isn't properly integrated into the game experience, and it isn't properly partitioned away. In the end, we will see unbounded construction games where mods are local to each ship or town, not to each universe.

It's not that Space Engineers is bad, it's that the concept is bizarre and wasn't even on the radar when the game was laid out.

... I should stop playing Space Engineers and finish programming some of this stuff, I guess.