headers
Doug Orleans | 1 May 03:55
X-Face

Re: How referees should respond to illegal plays

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

 > 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, but it would
be a pain to have to set up a handler for error "requests" that can
come at any time.  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?

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

Permalink | Reply | 17 comments |
headers
Jason McIntosh | 1 May 01:20
Gravatar

How referees should respond to illegal plays

Currently, game-level errors (i.e. illegal moves) are handled by RPC 
faults. For example, if you try to play the three of clubs when you're 
not holding it, the referee responds not with a positive RPC response 
packet but with a fault, containing a numeric error code defined by the 
ruleset.

I concluded a while ago (encouraged by developer feedback) that this is 
actually incorrect behavior. For one thing, RPC faults should probably 
be reserved for lower-level errors, such as malformed RPC requests. 
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.

One developer suggested replacing the faults with a standard "illegal 
play" referee-to-client RPC request, whose arguments would be a text 
string identifying the error (from a list of possible strings defined 
by the ruleset) and an optional argument list.

On thinking about this a bit, I propose something simpler: much as 
table configuration is now defined by the ruleset (see 
http://www.volity.org/wiki/index.cgi?Table_Configuration), so is error 
handling. That is, the ruleset would define a set of referee-to-client 
RPC requests that would handle every possible error condition. Rather, 
every possible _class_ of error; the arguments would contain the 
specifics, and it would be up to the receiving UI to pass this 
information to the human player as best it can.

So, the Eights ruleset would add seven RPC requests, perhaps with these 
names (based on the list currently at
(Continue reading)

Permalink | Reply | 18 comments |
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 | 9 comments |
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 | 8 comments |
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 | 6 comments |
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 | 0 comments |
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 | 5 comments |
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 | 0 comments |
headers
Andy Turner | 3 May 23:15

Re: How referees should respond to illegal plays

On Sat, Apr 30, 2005 at 09:55:13PM -0400, Doug Orleans wrote:
>  > 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. 

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

--

-- 
Andy <turner <at> mikomi.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
Permalink | Reply | 6 comments |
headers
Benjamin Teuber | 6 May 15:59
Picon

Go for Volity

Hi brave volity-developers!

We're planning to design a OS game-server for the game of Go 
(http://senseis.xmp.net/?Go) and Volity looks very interesting for it.
I've already talked a bit with Jason about that topic before and he 
encouraged me that it's promising, although we have some longtime-goals 
that seem to go beyond volity's core-abilities.

The first problem would be game-discussions, that are sort of "games 
without winner that anyone can join/leave all of the time" in order to 
analize possible variations in played games. People should be able to 
propose moves for both players that are displayed to others in a 
"variation-tree" and give scores to the moves in order to determine the 
best.  I guess sth. like this could be interesting for other games like 
e.g. chess as well, so maybe this could become a volity-feature in the 
future - what do you think?

There are other ideas like voice-chat or database-connection for 
opening-libraries etc., but I think this could be done somehow.

Probably we will also want to make our own client in the future, as the 
UI-files probably don't cover contect-menues with DB-options etc - this 
can be decided later anyways.

Another question: How far are you with the project - everything running 
stable in the near future? Where are you working right now?

Btw, our project's page is http://senseis.xmp.net/?UGS if you're interested.

Greetings,
(Continue reading)

Permalink | Reply | 5 comments |

Gmane