single interval as that caused problems (which Charlie had to work around) and
added unnecessary complexity and indirection. There are not so many games and
so many tickers that we need to second guess the efficiency of Interval.
git-svn-id: svn+ssh://src.earth.threerings.net/vilya/trunk@644 c613c5cb-e716-0410-b11b-feb51c14d237
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
For games that make use of this, all occupants should call it,
unless they call playerReady().
git-svn-id: svn+ssh://src.earth.threerings.net/vilya/trunk@590 c613c5cb-e716-0410-b11b-feb51c14d237
up a shutdown interval. Let's override that method and implement GameManager's
special requirements instead of overriding an unrelated method and duplicating
most of the code from it.
git-svn-id: svn+ssh://src.earth.threerings.net/vilya/trunk@588 c613c5cb-e716-0410-b11b-feb51c14d237
all pre-game processing can properly know what round it is, but then actually
publish that value to the clients so that we can trigger off ROUND_ID to call
roundDidStart without having roundDidStart get called before gameDidStart.
git-svn-id: svn+ssh://src.earth.threerings.net/vilya/trunk@583 c613c5cb-e716-0410-b11b-feb51c14d237
already sitting at a table. We also enforce this in the UI (though not in
certain cases in MSOY at the moment which is how this was uncovered).
git-svn-id: svn+ssh://src.earth.threerings.net/vilya/trunk@577 c613c5cb-e716-0410-b11b-feb51c14d237
but apparently not. Use the helper method to see if the game's in play since
it's there for just that reason.
git-svn-id: svn+ssh://src.earth.threerings.net/vilya/trunk@566 c613c5cb-e716-0410-b11b-feb51c14d237
While testing the new code I discovered that redistribution of large data sets
that approximate a normal curve can cause some funny quantization because the
redistribution algorithm assumes all values in a single bucket are flatly
distributed, but if they actually skew substantially toward the high or low end
of the bucket, then the redistribution generates a choppy curve. Fortunately
this has almost no impact on the percentile curve, which is what's actually
important, it just makes the graph of the contents of the buckets look less
smooth and sexy. Alas.
git-svn-id: svn+ssh://src.earth.threerings.net/vilya/trunk@530 c613c5cb-e716-0410-b11b-feb51c14d237
that was stupid. Now they're called players. Next I added a list of watchers
rather than simply a count. If we're going to go to all the trouble to update
the table when the watchers change, let's have the goods.
This will probably break Bang and/or Yohoho. I'll fix them toot sweet.
git-svn-id: svn+ssh://src.earth.threerings.net/vilya/trunk@515 c613c5cb-e716-0410-b11b-feb51c14d237
Par Winzell