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