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.

More recent screenshots

It’s been three weeks since my last post, time for another recap.

While the two first weeks that will be covered were mostly oriented on getting big systems working, or on improving existing systems, this last week has been the occasion of working on a multitude of minor details that need to be ready for an interesting user experience. I’m currently working on making a first test version for a few concurrent users. If successful, I might try to gather more people – even if there’s nothing to do in the game at the moment outside of fighting each other or mobs – to check how the server application will handle a real load with real network latencies. At the moment, I’m still targetting a few hundred concurrent users.
But for now, here are more screenshots of recent development:

I keep (slightly) improving graphics, adding some details here and there, modifying colors… It was the case for the sky, that is now a bit closer to what a sky should look like:

Updated sky color.

I improved the water depth feeling, and added some algae:

Not obvious on a screenshot, but those algae are waving.

Mostly for testing purpose – at first – I added character collisions using terrain tiles as the base for them. I’m still testing them and need to improve them a bit, but so far I’ve been quite happy, since they give an extra TRPG feel, especially with the grid and tile indicators I’m currently using to make them obvious:

A grid to simplify tile visualisation, and colors for collision zones.

I took some time to test the render of low-resolution low-contrast textures on the terrain. On one hand, it’s satisfying to have more details, but on the other hand, it tends to make non-textured objects less attractive. I’m still not sure whether or not I’ll go for this textured style – if you have an opinion, I’ll gladly hear it. So far, most people had a preference for the simple color style over the textured one:

Textured Terrain
The textures are quite small, 8×8 pixels, and match the voxel resolution of trees.
Trees Shadows
An example of what can be done with textures: pseudo-shadow around tree trunks for a better integration.

I’ve reworked large parts of the biome and LOD system, and optimized a bit the graphic engine. It allowed me to improve by two to four the previous framerate, for a similar view range. It now allows this kind of scenery with the default settings:

Level of details view range
Probaly a bit hard to tell at first, but there are three level of details in this screenshot.

And in the most recent images I uploaded to Twitter, I’ve shown a bit more of the characters, that have been reworked to include tails for some races, and the keyframes for the future dual weapons:

Running fox-based character
Beginner stuff on a fox-based character and dual beginner swords. Not amazing, but should be kinda cute!