never started and the server eventually gave me the boot."
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@2776 542714f4-19e9-0310-aa3c-eee0fc999fb1
method invocation services and converted everything to the new style.
Could this be my biggest checkin ever?
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@1642 542714f4-19e9-0310-aa3c-eee0fc999fb1
separately in the game manager and controller which can then get unhappily
out of sync.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@1450 542714f4-19e9-0310-aa3c-eee0fc999fb1
incremented whenever the game is reset. Games that don't make use of the
resetting functionality essentially consist of a single round.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@1420 542714f4-19e9-0310-aa3c-eee0fc999fb1
AWAITING_PLAYERS, CANCELLED, etc. are properly addressed by those that
check in on these sorts of things.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@1276 542714f4-19e9-0310-aa3c-eee0fc999fb1
start processing on the server so that we don't want for the IN_PLAY
attribute change to be processed before calling gameDidStart() because we
don't want to do that when resetting the game (because someone could come
along and end the game in between gameWillStart() and gameDidStart() which
would be annoying and bad), so we need to be consistent and run straight
through both when starting the game for the first time and when resetting
it.
This means that game managers that really need to wait until their events
are processed and do some game start processing at that point will have to
listen for the IN_PLAY transition themselves *and* they'll have to be
aware that someone could have come along and ended the game in between the
call to gameDidStart() and the dispatch of the IN_PLAY event. Sketchy, but
unavoidable.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@1235 542714f4-19e9-0310-aa3c-eee0fc999fb1
classes is only going to become more common, I've gone and created a
comprehensive facility for creating and using delegates in the place
controller and manager as well as the game controller and manager. With
the pattern nicely set, it is also easy to extend to controller/managers
further up the hierarchy that might need to delegate special methods of
their own. Whee!
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@994 542714f4-19e9-0310-aa3c-eee0fc999fb1
with distributed objects rather than having a single handleEvent() by
which all subscribers are forced to hear about all events. Now one
subscribes separately and then adds onesself as any of a few types of
listener once they have access to the subscribed object reference.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@439 542714f4-19e9-0310-aa3c-eee0fc999fb1
across parlor.client, parlor.server and parlor.data.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@437 542714f4-19e9-0310-aa3c-eee0fc999fb1
changed to Presents and Party changed to Crowd. Whee!
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@431 542714f4-19e9-0310-aa3c-eee0fc999fb1
things are set up properly when createPlaceView() is called.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@409 542714f4-19e9-0310-aa3c-eee0fc999fb1
provide some of what we were going to provide with the Parlor services.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@403 542714f4-19e9-0310-aa3c-eee0fc999fb1
the game on the client side and have started to wire up the DObject stuff.
Whee!
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@366 542714f4-19e9-0310-aa3c-eee0fc999fb1