headers
Jason McIntosh | 1 Jun 18:02
Gravatar

Wiki updates

Made a lot of Wiki updates on Monday. I have more to make (mostly  
based on May's list discussion and other conversations I've had), but  
invite people to crawl around the new stuff so far and let me know  
how sane it seems. As always, you can check out the recent changes  
here: http://www.volity.org/wiki/index.cgi?RecentChanges

Summary of my main changes:

* Following Doug's note that "role" is already in use by the MUC  
protocol, I'm taking Zarf's sort-of suggestion to decouple "users"  
from "players". This makes perfect since to me: a "player" is a  
single _force_ in the game. When a ruleset says that it supports 2-4  
players, this is what it's referring to, after all. In Volity, it so  
happens that several users can fit into a player. When a player  
contains only one user (which will be the case most of the time) the  
terms can be used interchangably and it's all good. (Then again I  
could be totally wrong and it's even more confusing... we'll see.)

Andy came up with an interesting idea, BTW: advisor-bots. That is, a  
special bot that is designed not to act as a stand-in for a human  
opponent, but to provide help and advice to individual human players.  
When invited, instead of joining the table as its own player, it  
joins the player of the user who invited it. It doesn't need any  
special UI functions to work; it can provide help over Jabber  
messaging. And it's completely possible using the protocol we already  
have defined.

* See the "User Departure" and "Table Timeout" pages for some ideas  
on how we can handle the issue of active users vanishing from the  
table while a game is in progress, as well as defining how patient
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jason McIntosh | 2 Jun 06:01
Gravatar

Seats: actual protocol proposal

But first, more groveling about what word to use.

In my last post I went with calling the abstract user-container a  
"player", but now that I've had a couple of days to try using it in  
writing (across several wiki pages) I'm not sure I like it anymore.

"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. (This is a weak reason in retrospect because  
"seat" has real meanings beyond "chair", but "chair" is the strongest  
definition when near the whole "table" metaphor...)

"Player" may be even worse, though. I keep feeling that a player  
_ought_ to be a person; it has a long history of being so in any  
computer-game context. It's hard to write about a user who is  
actively playing a game (as opposed to just watching it) without  
calling that user a player. I fear that trying to overload the  
definition is just inviting confusion.

Another point in "seat"'s favor is that it actually meshes pretty  
well with the minimal protocol I just drafted to handle all the seat- 
swapping I think we'll need to do. I propose the following four RPC  
calls:

(User-to-ref)
* sit(seat_name) - This complements the existing sit() request, and  
means "I want to sit at that seat there" versus "I want to sit in my  
own seat; you tell me what it's called", which is what sit() would  
now mean. The ref can choose to say "That seat same makes no sense,
(Continue reading)

Permalink | Reply | 13 comments |
headers
Doug Orleans | 2 Jun 15:02
X-Face

Re: Seats: actual protocol proposal

Jason McIntosh writes:
 > Thoughts on either the name or the protocol?

Looks OK.  But as always when talking about JIDs in a MUC context, you
should specify whether they are Room Nicknames, Room JIDs, Bare JIDs,
or Full JIDs (or the union of some of them).  (Personally I'd prefer
they be Room Nicknames but I think that was already overruled.)

I think it would also be good to specify whether player_sat() is called
before or after sit() returns, or whether this order is unspecified.

--dougo <at> place.org

-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
Permalink | Reply | 1 comment |
headers
Jason McIntosh | 2 Jun 17:04
Gravatar

Re: Seats: actual protocol proposal

On Jun 2, 2005, at 9:02 AM, Doug Orleans wrote:

> Jason McIntosh writes:
>
>
>> Thoughts on either the name or the protocol?
>>
>>
>
> Looks OK.  But as always when talking about JIDs in a MUC context, you
> should specify whether they are Room Nicknames, Room JIDs, Bare JIDs,
> or Full JIDs (or the union of some of them).  (Personally I'd prefer
> they be Room Nicknames but I think that was already overruled.)
>

Yeah, I was thinking Full JIDs.

> I think it would also be good to specify whether player_sat() is  
> called
> before or after sit() returns, or whether this order is unspecified.
>

Hm. I suppose what should actually happen is that the return value of  
sit() is either true or false, depending on whether the ref let you  
sit or not. Actually, how about it returns the name of the seat on  
success? (It duplicates information available through the ref's  
followup player_sat() call, but it's a free convenience for the  
client programmer.)

