headers
Jason McIntosh | 1 Mar 23:16
Picon

Matchmaking, and an extra-snoopy bookkeeper

While I'm working on the volity.net website I'm starting to think
about matchmaking, a feature I've wanted Volity to have since I first
saw it work on Internet-enabled console games. In a nutshell, this is
where you bypass the whole pick-a-server, pick-a-room business and
instead hit a big glowy "I don't care, I just want to play" button.
Then you let the network do the work of pairing you with some other
players.

Prerequisite to my ideas: tables now feature more restrictions about
who gets to sit at them, in the form of three disco-able attributes:
* minimum rating
* maximum rating
* minimum reputation

The referee will refuse a seat to anyone whose rating at the table's
ruleset does not fall within the defined rating range, or whose
reputation is below the stated minimum. Players so unqualified can
still observe.

Any of these three attributes can be independently set to undefined,
meaning that there is no such restriction. In this way, you could
configure a table to allow players with ratings below yours, or not
more than 400 points above yours.

Now on to how matchmaking could work:

I propose a new RPC that clients can send to the bookkeeper when they
want a match to be made for them. The call has these arguments:
* The ruleset URI you want to play
* A list of other JIDs you'd like to share your seat with
(Continue reading)

Permalink | Reply | 3 comments |
headers
Andrew Plotkin | 2 Mar 01:38

Re: Matchmaking, and an extra-snoopy bookkeeper

On Wed, 1 Mar 2006, Jason McIntosh wrote:

> Prerequisite to my ideas: tables now feature more restrictions about
> who gets to sit at them, in the form of three disco-able attributes:
> * minimum rating
> * maximum rating
> * minimum reputation
>
> The referee will refuse a seat to anyone whose rating at the table's
> ruleset does not fall within the defined rating range, or whose
> reputation is below the stated minimum. Players so unqualified can
> still observe.

I take it that player-created tables would start these values as 
"undefined"?

> I propose a new RPC that clients can send to the bookkeeper when they
> want a match to be made for them. The call has these arguments:
> * The ruleset URI you want to play
> * A list of other JIDs you'd like to share your seat with
> * An integer representing how close to your rating other players
> should be. For example, "100" here will limit the match to players
> with ratings no worse than 100 below and no better than 100 above the
> requester's rating. "0" is special, interpreted as "I don't care, I'll
> play anyone". Default is 400, which is the "class" size our ELO
> formula uses.
> * The minimum reputation of people to pair you with (default 0).

Okay.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Jason McIntosh | 2 Mar 02:10
Picon

Re: Matchmaking, and an extra-snoopy bookkeeper

On 3/1/06, Andrew Plotkin <erkyrath <at> eblong.com> wrote:
>
> I take it that player-created tables would start these values as
> "undefined"?

Yep. Unless otherwise directed. So with present-day Javolin, yes, all undefined.

> > What happens after this, I'm not sure. One possibility: the bookkeeper
> > keeps an internal table of everyone asking for matchmaking, and when
> > it sees several players whose requests line up, it creates a table for
> > them and sends them RPCs that suggests they go join. (This would
> > require as-yet undefined RPCs.)
>
> The existing invitation mechanism should work for this.

Who is inviting whom, in this case?

> > Another take: As above, except that the bookkeeper also has an eye on
> > the whole Volity network, including a list of tables that are open and
> > which happen to have rating & reputation attributes that confirm to
> > the matchmaking player's request. If such a table exists, then the bkp
> > will toss the player into it. If it does not exist, then the bkp will
> > create it and _then_ toss the player in. In either case, it then
> > forgets about the player.
>
> I am cautiously in favor of this. I wouldn't make it a requirement -- that
> is, tables can still be created with the "show_table false" attribute,
> which means that the bkp doesn't butt in on it.

That's right. Hiding a table from the finder should also make the
(Continue reading)

Permalink | Reply | 1 comment |
headers
Andrew Plotkin | 2 Mar 02:15

Re: Matchmaking, and an extra-snoopy bookkeeper

On Wed, 1 Mar 2006, Jason McIntosh wrote:

>>> What happens after this, I'm not sure. One possibility: the bookkeeper
>>> keeps an internal table of everyone asking for matchmaking, and when
>>> it sees several players whose requests line up, it creates a table for
>>> them and sends them RPCs that suggests they go join. (This would
>>> require as-yet undefined RPCs.)
>>
>> The existing invitation mechanism should work for this.
>
> Who is inviting whom, in this case?

The bookkeeper is inviting everybody? It could have a separate 
"matchmaker" identity for this purpose.

--Z

--

