Properties

[exectails]

Intro

Early in Melia's life, it became obvious that we'd need some kind of property system, because basically anything in ToS has properties, a collection of named values. The whole game is made up of them. Actually, even more so than I thought back then, which is why our current property system is a little lackluster.

Properties

In game development, properties often times receive special handling. You might have a container that manages an object's properties, and a series of property classes, like PropertyInt, PropertyString, etc, that are used to set up an object, and which can then be used by querying that property with an id.

player.Properties.Add(new PropertyInt(Property.Level, 9001));
player.Properties.Add(new PropertyInt(Property.MaxHp, 20));

var level = player.Properties.GetInt(Property.Level);
player.Properties.SetInt(Property.Level, level + 1);

This has its advantages and disadvantages. Particularly, it takes more effort to set up and isn't nearly as comfortable to use as a simple C# property. However, you gain the ability to add, remove, and modify properties without affecting packet structures, because you can simply iterate over all existing properties. You can also add additional features to the property classes, like clamping the values or adding OnChange events.

Melia

Since we were coming from a game where this property situation wasn't nearly as bad, we figured we'd implement a hybrid between C# properties and a proper property system for Melia, because we thought it would be comfortable to use and flexible enough. Basically, we would keep using C# properties, but create reference properties, that point to these values.

this.Properties.Add(new RefFloatProperty(PropertyId.PC.STR, () => this.Str));

This allowed you to simply use player.Str to modify someone's strength, but also put that property "on the map" for packets that need a character's properties.

Problem

Now the problem is, that there are just way. too. many. properties in ToS. Hundreds of player properties, hundreds of item properties, hundreds of guild properties, and thousands more. If we were to apply our hybrid design to those, the respective classes would become a mess of properties. They'd be thousands of lines long, just for the properties and to set them up.

Solution

My proposed solution: Go from hybrid with focus on C# properties, to hybrid with focus on property collections. Create property containers, potentially specialized ones, and add C# properties for commonly used fields. For example, in a more recent project of mine, I have a CharacterParameters class, which is such a property collection, and on it, I also have a few C# properties, for quick access and for properties that are made up of multiple other properties.

void InitParameters()
{
	this.Add(new ParameterFloat(ParameterType.Mana, DefaultMana, min: 0, max: DefaultMana));
	this.Add(new ParameterFloat(ParameterType.ManaMaxBase, DefaultMana));
	this.Add(new ParameterFloat(ParameterType.ManaMaxMod, 0));
	// ...
}

public float Mana => this.GetFloat(ParameterType.Mana);
public float ManaMax => this.SumFloat(ParameterType.ManaMaxBase, ParameterType.ManaMaxMod);

This removes the hundreds and thousands of lines of code for the properties from classes like Character, embraces the property design that ToS is so fond of, and still keeps the ability to easily access common properties easily.

[exectails]

Oh, and this should also be extended to the database, so you don't have to add a new field for every single property.

[ovflowd]

For me, this is exactly what a Dictionary should be. In some past Emulators, I left everything Dictionary related outside of the source code of the repository.

Basically, you would have a dictionary that acts as Key-Value Dictionary (IdentifierString, NumericValue)

It is mostly an INI file

IdentifierNumberOne=0001
IdentifierNumberSomething=8565

And inside the Emulator, you have a Manager, that during the initialization it loads the Dictionaries.

We could even have a command during execution time to reload the Dictionary if you make a change, or like for example, updating the Revision.

So you could easily do something like:

ParameterDictionary.get("IdentifierNumberOne");

This is just a different approach for at least mapping the Identifiers. But I definitely think your Solution is great.

Also instead of an Ini file, it could be inside the Database. Whatever it's easier or better.

[exectails]

What I meant about it getting extended to the database, is that there should be a table for character properties for example, where you can simply dump and read all of their properties from. Instead of declaring a field for level, and one for HP, and one for stamina, etc. on the character table, you'd simply write the id, type, and value of every property, together with the character id into a property table. This way, when you declare a new property for a character, you don't have to update the database, it simply gets read and written together with the others. Similar to how we currently store scripting variables in the database.

On that note, for future reference, when saving properties to the database this way, we should not use a property's integer id as the index, because those have had a tendency to change a lot in the past. Sometimes, after an update, all the property ids were suddenly different, which would completely break the data. We should either use an intermediary index, that we can make sure never changes, or use the property names instead.

[ovflowd]

We could also use the name of the property itself as the index. So the table structure would basically have the key as a string field. But of course, that could make things slower. So an intermediate database index key and then a number for the actual identifier. Something like that, as you mentioned.

[exectails]

Yea, I just thinking that we could probably generate indices based on the strings. Basically hashes. Not very intuitive if you look at the data in the database, but it would work. Or we create a lookup table, where we assign every property name a fixed id.

[ovflowd]

If our Database actually supports HashMaps that would actually be quite fast :)

[icavalheiro]

We don't need hashmaps, we could just use tables with 'id'(entry_id), 'attrb_name', 'value'.
We could also, to avoid massive tables, have different instances of this table for things like items_attrbs, characters_atrbs, monsters_attrbs, etc... This should work in any database, and working directly with SQL should be pretty easy to implement.
The issue is the field "value" that would need to be some generic serialization reuslt, either a json or binary (we are using postgres right? so we could just use json)
Other option is just use a document db for this, something embeddable into the server such as https://www.litedb.org/

[icavalheiro]

nvm the json field, we are using mysql, so json is not an option