It’s recap time

It’s been no less than 13 months since I last updated the dev blog, so, it’s more than time for a recap and some news about Metaworld. What happened during the last year, what’s going on at the moment, and what I plan for this year.

The plan that was

I initially started working on Metaworld’s prototype at the end of 2014, after a few years digressing around voxel engines. For most of 2015, I worked fulltime on the game, gradually building a robust engine both on the client and the server sides, and implementing the first gameplay mechanics. I initially expected a release in the second half of 2016, something that didn’t happen, as you can see.
The plan actually changed in late 2015. At that time, I was evaluating the remaining work load at roughly six man-months. What would have matched the schedule if I hadn’t to include the business/marketing aspect of releasing the game. The fact is that I gradually got late in the development due to unexpected but necessary graphical improvements and a rework of the character style to differentiate it more from the existing offer (mainly Cube World, that is).
In a best case scenario, the game would have been released at the end of 2016 or early 2017. One additional year was unfortunately a bit too much for me, so I accepted a job offer for a software engineer position, and since then I’ve kept working on the game on my free time.

What was done in 2016

Not being fulltime on the game allowed me to stop focusing purely on development, and instead to make a game design check up. I already had some doubts about some systems I designed that didn’t seem to work as well as I thought they would, so that was the perfect time for it (note that if I kept working fulltime I would have needed to do that check up anyway, what would have pushed the release even further).

The check up made it obvious that the game has two major issues:

  • the vastness and continuity of the overworld: this is a desirable feature for a virtual world as it improves immersion and creates a true sense of a “world”. I planned mechanics to go with the immensity of the world (mobile resource hot spots, dynamic mob spawns, rare events/object spawn, etc), and reward exploration, but at the moment the incentive is not that strong. This problem is something that I’m still working on. Many possibilities, but they’re all give and take.
  • the player city/housing system: it is suffering from the same “messy town” issue than most player city systems, and isn’t working well with terrain variations. To put it simply, it’s ugly. I have (mostly) settled on a solution, but not on the details. It’s very likely that I’ll change it in favor of an procedural/organical growth approach. Basically, a player plant a city seed, and by feeding it with specific materials, a city layout creates itself around (with either complete buildings or purchasable building spots).

Beside the check up and work on the game design, I’ve mostly done bug fixes, added UI details, and did a lot of graphical experimentations (shadows, ambient, occlusion…), the most notable being a deferred renderer.

The current state

Since the beginning of the year, I’ve mostly worked on adding a DirectX 12 support. Note that you can still play the game with XNA, what will be useful for older PCs.
The DX12 support was done with the goal of adding a VR support to the game (yes, “that” VR, as in Virtual Reality). At the time I’m writing, both of these objectives are close to completion, only the 2D is left to implement, and I’ve experienced the game in VR quite a bit :). I still have a lot of polish to do, but all of that makes a good 2017 start!

The plan that is

For now, I don’t intend to go fulltime again. I have the necessary resources for it, however I still need time to rethink the parts of the game design that don’t work, a task that I’m most efficient at when slowly processing informations and ideas, rather than when working on it fulltime. In the meanwhile I’ll keep improving the tech that runs the game, add content, and implement the remaining gameplay mechanics. I’m committed to create a great game, and will keep moving forward, even if a bit slowly.

Additionally, I’ll try to update the dev blog more often. It usually takes me a lot of time to write a post, but since a few people recently asked me about the game by mail, it seems as worth as ever!

Until next time.

Screenshot saturday #9

A bit late as usual, but here is last week’s saturday screenshot.

A shot of a character in the new volcanic environment, that is still being developed. If you’re not following me on Twitter, you might notice the slightly different character. I’ve indeed reworked them, something I’ll talk about longer in a future post. But for now:

Volcanic environment
Volcanic environment with glowing hot rocks.

About the Art system

Art System Window
The window dedicated to Arts: simple!

I’ve been working lately on the Art system implementation. It took some time to code it, but most of the work actually went into its design. The window in the screenshot above is not fully self-explanatory, so let’s talk a bit about this system, and what it provides.

Why it exists

Usually, MMOs and online RPGs tend to be very restrictive when it comes to what they allow players to do. Crafting jobs are limited in number or levels, you can’t change your class or use a weapon other than the intended one(s), etc. While I can live with such limits, I rarely like them, mostly because if you want to experience what is beyond them, they become a cheap way to force you to consume again the same content with another class/job/whatever by creating an alt. And if there’s one thing I’m sure of about MMOs, it’s that they already take more than enough time for a single character.

As you can guess after reading the previous paragraph, I didn’t want to put too many limits regarding how characters can be built in Metaworld. Or rather, in this case, I didn’t want to put too many locks that couldn’t be removed. The Art system is the key for these locks.

How it works

A new player does not know any Art. It’s a novice that can’t do much until it acquires some bits of knowledge about how to use a weapon or a tool, what will be done by starting to research Arts.
The mechanic behind Arts is very simple. Pick an Art, research it, and after some time (whether you’re online or offline), it will be complete, and you’ll have access to new items, classes, etc. It’s a core part of Metaworld’s character progression.

Once a player has acquired the first level of whatever it may want to try, the research time start to increase drastically. Most of the first Art levels take around 5~15 minutes of research. Level 2 rise to ~40 minutes, Level 3 to ~2 hours, and so on. The higher the level of an Art, the more time it will require to be researched. Needless to say, higer levels can take up to days. Oh, and there isn’t any upper limit to Art levels.

The time resource will encourage players to make choices about how much they’ll level a class or equipment. They can be jacks of all trades, but can also be very specialized. A new player can quickly be efficient if it goes straight to his Art goals.

