Offline play

"Offline play" isn't the best term here. What I mean is, some people will 
want to play some Volity games with a "play-by-email" pace. Sit down at 
computer, start Volity, look at all the games you're in, make a move in 
each, shut down Volity, go do something else.

(Note that "start Volity" is a deliberately vague term. If we had a 
web-browser client, it would mean "open a new window with the game 
finder", and then shutting down Volity would mean closing that window. 
With Gamut, someone might leave the client running in the background, but 
would probably want to close all the game windows or even sign off of 
Jabber.)

What I'm sure of is that many people will *not* want to leave Gamut 
running for days at a time, with game windows open. That's what you 
currently have to do to play a slow-paced Volity game. It's not an 
acceptable solution for everybody.

So we need some system to allow "offline" games -- games where all the 
players are offline most of the time.

At the same time, I think there's a lot of value to the current system, in 
which games are discarded quickly when the players abandon them. The 
current rules (see wiki [[Referee_States]]) say that an abandoned game 
auto-suspends after a few minutes, so that interested observers can jump 
in and take over the empty seats. And if there are no human players *or* 
observers, the game auto-destroys itself after 90 seconds. With these 
rules, any table you see in the game finder is an active table -- or at 
least a table with some humans logged on whom you can talk to.

One obvious way to allow "offline" games is to crank that auto-suspend 

Re: Offline play

Andrew Plotkin wrote:
> So the first question is, is this okay? Setting up a binary split between 
> fast-paced games and slow-paced games. I figure this would be a boolean 
> config variable (like "record outcome" and "table visible") -- settable by 
> the players, with the default value determined by the parlor admin. Am I 
> missing a third class which it is reasonable to distinguish?