--
(Continue reading)

Permalink | Reply | 0 comments |
headers
efran | 2 Jun 18:32

Re: Seats: actual protocol proposal

Quoting Jason McIntosh <jmac <at> jmac.org>:

> always got a goofy mental image of several players squishing into the
> same physical chair.

I would argue that this is a benefit of the term "seat", not a problem with it.
The image may be goofy, but it is a clear and accurate metaphor for the
functionality. It even helps you predict the implications: the mental image
suggests that the two players ought to know each other well, and that they may
get in each other's way even so.

> "Player" may be even worse, though.

I agree. I've tried to use "user" and "player" in the past, and it's usually
confusing.

> Thoughts on either the name or the protocol?

I like 'em.

 - Dan Efran
   efran <at> wunderland.com

-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
Permalink | Reply | 1 comment |
headers
Jason McIntosh | 3 Jun 21:48
Gravatar

Re: Seats: actual protocol proposal

On Jun 2, 2005, at 12:32 PM, efran <at> telerama.com wrote:

> Quoting Jason McIntosh <jmac <at> jmac.org>:
>
>
>> Thoughts on either the name or the protocol?
>>
>>
>
> I like 'em.
>

Righto, have finally updated the Seats page of the Wiki: http:// 
www.volity.org/wiki/index.cgi?Seats

(...as part of a continuing campaign of mad Wiki updates. It's  
becoming clear to me that even more important than getting a working  
system out the door (client and all) is having a stable, core  
protocol with a version number attached to it. We're still not there  
yet, but that's mainly because nobody has ever asked "are we there  
yet?". I will start asking this in the next week or so.)

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

-------------------------------------------------------
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 | 0 comments |
headers
Andy Turner | 4 Jun 14:37

SVG Widgets Part 2 (again)

Okay, since the discussion surrounding this email didn't actually
involve its content, I thought I resend it.

Everything thinks they're a good idea but hardly anyone's actually
done anything with them.  I guess this shouldn't really be surprising
given that there has been almost no practical use for them.  As far
as I can tell we'll be one of the first projects to actually have a
real world need for SVG widgets.

Sure, lots of web developers would love to be able to build SVG
widgets.  But practically they can't since they can't guarantee that
their visitors will have the ability to view them.  If they really
want something like that they'll have to use flash, which these days
comes with a very rich widget library.  From what I've heard,
many/most of the features added to the official flash development
tools have been centered around form and gui building.

So, anyway, I think that we really are going to have to build our own
widget sets.  There are three mostly independent questions that we
need to answer:

1. What do the tags representing widgets look like?

I'd say xforms but I'm not clear on how we would tie presentation to
them.  I guess that presentation related attributes could be in a
different name space then the tag itself, but I'm inclined to nix
that as being unreasonably ugly.  So barring that, I'm inclined to go
with an (x|html)forms-like set of tags.

2. What do the objects representing widgets look like?
(Continue reading)

Permalink | Reply | 3 comments |
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 | 8 comments |
headers
Jason McIntosh | 5 Jun 02:14
Gravatar

Are we there yet? Volity 1.0 feature freeze RFC

Two things I haven't done, and which I want to do ASAP:

1) Have a clear idea of everything that is part of version 1.0 of the  
Volity platform. This includes:
1a) A list of all the volity.* RPC requests recognized by the core  
Volity network entities (inlcuding servers, referees, clients, and  
the bookkeeper)
1b) A list of all the service discovery techniques that the core  
Volity etc. etc.
1c) Protocols and procedures that describe how the things described  
above work together to create a functional, extensible game platform.
1d) Enough stability to say that everything not included in the above  
lists or protocols is free to collect in a waiting area for future  
platform versions.

2) Write a spec that clearly and succinctly describes everything  
contained within (1).

I will take it upon myself to actually undertake (2). I've already  
done it once, more or less, a year and a half ago with that overview  
essay (which is surprisingly not _that_ out of date, now that I've  
looked at it again). This next attempt will be less an essay and more  
an actual spec-looking spec, though.

Once I have a spec draft, we can knock it around until we all agree  
it's golden. But I do want to declare a feature freeze on the  
protocol before I start writing it. I think the recent settling of  
the seats issue (a.k.a. me finally conceeding that everyone else was  
right) is a good signal that we're ready to think about this now.
(Continue reading)

Permalink | Reply | 0 comments |
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 | 7 comments |

Gmane