| View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||
| ID | Project | Category | View Status | Date Submitted | Last Update | ||||
|---|---|---|---|---|---|---|---|---|---|
| 0000304 | Spring engine | General | public | 2006-09-29 03:12 | 2010-12-07 11:43 | ||||
| Reporter | RichiH | ||||||||
| Assigned To | abma | ||||||||
| Priority | normal | Severity | feature | Reproducibility | N/A | ||||
| Status | resolved | Resolution | won't fix | ||||||
| Product Version | |||||||||
| Target Version | Fixed in Version | ||||||||
| Summary | 0000304: Offer resync of games | ||||||||
| Description | When the game detects desync between players, instead of flooding the status window, TA should offer a resync mode. There are two different approaches how sync data and at least three ways of deciding what state to sync to. Ways to decide on a state: 1) Host decides. This would be the easiest implementation. You have one state of the game and that is used. Period. Having a modified TA client as host would enable serious cheating, though. 2) Clients vote. The general consensus would be taken. This would prevent cheating in most cases, but could lead to invalid states. If a unit has two different locations, which does one use? If we choose to take the middle, we need to safeguard that that point is valid, reachable for that unit type and that it would not have to take a very long path to reach that new location (think a wavy ridge that takes ages to walk around). Many other possible points of failure. Hard to implement good rules for it. 3) Rollback. Game states are saved every x seconds and the game can just roll back to the last common state. Would eat memory, but would be cheat proof and, apart from state management, simple. 1) Sync in the background while game continues. I assume that TA is based on UDP and a resync burst might block packets from the ongoing game. Also, the second the desynced players are synced again, they are confronted with a new situation and have to adapt to it on the fly. 2) Sync while game is paused. This could be initiated by the host, common vote or the game itself with the game being the preferred option. Display a warning that the game is about to resync, pause the game, sync, perhaps blink on the map, have these action squares rotate in or zoom to all places where changes occurred, possibly with a light overlay of what used to be there a few seconds ago. Having just had to abort a 3v3 2 1/2 hour game when we were finally winning is.. annoying.. | ||||||||
| Tags | No tags attached. | ||||||||
| Checked infolog.txt for Errors | |||||||||
| Attached Files |
| ||||||||
 Relationships |
 Notes |
|
|
tvo (reporter) 2006-10-02 10:39 |
Rollback could get stuck in an infinite loop if the desync is deterministic (e.g. caused by a game bug), plus the memory requirement is just insane. Syncing in the background also doesn't really work, I tried that a time ago but it just gives anomalies like units suddenly getting full health mid battle and units getting teleported to a position where they were a few seconds ago. Also my test code couldn't manage to stop the desync at all, it just made it worse. Clients vote with host takes priority on equal votes and no interpolation of unit variables (gives to much problems as you already say yourself), combined with sync while paused could work, but it's quite a lot of work to code :-) |
|
RichiH (reporter) 2006-10-03 17:56 |
Yah, i included anything besides stopped game and absolute values for completeness, only. If you had in-game voting on if a resynch should be done (only host can initiate and only if the game detects desynch) and absolute overriding of everything with host data, it should not be too hard to code, i think. Depending on how the game data is stored, it might even be enough to just replace a large chunk of memory with whatever comes over the line. Perhaps send back a hash to stop too easy manipulation and you are done. Only things that would be left are: a) Replay handling, probably done via a Big Fat Warning b) Groups and what unit/building is in what group c) Some manner for the players to see the diff between what they had and what is the new stuff. Probably with a minute tacked on at the end so people can set a few new orders or whatever they need to do. Alternatively have a ready button so if all players agree, they can skip the wait time. |
|
tvo (reporter) 2010-02-10 16:23 |
0001813 shows a typical desync that would not be properly solved by a rewind-and-try-again resync system. |
|
abma (administrator) 2010-12-07 11:43 |
if an game is desynced, everything is to late, because this could be an bug in a game and lead to an endless-loop to solve such stuff: make savegames + load (IMHO currently not implemented) See 0001828 for status of savegames |
| Notes |
| Issue History |
|||
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2006-09-29 03:12 | RichiH | New Issue | |
| 2006-10-02 10:39 | tvo | Note Added: 0000407 | |
| 2006-10-03 17:56 | RichiH | Note Added: 0000408 | |
| 2007-01-29 11:10 | tvo | Status | new => assigned |
| 2007-01-29 11:10 | tvo | Assigned To | => tvo |
| 2010-02-10 16:23 | tvo | Note Added: 0004639 | |
| 2010-07-28 23:13 | tvo | Assigned To | tvo => |
| 2010-07-28 23:13 | tvo | Status | assigned => new |
| 2010-12-07 11:43 | abma | Note Added: 0006035 | |
| 2010-12-07 11:43 | abma | Status | new => resolved |
| 2010-12-07 11:43 | abma | Resolution | open => won't fix |
| 2010-12-07 11:43 | abma | Assigned To | => abma |
| 2010-12-07 11:44 | abma | Relationship added | related to 0001828 |
| Issue History |