headers
Jason McIntosh | 1 May 21:37
Gravatar

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
(Continue reading)

Permalink | Reply |
headers
Doug Orleans | 2 May 00:05
X-Face

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
(Continue reading)

Permalink | Reply |
headers
Karl von Laudermann | 3 May 01:19
Favicon

Re: How referees should respond to illegal plays


On May 1, 2005, at 6:05 PM, Doug Orleans wrote:

> Jason McIntosh writes:
>> On Apr 30, 2005, at 9:55 PM, Doug Orleans wrote:
>>
>> 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?)

I would. Keep in mind that our "application" (Volity) is itself a 
platform on which other applications (games) run. If a user clicks and 
drags a chess piece to a space that it can't legally move to, this is 
an erroneous action on the level of the game application, not the 
Volity application. I think a "Volity error" would be an actual bug 
that the game implementor would have to fix, such as calling an RPC 
that doesn't exist.

--

-- 
				Karl J. von Laudermann
				karlvonl <at> rcn.com
				http://www.geocities.com/~karlvonl/
				Richard's PBeM Server ID: karlvonl
(Continue reading)

Permalink | Reply |
headers
Jason McIntosh | 2 May 01:11
Gravatar

Re: How referees should respond to illegal plays

On May 1, 2005, at 6:05 PM, Doug Orleans wrote:

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

As far as RPC goes, I'm thinking things like entirely unrecognized or 
malformed requests, versus valid requests that the actual game doesn't 
agree with.

> I think they could cause all sorts of trouble, since they can come at
> any time,

I'm not so sure that's true. They'd only come as a reaction to player 
input, and in this way be just like the requests that the referee makes 
back to the player when the player succeeds in performing an action. 
e.g. the player sends "play_card()", and the referee sends 
"player_played_card(player, card)" to all the players if it succeeds, 
or "cant_play_card(card)" to the player if it fails. (The Eights server 
currently supports all but this latter.)

> And what would you return as the response to the original request,
> anyway?  Or is everything just "void" now?

It'd just return truth, to acknowledge that the request was received. 
Much like the invitation protocol works, really.

> 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
(Continue reading)

Permalink | Reply |
headers
Andrew Plotkin | 3 May 02:48

Re: How referees should respond to illegal plays

Now that I'm on this list, I might as well start mouthing off...

On Sun, 1 May 2005, Jason McIntosh wrote:

> On May 1, 2005, at 6:05 PM, Doug Orleans wrote:
>
>> 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?)
>
> As far as RPC goes, I'm thinking things like entirely unrecognized or 
> malformed requests, versus valid requests that the actual game doesn't agree 
> with.
>
>> I think they could cause all sorts of trouble, since they can come at
>> any time,
>
> I'm not so sure that's true. They'd only come as a reaction to player input, 
> and in this way be just like the requests that the referee makes back to the 
> player when the player succeeds in performing an action. e.g. the player 
> sends "play_card()", and the referee sends "player_played_card(player, card)" 
> to all the players if it succeeds, or "cant_play_card(card)" to the player if 
> it fails. (The Eights server currently supports all but this latter.)

There is a small semantic difference between "successful player actions" 
and "failed player actions", which is that the latter doesn't change game 
state, so it's natural to think of the server's response *as* an RPC 
response. There's just one response message, and it goes back to the 
player who made the move.
(Continue reading)

Permalink | Reply |
headers
Andrew Plotkin | 13 May 02:15

Re: How referees should respond to illegal plays

Getting back to this, now that I've had more time to read Jabber and 
XML-RPC docs:

On Mon, 2 May 2005, Andrew Plotkin wrote:

> My guess is that it's actually okay to have separate "move" and "result" 
> RPCs (whose RPC return values are trivial "ok" codes). Despite the 
> asynchronousness that Doug noted.

Andy Turner noted:

> I'm confused as to why you think it's any more asynchronous then an
> RPC fault.  They seem equally asynchronous to me.  RPC calls, at
> least in friv, don't wait for a response from the server but instead
> return immediately.  (Responses are captured by handler subroutines
> that are defined when the call is made.)

Whee, asynchronous callback fun. :)

Anyhow, I've never liked the RPC fault (code: INTEGER, reason: STRING) as 
the bearer of any significant amount of Volity traffic. Integers were a 
bad idea in FTP and HTTP. (Go on, tell me what they make better.) Strings 
make good programming identifiers ("ENOTYOURMOVE", etc), but can't be 
presented to the user in the common case, because of i18n issues. And in 
general, interactions between the player and the referee need to contain 
arbitrarily detailed information, as defined by the game.

