headers
Jason McIntosh | 27 Nov 05:33
Gravatar

Table configuration (& other stuff)

Hello, hello. Long time no see.

I've got a proposed method of table configuration described at 
http://www.volity.org/wiki/index.cgi?Table_Configuration and related 
pages. Despite my earlier thinking, it ends up having nothing to do 
with Jabber data forms at all. On the other hand, it doesn't really add 
anything else new to the Volity protocol, either; it just extends on 
the existing RPC-using model. Basically, changing one of a table's 
configuration variables simply involves calling a corresponding RPC 
request on its referee.

At the same time, I have rethought the process of starting games, 
_finally_, as this has been something bugging me for a long time. To 
this end, I introduce the concept of "readiness", described here: 
http://www.volity.org/wiki/index.cgi?Readiness It's meant to dovetail 
nicely with the aforementioned table-config ideas.

And a minor change: I've renamed the game.end_game RPC request to 
volity.end_game. (game.start_game is also gone, but more because it's 
been replaced by volity.ready, as described by the previous link). This 
keeps the "game" RPC namespace completely free of pollution, ready for 
rulesets to define whatever they'd like within. It was a lazy hack for 
me to put any core RPC requests into that namespace, and one I won't 
repeat.

No corresponding Frivolity code checked in yet, though it's implemented 
and tested on my development machine. Needs polish and docs.

On my horizon: the long-overdue roadmap leading to the Volity protocol, 
version 1.0. Or a sketch of it, anyway.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jason McIntosh | 28 Nov 07:26
Gravatar

Game finder

In the tradition of the UI finder. Once again, the idea is that client 
does most of the disco-digging work where the user can't see. For a 
given ruleset URI, it should be able to generate a list of open tables 
very quickly, and also allow things like a "quick game" button that 
scurries the player to the first open table serving that game that the 
client can find. (Yes, I should add these ideas to the Wiki, too...)

http://www.volity.org/wiki/index.cgi?Game_Finder

Volity's game finder allows players to quickly list and locate games. 
Like the UI finder, it is a bookkeeper-hosted information directory 
that client applications access through service discovery.

  Through the game finder, Volity users can use their client 
applications to:
	• 	 Learn what games (rulesets, really) are available on the Volity 
network
	• 	 Locate various network entities that support a given ruleset:
		◦ 	 Game servers
		◦ 	 Active games (at least ones whose tables aren't configured to 
hide from the game browser)
		◦ 	 Lobbies

Discovering rulesets

Easy: send a disco items query to the bookkeeper, node rulesets. You'll 
get back a list of node pointers, one for every ruleset the bookkeeper 
knows about. (And, as it happens, each node will be exactly named after 
its ruleset's URI.) Each node's name will be a brief, human-readable 
game name.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jason McIntosh | 28 Nov 04:44
Gravatar

Lobbies

[ In this and future list posts along the "Whee, look at what I just 
made up" lines, I will post both a link to the Wiki page (for there 
will always be a Wiki page, oh yes) and the initial text of the same 
page, with the intention that discussion go on here, and resolution 
occur there. But anyone should still feel free to edit the Wiki page in 
question whenever they see fit to do so. ]

My holiday rampage through long-overdue parts of the 1.0 protocol (huh? 
wuzzat?) continues. Lobbies are actually sort of a side-effect of the 
game browser, which I'm still drafting, but I think they're important.

http://www.volity.org/wiki/index.cgi?Lobby

A lobby is a multi-user chat dedicated to discussion of a specific 
ruleset, allowing players interested in that game to find one another 
and socialize outside of formal tables.

  There is nothing technologically special about a lobby; it's just an 
ordinary MUC. However, the bookkeeper knows about its location, and 
well-behaved client applications can easily guide players to a 
ruleset's lobby, with the bookkeeper's help.

  Discovering lobbies

Any client that can use service discovery (which is to say, any 
self-respecting client) can easily discover a lobby's JabberID. It need 
only send a disco items request to the bookkeeper, with a node 
comprising the ruleset's URI followed by the string |lobby. (That's a 
"pipe" character, then the word "lobby".)
(Continue reading)

Permalink | Reply | 2 comments |
headers
Doug Orleans | 28 Nov 20:59
X-Face

Re: Lobbies

Jason McIntosh writes:
 > Any client that can use service discovery (which is to say, any 
 > self-respecting client) can easily discover a lobby's JabberID. It need 
 > only send a disco items request to the bookkeeper, with a node 
 > comprising the ruleset's URI followed by the string |lobby. (That's a 
 > "pipe" character, then the word "lobby".)

I still don't like this pipe convention...  Why not have the disco
info for the ruleset URI include a "lobby" field?  Same goes for
"servers", although we'd have to have a convention for putting
multiple JIDs into a single string (whitespace-separated would be my
preference, but perhaps comma-separated is more conventional).

I've also been thinking about RDF, which is a mechanism (and concrete
XML syntax) for representing arbitrary directed graphs whose nodes and
edges are labeled with URIs.  This might be a more natural fit for
this Resource Description task, but it's also Yet Another Technology.

--dougo <at> place.org

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
Permalink | Reply | 1 comment |
headers
Jason McIntosh | 28 Nov 23:06
Gravatar

Re: Lobbies

On Nov 28, 2004, at 2:59 PM, Doug Orleans wrote:

> Jason McIntosh writes:
>> Any client that can use service discovery (which is to say, any
>> self-respecting client) can easily discover a lobby's JabberID. It 
>> need
>> only send a disco items request to the bookkeeper, with a node
>> comprising the ruleset's URI followed by the string |lobby. (That's a
>> "pipe" character, then the word "lobby".)
>
> I still don't like this pipe convention...  Why not have the disco
> info for the ruleset URI include a "lobby" field?  Same goes for
> "servers", although we'd have to have a convention for putting
> multiple JIDs into a single string (whitespace-separated would be my
> preference, but perhaps comma-separated is more conventional).

You can actually put a list of discrete values into a single Jabber 
data form field. 
http://www.jabber.org/jeps/jep-0004.html#protocol-results

However, if we moved all server information into the form, my concern 
is that every info query to a ruleset node would blast you with 
_everything_ the bookkeeper knows about that ruleset -- the servers, 
the ui files, and categories of information we haven't thought of yet. 
I don't know if that is optimal behavior.

And I don't see how using a pipe as a field separator is any worse than 
using a comma, anyway. :)

> I've also been thinking about RDF, which is a mechanism (and concrete
(Continue reading)

Permalink | Reply | 0 comments |

Gmane