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 :)

Introduction to the weight system

Continuation of the work on characters.

If you have read my previous entry, you might have noticed that I pointed that playing with the character creation is something that I liked to do. I do, and I know that many other people do. At some point, I had to question myself. How could I put this fun into the game ? This question can be answered pretty easily : the game should allow characters appearance to change according to some factors. One of these factors that a player will be able to toy with is the character weight. A rather obvious one since it defines a lot of a character’s shape.

Currently, the weight system works through food buffs. If you’ve ever played a MMORPG, you’ve probably come accross food buffs. Things that you craft in cooking professions, that give you various bonuses. Usually, they’re not that great, but since I want cooking to have an important place in Metaworld (like crafting in general), these bonuses will be relatively strong. And coming with an additional effect to manage.
When a player consumes a food, it grants it a buff with a number of stacks and a buff timer. Those stacks grant the player bonuses when being consumed, what occurs when performing some action (mining, casting, attacking, resting, etc). If there are unused stacks at the end of the buff timer, they’ll disappear, but add some weight to the character.

The effects of additional weight have yet to be determined. But you can be sure that there will be both advantages and drawbacks. I don’t want extra weight to be considered like a bad or good thing, but as something that is part of character building, both visually and gameplay-wise.

And I’ll conclude this post with an image of what it’s looking like in-game. The way I’m making characters heavier or lighter is fairly basic, since it’s a simple scale on some voxels, yet it’s working well in my opinion :

Metaworld voxel character weight variation
Only 4 steps represented here, but it’s linear between each one.

Scene details and the signs they send

After some time working on a very basic landscape… which is basically just a 3d heightmap, I’ve made a new step by adding the system that will handle everything related to scene details such as vegetation, rocks, buildings etc. It’s a good occasion to talk a bit about both technical and design aspect of these things :)

Very often, when it comes to voxel games, the default solution to display scene details is to merge their mesh with the terrain mesh. It’s indeed a very efficient and flexible solution, since it easily allows things such as unique trees, and does not cost much in terms of performances compared to the terrain alone. But it’s only true as long as you don’t want the the scene details to be too much detailed.
Put two detailed trees on a chunk, and you’ll have two detailed trees in memory. Every time you’ll add a tree, it will be a new tree in memory, too. When having a lot of details, it can quickly get out of hand. Luckily, there are a few alternative techniques to render numerous objects, and one of them is hardware instancing. Rather than just duplicating elements, we keep a single tree/house/whatever mesh representation in memory, and display it at defined positions. There’s still an overhead for each duplicata created – its position – but it’s ridiculous when compared to the cost of duplicating a whole mesh. Hardware instancing has a drawback compared to the previous option, though : a single shared mesh means no unique trees or rocks. Is it a problem in my case ? No. And even if it was, there are some tricky workarounds, anyway (such as generating part of the mesh on the GPU).

Grass field
Grass field using hardware instancing.

My take on scene details is not only that I don’t need uniqueness, but that I don’t want it, nor I want too much of them. I’ll explain : one of the thing that I really want Metaworld’s graphics to allow is for the player to be able to recognize things. To avoid to send too many graphical informations, while still being good looking. Do you remember the 2d tile-based games from the 80-90s ? It’s close to the kind of redundant visual richness that I’m looking for. The tilesets of those games were originally a way to minimize memory usage, but they created a graphical style and – in my opinion – self-explanatory signs, because interactive details could be recognized easily.

If you don’t know what the expression ‘signs and feedbacks’ refers to in game development, it’s basically all the graphical polish used by the game to indicate to the players that an action occured (feedback) and to guide them through possible actions (signs). Examples : when a button is disabled, it’s usually gray. This is a sign (the user can’t use it). When the button is enabled, it’s colored. Another sign (the user can use it). When a mouse cursor is put above an enabled button, and it changes its color, it’s a feedback (the user has put the mouse above the button). If the user clicks it and the button appears pressed, it’s another feedback (the user clicked it).
Another sign example in games : when a player can interact with an object, it’s really common in modern games to have it glowing in some way. Most of the time, this sign is here because the players can’t understand “naturally” by seeing the object that they can interact with it. The question is, why can’t they understand it ? Usually, it’s because there’s too much of everything everywhere, making nothing recognizable until after a long learning curve of what is interactive and what is not. It’s not really a problem as long as there are additional signs, but where tilesets were awesome, it’s that their redundancy implied a short learning curve, leading the players to be naturally curious and interested about anything new or unusual. They tried to interact with it.

I don’t want a mining rock to be all shiny because players can’t differentiate it from a normal rock. I want the players to be able to tell that it’s not the same rock that they know. For new players to wonder “why is this rock different ?”. Curiosity and action. This is the kind of spirit that I’d like to give to Metaworld. Even through something as basic as environmental details.

Voxel landscape
Add some grass, add some trees, and everything gets better.

I’ll conclude with an interesting note : even when some details were not interactive, they are sometimes so weird that people believe that they must be interactive, and thus start to build theories extrapolating how to activate them. Before the advent of Internet, unusual details could even creates the so-called “rumours” and “secrets”. One of the most infamous probably being Pokémon Red/Blue’s truck :

Pokemon Red/Blue's truck.
What if… What if there were a Mew under the truck ?

Short description of the game

If there’s one thing that I should start to do with this blog, it’s to explain a bit more what is the game I’m working on.

My project is to create an online game with some of the usual RPG elements you find in MMOs : equipment, stats, classes, skills, PvE. Classical but well-rounded game mechanics. Contrary to most RPG, I don’t intend to add a story to the game, only a context and an ambience. This is the reason I’m only talking about “RPG elements”, and not a full fledged RPG, where role playing/story is normally a core part of the game. I’ll probably detail the reasons of this choice in a future post, but one of the main is that the core gameplay that I’m targetting is all about player interactions and player cities. Open world and PvP are parts of these interactions. Note that I’m trying to build the PvP in a somewhat “political” way so that the abuses usually seen in PvP games (chain kill, grey kill, spawn kill, etc) would be naturally detrimental to the PKs, and force them to choose between being able to have normal player interactions and poor behaviour (not that I’m fundementally considering such lacks of fair-play “bad”, it’s player freedom, but retaliation from the PKed players should be possible by some means, if not from fighting).

Regarding the game scale, the goal is to create a server able to handle between 1k and 2k concurrent users. I’ve already developped some months ago a game server that went to production and handled above 2k concurrent users. Thanks to this prior experience, I’m confident that I should be able to reach these numbers even with a more CPU-hungry game.

I’ll conclude this post with a project name : Metaworld. It’s not very specific, but its purpose is mainly to give the game I’m working on a name that can be used to designate it. That way, I can avoid to use “the game”, “the project”, etc. It’s way more practical!
If I have to pick a real name at some point, I’ll take the time required for it. Picking a definitive name is not exactly a priority at this time considering how much Metaworld can change.