headers
Jason McIntosh | 7 Jan 10:45
Picon

Javolin betatesting and other stuff

Howdy, and Happy New Year from the bowels of the Volity project in
beautiful Somerville, Massachusetts. I have a couple of announcements
for readers of this list.

* Javolin -- as well as a handful of games -- has entered a quiet beta
period. By "quiet" I mean that I am trying to limit this testing phase
to people I already know to some degree. I've decided to extend the
testing invitation to everyone on the volity-devel list, under the
logic that we're a fairly small bunch, and if you're so interested in
Volity to have subscribed to this list, then I'd like to get your
feedback on what we've accomplished so far.

You can get yourself set up by visiting http://www.volity.org/betatesting.html .

I only ask that you don't share this information far and wide. The
system is still very rough -- the entire supporting Web application
doesn't exist yet, for one thing. But we do have a functional client,
and now's the time to start beating it into shape.

* Most of you already know this, but I'm pretty sure I've never made a
post about it here, so I'll do so now: Andrew Turner, Andrew Plotkin
and I started a Volity-centric company in August. We began to actually
work together in December, and one of the reasons we don't post to
this list nearly as often as we used to is that we're now able to
simply shout across the room at each other.

The company's name is Volity Ventures LLC, though we've an (as yet
unofficial) DBA of Volity Games that we will probably end up using
more. We are building a Volity-driven platform that we're calling
Volity.Net. It's basically the open game platform that we've been
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andrew Plotkin | 7 Jan 21:28

UI versioning (and other metadata)

We've had a "ruleset version number" (attached to the parlor) for a long 
time now, and I recently added an independent "ECMAScript API version 
number" (attached to Javolin).

What we don't have is a way for the UI to actually check itself against 
those versions, to make sure it fits.

The two obvious options are "do it in UI script code" and "do it with 
metadata in the UI file". I prefer the latter. (I'd like the bookkeeper to 
extract version numbers -- and other metadata -- from UIs, in order to 
fill in its UI database. It would be a pain in the ass for the bookkeeper 
to execute script code in order to find that stuff out.)

SVG has a metadata element: see <http://www.w3.org/TR/SVG/metadata.html>.
You can use any format you want, but their example uses RDF and Dublin 
Core. Unless someone has an objection, I proposing sticking with that.

(I don't mean that we have to process everything that DC defines. However, 
when we want some metadata, DC should cover it. For example, a UI file 
could declare its supported language(s) via metadata. Title, author, and 
creation date are also nice -- although SVG has a <title> tag, so we may 
need to support both options there.)

