headers
Roger Crew | 5 Jun 00:23
Picon

Re: Seats: actual protocol proposal

>   "Seat" (originally Rog's suggestion, way back last year) I didn't  
>   like because, I suppose it sounded too inanimate, and because I  
>   always got a goofy mental image of several players squishing into the  
>   same physical chair.

I had pretty much exactly this image, except the chairs are more like
those big spherical things they used in "The Prisoner" -- big black
ball that Number Two sits in -- you can see in occasionally, but most
of the time, you just hear the voice and have no idea who's really in
there and what they're actually doing ...

... which is sort of the point.

Actually, I was growing fond of "role" but if Jabber has screwed
that up for us, so be it.

Anyway, I have a counterproposal, which is simpler in some ways:

    ref_to_player:
       players_sitting(seat_id, LIST of jids)

    Reports the current state of a given seat.  
    The list may be empty.

    player_to_ref:
       change_seat(jid[, seat_id])

    Expresses the preference that jid should be sitting in seat_id.
    The sender does not need to be jid.
    Omitting seat_id means "I don't care" and undoes any previously
(Continue reading)

Permalink | Reply |
headers
Jason McIntosh | 5 Jun 04:47
Picon

Re: Seats: actual protocol proposal

On 4 Jun 2005 15:23:47 -0700, Roger Crew <wrog <at> users.sourceforge.net> wrote:
> 
> Anyway, I have a counterproposal, which is simpler in some ways:
> 
>     ref_to_player:
>        players_sitting(seat_id, LIST of jids)
> 
>     Reports the current state of a given seat.
>     The list may be empty.

So you'd send this out every time a player changed seats, with the
whole roster of that seat as an argument? Is this more efficient or
easy to handle than using my player_sat(seat, jid) call instead,
accepting that my version might have to be called more times (once for
each sitting player) initially?

>     player_to_ref:
>        change_seat(jid[, seat_id])
> 
>     Expresses the preference that jid should be sitting in seat_id.
>     The sender does not need to be jid.
>     Omitting seat_id means "I don't care" and undoes any previously
>     expressed preference that might still be pending.
> 
> The players_sitting() calls come first, i.e., everyone who joins the
> game gets seated *somewhere* AND gets a full seat roster blasted at them
> in the form of players_sitting() msgs.

When you join the table, though, you're not sitting anywhere... you're
standing, which is a separate state, and useful if you just want to
(Continue reading)

Permalink | Reply |
headers
Roger Crew | 5 Jun 09:59
Picon

Re: Seats: actual protocol proposal

>   > If you don't like where anybody is sitting, you move people around
>   > using change_seat() calls, which the ref acts on or not however it
>   > chooses.  But, by default, anyone can move anyone else.
>
>   But why not let people move just themselves around? 

I never said they couldn't, i.e., you can move yourself with a
change_seat() just fine.  The point is not to have the question of
whose seat you're changing be a hardwired implicit argument 
(i.e., ==you)

>   And if Alice has taken it upon herself to set up the game and 
>   thinks Bob should be sitting in West, I don't think it's unreasonable 
>   to leave it to her to go "Hey Bob, go sit in West" via Jabber messaging. 
>   I think that's even simpler, and seems more natural to me than the 
>   ref dragging me around based on another player's whim. 

  A:sit('s')
  A:"Hey Bob, go sit in West"
  A:"Hey Charlie, go sit in East"
  A:"Hey Dave, go sit in North"
  C:sit()
  A:"Hey Ed, go sit in Northwest"
  A:"No, no, Charlie. EAST!"
  D:sit('b')->error
  D:"Hey Alice, how do I move to North?"
  C:sit('e')
  A:"Go to the seat menu in the upper right corner."
  D:"What?"
  ...
(Continue reading)

Permalink | Reply |
headers
Roger Crew | 5 Jun 09:57
Picon

Re: Seats: actual protocol proposal

>   >     player_to_ref:
>   >        change_seat(jid[, seat_id])
>   > 
>   >     Expresses the preference that jid should be sitting in seat_id.
>   >     The sender does not need to be jid.
>   >     Omitting seat_id means "I don't care" and undoes any previously
>   >     expressed preference that might still be pending.
>   > 
>   > The players_sitting() calls come first, i.e., everyone who joins the
>   > game gets seated *somewhere* AND gets a full seat roster blasted at them
>   > in the form of players_sitting() msgs.
>
>   When you join the table, though, you're not sitting anywhere... you're
>   standing, which is a separate state, and useful if you just want to
>   watch (from no particular player's POV) and kibitz. (And you can pop
>   out of all seats but remain at the table with the volity.stand()
>   call.)
>
>   Agreed on the idea of the seat-definition blast upon joining the
>   table, but I can't agree that the ref _must_ send the contents of
>   every possible seat at that moment... there are, after all, games with
>   no upper limit on seats (until it starts). 

In any such game, there will never be any more seats than players in
the game.  The ref only needs to report the existence of sufficiently
many seats to cover the various choices the players can make at that
point.  So, for example, if game rules call for N undistinguished
players with no bound on N, then we could have a ref reporting

  players_sitting(0, [])         # Hey, everybody! seat 0 is empty
(Continue reading)

Permalink | Reply |
headers
Andrew Plotkin | 5 Jun 18:01

Re: Seats: actual protocol proposal

On Sun, 5 Jun 2005, Roger Crew wrote:

>>   Agreed on the idea of the seat-definition blast upon joining the
>>   table, but I can't agree that the ref _must_ send the contents of
>>   every possible seat at that moment... there are, after all, games with
>>   no upper limit on seats (until it starts).
>
> In any such game, there will never be any more seats than players in
> the game.  The ref only needs to report the existence of sufficiently
> many seats to cover the various choices the players can make at that
> point.

> [example]
> At each stage, with K seats filled, a new player has K+1 choices,
> i.e., join one of the existing players (1..K) or sit in a fresh seat
> (0).  So the ref never needs to report on more than K+1 seats,
> even if the game might ultimately get much larger.

Can we drop idea of "seat zero" and go back to Jason's idea of sit() and 
sit(seat)? Except make it sit(player) and sit(player, seat). [Ignoring the 
question of whether we want to do that, which I'll hit later on.]

Umf, but then the referee has no way to tell the clients "all seats are 
full", except to return an error to a sit() request. Which doesn't bother 
me.

> Once there are enough players and they all indicate readiness,
> the ref can then start the game and do
>
>  players_sitting(0, undef)      # seat 0 is no longer valid
(Continue reading)

Permalink | Reply |
headers
Roger Crew | 6 Jun 00:58
Picon

Re: Seats: actual protocol proposal

>   From: Andrew Plotkin <erkyrath <at> eblong.com>
>   >>   Agreed on the idea of the seat-definition blast upon joining the
>   >>   table, but I can't agree that the ref _must_ send the contents of
>   >>   every possible seat at that moment... there are, after all, games with
>   >>   no upper limit on seats (until it starts).
>   >
>   > In any such game, there will never be any more seats than players in
>   > the game.  The ref only needs to report the existence of sufficiently
>   > many seats to cover the various choices the players can make at that
>   > point.
>
>   > [example]
>   > At each stage, with K seats filled, a new player has K+1 choices,
>   > i.e., join one of the existing players (1..K) or sit in a fresh seat
>   > (0).  So the ref never needs to report on more than K+1 seats,
>   > even if the game might ultimately get much larger.
>
>   Can we drop idea of "seat zero" 

Hello.  This was an EXAMPLE of how to deal with games where it doesn't
make sense to list all possible seats in advance, and thus you have to
do SOMETHING weird no matter what.  There are doubtless all sorts of
other ways to handle this.

The main underlying point is that as long as we don't require the
referee's player_sat/sitting() messages to necessarily have anything
to do with the various sit/change_seat() requests (we don't, do we?),
e.g., that we don't require the ref to assign the requested seat_id or
forbid the ref from spontaneously reseating people at whim, stuff like
this will be allowed,
(Continue reading)

Permalink | Reply |
headers
Andrew Plotkin | 5 Jun 07:34

Re: Seats: actual protocol proposal

On Sat, 4 Jun 2005, Jason McIntosh wrote:

> On 4 Jun 2005 15:23:47 -0700, Roger Crew <wrog <at> users.sourceforge.net> wrote:
>>
>> Anyway, I have a counterproposal, which is simpler in some ways:
>>
>>     ref_to_player:
>>        players_sitting(seat_id, LIST of jids)
>>
>>     Reports the current state of a given seat.
>>     The list may be empty.
>
> So you'd send this out every time a player changed seats, with the
> whole roster of that seat as an argument? Is this more efficient or
> easy to handle than using my player_sat(seat, jid) call instead,
> accepting that my version might have to be called more times (once for
> each sitting player) initially?

I think player_sat will be easier to handle. If a player changes seats, 
you'd need two players_sitting(seat, list) calls. Phooi.

In theory, players_sitting() reduces the chance of clients getting out of 
sync, because it's blasting more information around. But, this is only a 
probabilistic improvement, and I'm not expecting that kind of trouble 
anyway.

>> If you don't like where anybody is sitting, you move people around
>> using change_seat() calls, which the ref acts on or not however it
>> chooses.  But, by default, anyone can move anyone else.
>
(Continue reading)

Permalink | Reply |
headers
Jason McIntosh | 6 Jun 08:07
Picon

Re: Seats: actual protocol proposal

On 6/5/05, Andrew Plotkin <erkyrath <at> eblong.com> wrote:
> We are assuming, right, that the players-sitting-down stuff is
> "in game code"?

I've actually been thinking all along that it'd be all the client's
responsibly to sort that out. Karl and I have been discussing how to
do with with Javolin, albeit not since the most recent seat discussion
here. Still, the UI I'm envisioning could still accomodate it: a
simple list of the table's occupants (represented by their MUC
nickname and -- in the future -- an icon) separated into who is
standing (just observing) and who is sitting. We'd just further break
down the latter list into seats. (Rather, visually group together
occupants sharing a seat, and sticking a label ("Red", "East", "Player
5") on each group.)

There'd be two distinct sitting commands which actually call the "make
me a new seat" and "put me in the [foo] seat" referee requests. These
can be variously linked to buttons and menu commands in several sane
ways. The new-seat one would be more obvious by design, since it's the
one that people will usually want, but the other one won't be hard to
reach.

If we decide that UI files can have this info too (and we very well
may) then they can present it too, but this way they don't have to,
and I bet that most of the time it's just as well that they don't.

-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.
(Continue reading)

Permalink | Reply |
headers
Roger Crew | 5 Jun 12:07
Picon

Re: Seats: actual protocol proposal

>   From: Andrew Plotkin <erkyrath <at> eblong.com>
>   On Sat, 4 Jun 2005, Jason McIntosh wrote:
>
>   > On 4 Jun 2005 15:23:47 -0700, Roger Crew <wrog <at> users.sourceforge.net> wrote:
>   >>
>   >> Anyway, I have a counterproposal, which is simpler in some ways:
>   >>
>   >>     ref_to_player:
>   >>        players_sitting(seat_id, LIST of jids)
>   >>
>   >>     Reports the current state of a given seat.
>   >>     The list may be empty.

It's something of a matter of taste, I'll grant, but this version can
accomodate a jid being in more than one seat at a time if we ever want 
to allow that (and I think we do).

But more importantly, it allows announcing the seats that don't have
players in them yet, which is how you get the seat_ids out there to
begin with.  Though I'll grant one could also allow player_sat() to
omit the jid, even if that looks a bit weird to me.

>   > So you'd send this out every time a player changed seats, with the
>   > whole roster of that seat as an argument? Is this more efficient or
>   > easy to handle than using my player_sat(seat, jid) call instead,
>   > accepting that my version might have to be called more times (once for
>   > each sitting player) initially?
>
>   I think player_sat will be easier to handle. If a player changes seats, 
>   you'd need two players_sitting(seat, list) calls. Phooi.
(Continue reading)

Permalink | Reply |

Gmane