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!

Improving the combat system

If you watched the previous video (here on YouTube), you might have noticed that the combat looked a bit dull. There were multiple causes to it:
– click targetting,
– long skill cooldowns,
– no auto-attacks,
– move-locked skills,
– characters drew their weapons for an attack, then immediately put it away,
– reworked UI.

I’ll detail all of these points, but for now, let’s start with the video:

Adding tab targetting

Tab targetting is something that is well-known to players. If you’ve ever played an MMORPG, there are good chances it used tab-targetting for target selection. While some players feel that such systems have been overused, and wish for more actiony ones, it’s still used daily by millions of players (WoW, FFXIV…), and remains one of the more precise and quick way to select a target.
With this addition, the combat is more maniable than with just the click targetting, that remains available.

Low-cooldown skills

Having no short cooldown skills or auto-attacks forced the players to move around a target to avoid being attacked. While it can be interesting in itself, it was 80% running for 20% skills… Which is a bit too much. The fact that the current classes didn’t had a lot of skills surely didn’t help, but still, I meant them to be representative, so, the fact that it didn’t feel good enough made it obvious that a rework was neededg.

Adding auto-attacks was tempting. It’s another well-known system consisting simply in having a weapon-based implicit skill dealing some damages on a regular basis, without the need for a player input other than start/stop. It’s not just use in some RPGs, but also in MOBAs and other genres.
I thought about this auto-attack option for quite some time, but came up with something I consider a bit more interesting in the form a low cost skill with a low cooldown (500 ms). Practically, it’s the same thing than an auto-attack, except that it requires a permanent key press or skill click to be activated. To bring some depth, there will be more than just one skill per weapon type, though players will have to choose only one. As you might guess, these different skills will have varying execution time and damage.

Combat in motion

This is certainly the biggest improvement of all, and one that cost me a lot of development time: the ability to use skills when moving. Modifying the animation system to allow this wasn’t easy (I might write a post about it, by the way), but totally worth it, since, as you can see in the video below, the combat is a lot more dynamic now, and even the player character looks more alive when following the target.

Fighting when moving around also implies that the angle of attack is now an important thing to consider. As before, when you’re idle, then initiate an attack, the game makes your character face its target. However, if you’re running around, it’s not something that can be done without changing where you’re going to – what could be potentially dangerous – thus, it is the player’s task to make the character face the right direction. Note that the system remains quite flexible, granted your target is not in your character’s back, as you can see in the video.

Also, regarding the “why should I move if I can stay put?” argument, I plan to add some bonuses for attacks done when moving. Nothing that could turn the tide of a combat, but bonuses big enough to make the difference between two players with similar builds.

Combat mode

“Combat mode” simply means that when a player starts using a weapon, it will stay in combat mode for some time, showing a drawn weapon even when running or being idle. At first, it might seem to be an eye candy – and it partly is – but this offensive stance will have an impact on both PvE and PvP. They don’t exist yet, but some skills will require to be in or out of combat mode to be used, the most notables probably being the stealth skills.

Reworked UI

The UI has been cleaned, a lot. The chatbox is now auto-hiding itself to avoid cluttering the screen more than necessary. In low resolutions such as 1280×720, the difference is quite visible. While the chatbox appearance is still the same than, I plan to rework it a later date.

The other big UI change is the transformation of the small player status bars (HP, MP…) that were on the top left of the screen into big and visible bars at the bottom center of the screen, under the default position of the hotbar. You’ll have to trust me on this one since few people have tested the first combat version, but having these informations more visible and accessible is a lot more comfortable aswell as helpful when it comes to understand what is going on and evaluating your chances of survival.

That’s all for now!

First test session

At the end of last week, Metaworld’s first multiplayer and stability test took place. Considering how an important step it is, I will take some time to talk about it, and will try to be as transparent as possible regarding its results. If you would like to hear more about some details, feel free to ask about them in the comments.

These were the initial goals I set for this first test session:
– check the server stability,
– check the client stability,
– test the combat system and have some feedback on it,
– have some graphical feedbacks,
– find as much bugs as possible.

– 5 concurrent uers,
– ~16 square kilometers (~6.2 square miles) map,
– 40 mobs on a restricted area
– ~2 hours long test

Server stability

The good surprise was that the stability of the game server was great. Not only did it never crashed, but it never entered a deadlock or any kind of blocking state, and all of its task were properly done with a low impact on resources consumption – to be expected considered the low scale of the test. I initially thought it had a major network blocking issue, but later debug proved that the source of it was actually the client.

The chat server being a chat server for a game with all players on TeamSpeak, it was idle most of the time, but did its job when needed.

Client stability

Contrary to the server, the client proved to be quite unstable in some cases. Drag-and-drop of skills or items to the hotbar was the source of most crashes. The other source being the swap from the fullscreen game to desktop + swap back to the fullscreen game. Indeed, I wasn’t handling lost graphical devices yet, and was developing in windowed mode, so, obviously, it became quite apparent in this test.

Another issue was the one I talked about previously: some kind of (apparent) network blocking was randomly occuring.
Practically, players were rolled back to earlier positions, some attacks weren’t landing, players were disconnected for inactivity, etc, it really felt like messages weren’t reaching the server when they should, similarly to what can cause an heavy latency.
It was actually due to multiple causes. The first was that the player’s position timer (currently, this information is sent every 20 ms) was not precise enough, and if the time between each send was exactly 20 ms, it would just never send the information due to a poorly placed modulo operation making the timer go back to 0. The other reason was – bash me – that the client was sending to the server the position information for every single movable entity it knew about. Basically: 40 mobs + 5 players. The server had no problem dealing with this situation, and discarded the unauthorized messages (a good test in itself), but the client was occasionally struggling when it was trying to send data for 45 characters at the same time.

Combat system

The combat system was in a pretty rough state, and it totally felt like it. It was riddled with minor bugs (dead people could resurrect other dead people, some damage numbers weren’t shown, people could attack when flying or sailing, etc), but the biggest problem was a gameplay one, with the lack of a zero-cooldown or automatic attack, forcing players to wait for 2~5s cooldowns between each skill, making the combat quite slow (as you can see in the video below). Otherwise, it felt very classical to the testers (that are used to play MMORPGs). Some remarks done on the vocal server we were on, like “the skill is not working” or “I die when I use a life consuming skill”, made it clear that the combat needed better feedbacks, both graphical and audio, to make it clearer when the player can or can’t/shouldn’t do something.

Graphical feedbacks

Overall, the feedback was quite positive regarding graphics, especially characters and the view range, with an exceptions being the sea details – the lack of feedback when sailing made it hard to tell where you are when no land was at the horizon, and if you’re even moving in the first place.
Some testers were also worried that using cubes could make the game too close to Minecraft. Note that amongst the testers only one knew and played to Cube World, so let’s guess that the worries would have gone towards the resemblance with this game instead, should have they know about it.


The day after the tests, I uploaded a 5 minutes video on YouTube with some sequences from the test. No sound for now, not that there aren’t any in-game, but voices from the testers were on the video. Keep in mind that this is still a work in progress. Enjoy:

Post-test state

At the time I’m writing this post, all of the technical issues and found bugs have been dealt with, what means that the game in its current state is quite stable. Something that will need to be proven in a future test.
I’m now working on the combat, that needs to be improved, before developing anything new.

As previously said, if you have any question, go for it! See you next time.