headers
Jason McIntosh | 4 Jan 06:48
Gravatar

MUC configuration question

Peter, or anyone else who pays more attention to the spec than me:

In JEP-0045, are the the Jabber Registrar-defined "muc#roomconfig_foo" 
fields the _only_ fields that the MUC server should expect in incoming 
room-configuration forms?

I'm currently running into a problem where a new Volity referee is 
having trouble configuraing a room for the non-anonymity it wants, 
because the MUC server currently running on volity.net seems to be deaf 
to all those fields, and offers instead (when asked for a blank form) 
some completely different, non-namespaced fields of its own.

(I am suspecting that the ejabberd MUC (at least the version we're 
running now) is a little weird and off-spec in other ways -- most 
notably in that, if I send no config form at all to a new room, other 
users can still wander in.)

--
   Jason McIntosh             jmac <at> jmac.org
Somerville, MA, USA       http://www.jmac.org

-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
Permalink | Reply | 3 comments |
headers
Peter Saint-Andre | 4 Jan 19:30

Re: MUC configuration question

In article <488274E4-5E14-11D9-99C2-000A95CBBC34 <at> jmac.org>,
 Jason McIntosh <jmac <at> jmac.org> wrote:

> Peter, or anyone else who pays more attention to the spec than me:
> 
> In JEP-0045, are the the Jabber Registrar-defined "muc#roomconfig_foo" 
> fields the _only_ fields that the MUC server should expect in incoming 
> room-configuration forms?
> 
> I'm currently running into a problem where a new Volity referee is 
> having trouble configuraing a room for the non-anonymity it wants, 
> because the MUC server currently running on volity.net seems to be deaf 
> to all those fields, and offers instead (when asked for a blank form) 
> some completely different, non-namespaced fields of its own.

Those are the recommended configuration fields. A MUC server is allowed 
to offer other fields, but that is not recommended. I'd file a bug 
report with the ejabberd folks.

> (I am suspecting that the ejabberd MUC (at least the version we're 
> running now) is a little weird and off-spec in other ways -- most 
> notably in that, if I send no config form at all to a new room, other 
> users can still wander in.)

It may time out the room configuration. That's mentioned in JEP-0045 as 
allowable.

/psa

-------------------------------------------------------
(Continue reading)

Permalink | Reply | 2 comments |
headers
Jason McIntosh | 6 Jan 22:05
Picon

Reconnection and recovery

Though it's not on the roadmap (yet) I definitely want to have 
reconnection ability in the protocol and implemented in Frivolity this 
month.

The client side is the easy part. See my proposed protocol here: 
http://www.volity.org/wiki/index.cgi?State_Recovery

In a nutshell, the client can, at any point, send a RPC request called 
volity.get_full_state() to the referee. It responds by calling a 
sequence of ordinary ruleset-specific RPC requests back on the player, 
tailed with a volity.state_sent() request to show that it's finished.

The more complicated part involves how referees should react to players 
abruptly leaving the table. There are several ways I think of to handle 
this, such as:

1. The referee just sits and waits indefinitely for the player's 
return. The returning player must have the same JID as the lost one. 
The simplest solution. Also, the lamest.

2. The referee waits for some amount of time for the same-JID-player's 
return (perhaps determined by table configuration) and then kills the 
game. It tells the bookkeeper that the player cut out.

3. As above, except that the ref plops a bot in the lost player's seat. 
It still tells the bookkeeper that the player cut out, and lets the bot 
take credit appropriately.

4. The referee remembers how many seats were filled (lets call this 
number S), and then sets all players' status to 'unready', preventing
(Continue reading)

Permalink | Reply | 3 comments |
headers
Denis Moskowitz | 7 Jan 00:38
Favicon

Re: Reconnection and recovery

This is something multi-player poker sites deal with as well.  The
usual solution in straight money games is to give someone a small amount 
of time to reconnect, then assume a "check or fold" strategy for that hand
and drop them from the game afterwards if they haven't rejoined.  In 
tournaments (where the play is in special "tournament chips" that are not 
directly redeemable), they are set to a stupid conservative strategy that 
slowly loses money until they return or are knocked out of the tournament.  
Some sites provide a limited number of special protections to keep someone 
from being raised out of a hand if they lose connection in mid-hand, but
those protections are limited to prevent abuse.
--Denis

-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
Permalink | Reply | 2 comments |
headers
Jason McIntosh | 7 Jan 00:47
Picon

Re: Reconnection and recovery

On Jan 6, 2005, at 6:38 PM, Denis Moskowitz wrote:

> This is something multi-player poker sites deal with as well.  The
> usual solution in straight money games is to give someone a small 
> amount
> of time to reconnect, then assume a "check or fold" strategy for that 
> hand
> and drop them from the game afterwards if they haven't rejoined.  In
> tournaments (where the play is in special "tournament chips" that are 
> not
> directly redeemable), they are set to a stupid conservative strategy 
> that
> slowly loses money until they return or are knocked out of the 
> tournament.
> Some sites provide a limited number of special protections to keep 
> someone
> from being raised out of a hand if they lose connection in mid-hand, 
> but
> those protections are limited to prevent abuse.

So in other words, it takes the replace-with-bot strategy, with the 
condition that it's a special bot designed to have no winning ambition 
and generally do as little as possible for as long as is needed to see 
the game through?

--
   Jason McIntosh             jmac <at> jmac.org
Somerville, MA, USA       http://www.jmac.org

-------------------------------------------------------
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jason McIntosh | 7 Jan 00:27
Gravatar