Now, I don't actually know a whole lot about DC. It looks like the 
"conformsTo" term is correct for this relation. (See 
<http://dublincore.org/documents/dcmi-terms/>.) The question is, is it 
legal to say

   dc:conformsTo="1.5"
(Continue reading)

Permalink | Reply | 3 comments |
headers
Andrew Plotkin | 8 Jan 07:35

Bot behavior

While working out our first full-weight bot (for Barsoomite Go), I ran 
into a few issues.

First, I don't like the way state recovery works. If you join a game in 
progress, you get a state burst -- but nothing in that state burst 
corresponds to the volity.begin_game call you would have gotten if you'd 
been in the game all along. And the begin_game call is useful. I want to 
put code there.

(Really, this is true of both bots and UIs. All along, writing UIs, I've 
been working around the fact that there is no equivalent of begin_game 
when you join in mid-game. It's been work-around-able, but not fun.)

So I'm proposing a new ref-to-client RPC: volity.game_has_begun. The 
referee sends this in the *middle* of state recovery (between 
receive_state and state_sent). More specifically, it sends it after all 
the seating and game config info, but before all the game-move RPCs that 
describe the game so far. It only does this if the game is in progress or 
suspended. (In setup phase, there *are* no game-move RPCs, of course.)

(I can give specific examples of why I want this. Feel free to ask.)

Second issue: if you put two bots into a two-player game, they'll fight to 
the death without human intervention. That's cool.

However, bots are defined to be "always ready" -- they pound the Ready 
button whenever they're seated. So when that two-bot game finishes, the 
bots will immediately start a new game! There's no good way to break them 
out of the cycle. (You can spam the referee with "stand up" requests, 
hoping that one of them arrives in the brief interval between games, but
(Continue reading)

Permalink | Reply | 2 comments |
headers
Jason McIntosh | 8 Jan 21:30
Picon

Re: Bot behavior

On 1/8/06, Andrew Plotkin <erkyrath <at> eblong.com> wrote:
>
> So I'm proposing a new ref-to-client RPC: volity.game_has_begun. The
> referee sends this in the *middle* of state recovery (between
> receive_state and state_sent). More specifically, it sends it after all
> the seating and game config info, but before all the game-move RPCs that
> describe the game so far. It only does this if the game is in progress or
> suspended. (In setup phase, there *are* no game-move RPCs, of course.)

This sounds OK to me. It also sounds backwards-compatible with current
UIs, which is good.

> My off-the-cuff solution: after a bot finishes a game, it stands up. If
> you want the bot to start another game, you have to sit it down again.

This is fine.

> I have no theory about how to proceed here. (Mostly because it's 1:30
> AM...) I've already said that all-bot games are both cool and
> unnecessary... maybe we should punt this whole issue and declare that
> Volity is for humans?

There are times when an all-robot fight might be more than cute,
perhaps in cases where a bot is invited in to take the place of a
missing human, so it's really a "cyborg" battle with mixed human/bot
seats. But even here we're assuming that all the other seats are
bot-driven before the last human cedes control, which seems pretty
edge-casey.

I can also see controlled bot-only battles being used to help a game
(Continue reading)

Permalink | Reply | 1 comment |
headers
Andrew Plotkin | 8 Jan 22:03

Re: Bot behavior

On Sun, 8 Jan 2006, Jason McIntosh wrote:

> On 1/8/06, Andrew Plotkin <erkyrath <at> eblong.com> wrote:
>>
>> So I'm proposing a new ref-to-client RPC: volity.game_has_begun. The
>> referee sends this in the *middle* of state recovery (between
>> receive_state and state_sent). More specifically, it sends it after all
>> the seating and game config info, but before all the game-move RPCs that
>> describe the game so far. It only does this if the game is in progress or
>> suspended. (In setup phase, there *are* no game-move RPCs, of course.)
>
> This sounds OK to me. It also sounds backwards-compatible with current
> UIs, which is good.

Sure. (I will need to add it to Javolin and get it distributed to 
everybody before I can *update* UIs. But the current UIs work, so that's 
okay.)

>> My off-the-cuff solution: after a bot finishes a game, it stands up. If
>> you want the bot to start another game, you have to sit it down again.
>
> This is fine.

Nope, I changed my mind. :) See below.

>> I have no theory about how to proceed here. (Mostly because it's 1:30
>> AM...) I've already said that all-bot games are both cool and
>> unnecessary... maybe we should punt this whole issue and declare that
>> Volity is for humans?
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jason McIntosh | 21 Jan 07:38
Picon

New Frivolity and Javolin stuff

I just released Frivolity 0.5.2, the latest version of Volity's
server-side implementation in Perl. It contains numerous bugfixes and
tweaks that support minor changes which the Volity protocol has seen
since October 2005. It also abandons the Module::Build build style for
a more standard MakeMaker one. This should make it much easier to
install. You can download it from SourceForge:
http://prdownloads.sourceforge.net/volity/Frivolity-0.5.2.tar.gz?download
.

Meanwhile, so much work is going into Javolin that we've set up a
nightly build system for it, which should prove especially interesting
to those helping in the betatesting effort. (In fact, if you're
subscribed to the betatest list then you probably already knew this,
but whatever.) Please see the relevant links on Javolin's homepage:
http://www.volity.org/projects/javolin/ .

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

-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642
Permalink | Reply | 0 comments |
headers
Jason McIntosh | 26 Jan 00:01
Picon

Game history UI

I'm starting to think about how game histories will work. Zarf last
month made a wiki page at
http://www.volity.org/wiki/index.cgi?Game_History_UI that lay out the
results of a conversation we had at the time.

An unanswered question is where the history-display UI file would
live, and how it would work. So here's a quick proposal that attempts
to address this:

History would simply be another function of a game's UI file. That is,
a client that wished to download a UI file in order to look at a
game's history would simply ask the bookkeeper for a UI file for that
game's ruleset -- exactly as it does now, and with the same results.

We'd extend the Javascript API to include another subroutine -- call
it display_history(history_struct) for now. During gameplay, this sub
is unused. When the client is loading a UI for the purpose of
history-viewing, however, it would call the routine as soon as the
document loaded, and the argument would be the same history
datastructure that was in that game's record (see [[Game Record]] on
the wiki).

What happens after that is up to the UI, since there need be no
further communication with any Jabber entity; it's just going over the
past as recorded in that datastructure.

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

Permalink | Reply | 3 comments |
headers
Andrew Plotkin | 26 Jan 02:25

Re: Game history UI

On Wed, 25 Jan 2006, Jason McIntosh wrote:

> I'm starting to think about how game histories will work. Zarf last
> month made a wiki page at
> http://www.volity.org/wiki/index.cgi?Game_History_UI that lay out the
> results of a conversation we had at the time.
>
> An unanswered question is where the history-display UI file would
> live, and how it would work. So here's a quick proposal that attempts
> to address this:
>
> History would simply be another function of a game's UI file. That is,
> a client that wished to download a UI file in order to look at a
> game's history would simply ask the bookkeeper for a UI file for that
> game's ruleset -- exactly as it does now, and with the same results.

Good so far.

We would need a way to refer to a particular game record. (That is, if you 
are browsing the game records, and you want to throw one at your client, 
there has to be a way to name it.) I suppose this would be the game URI 
plus a record number of some sort.

> We'd extend the Javascript API to include another subroutine -- call
> it display_history(history_struct) for now.

I think that's backwards. The javascript API is stuff that the UI calls, 
not that the client calls.

What we want is an RPC "volity.game_history(data)". Actually, two RPCs.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Jason McIntosh | 26 Jan 05:00
Picon

Re: Game history UI

On 1/25/06, Andrew Plotkin <erkyrath <at> eblong.com> wrote:
>
> We would need a way to refer to a particular game record. (That is, if you
> are browsing the game records, and you want to throw one at your client,
> there has to be a way to name it.) I suppose this would be the game URI
> plus a record number of some sort.

Why not skip the URI and just use a record ID string?

> What we want is an RPC "volity.game_history(data)". Actually, two RPCs.

Oh, yes, of course, this is what I think I meant to say...

Except that let's actually make this a bit more general (and useful)
by replacing it with these calls, which deal at the game record level
(which will include history, plus other useful metadata):

Client->Bookkeeper: volity.game_record($record_id)
Bookkeeper->Client: volity.game_record($record_id, $record)

The second argument in the latter call is a game record struct,
exactly as described in [[Game Record]]. I'm keeping the ID separate
just to avoid changing that specification by adding an ID field, but
maybe it should have one anyway...?

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

Permalink | Reply | 1 comment |
headers
Andrew Plotkin | 26 Jan 05:34

Re: Game history UI

On Wed, 25 Jan 2006, Jason McIntosh wrote:

> On 1/25/06, Andrew Plotkin <erkyrath <at> eblong.com> wrote:
>>
>> We would need a way to refer to a particular game record. (That is, if you
>> are browsing the game records, and you want to throw one at your client,
>> there has to be a way to name it.) I suppose this would be the game URI
>> plus a record number of some sort.
>
> Why not skip the URI and just use a record ID string?

Works either way. If you have only a record ID string, then it has to be 
globally unique (at that bookkeeper), instead of being unique to that 
game. You're the bookkeeper implementor; you tell me which makes more 
sense. :)

>> What we want is an RPC "volity.game_history(data)". Actually, two RPCs.
>
> Oh, yes, of course, this is what I think I meant to say...
>
> Except that let's actually make this a bit more general (and useful)
> by replacing it with these calls, which deal at the game record level
> (which will include history, plus other useful metadata):
>
> Client->Bookkeeper: volity.game_record($record_id)
> Bookkeeper->Client: volity.game_record($record_id, $record)

I retain a preference for naming these RPCs differently. get_record and 
game_record? You're entirely right that they should deal with game 
records, rather than just the "history" data field.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane