Re: How referees should respond to illegal plays

Jason McIntosh writes:
 > On Apr 30, 2005, at 9:55 PM, Doug Orleans wrote:
 > 
 > > Jason McIntosh writes:
 > >> Secondly, fault packets simply can't hold very much data (so long as
 > >> they stick to the XML-RPC standard); the code has to be numeric and
 > >> therefore not immediately human-readable, and it can't contain any
 > >> arguments.
 > >
 > > That's not true, RPC faults have both an integer code and string.
 > 
 > The string isn't really data in the way that the code is, though. It's 
 > meant to be a human-readable string for passing directly to the user. 
 > But in taking advantage of this, the referee is overstepping its 
 > limits, I think. We last year decided that referees make all their 
 > in-game communication in the form of ruleset-defined RPC requests, but 
 > here they are passing a string?

It's not "passing" anything, it's returning a fault response to the RPC request.

 > The specific objection I've heard from two different people is that, as 
 > UI authors, they want total control over what the player sees when they 
 > try to do something illegal. If it's left to an RPC fault, then control 
 > stops at the client without getting passed to the game UI. (In the case 
 > of Javolin right now, this takes the form of a dialog box that displays 
 > the string.)

This is easy to change in the Javolin client library.  The "rpc"
ECMAScript function could be made to raise an ECMAScript exception
when it gets an RPC fault, instead of calling the ErrorHandler that
was used to initialize the GameUI, which is what it does now.  Then it
would be up to the UI script author to handle the exception, or else
it would bottom out and Batik or Rhino (if GUI or non-GUI
respectively) would display the error.  Or we could change this to
have it call the ErrorHandler when there is no ECMAScript exception
handler defined in the script.

 > >   And
 > > I think it would be okay to insert our own subelements to the fault
 > > XML (in the Volity namespace) if we really need something more
 > > structured than a string.
 > 
 > I really want to avoid doing any XML-level diddling in any part of 
 > Volity. (It's a major reason why we're using RPC in the first place...)

Fair enough.  I thought I remembered we were already doing this, but I
guess it's just something we discussed and then decided not to do.

 > >> That is, the ruleset would define a set of referee-to-client
 > >> RPC requests that would handle every possible error condition.
 > >
 > > I don't think I like this.  It's too asynchronous.  It seems natural
 > > for an erroneous request to result in a fault response,
 > 
 > I'm arguing that a request to make an illegal move is not really 
 > erroneous. It's against what the referee is willing to allow in the 
 > game, but it's a perfectly valid request just the same. It simply has 
 > an answer of "no", rather than "WTF".

It's an "application-level error" which is what the Jabber-RPC spec says
that RPC faults are for.  But maybe you want to distinguish between
"Volity error" and "game error".  (But is anything a Volity error?)

 > >  but it would
 > > be a pain to have to set up a handler for error "requests" that can
 > > come at any time.
 > 
 > Yes it would. Good think we wouldn't have to. :) The UI script (not the 
 > client) would simply need to define a few more callbacks (in 
 > ECMAScript), and these wouldn't be any harder to write than every other 
 > callback that the UI requires to play normally.

I think they could cause all sorts of trouble, since they can come at
any time, and the UI script might be in some state where it's awkward
to handle the error.  Or more generally, the error handler would have
to know what state the UI is in (e.g. what request was just made) so
it knows how to handle the error.

And what would you return as the response to the original request,
anyway?  Or is everything just "void" now?  That just seems like an
overly imperative style.

 > > If you don't like using/extending
 > > RPC faults, how about coming up with our own error structure that
 > > would be returned as the (non-fault) result?
 > 
 > I just think we should keep it simple and eliminate the concept of 
 > in-game errors entirely. It would simply be up to the ruleset to define 
 > a few more ref-to-client methods to handle the possible bad moves that 
 > a player might make.

I guess by "our own error structure" I meant that each game author
would define that game's error structures that would be returned by
each request, although it might be useful to define some common
structures (and provide them in a common ECMAScript library, along
with other common widgets).  I think this follows the same philosophy
of removing the Volity-wide concept of game errors and having only
game-specific errors.  I just really don't like the notion of the
referee sending responses as separate, asychronous requests.

--dougo <at> place.org

-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20