Screenshot saturday #7 and map editor video

New screenshot based on what I’ve worked the most these days: improving the environment. To do this, the map editor has been upgraded (check the video below to see it in action), the biomes has been slightly reworked, a sea level has been added and both a vertical fog and an horizontal fog has been implemented. Nothing ultra fancy but the rendering is quite better, and it now allows to find some interesting sceneries that I’m not necessarily aware to create when editing the map from above. For example, this scenery :

Moutain view
Newly added water and far distance fog on a small moutain equals to a somewhat nice view.

And here the video showing the map editor. Quick and efficient with the procedurally generated biomes transforming a plain heightmap into green hills, rocky mountains, or sea shores:

Character style

Another long time since the last update. Not much happened regarding features development, but I’ve fairly well advanced on the character style, enough to show more properly what they’ll look like in Metaworld. No big suspense since people can immediately see it, this is how they’re looking :

Metaworld voxel characters
Metaworld voxel characters : remembrance of character sprites from the 2D era.

Chibi looking, somewhat cute, big heads with room for facial features, small bodies, closer to SNES/Game Boy character sprites than to 2015 AAA character models. I’m fully aware that comparison will probably be made with other games (Cube World ahead), but I expect experimented eyes to be able to make the difference!

My objectives with this character style were various.
If there’s one thing that I like when playing RPG, it’s to create characters. I can waste hours there. When it’s well-done, not only does it allow one to have a (potentially) unique character, but also a recognizable character. But sadly… Many RPG/MMORPG does not have a well-done character creator (for my tastes, at least).
The current trend seems to have powerful tools for face customization, but little to no body customization. This focus on faces is something that I’m struggling to understand. Faces sure does allow one to have a unique character, but how many occasions are there for a player to zoom on characters faces when playing ? Whether it is a player character or an NPC, in online RPGs, You hardly recognize characters by zooming on their face, you recognize them thanks to their clothes, hair, body features, equipment, etc (unless of course there’s an auto-zoom).

From the beginning, I wanted Metaworld’s character to be recognizable, not only due to their bodies, but also thanks to their faces. It implied to have big heads that would emphasizes on facial features (eyes, eyebrows, facial hair, etc). What I had in mind at the moment was a style as a remembrance of characters sprites from the NES/SNES/Game Boy era. Something that I hope to have been able to capture to some extent.

Another constraint was the need for coherence and harmony. Example : if I want to play a bald character, I want it to be as nice as a character with long hair. Similarly, male, female, tall, large, fat, thin or small characters should be equally nice to look at. A character should not be inherently ugly or beautiful, unless its player wants it to be. That’s the reason I don’t like character such as TESO’s one, for example (whatever you do, they are not nice to look at, even if you can hide them under gorgeous armors).

To settle for a character style might sound easy and be a light task, but it’s something more complicated than it looks like. As far as I can remember, every single time I had to design a character style, whether it would be sprites or voxel models, I would take an eternity. Thus, I’m quite happy to already have a satisfying one.

Scene details and the signs they send

After some time working on a very basic landscape… which is basically just a 3d heightmap, I’ve made a new step by adding the system that will handle everything related to scene details such as vegetation, rocks, buildings etc. It’s a good occasion to talk a bit about both technical and design aspect of these things :)

Very often, when it comes to voxel games, the default solution to display scene details is to merge their mesh with the terrain mesh. It’s indeed a very efficient and flexible solution, since it easily allows things such as unique trees, and does not cost much in terms of performances compared to the terrain alone. But it’s only true as long as you don’t want the the scene details to be too much detailed.
Put two detailed trees on a chunk, and you’ll have two detailed trees in memory. Every time you’ll add a tree, it will be a new tree in memory, too. When having a lot of details, it can quickly get out of hand. Luckily, there are a few alternative techniques to render numerous objects, and one of them is hardware instancing. Rather than just duplicating elements, we keep a single tree/house/whatever mesh representation in memory, and display it at defined positions. There’s still an overhead for each duplicata created – its position – but it’s ridiculous when compared to the cost of duplicating a whole mesh. Hardware instancing has a drawback compared to the previous option, though : a single shared mesh means no unique trees or rocks. Is it a problem in my case ? No. And even if it was, there are some tricky workarounds, anyway (such as generating part of the mesh on the GPU).

Grass field
Grass field using hardware instancing.

My take on scene details is not only that I don’t need uniqueness, but that I don’t want it, nor I want too much of them. I’ll explain : one of the thing that I really want Metaworld’s graphics to allow is for the player to be able to recognize things. To avoid to send too many graphical informations, while still being good looking. Do you remember the 2d tile-based games from the 80-90s ? It’s close to the kind of redundant visual richness that I’m looking for. The tilesets of those games were originally a way to minimize memory usage, but they created a graphical style and – in my opinion – self-explanatory signs, because interactive details could be recognized easily.

If you don’t know what the expression ‘signs and feedbacks’ refers to in game development, it’s basically all the graphical polish used by the game to indicate to the players that an action occured (feedback) and to guide them through possible actions (signs). Examples : when a button is disabled, it’s usually gray. This is a sign (the user can’t use it). When the button is enabled, it’s colored. Another sign (the user can use it). When a mouse cursor is put above an enabled button, and it changes its color, it’s a feedback (the user has put the mouse above the button). If the user clicks it and the button appears pressed, it’s another feedback (the user clicked it).
Another sign example in games : when a player can interact with an object, it’s really common in modern games to have it glowing in some way. Most of the time, this sign is here because the players can’t understand “naturally” by seeing the object that they can interact with it. The question is, why can’t they understand it ? Usually, it’s because there’s too much of everything everywhere, making nothing recognizable until after a long learning curve of what is interactive and what is not. It’s not really a problem as long as there are additional signs, but where tilesets were awesome, it’s that their redundancy implied a short learning curve, leading the players to be naturally curious and interested about anything new or unusual. They tried to interact with it.

I don’t want a mining rock to be all shiny because players can’t differentiate it from a normal rock. I want the players to be able to tell that it’s not the same rock that they know. For new players to wonder “why is this rock different ?”. Curiosity and action. This is the kind of spirit that I’d like to give to Metaworld. Even through something as basic as environmental details.

Voxel landscape
Add some grass, add some trees, and everything gets better.

I’ll conclude with an interesting note : even when some details were not interactive, they are sometimes so weird that people believe that they must be interactive, and thus start to build theories extrapolating how to activate them. Before the advent of Internet, unusual details could even creates the so-called “rumours” and “secrets”. One of the most infamous probably being Pokémon Red/Blue’s truck :

Pokemon Red/Blue's truck.
What if… What if there were a Mew under the truck ?

Voxels and level of details

If you look at some of the most popular voxel games, I’ll say – totally randomly – Minecraft or Cube World, you tend to notice quickly that their camera range view is not exceptionnal, unless you have a 4000$ battle computer with a lot of memory and great CPU/GPU. It’s something that has always bothered me a bit, since I like games to have huge landscapes to show to the player. It’s something that helps a lot to increase immersion or at least to keep a coherent and believable world. It’s something that I’ll try to accomplish with Metaworld.

There are a few ways to improve a game camera range without killing your computer, and one of these is to implement a level of details system (LOD). LOD systems are a common graphic optimization technique in video games which consists in reducing the amount of triangles of the meshes to display. It’s a technique implying some quality-loss, but it’s supposed to be primarily used on meshes that are so far away from the camera that their details can’t be precisely distinguished in the first place.

A chunk in Metaworld is currently 32 voxels wide. The most obvious solution to simplify the generated meshes is to divide the chunk precision by two to have a second detail level (16 voxels wide where 1 cube = 2 voxels), then two again (8 voxels wide where 1 cube = 4 voxels), etc, until the geometry is not detailed enough to be interesting to show.

LOD Problem
Early implementation of the LOD system generated some… Interesting bugs. I “just” forgot to resend the vertex and index buffers to the graphic device after a LOD change.
LOD Transition
Transitions between two chunks of different LOD creates some gaps in the meshes.

Regarding the above issue of gaps between meshes – on which one I struggled a bit – I tried to simplify as must as possible the problem, since it’s often a good path toward a solution. One of the major simplification is that I only needed to care about the transition from a high detailed chunk to a lower detailed one. This is the typical LOD case, after all. When creating such a system, you want the chunks close to the camera to be detailed, and those far away to be less detailed. There are no common case where you should care about the transition from a low detail chunk to a high detail one, that would imply that the LOD is reversed.

In the end, it took me two days to have a LOD system satisfying enough, but the memory cost has been divided by 4. Worth it, I can now display farther than before :)

LOD Above view
As you can see from above, the voxels around the center of the screenshot is far more precise than the those from the outer parts.
LOD Perspective
You can see some LOD transition on the left, and the back. It’s going from a LOD of 1 to a LOD of 16.