Developement-level discussion of Volity, a network protocol and programming framework for Internet game-playing.

Jason McIntosh | 1 May 01:20

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)

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)

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

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)

Jason McIntosh | 7 May 17:44

Re: Go for Volity

On May 6, 2005, at 9:59 AM, Benjamin Teuber wrote:

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

In mulling this over, I think there are are two ways to solve this. In 
either case, your task is made easier by the fact that you are 
primarily interested in one game with no real variants. (If I 
understand correctly, the only variable in Go is the possibility of one 
side, the stronger player, starting with a voluntary handicap.)

First, you could write a very specialized client just for playing Go 
over Volity, as I described to you in email already. It would add all 
these features and player-to-player communication you want at the 
client level, and use some communication protocol of your own invention 
as well as using Volity's to actually play the game.

(Continue reading)

Benjamin Teuber | 8 May 20:42

Picon

Re: Go for Volity

Oh, I just did send this to Jason on accicent:

>> 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?
>
>
> In mulling this over, I think there are are two ways to solve this. In 
> either case, your task is made easier by the fact that you are 
> primarily interested in one game with no real variants. (If I 
> understand correctly, the only variable in Go is the possibility of 
> one side, the stronger player, starting with a voluntary handicap.)

Well, variables are board size (normally 19x19) and time limitation
(basic time and so-called "byoyomi"[kind of overtime]) - do you have
anything for time-limits yet?

>
> First, you could write a very specialized client just for playing Go 
> over Volity, as I described to you in email already. It would add all 
> these features and player-to-player communication you want at the 
> client level, and use some communication protocol of your own 
> invention as well as using Volity's to actually play the game.
>
> Another option, though, is to put all this stuff server-side. That is,

(Continue reading)

Jason McIntosh | 8 May 22:36

Re: Go for Volity

On May 8, 2005, at 2:42 PM, Benjamin Teuber wrote:

> Well, variables are board size (normally 19x19) and time limitation
> (basic time and so-called "byoyomi"[kind of overtime]) - do you have
> anything for time-limits yet?

Interesting question. No, there's no concept of the passage of time in 
Volity, and I'm not sure that there should be, even though it's a 
feature of many real-life games. The questions of variable network 
latency and dropped-connection recovery make this a pretty complex 
problem, assuming you want to referee to be fair about it.

> Great! Well, I wouldn't call myself a Perl-fan, and most people in our
> project seem to prefer Java, but I guess to start with basic modules 
> and
> stuff, Perl is fine. Maybe someone of you could help me with buildung a
> simple Go-module?

I'm the author of most of the Perl stuff (the Frivolity package), so 
you can just write me directly with questions about it. (Hmm, perhaps I 
should launch a mailing list about Frivolity, too... well, we'll see.)

--
   Jason McIntosh             jmac <at> jmac.org
Somerville, MA, USA       http://www.jmac.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

(Continue reading)

Doug Orleans | 8 May 23:04

X-Face

Re: Go for Volity

Jason McIntosh writes:
 > On May 8, 2005, at 2:42 PM, Benjamin Teuber wrote:
 > 
 > > Well, variables are board size (normally 19x19) and time limitation
 > > (basic time and so-called "byoyomi"[kind of overtime]) - do you have
 > > anything for time-limits yet?
 > 
 > Interesting question. No, there's no concept of the passage of time in 
 > Volity, and I'm not sure that there should be, even though it's a 
 > feature of many real-life games. The questions of variable network 
 > latency and dropped-connection recovery make this a pretty complex 
 > problem, assuming you want to referee to be fair about it.

While I wouldn't want to play a timed game for money on the Internet,
I have played plenty of timed Scrabble games on the net, and it was
never a big deal.  The granularity of time penalties (10 points per
minute or portion thereof) is not really fine enough for latency to be
an issue, and if one player has network connection problems, his
opponent can pause the clock.  If both players have serious netlag,
they can just agree to stop the game, or to just set the game to be
untimed (perhaps retroactively).  Some of this could even be
automated, i.e. every time a player (or the referee!) leaves the table
the clock is automatically paused.

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

(Continue reading)

Jason McIntosh | 8 May 23:53

Re: Go for Volity

On May 8, 2005, at 5:04 PM, Doug Orleans wrote:

> Some of this could even be
> automated, i.e. every time a player (or the referee!) leaves the table
> the clock is automatically paused.

And you know, it just occurred to me that I didn't really answer 
Benjamin's question correctly.

While it's true that _I_ haven't though of it, there's absolutely 
nothing stopping a game implementation from giving the referee a 
turn-timer. Referees are perfectly capable of sending RPC requests that 
aren't purely reactive, and these can include "Oops, you took too long" 
followed by an announcement that it's now the next player's turn.

I don't think it needs to be something supported at the core level. 
Which is good.

--
   Jason McIntosh             jmac <at> jmac.org
Somerville, MA, USA       http://www.jmac.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

Jason McIntosh | 1 May 21:37

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)

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)

Karl von Laudermann | 3 May 01:19

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)

Jason McIntosh | 2 May 01:11

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)

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)

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)

Jason McIntosh | 13 May 18:40

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)

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)

Jason McIntosh | 13 May 22:05

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)

Denis Moskowitz | 3 May 03:39

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

Return

Return to gmane.comp.games.volity.devel.

Project Web Page

Developement-level discussion of Volity, a network protocol and programming framework for Internet game-playing.

Search Archive

Language

Change language

Options

Current view: Threads only / Showing only 20 lines / Not hiding cited text.
Change to All messages, whole messages, or hide cited text.

Post a message
NNTP Newsgroup
Classic Gmane web interface
XML

XML

RSS Feed
List Information

About Gmane