improve simultaneous play support

[wsu-cb]

The current CB code checks that the initial state of a .gmv file matches the current state of the .gam into which it is being loaded, and presents CSelectStateDialog if the initial states don't match. However, that isn't ideal for games where players naturally take actions in parallel, for example, the programming phase of Roborally. In that case, either the players have to explicitly define a turn order, which slows down the game, or they have to effectively opt out of the error checking provided by the game state comparison (by using the "Use current game state" option of CSelectStateDialog).

It would be nice if we could find some middle ground so that games can proceed in parallel as much as possible while still performing error checking. Unfortunately, I haven't thought of any straightforward way to achieve this yet.

[DLLarson]

Unfortunately, I haven't thought of any straightforward way to achieve this yet.

Yes, it can be tricky. It's not unlike source control with GIT. We need a merge operation that can handle collisions (two players moving the same piece in two different move files for instance.) Resolving the collisions is where the difficulty arises.

The current approach either insists on game state perfection but allows the player to ignore state purity and apply the moves anyway. In essence, collisions are ignored--the last applied move file wins.

-Dale

[wsu-cb]

Yes, it can be tricky. It's not unlike source control with GIT. We need a merge operation that can handle collisions (two players moving the same piece in two different move files for instance.) Resolving the collisions is where the difficulty arises.

Actually, that's a "simple" case; the system can (theoretically) see that the same piece has been moved to different places. I have thought of at least one scenario that looks much worse to me: Three pieces that overlap (i.e., are stacked), and one player moves the bottom piece to the top of the stack, while the other player moves the middle piece to the top of the stack. The players have not touched the same piece, yet the end result is different.

[DLLarson]

The players have not touched the same piece, yet the end result is different.

That one didn't occur to me. Nasty!

-Dale