Developement-level discussion of Volity, a network protocol and programming framework for Internet game-playing.

matchmaking

Tonight's totally random thought: Would some games want to use some rating 
system other than ELO?

This spins off the "Volity-based MMORPG" idea. You have a score-like 
attribute in a MMORPG, your experience, but it doesn't behave like an ELO 
score. And why does Volity care about XP, you ask? Because players will 
want to use a matchmaking system -- they want to adventure with people of 
a similar experience level.

Why should the MMO developer have to write his own? It would be cool if 
his game could tie into (what will be) our sophisticated and easy-to-use 
rank-tracking and matchmaking system.

That is all.

--Z

--

-- 
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
If the Bush administration hasn't subjected you to searches without a warrant,
it's for one reason: they don't feel like it. Not because you're innocent.

-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

headers

Jason McIntosh | 10 Mar 08:49

Re: matchmaking

On 3/10/06, Andrew Plotkin <erkyrath <at> eblong.com> wrote:
>
> Why should the MMO developer have to write his own? It would be cool if
> his game could tie into (what will be) our sophisticated and easy-to-use
> rank-tracking and matchmaking system.

Howsabout if game records contain an optional "ratings" field that's a
simple struct of new ratings keyed to seat IDs? The ratings would be
strings, and stored by the bookkeeper as such. (This presupposes that
the ref would be able to ask the bkp for any seat's rating at any
time.) (Hm, there may be some race-condition dangers to look out for,
though...)

The bookkeeper would interpret the lack of this field as a go-ahead to
use Volity's default ELO system.

However, a price would come with this. The bkp (and systemwide
analysis tools) can meaningfully interpret ELO data for any game,
giving interesting stats such as percentiles and standard deviations
and such. But ratings data that comes from outside is not just tainted
but potentially machine-unreadable, and so in those cases the bkp
would only be able to offer the ratings as-is without further comment.

I suppose that one could set up a "ratings factory" and processing
plant somewhere that the bkp would proxy this work through... yikes.

--
Jason McIntosh
zendonut <at> gmail.com
Jabber: jmac <at> volity.net

(Continue reading)

headers

Andrew Plotkin | 10 Mar 22:19

Re: matchmaking

On Fri, 10 Mar 2006, Jason McIntosh wrote:

> On 3/10/06, Andrew Plotkin <erkyrath <at> eblong.com> wrote:
>>
>> Why should the MMO developer have to write his own? It would be cool if
>> his game could tie into (what will be) our sophisticated and easy-to-use
>> rank-tracking and matchmaking system.
>
> Howsabout if game records contain an optional "ratings" field that's a
> simple struct of new ratings keyed to seat IDs? The ratings would be
> strings, and stored by the bookkeeper as such. (This presupposes that
> the ref would be able to ask the bkp for any seat's rating at any
> time.) (Hm, there may be some race-condition dangers to look out for,
> though...)
>
> The bookkeeper would interpret the lack of this field as a go-ahead to
> use Volity's default ELO system.

Really, this is more of a web service than a standard Volity service. I 
think that the game designer should set it up as an option in his 
(volity.net) game management page. It doesn't have to be specified purely 
through RPCs.

> However, a price would come with this. The bkp (and systemwide
> analysis tools) can meaningfully interpret ELO data for any game

Sure. I wasn't thinking of a replacement for ELO scores, but rather an 
additional set of statistics. (Although the value for the designer is 
getting percentiles and statistics for free, so he'd want to be able to do 
that.)

(Continue reading)

headers

Andrew Plotkin | 17 Mar 02:53

Bookkeeper query RPCs

Currently we get a UI list from the bookkeeper by doing a disco query:

  * disco#items: RULESET+"|uis" => [ UI1, UI2, ... ]

(where each UI item has node=URL, name=UIName.)

We then have to do a new query for each item, which returns a form full of 
fields:

  * disco#info: URL => { ruleset, reputation, languages, description, 
contact-jid, contact-email, client-type }

Other kinds of queries are crammed into the disco nodes in other ways.

I don't propose getting rid of those disco queries, but I would like to 
add a clearer and more powerful set of RPC queries:

  * volity.get_ruleset_info(ruleset) => struct

This returns everything about the ruleset with the given URI. (Same struct 
fields as the existing disco query.)

  * volity.get_uis(ruleset) => [ URL1, URL2, ... ]

Returns a list of URL strings, of UIs which require this ruleset. (Ruleset 
may include a version number fragment, in which case the UIs must match 
that version number.)

  * volity.get_uis(ruleset, constraints) => [ URL1, URL2, ... ]

(Continue reading)

headers

Andrew Plotkin | 10 Mar 07:20

Invitations, once again

It is becoming clear in playtesting that the invitation system bites 
people hard. Not because of the UI -- the UI needs several extra features, 
but they're filed and I'll get to them in due course. It bites because of 
the "you must add that person to your roster first".

