-1
\$\begingroup\$

I am looking at storing player data in Unity from a script that I'm writing in C# and I would like to get an opinion on the best way to store the player's stats/data about the player like hours played, etc.

I know that I can set up a database, and that is one way that I'm going to store the most important data like username/password (of course using hashing and not the actual password).

What I would like to know is really about player data/stats about the player's character. Should I also store that data in the database or should I just have a file that I write over each time the player performs and upgrade, etc. or what other way can I effectively manage that data?

I am wanting to store things like the player's level, XP earned toward next level, currently active character, etc.

Edit: This will be for an MMORPG, so there will be many different pieces of data being stored.

\$\endgroup\$
  • 1
    \$\begingroup\$ If you already are storing data in a database, why would you want to scatter other data around other data stores? \$\endgroup\$ – jgallant Apr 20 '16 at 13:56
  • \$\begingroup\$ I just want to know if there's a way to avoid having so many columns for all of the data pieces that I will be storing for an MMORPG. \$\endgroup\$ – Trey50Daniel Apr 20 '16 at 13:59
  • \$\begingroup\$ Use a database, with an external connector. \$\endgroup\$ – Luis Masuelli Apr 20 '16 at 15:59
0
\$\begingroup\$

When this is for an online game, you should definitely store that information online on your server. When you store the character state on the client, your players will edit it to cheat.

The MM in MMORPG stands for "Massive Multiplayer", as in "Too many players to store in regular flatfiles". You will definitely need a database which is used by your server to persist the state of any offline players. Usually you would keep the data of all currently playing characters in memory and only persist them to the database when they disconnect. You might also want to persist them every few minutes in case of a sudden server crash.

\$\endgroup\$
  • \$\begingroup\$ Okay, so I just have to have all of those columns? Because I plan to have leveling systems for weapons, characters, and also a tier base for the player's account. And I should still store all of that data and update each time the player makes a change? \$\endgroup\$ – Trey50Daniel Apr 20 '16 at 14:06
  • \$\begingroup\$ In other words I don't want to have to bog down the server with all the players updating their stats simultaneously. Is there a way to avoid doing that? Or will it not even have the impact that I am forseeing? \$\endgroup\$ – Trey50Daniel Apr 20 '16 at 14:11
  • \$\begingroup\$ @Trey50Daniel Usually you would keep the data of all currently playing characters in memory and only persist them to the database when they disconnect. You might also want to persist them every few minutes in case of a sudden server crash. \$\endgroup\$ – Philipp Apr 20 '16 at 14:13
  • \$\begingroup\$ @Trey50Daniel Regarding what tables with what columns you will need and how you define primary and foreign keys... that's really general relational databases 101 knowledge which is too much to explain in just a comment and which is not really specific to game development. \$\endgroup\$ – Philipp Apr 20 '16 at 14:16
  • \$\begingroup\$ Okay, this makes perfect sense. So I keep updating their stats in memory and then perform the update as soon as they log off. That way it only has minimal effect on the players currently in-game. And I would want to make sure to re-establish the players stats every so often in the event that the server crashed suddenly. \$\endgroup\$ – Trey50Daniel Apr 20 '16 at 14:16
0
\$\begingroup\$

I think you should not update database whenever something changed by player. You should update database in a sufficient frequency. Before updating database you should hold frequently changed data in the memory; a database updater thread can update/store database for instance at 1 hz.

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