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.
Showing posts with label voxel. Show all posts
Showing posts with label voxel. Show all posts
Friday, June 08, 2018
Thursday, February 05, 2015
Voxel Parkour
Let's talk about parkour voxel games!
This will have two parts. One: technicals of parkouring on voxels. Two: Why the hell would we use a voxel game?
Most parkour games are magnetic. Setpieces are put in the game world specifically to attract your parkouring, and if a jump looks a bit risky, your character will usually snap to the target in a very forgiving manner. This is because parkour is all about judging distance and speed, but in the average 3D world it's a bit difficult to do. So they simplify it by making a pretty clear dividing line between "obviously OK" and "obviously not OK".
In a voxel world, you can read distance and speed pretty well, out to about 6 or 7 bricks. So if your jump is 3.5 bricks, you'll quickly be able to determine whether you can make it or not.
Nothing is ever simple, though, because that's when you're running orthogonally. If you're running across the blocks diagonally, the actual distance is much harder to judge.
Well, that's not actually a problem. When a distance is near their jump limit, players will naturally align themselves square with the jump - IE, orthogonal. The only times players will jump at an awkward angle is when they're pretty sure they'll make it and don't need to try very hard. So there's no need to restrict the player to orthogonal movement like in the original Tomb Raiders - we can just assume the player will square off naturally if a jump looks difficult.
There would still be some gotchas - like a knight's move jump, for example. But in general, that'd work, especially if ledge grabbing is pretty forgiving.
In these case we've been talking about jump distances of 3.5 bricks. That sort of implies the bricks are quite large - perhaps a cubic meter. That's larger than an average voxel game.
Well, the smaller the bricks (or the longer the jumps), the more difficult it is to read distances and the more complex layouts become. Large blocks are easy to read, so in this world that would be the voxel size. Of course, you can add a lot of complexity to that. For example, design your own blocks using cubic centimeter voxels to build a cubic meter voxel. Or have 'small voxels' for things like chairs and books and stuff, but if you use them, that voxel becomes too cluttered to run through and the character either trips or slows to a walk - basically, if you shrink the voxel size, you necessarily shrink the player's mobility to match.
Anyway, there are other technical concerns when building a parkour game - parkour moves, inertia, camera motion, etc. However, none of those seem particularly voxel-centric, so let's gloss over them and move on to WHY?
...
Why build a voxel parkour game?
In general, you can think of a parkour game as oscillating between linear and exploration segments. Something like Mirror's Edge is mostly linear segments, with exploration limited to finding the path the developers allow you to take. Something like Crackdown or Assassin's Creed is mostly exploration, with the only linear sections being challenges or you trying to get through an area as quickly as possible because you've been here before.
As you might expect, if a game has more exploration segments, then the game needs more things to find. Crackdown and Asscreed are both littered with collectibles, side missions, and random encounters, as are most games with an open-world feel.
The old Tomb Raider games took this another direction: they were primarily exploration, and there were certain collectibles to find, but the core thing to explore for was puzzle solutions. This has fallen by the wayside in recent years, because nobody likes spending time thinking about how to do something... but in our voxel game, it might be worth reconsidering.
See, the strength of a voxel game is player-created content. Voxels are very easy to comprehend, and players can place them in a straightfoward way. However, a player's capabilities are limited: they can only visualize so many blocks at once, and the UI only allows them to place blocks in certain ways. Minecraft's relatively small voxels may seem like a strength, but they are also a weakness: the scale at which most players build is quite small. Most players never build anything larger than a medium-size mansion. It's just too annoying. If you're going to build something bigger, you usually use a tool assist to make it easier.
Obviously, all of this varies. But the point is that if we want a parkour game, we have to allow player creations to be large enough to be fun to parkour. A single player needs to be able to create a small city, so that visitors can parkour on it.
In just raw voxel terms, using larger voxels is a big help. Tomb Raider's original voxels were about 2m on each edge, which is probably about right if we want players to be able to create cities... but it requires a huge variety of voxels. Walls that are two meters thick are absurd, and ceilings that thick are doubly so... which means that the voxels would have to be complex baked objects. This is a "floor and wall and ceiling" voxel. And it's cousins for every wall configuration. And windows. And doors. It gets really complex.
I think the best solution is to use a "voxel chunking" system. This is pretty straightforward: voxels might be, say, 25cm per edge (about a third of a Minecraft block), but you have to lay them down in 10x10x10 chunks (2.5m, about the size of one floor of a building). When you're in "build mode", the system highlights each chunk boundary with maneuverability by simply looking at the voxel layout. If the top edges are filled out with solid voxels, it can be ledge-grabbed. If the remaining 8x8 top blocks are filled out, it can be run across. If a subset of that is filled out (say, 4x8), it's a narrow beam which can be slowly walked across. If it's a subset of that (say, 3x3), then it's a point that can be stood on, but it's jump-on, jump-off. The walls determine your wall-jumping and wall-running capabilities, but the interiors of the voxel are wholly unimportant to the parkour engine. If you enter into one of these blocks, you stop parkouring and start walking slowly, and collisions are determined at the smaller scale.
A bunch of physics heuristics can also be applied, chunking your 10x10x10 object into a particular combination of pressure points, mass, and rigidity. That's optional, but it's always nice to have a powerful simplification available.
From the player's perspective, this voxel-chunking system works in a different way. Rather than "building up" your house, you "build down" your house. You place solid 10x10x10 voxels of the material you like, and then you clear away the insides using simple tools that clear away specific surface sizes. So you block out your world, then hollow out the areas you want hollowed out, and then you edit per-voxel. Unlike Minecraft, there wouldn't be a whole lot of special-case voxels, because our detail level is high enough to let the player craft chairs and windows and such without having them prefabricated.
We can also have shortcuts pretty easily. For example, if you block out a building then assign an NPC to finish its construction, the NPC will intelligently carve out the interior, create windows and doors and interior walls and furniture etc. Different NPCs might have different preferences, or if multiple NPCs are assigned the same building they might carve out pieces in different styles... there's lots of fun options if we want to spent some time creating algorithms for helping the player.
All of that complexity boils down to a surface simplicity. When the player is dashing, all they care about is which surfaces are solid. But when a player is not dashing, they can enjoy the complexity of the high-detail regions.
Building large is good, but exploring that world needs to have benefits. You want things to do and to find.
Sometimes, the player will place things to find or do - players will certainly enjoy creating dungeons full of traps and puzzles. However, I think players should also be allowed to nurture these into existence.
If a player builds a city, I'd like to see that same player dashing through the city, climbing, looking in alleys, peeking in subways and homes. And to incentivize that, I think the structures players build need to exist as more than empty buildings. I think NPCs, plants, and animals need to inhabit this world.
When you assign these things to live in your various creations, you do so with the understanding that after in-game time passes, they will create some useful resource. Fruit, magic essence, books, leather, whatever. But the rules as to how they appear and how they stack can be varied and interesting, meaning that as you become better at the game you'll learn to create more efficient housing, more interesting machines. And dash through them.
By making windows and streets an important part of whether an NPC is happy, you can make players block out cities rather than giant warrens. You could also introduce structural limitations - building out of stone or wood could result in specific stresses and buildings could collapse if built too tall or spidery... well, it could be really fun to experiment with the various restrictions and what sort of complex, parkourable structures arise. Especially if you start mixing together player content semirandomly into large, shared cities...
Well, add to that some kind of mechanical/electrical thing, and you have quite a game.
This will have two parts. One: technicals of parkouring on voxels. Two: Why the hell would we use a voxel game?
Most parkour games are magnetic. Setpieces are put in the game world specifically to attract your parkouring, and if a jump looks a bit risky, your character will usually snap to the target in a very forgiving manner. This is because parkour is all about judging distance and speed, but in the average 3D world it's a bit difficult to do. So they simplify it by making a pretty clear dividing line between "obviously OK" and "obviously not OK".
In a voxel world, you can read distance and speed pretty well, out to about 6 or 7 bricks. So if your jump is 3.5 bricks, you'll quickly be able to determine whether you can make it or not.
Nothing is ever simple, though, because that's when you're running orthogonally. If you're running across the blocks diagonally, the actual distance is much harder to judge.
Well, that's not actually a problem. When a distance is near their jump limit, players will naturally align themselves square with the jump - IE, orthogonal. The only times players will jump at an awkward angle is when they're pretty sure they'll make it and don't need to try very hard. So there's no need to restrict the player to orthogonal movement like in the original Tomb Raiders - we can just assume the player will square off naturally if a jump looks difficult.
There would still be some gotchas - like a knight's move jump, for example. But in general, that'd work, especially if ledge grabbing is pretty forgiving.
In these case we've been talking about jump distances of 3.5 bricks. That sort of implies the bricks are quite large - perhaps a cubic meter. That's larger than an average voxel game.
Well, the smaller the bricks (or the longer the jumps), the more difficult it is to read distances and the more complex layouts become. Large blocks are easy to read, so in this world that would be the voxel size. Of course, you can add a lot of complexity to that. For example, design your own blocks using cubic centimeter voxels to build a cubic meter voxel. Or have 'small voxels' for things like chairs and books and stuff, but if you use them, that voxel becomes too cluttered to run through and the character either trips or slows to a walk - basically, if you shrink the voxel size, you necessarily shrink the player's mobility to match.
Anyway, there are other technical concerns when building a parkour game - parkour moves, inertia, camera motion, etc. However, none of those seem particularly voxel-centric, so let's gloss over them and move on to WHY?
...
Why build a voxel parkour game?
In general, you can think of a parkour game as oscillating between linear and exploration segments. Something like Mirror's Edge is mostly linear segments, with exploration limited to finding the path the developers allow you to take. Something like Crackdown or Assassin's Creed is mostly exploration, with the only linear sections being challenges or you trying to get through an area as quickly as possible because you've been here before.
As you might expect, if a game has more exploration segments, then the game needs more things to find. Crackdown and Asscreed are both littered with collectibles, side missions, and random encounters, as are most games with an open-world feel.
The old Tomb Raider games took this another direction: they were primarily exploration, and there were certain collectibles to find, but the core thing to explore for was puzzle solutions. This has fallen by the wayside in recent years, because nobody likes spending time thinking about how to do something... but in our voxel game, it might be worth reconsidering.
See, the strength of a voxel game is player-created content. Voxels are very easy to comprehend, and players can place them in a straightfoward way. However, a player's capabilities are limited: they can only visualize so many blocks at once, and the UI only allows them to place blocks in certain ways. Minecraft's relatively small voxels may seem like a strength, but they are also a weakness: the scale at which most players build is quite small. Most players never build anything larger than a medium-size mansion. It's just too annoying. If you're going to build something bigger, you usually use a tool assist to make it easier.
Obviously, all of this varies. But the point is that if we want a parkour game, we have to allow player creations to be large enough to be fun to parkour. A single player needs to be able to create a small city, so that visitors can parkour on it.
In just raw voxel terms, using larger voxels is a big help. Tomb Raider's original voxels were about 2m on each edge, which is probably about right if we want players to be able to create cities... but it requires a huge variety of voxels. Walls that are two meters thick are absurd, and ceilings that thick are doubly so... which means that the voxels would have to be complex baked objects. This is a "floor and wall and ceiling" voxel. And it's cousins for every wall configuration. And windows. And doors. It gets really complex.
I think the best solution is to use a "voxel chunking" system. This is pretty straightforward: voxels might be, say, 25cm per edge (about a third of a Minecraft block), but you have to lay them down in 10x10x10 chunks (2.5m, about the size of one floor of a building). When you're in "build mode", the system highlights each chunk boundary with maneuverability by simply looking at the voxel layout. If the top edges are filled out with solid voxels, it can be ledge-grabbed. If the remaining 8x8 top blocks are filled out, it can be run across. If a subset of that is filled out (say, 4x8), it's a narrow beam which can be slowly walked across. If it's a subset of that (say, 3x3), then it's a point that can be stood on, but it's jump-on, jump-off. The walls determine your wall-jumping and wall-running capabilities, but the interiors of the voxel are wholly unimportant to the parkour engine. If you enter into one of these blocks, you stop parkouring and start walking slowly, and collisions are determined at the smaller scale.
A bunch of physics heuristics can also be applied, chunking your 10x10x10 object into a particular combination of pressure points, mass, and rigidity. That's optional, but it's always nice to have a powerful simplification available.
From the player's perspective, this voxel-chunking system works in a different way. Rather than "building up" your house, you "build down" your house. You place solid 10x10x10 voxels of the material you like, and then you clear away the insides using simple tools that clear away specific surface sizes. So you block out your world, then hollow out the areas you want hollowed out, and then you edit per-voxel. Unlike Minecraft, there wouldn't be a whole lot of special-case voxels, because our detail level is high enough to let the player craft chairs and windows and such without having them prefabricated.
We can also have shortcuts pretty easily. For example, if you block out a building then assign an NPC to finish its construction, the NPC will intelligently carve out the interior, create windows and doors and interior walls and furniture etc. Different NPCs might have different preferences, or if multiple NPCs are assigned the same building they might carve out pieces in different styles... there's lots of fun options if we want to spent some time creating algorithms for helping the player.
All of that complexity boils down to a surface simplicity. When the player is dashing, all they care about is which surfaces are solid. But when a player is not dashing, they can enjoy the complexity of the high-detail regions.
Building large is good, but exploring that world needs to have benefits. You want things to do and to find.
Sometimes, the player will place things to find or do - players will certainly enjoy creating dungeons full of traps and puzzles. However, I think players should also be allowed to nurture these into existence.
If a player builds a city, I'd like to see that same player dashing through the city, climbing, looking in alleys, peeking in subways and homes. And to incentivize that, I think the structures players build need to exist as more than empty buildings. I think NPCs, plants, and animals need to inhabit this world.
When you assign these things to live in your various creations, you do so with the understanding that after in-game time passes, they will create some useful resource. Fruit, magic essence, books, leather, whatever. But the rules as to how they appear and how they stack can be varied and interesting, meaning that as you become better at the game you'll learn to create more efficient housing, more interesting machines. And dash through them.
By making windows and streets an important part of whether an NPC is happy, you can make players block out cities rather than giant warrens. You could also introduce structural limitations - building out of stone or wood could result in specific stresses and buildings could collapse if built too tall or spidery... well, it could be really fun to experiment with the various restrictions and what sort of complex, parkourable structures arise. Especially if you start mixing together player content semirandomly into large, shared cities...
Well, add to that some kind of mechanical/electrical thing, and you have quite a game.
Subscribe to:
Posts (Atom)