0
\$\begingroup\$

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

\$\endgroup\$
  • \$\begingroup\$ You can save those information in any text format you like. For example you can have field of Armour in your table. If user purchased any armour, you can add it in your database. When player comes back later, the game will load all the information which is in your database. \$\endgroup\$ – Saad Anees May 1 at 5:42
  • \$\begingroup\$ But what data are you actually saving? \$\endgroup\$ – Tom Heeley May 1 at 21:14
  • \$\begingroup\$ As I said its any text format. Data can be any thing. For character customization it can be the names of items. It could be JSON, XML or CSV. Its really upto you. \$\endgroup\$ – Saad Anees May 2 at 6:09
  • \$\begingroup\$ Does your game actually have some kind of free-form character modeling feature that allows players to "create" models that are just not parameterizations or assembling the final character out of a variety of pre-existing pieces (as is done with most character creation systems)? \$\endgroup\$ – Josh May 4 at 14:25
1
\$\begingroup\$

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.
\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.