This is more of a general "known problem" instead of a workable action. Collecting notes, mostly.

In short: given a highly active player base, there's a chance that game state saving from Process #2 will overwrite data saved from Process #1. Consider, for example, User A and User B. User A is actively using the site (read: actively saving his state from page load to page load), and User B is fighting User A. If User A happens to be online at the same time as User B, and actively participating in some sort of state-saving mechanism, it's entirely possible that, when User B wins or loses their battle with User A, at the exact moment that User A saves a game state from his own activity, User B's process will be overwritten by User A's process. The win/loss statistic would only be recorded in User B's state.

Granted, this takes /exact/ timing, and would conceivably be rare, but that's the whole point and mystique of a race condition. In core, such as the node table, the form checks the updated timestamp in the database and compares it with that stored in the form. If the database's stamp is newer, it refuses to save the node, prompting again for user input. We can't implement the same sort of thing in Game, however, because there's no way to "replay" a turn with a freshly retrieved state. Merging game states would also fail, because there's no clear logic to which is the more "proper" change - the one from the database or the one from the session.

One possibility would be not necessarily to eradicate this race condition (which I don't yet have a solution for), but to minimize its potential: instead of saving statistics in the master game state, save them in a specific statistics table. Game state would still be saved each turn, but just once. This creates a second race condition (one for major game state, as discussed herein, and a new one for game statistics), but makes it more unlikely (that the "win" statistic is updated at the exact moment as another process, or that the more infrequent major game state saves happen at once). It'd also reduce the potential to create impossible mergings: if only a "win" statistic failed, that's a lot easier to swallow then an entire state with 25 changed statistics, etc., etc.

None of these are great solutions, mind. Merely waxing poetic. At the moment, my stance is to "proudly declare it a problem, but wait until it actually becomes one". I don't want to build failed scaffolding for all this until it really does become disastrous.