That restriction exists because of core XMPP rules: an IQ packet must be 
addressed to a full JID (name <at> host/resource). And you can't generally find 
out someone's resource strings (connection IDs) unless he's on your 
roster; and *that* can't happen without his permission.

An invitation is (currently) a Jabber-RPC packet, which is an IQ packet, 
and therefore we have to go through this roster-adding dance. I have tried 
to automate that dance as much as possible: Javolin auto-accepts roster 
requests (in the default configuration). However, it's still a flaky 
procedure. I don't know why. But it is. Every time new people come on 
board, we hear "Ok, um, did you get my roster request? You didn't? Let me 
try it again..."

Back in the summer when I was coding this, I asked about doing invites via 
message packet. The Volity wisdom at the time was that we didn't want to 
add a new Jabber protocol; we wanted to rely on existing JEPs.

I'm not certain that we need to take that step, but I'd like to reopen the 
subject.

For a start, I'd like to come up with a list of common cases in which you 
might want to invite some user into your game. For the technical reasons I 
mentioned, we've been leaning heavily on:

* You have a friend on your roster, you see he's logged on, so you invite

(Continue reading)

headers

Andrew Plotkin | 19 Mar 01:06

Re: Invitations, once again

On Fri, 10 Mar 2006, Andrew Plotkin wrote:

> For a start, I'd like to come up with a list of common cases in which you 
> might want to invite some user into your game.

No new discussion on this, so I'm going to start making proclamations. 
(Both UI and implementation.)

First: the client will have lots of ways to invite someone. All of them 
boil down to "here's a JID, invite it." In some cases, it will be a full 
JID; in others, a bare JID. The user won't see the difference, but full 
JID makes for better (more accurate) invitation delivery.

If the client doesn't know whether a particular resource string (on a full 
JID) refers to a Volity client, it shouldn't invite it. Invite the bare 
JID instead.

Javolin will always pop up an "Invite person..." dialog when you go to 
invite a person. You can (optionally) type in a message. You must hit OK 
on the dialog box. I'm sticking with this model because an invitation may 
always devolve into a Jabber message. (Transparently to the user, like I 
said.)

When the referee gets an invite command (remember, all invites are 
actually sent out by the referee on behalf of a user) it looks at the JID.

- For a full JID, it does an RPC invitation of the type we already have 
implemented. Stanza errors are reported back to the user. (I.e., "not 
logged on" or "not running a Volity client".)

(Continue reading)

headers

Andrew Plotkin | 21 Mar 03:21

Re: Invitations, once again

On Sat, 18 Mar 2006, Andrew Plotkin wrote:

> When the referee gets an invite command (remember, all invites are actually 
> sent out by the referee on behalf of a user) it looks at the JID.
>
> - For a full JID, it does an RPC invitation of the type we already have 
> implemented. Stanza errors are reported back to the user. (I.e., "not logged 
> on" or "not running a Volity client".)
>
> - For a bare JID, it sends a <message> invitation. There is no error 
> reporting on message packets, so from the user's point of view it's just 
> fired into the blue, but on the up side messages get delayed delivery and 
> other nice features.

I forgot to add: if Javolin tries to invite a full JID and gets an error 
back, it will try again with the bare JID. I think this is a sensible 
fallback strategy (to deal with cases where we have a bad resource string, 
for any reason).

There's a side effect, though: the player will almost never see errors 
about delivering invitations. (Because the error case will cause a retry 
with a bare JID, which will generate a <message> invitation, which gets no 
error reporting.)

Just noting that.

--Z

--

-- 
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."

(Continue reading)

headers

Andrew Plotkin | 20 Mar 20:43

Re: Invitations, once again

On Sat, 18 Mar 2006, Andrew Plotkin wrote:

> I have a standard data form there because -- well, because it's standard. And 
> it lets us add new fields without changing the schema. Experiment indicates 
> that clients (iChat, Adium, Psi) ignore an attached "result" form; they just 
> display the body of the message.
>
> Down side: a Volity client has to parse every standard form attached to a 
> message, to see if its FORM_TYPE is a Volity command. Alternative: put the 
> standard form inside a custom protocol tag. Anyone have any opinion on this?

I asked on the Jabber devel list, and Peter Saint-Andre suggested putting 
the form inside a custom protocol tag. (While keeping the FORM_TYPE.) This 
is an opinion I will pay attention to. :)

--Z

--

-- 
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
9/11 did change everything. Since 9/12, the biggest threat to American
society has been the American president. I'd call that a change.

-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

headers

Andrew Plotkin | 10 Mar 07:23

Re: Invitations, once again

PS: I realize that I started that message by saying "This isn't about 
UI", and then ended up asking about interface design. Hey, it's late. :)

Like I said, we should think about cases, then UI, then mechanism.

--Z

--

-- 
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
If the Bush administration hasn't subjected you to searches without a warrant,
it's for one reason: they don't feel like it. Not because you're innocent.

-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642