headers
Andrew Plotkin | 1 Feb 06:18

Re: Game record verification

On Fri, 27 Jan 2006, Andrew Plotkin wrote:

> Possible variant: Maybe we don't want to keep these interim records in the 
> bookkeeper. (There could be a lot of them, since a game could be in progress 
> for a long time... maybe indefinitely.) It's perfectly feasible for the 
> *referee* to hold onto them, as long as the bookkeeper digitally signs them 
> first. That is, the bookkeeper is still doing all the dialbacks at game-start 
> time, but it immediately sends the (signed) results back to the referee.

I now think this variant is broken. If the bookkeeper isn't keeping track, 
an evil referee could ping out a dozen players sets to the bookkeeper. The 
client would acknowledge all of them. The ref uses one for the actual game 
record, and keeps the other eleven (properly signed) for fraudulent use 
later.

So I think if we do this at all, the bookkeeper is going to have to hold a 
record for the duration of the game. This isn't a significant load for 
normal use (every game *ends* with a permanent record anyhow). But the 
bookkeeper would have to do occasional polling of referees to see if old 
interim records can be dropped.

There are still holes in the scheme. (Say, a referee submits a game record 
very late -- like, a week late -- and with bad winner info, in hopes that 
all the players will have gone on vacation and not be checking their game 
histories. Okay, that's not a very interesting hole...)

--Z

--

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

Permalink | Reply | 0 comments |
headers
Andrew Plotkin | 1 Feb 07:53

More on robots

Never got around to finishing this...

One of our excitingly focussed and forward-looking Volity design sessions 
popped out the notion of a "bot factory". This is a new class of Volity 
entity. It sits on the Net, waiting for a request; when it gets one, it 
creates a bot, has it join the requested table, and plays a game. (It's 
analogous to a parlor, but instead of generating referees on demand, it 
generates bots.) A factory handles exactly one game (one ruleset), but it 
could support one or several bots (AI algorithms).

So I figure the full bot sequence looks like this:

(This API presumes my previous robot idea, identifying algorithms with 
URIs. I'm still uncertain about that. If I give up on it, this changes in 
minor and obvious ways.)

When you run a parlor, you configure it to support some number of internal 
bots (which the referee itself can create) and some number of external 
bots (which come from bot factories). For the moment, I'm sticking with 
the idea that a table can only have bots that it was configured to have. 
There is no way for a player to summon a bot from an arbitrary factory.

(Of course, there's still the possibility of a truly independent bot -- 
one which doesn't follow this bot API, but connects and plays as any 
player client would. We encourage such things, as long as they label 
themselves as bots in their presence and disco info.)

So you can disco-query a parlor to determine what bots it supports.

* Parlor: disco#items node "bots": returns the list of supported bots. For
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jason McIntosh | 3 Feb 11:53
Picon

Various updates

The migration is done. Let's all send happy thoughts to Andy Turner,
who performed most of this labor over the last few days.

Also happy thoughts to Zarf who has found and plugged up even more
memory leaks in Javolin. I have uncorked version 0.2.5 in celebration.
Find it at the usual places. (It's not on sourceforge as I write this,
because their website is feeling crappy. But it's all over
volity.org.)

The new server is FAST, and this shows in game play. Where there was
once a pregnant pause between every action in SSA or Fluxx, there is
now, er, not one. This pleases me.

Fluxx? Oh, yeah, it's visible from the game finder now. Holy crap.
I'll be posting to the betatest list soon with more about that. (Yes,
there is actually a significant non-overlap between this list and that
one.) Probably after I make the bug-report link in the game finder
window actually work... grumble, grumble.

On the other hand, I have made the RPS parlors invisible, in light of
the recent ruleset-change discussion, and also because I'm tired of
apologizing for it.

I'll get around to updating the official RPS code and UI, but it's not
the next thing on my list... after Fluxx, I want to take a break from
game hacking for a bit.

--
Jason McIntosh
zendonut <at> gmail.com
(Continue reading)

Permalink | Reply | 2 comments |
headers
Jason McIntosh | 3 Feb 21:47
Picon

Re: Various updates

On 2/3/06, Jason McIntosh <zendonut <at> gmail.com> wrote:
>
> Fluxx? Oh, yeah, it's visible from the game finder now. Holy crap.
> I'll be posting to the betatest list soon with more about that.

Quick update on this: the parlor is cranky and crashy for reasons I do
not understand, and those who might understand have the day off today.
I'm trying to keep the parlor up anyway, so feel free to poke at it...
but I'm not going to announce its presence on the tester list until
its masters are available for bothering.

--
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 | 7 Feb 22:46
Picon

Note for Frivolity CVS users

