Re: How referees should respond to illegal plays

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?

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.)

>   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...)

>> 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".

>  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.

>   What do you propose should be the result of the
> original request, if not a fault?  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.

--
Jason McIntosh
Senior Bioinformatics Programmer
ICCB - Longwood
Harvard Medical School
jason_mcintosh <at> hms.harvard.edu
Office: 617-432-2071 Cell: 617-792-3829
Fax: 617-432-3702 AIM: zendonut

-------------------------------------------------------
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