Aren’t early players advantaged?

Take two players. Because the researches are done in real time, the one who started first is indeed advantaged as it could have learned more Art levels. But, that will be true only if none of these two players interacted with other “teacher” players, since there are actually two ways to lower the research duration:
– to be taught an Art by someone who already knows it,
– to use a book to learn an Art, book that can only be written/crafted by someone who already knows it.
Both of these methods involve other players who have either different Arts levelled, or have been playing longer than the learner do. There are no drawbacks for the learner, but the teacher/writer has some, so be prepared to see an economy based on Art transmission in the game :)

And that’s all for now. I tried to summarize as much as possible the essence of the Art system. I’ll gladly answer any question.

House works and tiling

If you were following my work back in march, you might remember this screenshot:

Player city
Player cities are on the way!

It was the early version of player cities that I prototyped to make sure that I could achieve what I wanted. It proved to be possible, and I’m now back on this system to fully bring it to life.
I started the work on it last week, with one of the first step being the necessary rework of the building style, and the creation of models for the new buildings. While I was satisfied with the look of building themselves, the overall composition when placed on the map was especially ugly, mostly because once the vegetation is removed, a city is a wide empty space with building here and there. The lack of textures in such a context was not forgiving at all. In consequence, I started to work once again on the graphics.

The first step was to densify the color variations of the terrain, so that it would make tile limits more obvious. It worked quite well, but was not enough, thus I decided to make another go at textures. Instead of trying to create Minecraft-esque ones like previously, I tried to create alteration patterns that would combine with the plain colors, not replace them. And it proved to be quite a good idea when I tried a texture faking rounded corners:

Empty Space
An empty space that does not look too bad!

Happy with that result, I tried it on more surfaces and with some vegetation. It still looked quite good, on top of strengthening the tactical RPG look that I’m striving for, while preserving the typical colored voxel look:

Grid works
Very “tactical RPG” feeling around here, isn’t it?

With these changes validated, I went back to cities:

Metaworld Player City
First look at the revamped player city buildings.
Metaworld Player City
Houses with warehouses in the background. To be used for trade!
Far City
There’s a city hidden in this screenshot. Will you find it?

I have a long list of tasks to complete before getting functionnal cities, but it’s going rather well.

Until next time!

World loading and rendering techniques

Last week, I implemented a new and useful feature into Metaworld: the view distance modifier, in the graphical options. Not only does it allow to lower the view distance (woah) but also to increase it (incredible). That small feature allowed me to make some tests about the maximum render distance that will be supported, and it’s not too bad, as you can see in this video:

That maximum render distance was determined by efficiency, using an arbitrary ratio framerate/distance. Above the value I determined (4000 units), adding view distance costs too much frames per second to be worth it. That maximum value runs quite well on my computer, at more than 100 frames per second, what allowed me too record the above video with no framerate problem.

Setting the view distance distance at the maximum is completely useless gameplay-wise. It does not give any kind or advantage, you just see very far heights that are minutes away from you, and use more resources from your computer. I mostly see it like a luxury feature. The default of 2000 units, half as much as the maximum, is already more than enough for proper gameplay.
This being said, setting the vie distance to 4000 units gives the world a strong depth, it’s quite immersive and impressive to see. Thus, it’s fully justifiable if immersion is what you seek (and now, I only hope to be able one day to add an Oculus Rift/Vive support to the game).

When I linked the video on Twitter, I was asked some questions about how the game is dealing with this render. I quickly answered, but Twitter is far from being the ideal platform for details. Thus, here are some more.


At the moment, at the maximum view range, and on my development computer, the loading is rather quick (~3 seconds), considering the amount of things displayed on the screen at max range.

There are multiple reasons to it:

– First of all, I must make it clear that the terrain is generated from 2D data. It might not be obvious to notice this detail without playing the game, but the terrain is generated from a heightmap. There is only one layer of floor, thus it is made of very simple meshes, devoid of any vertical hole. It requires very few calculations to generate meshes from such data, making the file loading the bottleneck instead of the CPU.

– The entire environment, that is procedurally placed on the map, is cached. What qualifies as “environment” is basically every static object visible above the terrain: trees, plants, etc. The environment effects on the terrain such as an altered ground color or a shadow are also cached (shadows are tile-based for gameplay purposes, making it worth to store them).
When this cache is initially generated, it takes a lot of time to be built, but once it’s available, the loading is very fast. While moving, more cache is generated, but it does not impact the game framerate at normal gameplay speeds. However, it tends to create hang ups when moving quickly (for example when I use the map editor).

– The environment does not have a lot of variations at the moment, limiting the amount of meshes to load.


Whether a terrain chunk is displayed or not is done through a basic frustum culling. There’s no culling of chunks hidden behind other chunks at the moment, the engine relies on the GPU z testing. When drawn, the chunks are more or less sent by a front to back order to the GPU to capitalize on the z test. However, the ordering is not very precise at the moment, which makes it very likely that some chunks are rendered when they shouldn’t.
Conclusion: the terrain rendering can still be perfected.

Everything else in the world: the trees, the plants, the rocks, the houses, etc, are voxel sprites displayed through hardware instancing. To avoid too much repetition of the environment, models are rotated, and modelized so that there’s no feature standing out too much that would make the lack of diversity too obvious.
For each chunk in the view frustum, the engine calculates the distance from objects above a chunk to the camera, and uses it to determine a LOD value. Following the value, a more or less detailed mesh is displayed. This task is not done continuously, since it would likely be too costly CPU-wise. It is only executed when a chunk enter or leave the view frustum.

More questions? Feel free to ask!