I think that there is a clear distinguishing factor between these two, and
I can't personally think of a third class of "game time" that makes any sense.
Either the game is "interactive" (people playing on the spot) or it's not.
(I will refer to this as "non-interactive" through the rest of the eMail,
although that's obviously a misnomer.)

> So again, the easy way to implement the "offline" game (once the config 
> variable is set) is to set the auto-suspend timer up to, say, a week. (The 
> particular value may be twiddled with by the parlor admin, but I think 
> it's overly confusing to make it a player choice. One reason I brought up 
> the binary split is that it's easy to explain.)

Anyone can hop into seats in a game that's suspended, right?  There needs to
be some way to say "only these JIDs are allowed to occupy the seats, despite
the suspension."  This could also be a configuration open on a particular
referee instance; jidBound (for example) defaulting to false for interactive
games and true for "non-interactive."

> With this implementation, everything works, except that we'd want to 
> rearrange the game finder to separate fast games from slow games.

Definitely.

Re: Offline play

(Dig the new sig file! I will be using zarf <at> volity.com for most 
Volity-related stuff, but the old erkyrath <at> eblong.com address still works 
-- it all goes to the same place.)

On Thu, 6 Jul 2006, Phil Bordelon wrote:

> Andrew Plotkin wrote:
>> So the first question is, is this okay? Setting up a binary split between
>> fast-paced games and slow-paced games. I figure this would be a boolean
>> config variable (like "record outcome" and "table visible") -- settable by
>> the players, with the default value determined by the parlor admin. Am I
>> missing a third class which it is reasonable to distinguish?
>
> I think that there is a clear distinguishing factor between these two, and
> I can't personally think of a third class of "game time" that makes any sense.

Ok, good.

> Either the game is "interactive" (people playing on the spot) or it's not.
> (I will refer to this as "non-interactive" through the rest of the eMail,
> although that's obviously a misnomer.)

At some point we'll have a consistent terminology.

>> So again, the easy way to implement the "offline" game (once the config
>> variable is set) is to set the auto-suspend timer up to, say, a week. (The
>> particular value may be twiddled with by the parlor admin, but I think
>> it's overly confusing to make it a player choice. One reason I brought up
>> the binary split is that it's easy to explain.)
>

Re: Offline play

Andrew Plotkin wrote:

> No, I think that policy should not change. A game can only be suspended if 
> (a) one of the seated players decides to suspend it, or (b) the 
> seated players all disconnect and then the auto-suspend timer fires. In 
> either case, the game should be open for re-seating by observers or bots.
> 
> The point of setting the timer to seven days for "offline" games is that 
> someone must make a move at least once a week. That's how we know that the 
> game hasn't been abandoned. As long as a seated player connects to the 
> table at least that often, the timer will never go off. If the game *is* 
> abandoned, reseating is okay.

So now you'll be able to leave the game (in terms of "closing the
Gamut window") while still being seated?  This is new functionality,
right?

> Reasonable idea, although serialization bugs are going to be a whole new 
> can of squid for the game developer to worry about.

Agreed.  The way Simon Tatham's Puzzle Collection gets around it is by
effectively serializing after every move--each play in the game is as
if you started from scratch.  This pretty much guarantees that your
serialized functions are written correctly; otherwise you wouldn't be
able to play a game to completion.

>> It could be a new, optionally-implemented set of function calls that 
>> referees can handle.  If a referee provides them, that referee is usable 
>> for "non-interactive" games; otherwise it can only do "interactive" 
>> games.  There are many games where "non-interactive" doesn't make much 

Re: Offline play

On Fri, 7 Jul 2006, Phil Bordelon wrote:

> Andrew Plotkin wrote:
>
>> No, I think that policy should not change. A game can only be suspended if
>> (a) one of the seated players decides to suspend it, or (b) the
>> seated players all disconnect and then the auto-suspend timer fires. In
>> either case, the game should be open for re-seating by observers or bots.
>>
>> The point of setting the timer to seven days for "offline" games is that
>> someone must make a move at least once a week. That's how we know that the
>> game hasn't been abandoned. As long as a seated player connects to the
>> table at least that often, the timer will never go off. If the game *is*
>> abandoned, reseating is okay.
>
> So now you'll be able to leave the game (in terms of "closing the
> Gamut window") while still being seated?  This is new functionality,
> right?

No, this is the way it works now. If you close a table window while you're 
seated, and then rejoin the table within three minutes, you'll find 
yourself back in your seat. Everybody can do this at once, as long as 
someone returns within three minutes. The game will be marked as 
"abandoned" but not "suspended".

(It would be desirable to change the label "abandoned" to something less 
frightening for offline games, but the underlying state definition 
wouldn't be any different.)

> Fair enough.  This brings up another point, though: Have you done

Proposal: scheduled games

One way to get more people on the network consistently would be to
allow players to schedule games. A person seeing some free game-time
in their future can declare that they would love to play, say,
Werewolf next Wednesday at 9pm in their time zone, and open up a list
where other people can add their own name to a list of players due for
an invitation to that table when the time comes.

My proposal extends bookkeeper and parlor behavior:

The primary addition is a bookkeeper-to-parlor "scheduled_table
(creator, message invitation_list)" RPC. The first argument is the
basic JID of the player who created the scheduled game, and the second
is a message that the creator might have specified to be attached to
the invitation - possibly null or a blank string. The third argument
is an array of all the players invited to the table (including the
creator).

Upon receipt of this RPC, the parlor would create a table and spawn a
referee into it. This referee would then send ordinary Volity
message-based invitations to all the players on the invitation list.
The text of the invitation must contain the message passed as the
second argument in the triggering RPC, if there is one. It should also
contain some referee-generated text identifying this as a
scheduled-game invitation, and naming the JID of the player who
scheduled it.

And that's all; the bookkeeper would effectively forget about the
event, and neither the parlor or the new referee would do anything
else about it. It would be up to the invited players to respond to the
invitation, and to assign seating and carry out the game(s) as usual.

Unixtime timestamps

Would it be Considered Harmful to specify, throughout the Volity
protocols, that all timestamps must be expressed as Unixtime - i.e.
seconds since the epoch, GMT?

--

-- 
Jason McIntosh
President and Founder
Volity Games
jmac <at> volity.com
617-792-3829

Digital Games for Analog People.
http://volity.net

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

Re: Unixtime timestamps

On Sat, Jul 08, 2006 at 03:15:39PM -0400, Jason McIntosh wrote:
> Would it be Considered Harmful to specify, throughout the Volity
> protocols, that all timestamps must be expressed as Unixtime - i.e.
> seconds since the epoch, GMT?

Why this rather then W3CDTF?  Unixtime is a giant pain in the ass on
non-unix platforms.

--

-- 
Andy <turner <at> mikomi.org>

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

Re: Proposal: scheduled games

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

_______________________________________________
Volity-devel mailing list
Volity-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/volity-devel

Re: Proposal: scheduled games

This can be alleviated to a limited extent with bots, which is how
we've been doing it so far. But with Werewolf, we've got a game that's
not only essentially bot-proof, but needs a <em>lot</em> of human
players present to work well.

It's for Werewolf's sake that I'd like to implement this, but I think
that it would make all the games happen far more often as well.
- Hide quoted text -

--
Jason McIntosh
President and Founder
Volity Games
jmac <at> volity.com
617-792-3829

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642