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.
Something I’m regularly doing when not working on Metaworld is reading forums/sites dedicated to online RPGs and MMOs, and try to answer the questions asked there, as if they were directed towards the game I develop. It’s something really interesting to do, since it’s forcing you to look at what you develop from another angle, and gives an indication of how far you’ve thought your game design or overall player experience.
For once, I’ll write and share the answers. These questions come from the site MassivelyOP, and more specifically this article about ten weird questions, that was published earlier today. If you’re interested in MMOs and online games in general, and does not already know about MassivelyOP (or its former self, Massively), I highly recommend this site!
Please note that all the informations I’m giving here are real, and based on Metaworld’s current game design, but of course, they might undergo some changes as I’ll progress in the development:
1. How easy is it for enemies to knock me off my mount?
It is not possible to be knocked off of a mount, however, your mount (or balloon/boat) will take damage and slow down the more it is hurt/damaged, until killed or destroyed, so it might be best not to let it take too much damage. Especially if you’re using a balloon, considering the potential fall damage.
2. Will I have a choice of weapons?
Metaworld’s class logic is inverted compared to the usual one used in online RPGs, it’s not the class that determines the weapon, but the weapon that determines the class(es). Let’s take the ‘staff’ and the ‘bo’ as examples: if you use a staff, you can pick either the Arbiter or the Warden class, whereas if you use a bo, you can pick between the Warden and Warrior classes. The staff-user Warden and the bo-user Warden are variants of the Warden class. They’re not exactly the same regarding skillsets, and they’re balanced individually, but the core remains the same. If you don’t consider variants as separate classes – and you shouldn’t in my opinion – then yes, there will be a choice of weapons.
3. Where’s the screenshot key and folder?
By default it’s the F12 key, and the screenshot are stored in the “my documents” folder. On this screenshot, it’s not in “my documents” for the simple reason that this folder is set to the D: disk drive on my computer:
4. What’s the most popular class?
Considering that some classes are starting classes, and that others can only be accessed by playing and getting the weapons and arts making them available, I’m 100% sure that the most popular ones will be the starting classes. In case you wonder, the main purpose of arts is to allow the usage of equipments, weapons and tools.
5. Do you have an insane dev on staff who thinks that jumping puzzles are the bee’s knees?
Huh, no, unless you consider column-like terrain artifacts to be jumping puzzles.
6. Where are your patch notes?
Patch notes will be accessible through an in-game window. It might seem like an invasion of the game technicality into the virtual world, but Metaworld is not a game using the suspension of disbelief. It’s just a virtual world with its own logic, and it is shown as it is.
7. How toxic and/or welcoming is your community?
So far the community – composed of a tremendous count of 5 players – has been focused on killing and resurrecting each others (then repeat), failing to kill mobs, “anonymously” insulting people in the chat, and competing for the first player to reach the highest moutain. So, yeah, it’s probably the most toxic community ever considering the evilness to player ratio.
9. What one or two stats do I need to concentrate on?
Depends of the class, but thanks to this question, I’ll probably add an in-game helper for beginners. Please note that the class system is made to allow multiple viable build and will probably also depends of a metagame, so it’s likely to be very variable.
10. Are there any red flags for your game’s future operation?
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.
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” 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.
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.