Multiplayer Game Server, Client Database Structure

Question

I had a general question regarding how game data is stored for multiplayer games. Items and characters have base stats and then there is the stats gained while playing the game through upgrades etc.

I would want to store the stats gained in the server-side database but I wasn't so sure for the base value. Specifically for a mobile game, I was thinking the amount of data passed back and forth should be reduced as much as possible.

Would storing these base values for items/characters client side, making use of prefab/scriptable object(I am using Unity) be a bad idea? The battle will take place client-side and the server handles mostly read/write to database of player game data. The main interaction between players will not be a real-time battle between players but something similar to that of clash of clans.

Answer 1

In my opinion, there are two ways to do this properly:

Store the base items client side only. If you want to update them later, you will have to publish a new build of your project, but you don't need to make web requests.

Store the base items server side. You can maintain them in your Database and let the client fetch them, i.e. when the game gets started. This way, every connected player will always have the current base stats.

Another possibility, depending on the scope of your project, is to have two databases. One on the server and one client side. Then, every time the game gets started, you check on your server for updates (you could use some kind of checksum or version number to make that easy).

Answer 2

What I would do is provision a decentralized or distributed database, have a source of truth where the base items are always available there, on a globally replicated basis (assuming this matters), and then have the client also implement a local cache of its own (like React does) where needed data is stored in a local DB that is synced with the remote DB. The game client now only ever talks to the local DB, and the smarts of synchronizing, etc, are left to the DB layer, making your application code much simpler.