Re: Seats

On Dec 30, 2004, at 7:29 PM, Roger Crew wrote:

> First of all, record keeping is NEVER going to be certain.
> You never really know who's standing behind the workstation looking
> over whoever's shoulder and giving advice.

Granted. I don't think any game system where the players can't 
physically see one another can avoid this. I don't foresee it being a 
huge problem, so long as we take the attitude the the story game 
records tell are more a suggestion of their players' relative 
abilities, and not a tournament-legal ladder. Furthermore, this 
information will be tempered by the reputation system (at least that's 
my hope).

> Note that you're already sweeping under the rug a whole pile of similar
> issues for the case of multiplayer games being won by alliances.

Mmmmaybe; it depends on what you mean by alliances. In-game shared wins 
among multiple players are actually accounted for in the current 
system, though there is no differentiation between an explicit team 
victory and some players who happened to place together at the end.

> Anyway, there are (at least) two easy solutions for version 1.0:
>
> (1) the game scores for "jmac;wrog" or somesuch canonical
>     concatenation of our JIDs.  This way, you get separate ratings for
>     every combination of people who've ever played a role together, and
>     there's no point in trying to break it down further than that.

Interesting idea.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jason McIntosh | 7 Jan 00:35
Gravatar

Re: Re: MUC configuration question

On Jan 4, 2005, at 1:30 PM, Peter Saint-Andre wrote:

> In article <488274E4-5E14-11D9-99C2-000A95CBBC34 <at> jmac.org>,
>  Jason McIntosh <jmac <at> jmac.org> wrote:
>
>> Peter, or anyone else who pays more attention to the spec than me:
>>
>> In JEP-0045, are the the Jabber Registrar-defined "muc#roomconfig_foo"
>> fields the _only_ fields that the MUC server should expect in incoming
>> room-configuration forms?
>>
>> I'm currently running into a problem where a new Volity referee is
>> having trouble configuraing a room for the non-anonymity it wants,
>> because the MUC server currently running on volity.net seems to be 
>> deaf
>> to all those fields, and offers instead (when asked for a blank form)
>> some completely different, non-namespaced fields of its own.
>
> Those are the recommended configuration fields. A MUC server is allowed
> to offer other fields, but that is not recommended. I'd file a bug
> report with the ejabberd folks.

OK.

Is there a way, perhaps through disco, to tell if a server responds to 
those fields? I'd would be nice if a game server program, upon launch, 
could make sure that the MUC server it's configured to use supports the 
only configuration fields it knows how to send.

>> (I am suspecting that the ejabberd MUC (at least the version we're
(Continue reading)

Permalink | Reply | 1 comment |
headers
Denis Moskowitz | 7 Jan 00:56
Favicon

Re: Reconnection and recovery

[jmac]
> So in other words, it takes the replace-with-bot strategy, with the 
> condition that it's a special bot designed to have no winning ambition 
> and generally do as little as possible for as long as is needed to see 
> the game through?

Yes, exactly, considering each hand at a cash table as a "game", but 
considering the entire tournament a "game".  The important thing is not to
"penalize" the other players, where "penalize" = "decrease chance of
winning".  In a game you're just playing for fun, you might have a
different definition of penalize.
--Denis

-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
Permalink | Reply | 0 comments |
headers
Jason McIntosh | 7 Jan 02:45
Gravatar

Re: ES SVG lib? (was Re: Eights SVG)

On Dec 30, 2004, at 8:26 PM, Mike Sugarbaker wrote:

> Is it time to start thinking about a standard set of scripts to
> provide to Volity UI writers? I'm thinking of basic things like
> generating combo boxes, draggable things and drag targets, simple
> sprites (on the level of "here are the shapes in your walk animation,
> flip through them when i tell you 'walk' and stop when i tell you
> 'stop'"), grids (automagically spec out either a chessboard-like thing
> or an RPG inventory-like thing, or a grid layout for something else
> entirely)...

My focus on finishing the core protocol, and cheering on the Javolin 
hackers as they push its first releases out the door, has prevented me 
from spending a lot of time thinking about how UIs are actually made, 
even though they're actually at least as important to actual gameplay 
as all the other stuff. (I made an exception to finish the Eights SVG 
so that Javolin would have multiple working examples, at least one of 
which was less lame than rock-paper-scissors.)

I have assumed (or, rather, dreamed) from the start that "someday" 
there would exist a whole application suite just for creating UI files 
and shared UI-component libraries. The first steps towards this ideal 
are little reusable patterns just of the sort you describe above.

> A casual cruise through google world has surprisingly not revealed any
> ECMAScript libraries for simple UI widgets, although it seems like
> such an obvious project that I could be wrong. Plenty for generating
> SVG from Java and such, but nothing in pure ES. Such a library seems
> both useful for Volity and likely to catch on with other projects as
> well.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jason McIntosh | 7 Jan 03:52
Gravatar

Proposed reputation system protocol

Since it was on my mind from posts earlier today, I went ahead and 
sketched out the minimum RPC requests needed to make the reputation 
system usable, and added them to the topic's Wiki page: 
http://www.volity.org/wiki/index.cgi?Reputation_System (halfway down)

I originally thought that the system would be completely anonymous -- 
players could see reputation scores, but not the individual player 
votes that constituted them. But now, I can't think of a reason why we 
shouldn't allow total transparency. I welcome any arguments in either 
direction.

--
   Jason McIntosh             jmac <at> jmac.org
Somerville, MA, USA       http://www.jmac.org

-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
Permalink | Reply | 1 comment |

Gmane