If you're using Frivolity (the Perl development modules) via CVS,
please do a "cvs update -d" in your sandbox sometime. I've checked in
forks of some of the POE::Component::Jabber modules that we use whose
CPAN versions are buggy, and whose maintainer is... taking his time in
posting fixes.

One of the forks gets rid of a warning message you see every single
time you run volityd, and another zaps a really nasty bug that turned
XML CDATA of "0" into "". The latter of these is included in the
latest downloadable release, I believe.

--
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 | 9 Feb 10:14
Picon

Stumbling into beta

Just to acknowledge it here: I've finally updated the news at
http://volity.org and in so doing made a public link into the betatest
page. I hereby declare a start to a soft beta launch of Javolin and
indeed the whole Volity concept, even while the existing bugboard is
tapdancing all over us. Whee!

As I state on that page, I am not making a push to publicize Volity
right now -- I really don't want to until there's more useful enduser
support and developer support available -- but I have dropped any
pretense of keeping parts of it actively under wraps. I really don't
think anyone benefitted from that.

--
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 | 9 Feb 10:22
Picon

Bot speed

A philosophical question:

Since we moved to the new server, the bots (when running on the same
machine as the Jabber host) are FAST. Often, if you're alone at a
table with these mechanical beasties, it seems that you've no sooner
clicked the "Go" button when *zap* it's your turn again, and you're
left to figure out what just happened. At least one betatester has
reported feeling intimidated by this behavior.

So:

1. Should the bots slow themselves down, for the sake of we
slow-thinking carbon units who often prefer to actually see the
sequence of moves play out?

2. If they should, where should this happen: in the bots themselves
(pausing for N msec before announcing their decision), in the referee
(making sure, globally, that all bots take at least N msec to move) or
in the UI (not displaying player-caused state change until N msec have
passed)?

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

Permalink | Reply | 20 comments |
headers
Doug Orleans | 9 Feb 21:50
X-Face
Picon
Gravatar

Re: Bot speed

Jason McIntosh writes:
 > Since we moved to the new server, the bots (when running on the same
 > machine as the Jabber host) are FAST. Often, if you're alone at a
 > table with these mechanical beasties, it seems that you've no sooner
 > clicked the "Go" button when *zap* it's your turn again, and you're
 > left to figure out what just happened.

Seems like the problem isn't that it happens quickly, but that there's
no way to rewind and see what happened (or to pause and catch up).
Even if the bots are slow, I would want this, e.g. if I step away from
the computer while it's not my turn.  With this functionality, I don't
see any reason to artificially slow down the bots (unless it's a
realtime game or something).

--dougorleans <at> gmail.com

-------------------------------------------------------
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&kid=103432&bid=230486&dat=121642
Permalink | Reply | 1 comment |
headers
Jason McIntosh | 9 Feb 22:53
Picon

Re: Bot speed

On 2/9/06, Doug Orleans <dougorleans <at> gmail.com> wrote:
>
> Seems like the problem isn't that it happens quickly, but that there's
> no way to rewind and see what happened (or to pause and catch up).
> Even if the bots are slow, I would want this, e.g. if I step away from
> the computer while it's not my turn.  With this functionality, I don't
> see any reason to artificially slow down the bots (unless it's a
> realtime game or something).

So, option 3, then: Create a UI that makes it clear what happened
recently. And arguably, this is more of an existing requirement than
an option, so...

--
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
Dan Efran | 10 Feb 04:27

Re: Bot speed

Jason McIntosh wrote:
> A philosophical question:
[...]
> 1. Should the bots slow themselves down, for the sake of we
> slow-thinking carbon units who often prefer to actually see the
> sequence of moves play out?
> 
> 2. If they should, where should this happen: in the bots themselves
> (pausing for N msec before announcing their decision), in the referee
> (making sure, globally, that all bots take at least N msec to move) or
> in the UI (not displaying player-caused state change until N msec have
> passed)?

1. Yes, please. But it should be optional. The first dozen times I play 
a game, I might want this; later, I might not care as much, or at least 
I might want to reduce N. If I'm using a sluggish client, on a PDA or 
something, then I might turn off the bot-slowness, since it's already 
covered by the PDA-slowness.

So I think each user might want a different N. This suggests that it 
should be done in the client.

Oh, wait. The other reason to reduce N is to compensate for a slow 
server. (That follows from the fact that you wanted a nonzero N to 
compensate for a fast server in the first place.) So perhaps it should 
be in the referee.

You don't want it done in the bot: you want the delay to be a *minimum*. 
So if the bot *or* the referee *or* the network is naturally slow enough 
to achieve the minimum, you don't need to add any further delay. That'd
(Continue reading)

Permalink | Reply | 17 comments |

Gmane