2 ms·
> Data Consistency as a Requirement Probably only sort of consistent, I imagine? Game servers tend not to support seamless failover. If the server crashes at t
by nitwit005 4y ago
> Data Consistency as a Requirement
Probably only sort of consistent, I imagine? Game servers tend not to support seamless failover. If the server crashes at the wrong moment, data is going to be lost, regardless of how politely behaved the data backend is.
That is, if you kill a boss and successfully pick up an item, you know it'll be saved to DB. If the game crashes before you can pick it up, it's probably just gone.
- dijit 4y agothe way we had it working was local storage (sqlite) and remote storage (postgresql with a middleware). If you pick something up it flags as an “interesting event” and syncs your profile to local storage- on game server crash, there would be a crash collector which syncs the local database with the remote one and removes the lock - meaning you can join a working server. The crash collector also did things like… well, collect the crash dump and send it for debugging. But thats roughly how it worked.
- nitwit005 4y agoInteresting. Hadn't heard of a scheme like that before. Appreciate the explanation.
- ilyt 4y ago> Probably only sort of consistent, I imagine? Game servers tend not to support seamless failover. If the server crashes at the wrong moment, data is going to be lost, regardless of how politely behaved the data backend is. You could just have a let's say "user profile service" where all of the transactions about user profile (items, XP, etc.) go, on top of internal game server data. That way the important stuff could be send immediately, like "epic or above item drops", and everything else either in batched update (XP, achievements etc.) or periodically (stuff like player rearranging inventory) or at end of the session.