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
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). A client should instead
just accept the reality of seats as it's told about them, whenever
that may be.

> 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? 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. (And as an aside I'll note that a
ruleset can implement its own imperative player-tossing methods if
it's _that_ useful for a particular position-intensive game to have.)

> Note that seat_ids are specified by the game designer back at the
> beginning of time and NEVER EVER CHANGE (*).  Since a seat identifies
> a role in the game, it is meaningless to talk about changing the ID of a
> seat; if you want to someone to assume a different role in the game,
> you change their seat.

The more I think about it the more I like this idea, mostly because
it's an excuse to pare off a couple of method calls, which I always
like to do.

Am I right in thinking that most rulesets actually _will_ proscribe
their seat names? I mean, if they don't have names that are
well-defined at the the game level (as in Bridge or Chess or Sorry or
Monopoly), then the ruleset could just specify that the seats shall be
called "Player 1" through "Player N" or whatever. The slim minority of
rulesets where a seat namechange is actually useful can define that in
its own API, as you describe. (Though, depending on the game, I might
throw in arguments on the ref-to-client side that announce who made
the namechange.)

(And here's a Useful Feature that might or might not make the
pre-freeze cut: whether the UI file knows not just about seats, but
seat occupants. Perhaps it's important that it can refer to Alice and
Bob (or even Alice and the Bob/Carol conglomerate) and not merely
Player 1 and Player 2, if it's feeling up to the task.)

-------------------------------------------------------
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.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r