-- 
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
"Bush has kept America safe from terrorism since 9/11." Too bad his
job was to keep America safe *on* 9/11.

-------------------------------------------------------
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
Permalink | Reply | 0 comments |
headers
Jason McIntosh | 4 Mar 19:27
Picon

Putting seat IDs in game records

(As website work continues to have me look into corners of the system
I haven't thought about in a long time...)

It has occurred to me that any kind of game history display is hobbled
by the fact that current game records do not contain seat IDs. They do
show how many seats there were, what players sat in them, and the
order in which they finished the game -- but you don't know who was
red and who was green.

Over the long view of the players' game performance, this makes no
difference. However, if you want to play back any game history stored
on the record -- or if you want to give a reputation score to
whats-his-name, whoever that was in the Blue seat -- then you're
stuck.

My proposal:
* Add a "seats" field to game record structs. Its value is a struct
whose keys are seat IDs and whose values are arrays of player JIDs.

* Modify the "winners" field so that, instead of the complex
list-of-lists-of-lists that's there now, you have a simpler ordering
of seat IDs. You'll still need to use sub-lists to represent places
(i.e. one list for first place, another for second, etc.) but I think
this would make the records far easier to read (and program around).

--
Jason McIntosh
zendonut <at> gmail.com
Jabber: jmac <at> volity.net
AIM: zendonut
(Continue reading)

Permalink | Reply | 11 comments |
headers
Andrew Plotkin | 4 Mar 21:46

Re: Putting seat IDs in game records

On Sat, 4 Mar 2006, Jason McIntosh wrote:

> My proposal:
> * Add a "seats" field to game record structs. Its value is a struct
> whose keys are seat IDs and whose values are arrays of player JIDs.
>
> * Modify the "winners" field so that, instead of the complex
> list-of-lists-of-lists that's there now, you have a simpler ordering
> of seat IDs. You'll still need to use sub-lists to represent places
> (i.e. one list for first place, another for second, etc.) but I think
> this would make the records far easier to read (and program around).

I like this.

When I wrote the Python ref code, I set it up so that the game designer 
*gives* a list-of-lists-of-seats (as you describe) -- I'm translating that 
to the more complex form under the hood.

--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!
(Continue reading)

Permalink | Reply | 1 comment |
headers
Man_In_Red | 4 Mar 22:57
Picon

Lua Programmers wanted to create New Age


Team Name 
ManInRed Studio 

Project Name 
Newage 

Genre 
Role Play Game

Target Aim 
Freeware 

Compensation  
This is volunteer based, so there is no money to be gain yet.  But this also
means you can set your own hours and stay on for as long as you want.

Talent Needed  
Lua Programmer 
Spriters 
Concept Artists 

Website 
http://maninred.250free.com/newage.html 

Contacts  
Producer:
E-mail: rob.maninred <at> gmail.com
AIM: ManInRed1212
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jason McIntosh | 5 Mar 23:18
Picon

Re: Lua Programmers wanted to create New Age

On 3/4/06, Man_In_Red <rob.maninred <at> gmail.com> wrote:
>
> Blah blah blah I'm some kind of spammer come work for me for free
> because I like corn dogs.
>
> Sent from the Volity - Dev forum at Nabble.com.

Ah, so that's what that weird address in the subscriber list is for.
Thanks. *punt*

--
Jason McIntosh
zendonut <at> gmail.com
Jabber: jmac <at> volity.net
AIM: zendonut
http://jmac.org

-------------------------------------------------------
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&kid0944&bid$1720&dat1642
Permalink | Reply | 0 comments |
headers
Jason McIntosh | 6 Mar 01:37
Picon

Re: Putting seat IDs in game records

On 3/4/06, Andrew Plotkin <erkyrath <at> eblong.com> wrote:
> On Sat, 4 Mar 2006, Jason McIntosh wrote:
>
> > My proposal:
> > * Add a "seats" field to game record structs. Its value is a struct
> > whose keys are seat IDs and whose values are arrays of player JIDs.
> >
> > * Modify the "winners" field so that, instead of the complex
> > list-of-lists-of-lists that's there now, you have a simpler ordering
> > of seat IDs. You'll still need to use sub-lists to represent places
> > (i.e. one list for first place, another for second, etc.) but I think
> > this would make the records far easier to read (and program around).
>
> I like this.

I've updated the Wiki and am similarly abusing the bookkeeper code now.

--
Jason McIntosh
zendonut <at> gmail.com
Jabber: jmac <at> volity.net
AIM: zendonut
http://jmac.org

-------------------------------------------------------
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&kid0944&bid$1720&dat1642
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andrew Plotkin | 10 Mar 06:31

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

Gmane