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 
    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.

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.

(I could see an argument for having vote/preference-style
change_seat() messages be distinct from command-style change_seat()
messages, but then you have to know in advance which is which -- I
rather prefer the flexibility of treating everything as a "vote" but
where, by default, it only takes a single "vote" to make stuff happen
and if a given ref/game-setup wants to implement more complicated
rules/seat-permissions, so be it)

People who don't care where they're sitting (likely the most usual
case) don't have to do anything in this version of the world.

Having the players_sitting() calls come first also means that a generic
client can immediately learn the full range of seat_ids available
in the current game configuration.

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.

Now, if you want to have seat NAMEs as a convenience feature to use in
the UI display, in player conversation, whatever, that's well and good
but that's a separate API:

  player_to_ref:
     set_seat_name(seat_id, seat_name)
  ref_to_player:
     seat_name_is(seat_id, seat_name)

Seat names still have to be managed by the ref, but now that can all
sit in a separate module that the game designer doesn't even have to
know/care about.

Or, if the game designer really DOES want to specify "traditions"
about which names are appropriate (or not) for which seat_ids, then he
*can* mess around in the seat naming module as he chooses, or
alternatively leave it to the UI authors to enforce these traditions
at the client end (which I'd say is better way to handle this).

But the logic of the game itself (and thus the game protocol)
should work solely off of the seat IDs, just as messages to individual 
players are addressed to their jids regardless of whatever user-friendly
handles you allow players to adopt for themselves.

(*) the full set of seat ids in use in a given game WILL of course
depend on the number of players playing; it may also depend on certain
rule options.  So if you change a rule option that affects the set of
seat ids available, then you can expect a bunch of new
players_sitting() msgs to show up in your inbox imediately thereafter.
The ref will just arbitraily reassign whoever's sitting in a now-invalid
seat_id.

Clearly you should settle what game you're actually playing FIRST
before you expend energy tweaking the seat assignments...

-------------------------------------------------------
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=20