The obvious (ok, to me) distinction is between "bugs" and "illegal moves". 
A player expects to get through a game session without hitting any bugs; 
but he may make any number of illegal moves.
(Continue reading)

Permalink | Reply |
headers
Jason McIntosh | 13 May 18:40
Gravatar

Re: How referees should respond to illegal plays

On May 12, 2005, at 8:15 PM, Andrew Plotkin wrote:

> Codes off the top of my head: (these apply only to the "game." RPC  
> namespace.)
>
> 400: Network failure
> 401: XML syntax error
> 402: Jabber protocol error
> 403: Unknown methodName
> 404: Missing method parameter
> 405: Mismatched parameter type
> 406: Identity rejected
> 409: Call illegal in this game state

Which one would the "quiamonds" example fall into? It's not really a  
parameter mismatch, since it was expecting a string and got one, or  
are you thinking more abstractly than that?

> "Identity rejected" means the caller isn't a player of this game.  
> That would be tested by common Volity::Game code, not game- 
> developer-written referee code.
>
> "Call illegal in this game state" is a generic fallback for  
> "illegal move" or "not your move". As I said, I don't think game  
> developers should rely on it, but it would be kind of anal not to  
> provide it as a possibility.

I think an advantage to this is that it allows a game programmer to  
handle player-generated exceptions that the ruleset (and therefore  
the UI files) didn't have the foresight to provide a method for.
(Continue reading)

Permalink | Reply |
headers
Andrew Plotkin | 13 May 20:46

Re: How referees should respond to illegal plays

On Fri, 13 May 2005, Jason McIntosh wrote:

> On May 12, 2005, at 8:15 PM, Andrew Plotkin wrote:
>
>> Codes off the top of my head: (these apply only to the "game." RPC 
>> namespace.)
>> 
>> 400: Network failure
>> 401: XML syntax error
>> 402: Jabber protocol error
>> 403: Unknown methodName
>> 404: Missing method parameter
>> 405: Mismatched parameter type
>> 406: Identity rejected
>> 409: Call illegal in this game state
>
> Which one would the "quiamonds" example fall into? It's not really a 
> parameter mismatch, since it was expecting a string and got one, or are you 
> thinking more abstractly than that?

Ha. No, I'm thinking more fuzzily than that. Add "407: Invalid parameter 
value".

>> "Call illegal in this game state" is a generic fallback for "illegal move" 
>> or "not your move". As I said, I don't think game developers should rely on 
>> it, but it would be kind of anal not to provide it as a possibility.
>
> I think an advantage to this is that it allows a game programmer to handle 
> player-generated exceptions that the ruleset (and therefore the UI files) 
> didn't have the foresight to provide a method for.
(Continue reading)

Permalink | Reply |
headers
Jason McIntosh | 13 May 22:05
Gravatar

Re: How referees should respond to illegal plays

On May 13, 2005, at 2:46 PM, Andrew Plotkin wrote:

> On Fri, 13 May 2005, Jason McIntosh wrote:
>
>> I'm remembering now I that I was thinking about this somewhat last 
>> year... standardizing the responses from the referee to game.* 
>> requests. (Right now it's just 'respond with something true' and 
>> usually isn't checked.) One idea I had, I think, involved letting all 
>> responses have a struct as their param. The struct has a key 'type' 
>> which can be "OK" for acknowledging a legal move, or "ERROR" or 
>> complaining that the player just committed a no-no. In the latter 
>> case, the struct contains 'error_type' and 'error_info' keys 
>> containing a string and another struct, respectively. Their content 
>> is defined by the appropriate ruleset.
>
> Again, this seems more like a recommended design pattern than 
> something we specify. But I could go either way with it.

Hm. I'd think I'd favor recommended patterns over enforced protocol at 
any choice between the two. I want to keep core Volity as simple as we 
can.

Zarf, could you add your suggested fault list to the Wiki somewhere, 
with some context?

--
   Jason McIntosh             jmac <at> jmac.org
Somerville, MA, USA       http://www.jmac.org

-------------------------------------------------------
(Continue reading)

Permalink | Reply |
headers
Denis Moskowitz | 3 May 03:39
Favicon

Re: How referees should respond to illegal plays

Zarf wrote:
> Doug wrote:
> > 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
> Yes, as a game author I'd certainly want this capability, in both the 
> failure responses and the success responses. ("You can't move your 
> <knight>, because that would expose your king to check from <queen> on 
> <e4>." Fields filled in from error response. SVG draws little dotted 
> attack line to illustrate.)

I just wanted to put in another call for errors not being in English 
strings - if you can avoid passing English sentences around, it'll be 
much easier to translate your game to other languages, or even have
players using different languages playing against each other in the same
game.

--Denis

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

Gmane