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.