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
Gravatar

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
Gravatar

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
Gravatar

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

Gmane