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 #7 and map editor video

New screenshot based on what I’ve worked the most these days: improving the environment. To do this, the map editor has been upgraded (check the video below to see it in action), the biomes has been slightly reworked, a sea level has been added and both a vertical fog and an horizontal fog has been implemented. Nothing ultra fancy but the rendering is quite better, and it now allows to find some interesting sceneries that I’m not necessarily aware to create when editing the map from above. For example, this scenery :

Moutain view
Newly added water and far distance fog on a small moutain equals to a somewhat nice view.

And here the video showing the map editor. Quick and efficient with the procedurally generated biomes transforming a plain heightmap into green hills, rocky mountains, or sea shores:

Screenshot saturday #5

New screenshot for this (freakishly hot here) saturday.

If you remember my post from two weeks ago about the UI, you may remember aswell that I was planning to rework the text display. It’s done. Much nicer with antialiasing.

The screenshot contains a mob fight with a hundred entities around. It was mostly a load test, but makes for an interesting screenshot. Note that I can go up to 500 fighting entities on that little square of map before encountering problems. Not exactly what is supposed to happen.

Fighting Mobs
3… 2… 1… Ready? Fight!

Picking a number of character attributes

There’s one thing that few game developers can avoid when working on an RPG, it’s designing attributes. As long as an RPG includes equipments with a progression curve using numbers, you have to give a mean to those numbers. Not only regarding the way they’re used internally to determine – for example – attack damage and defenses, but also if and how they’ll be exposed to the players to allow them to compare equipment and understand what is better. One of the notable decision is the “model” that a game will use for its attributes, model that mostly plays on the amount of attributes that the players will have to deal with.

Warning: text wall ahead.


Common attribute models

If I’ve only recently started to implement attributes meaning inside Metaworld, I’ve been working on them for quite some time, on paper. I did some research, and I identified five of these attribute models. Of course, all of them are abritrarily defined by me, but it helped me to categorize such things. If you’re thinking of any other, feel free to comment, I’d like to hear about it!

  • the simpler the better (15- attributes), aka the beginner-friendly model. Few, easy to grasp attributes such as attack, defense, hp, mp. Classic and efficient, found in a lot of games. Does not offer much in terms of build customization, it can be very limitating on the long run regarding equipment quality and diversity. So, Usually, it’s used by smaller games, or games focused on fun or short-term gameplay rather that long-term equipment build. An example: Cube World.
  • complexity is depth (35+ attributes), the more attributes you have, the more complex it is, the deeper it is. Even if it’s true that this option will bring a lot on the table, it can take some time for players to digest the use and meaning of all attributes, especially if they’re not named distinctevely enough. An example? When you have magic resist, magic resist, magic power, spell strike, magic fortitude, magic suppression, it’s a bit hard to expect the players to intuitively know what they’re used for (Aion, are you here?).
    Something I regularly saw in this case is that the attributes where duplicated for each damage type. You’ll have attack, defense, precision, etc, existing in different versions: physical attack, magic attack, physical defense, magic defense, etc. It helps to understand the attributes, but when overdone, it feels a bit cheap… ArcheAge is faulty of this for having three damage type, melee, range and magic, with plethora of duplicated attributes. It does not seem deep, it seems that every basic stat has been copy/pasted to grant a complexity to the game.
  • average all the way (15~35 attributes): games using a middle ground count of attributes, trying to bring the best of the two world, but bringing some of the worse too. While not exactly being beginner-friendly, the learning curve is not as steep as the more complex games. The build complexity is usually good, at least enough for many players to enjoy it on the long-term. Final Fantasy XIV or Star Wars The Old Republic, both being MMOs, are in this category.
  • composite attributes… Too few is shallow, too much is too complex… Other than going for the middle ground, there’s the possibility to regroup attributes to reduce their amount. Happens a lot in games using things such as “dexterity”, that will for example determine the critical rate, hit precision and evasion rate… All of the sub-attributes are being hidden, though. In this case, it’s obvious that the game need to have a clear explanation of what each attribute does. If my memory is not failing me, Diablo 1 had such a system.
  • hierarchical attributes, that are actually quite similar to composite attributes, except that both the parent and children attributes are modifiable. For example, you have a “Strength” attribute that increases HP, damage, etc, while HP and damage can still be modified individually. It makes the “Strength” attribute very valuable, while still offering granularity in the build. Something also used by ArcheAge.

Three details that are worth noting:
– some games are using a mix of these models, some only one.
– in most cases, there are attributes deemed “primary”, meaning that they’re more important than the other. It does not mean that other attributes are useless, but that those primary attributes are more powerful and visible. Having such a split helps player comprehension when having many attributes since it gives them something to focus on.
– there are some cases of “fake” attributes, that does not impact the gampleay, but are mostly informations given to the player that are deduced. It’s the case of the “DPS” attribute, that shows the damage per second, but is something players won’t have a direct impact on. However if they increase their damage, the DPS value would change in consequence.


Metaworld’s case

I’ve played Aion for quite some time, and while at its begins, it was rather tame on attributes (the balance between simplicity and depth was good), through the successive versions, their count have exploded up to the point that it ended up in the situation I described earlier with hard to understand attributes, and worse, no in-game explanation for them. Somehow, it convinced me that the primary goal I should have was to make attributes easy to identify, and, ideally, intuitive regarding their purpose.

If you look at this picture, you’ll see most of the Metaworld’s current attributes:

Metaworld character attributes
Current character attributes in Metaworld

Even without the labels, how most of these are used should be rather intuitive, except maybe for the three ones on the top left, that are skill damage values.

Other than all these attributes, what’s left to add are the HP and MP, aswell as HP and MP regen, that clearly don’t need explanations if you’re a bit used to games, and the life steal/magic absorb attributes thar aren’t named yet.

As you can see, I’m going for the average count model (close to the arbitrary upper bound with 32 attributes). I’m not interested by a tremendous amount of attributes since it would likely lead to a dilution of the player’s attention between many values, and a steep learning curve. Beside this, I also used the duplication model for four attributes: Attack, Precision, Critical and Defense, that are coming in two different versions corresponding to the two different types of damage that can be inflicted. And finally, I have somewhat composite attributes with the elemental resistances, since they indeed increase resistance towards an element, but all effects from this element also. Which means that increasing the Lightning Resistance will reduce damages of lightning type, but also reduce the chances to be hit by a paralysis effect, that is of lightning type.

I’m quite satisfied with the current set of attributes, but it wasn’t always like that (and there will come someone to say that it’s still unclear ^^). At first I used attributes such as “Cancelling”, “Nulling” and “Concentration”. While the last one can evoke something, it’s tricky to say for sure what it will do. However, the two first attributes… Good luck. I’d like to hear your ideas, just for fun (answers are next paragraph).

Any idea?

Cancelling and Nulling were actually the same attribute with two different temporary names. It was supposed to be an equivalent to an evasion of magic damages: have enough points of that and a bit of luck, and you don’t receive any damage. In the end, I merged this idea with the Evasion, that now allows one to dodge any kind of damage, as long as the player faces the damage source. The split between physical and magic evasion appeared to be somewhat unnecessary, and more restricting than interesting (use one? use both? probably none).
And regarding concentration, it was an attribute used to determine whether or not the player could be interrupted when casting a spell. Another name could have worked, but I went for another mechanic instead, thus removing the “problem”.

And done with this post. Talking about the number of character attributes can be a bit underwhelming, but in my opinion, it’s more important than what it seems to be for both accessibility and long-term investment of the players :)