Storing Users Character in MySQL Database

Question

Just asking a quick question about storing Characters in a database.

I am currently implementing a MySQL Database to store character data, using this current structure

Character Table:

playerUsername: VARCHAR(255)
characterName: VARCHAR(255)
idCharacter: INT(11)

Which is working fine to get all the characters that a certain person has.

While implementing this I was wondering how I would go about storing the character model data, like in WoW or other MMO's. Do they store all the models you create locally? or is that somehow stored in the database.

I have found a few structures online but they mainly contain character names and id not how the individual models are stored.

Any help on this would be greatly appreciated

Answer 1

While implementing this I was wondering how I would go about storing the character model data, like in WoW or other MMO's. Do they store all the models you create locally? or is that somehow stored in the database.

In almost all circumstances, model data itself isn't something you'd want in a database. You might store (directly or indirectly) a reference to some model... for example, your table might have a column for modelId: INT. In cases where the model can be derived 100% from existing data like the character's race and/or gender, you don't even need that.

The actual geometry data for the model, and it's textures and other rendering-related stuff should generally not be anywhere near the database. It is typically stored with the client data in a simpler file-based form, either as loose model data in a "Data" folder next to the game's executable, or stuff into a single-file archive or pack file.

---

The reasons you don't want model data in the database include (but are not limited to):

• you don't need it there; the database itself will never render anything, and a reference is sufficient information to allow you to distinguish characters based on model via queries (and is a much faster way to do so as well)
• it probably complicates your schema; unless each player is allowed to free-form model their avatar, most of the actual model data will be shared across many characters, so you'd want to break it into its own table to save space, but this means you now need to join against that table in some queries, making them less efficient
• it isn't where you want it; you want the model data on the client, where you can render. If it's on the server, you can't render anything until you log in, request that data, and wait for it to come back. This means certain features (like character previews before playing) are harder to implement because you have to deal with logging in and latency. They're impossible to implement if the connection can't be established.
• it's not actually solving a security issue; one argument for storing the data server-side is that user's can't tamper with it. Except you have to send it to them to render, so they could tamper with it then. And in any event you don't need the server-side storage to be a database for all the above reasons. You can achieve largely the same effect with less overhead by employing some kind of content verification hash instead.