Back in the wild and wooly days of Puzzle Pirates development, we determined

that we needed to be able to tell if one game ended and another one had started
so we introduced GameObject.roundId which was a value that was incremented
every time the game started. Thus if you had a timer that expired and you
wanted to make sure that somehow the game hadn't ended and then been started
anew while you were away, you could save the roundId and check it when you woke
up. That was all fine and good, except for the poor choice of variable name.

Then we came to implement Whirled and wanted to provide an abstraction of
"rounds" which were subunits into which a single game is divided. We had this
lovely variable already lying around called roundId and we succumbed to the
temptation to overload its meaning and have games that use round increment the
round id multiple times during a game which preserves the monotonically
increasing nature of roundId as expected by the Parlor code and seemed to do no
harm.

Then we discovered a pesky wrinkle, which is that GameManager sets
GameObject.roundId in gameWillStart() and then goes on to set GameObject.state
after that. We were naturally listening for roundId to change and triggering a
call to roundDidStart() at that time, but this resulted in a strange sequencing
of callback methods that went: roundDidStart(), gameDidStart(), roundDidEnd(),
roundDidStart(), ..., roundDidEnd(), gameDidEnd().

The premature roundDidStart() was irksome, and I looked into what would be
needed to remedy it. It turned out that a lot of code on the server-side of
things depended on the Parlor semantics of roundId and wanted roundId to be set
to the current round's value in gameWillStart() and similarly in
gameDidStart().  However, there's no gameWillStart() on the client and it
didn't appear to me that anyone much cared about roundId in gameDidStart(), so
I opted for some hackery in the name of expedience that preserved the
server-side semantics but changed the client to see ROUND_ID change after STATE
changed.

As you might expect given the verbosity of this explanation, that turned out to
be a new bad idea stacked on the previous bad idea of reusing roundId which was
stacked on the bad choice of name for roundId. It turns out some puzzles in
Yohoho did expect roundId to be already set in gameDidStart() which was no
longer the case and the inevitable digital mayhem ensued.

The time has come to undo the various bad decisions and replace them with new
decisions that we hope aren't bad. Those decisions are:

- rename roundId in GameObject to sessionId and restore its original semantics
  which are that it represents a monotonically increasing integer that is
  incremented (and published to the client) in gameWillStart() and thus
  represents the current game session from the very first to the very last;

- add WhirledGameObject.roundId for handling rounds in Whirled games and give
  it the semantics we desire which are for it to be set to 1 in gameDidStart()
  and then incremented only when a new round is started, and reset to 1 when a
  new game is started (this change is in another commit).

This will temporarily break some builds as I need to go rename some things in
Yohoho and then I need to look at Bang! Howdy which if I recall correctly also
naughtily uses roundId for nefarious ulterior purposes and needs also to be
cured of its wayward habits.


git-svn-id: svn+ssh://src.earth.threerings.net/vilya/trunk@611 c613c5cb-e716-0410-b11b-feb51c14d237

src/java/com/threerings/puzzle/client/PuzzleAnimationWaiter.java

@@ -26,11 +26,9 @@ import com.threerings.media.animation.AnimationWaiter;
 import com.threerings.puzzle.data.PuzzleObject;
 
 /**
- * An animation waiter to be used with puzzles that want to modify the
- * game object or board in some way after the animations end, and would
- * like to do so in a safe fashion such that their changes aren't
- * unwittingly performed on game data for a subsequent round of the
- * puzzle.
+ * An animation waiter to be used with puzzles that want to modify the game object or board in some
+ * way after the animations end, and would like to do so in a safe fashion such that their changes
+ * aren't unwittingly performed on game data for a subsequent round of the puzzle.
  */
 public abstract class PuzzleAnimationWaiter extends AnimationWaiter
 {
@@ -40,16 +38,15 @@ public abstract class PuzzleAnimationWaiter extends AnimationWaiter
     public PuzzleAnimationWaiter (PuzzleObject puzobj)
     {
         _puzobj = puzobj;
-        _roundId = puzobj.roundId;
+        _sessionId = puzobj.sessionId;
     }
 
     /**
-     * Returns whether the puzzle associated with this puzzle animation
-     * waiter is still valid.
+     * Returns whether the puzzle associated with this puzzle animation waiter is still valid.
      */
     public boolean puzzleStillValid ()
     {
-        return (_puzobj.isInPlay() && (_roundId == _puzobj.roundId));
+        return (_puzobj.isInPlay() && (_sessionId == _puzobj.sessionId));
     }
 
     // documentation inherited
@@ -59,16 +56,14 @@ public abstract class PuzzleAnimationWaiter extends AnimationWaiter
     }
 
     /**
-     * Replacement for {@link AnimationWaiter#allAnimationsFinished} that
-     * also reports whether the puzzle associated with this animation
-     * waiter is still valid.
+     * Replacement for {@link AnimationWaiter#allAnimationsFinished} that also reports whether the
+     * puzzle associated with this animation waiter is still valid.
      */
     protected abstract void allAnimationsFinished (boolean puzStillValid);
 
-    /** The initial round id. */
-    protected int _roundId;
+    /** The initial session id. */
+    protected int _sessionId;
 
-    /** The puzzle object that the animations we're observering want to
-     * modify. */
+    /** The puzzle object that the animations we're observering want to modify. */
     protected PuzzleObject _puzobj;
 }