If you were following my work back in march, you might remember this screenshot:
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:
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:
With these changes validated, I went back to cities:
I have a long list of tasks to complete before getting functionnal cities, but it’s going rather well.
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.
Quick post to show the last screenshot saturday screenshot I uploaded. If you follow me on Twitter, there are good chances that you already saw it some weeks ago, but I posted it on Reddit’s /r/gamedev only last week.
It’s a very simple screenshot, nothing fancy about it, since it’s mostly showing the color rework and UI modifications that I was talking about in earlier posts.
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
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.
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.
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.
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:
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.
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:
I improved the water depth feeling, and added some algae:
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:
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:
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:
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: