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 |
headers
Andrew Plotkin | 10 Feb 17:59

Persistent player storage

Josh on the Icehouse list mentioned the topic of game-specific data 
associated with the player. (I.e., the set of cards you own in a CCG.)

My immediate answer was "The referee can operate its own local database." 
Which is certainly true.

But we may also want to offer central data storage. Quite possibly as a 
for-pay service -- a game developer pays us to host a database table. (Or 
small amounts for free, large amounts for money.)

Player data might be specific to one referee (for "valuable" data like 
card ownership). There may also be data shared among all referees of a 
particular ruleset. (That's open to editing by anyone, which is why I made 
the distinction between "valuable" data and not.)

Idea, thrown on the stack.

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

Permalink | Reply |
headers
Andrew Plotkin | 10 Feb 17:53

Re: Bot speed

On Thu, 9 Feb 2006, Dan Efran wrote:

> 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.

One problem with doing it in the client is that synchronization becomes a 
bitch. The client is queuing up RPCs and applying them with a delay? 
Scary. (Also, that's not truly representative of game speed. In BGo, a 
move is either one or two RPCs -- penalties are sent separately from piece 
motion.)

A more general idea -- and this also gets to Doug's comment about rewind 
-- would be for the UI to mark "save points", each of which is one 
notional stage of the game, and each of which saves a graphical snapshot 
of the UI. Then the player could scroll freely up and down. But, wow, 
*huge* memory hog. (Yes, even with the vector graphics.)

> So I agree that there should be a "what just happened?" feature of some kind 
> too, but I do *not* think this eliminates the need for bots to (optionally) 
> slow down to a perceptible speed.

Well, if the rewind actually works, then the client can do all the work -- 
accepting RPCs behind the scenes, and winding forward through the steps at 
a fixed rate (until it catches up). And this would apply to fast human
(Continue reading)

Permalink | Reply |
headers
Denis Moskowitz | 10 Feb 18:59
Favicon

Re: Bot speed

[Andrew Plotkin]
> A more general idea -- and this also gets to Doug's comment about rewind 
> -- would be for the UI to mark "save points", each of which is one 
> notional stage of the game, and each of which saves a graphical snapshot 
> of the UI. Then the player could scroll freely up and down. But, wow, 
> *huge* memory hog. (Yes, even with the vector graphics.)

There's no reason to store it graphically - it can store it as a game
state snapshot, and display it using its standard routines.
--Denis

-------------------------------------------------------
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 |
headers
Dan Efran | 11 Feb 03:44

Re: Bot speed

Denis Moskowitz wrote:
 > [Andrew Plotkin]
 >
 >>A more general idea -- and this also gets to Doug's comment about rewind
 >>-- would be for the UI to mark "save points", each of which is one
 >>notional stage of the game, and each of which saves a graphical snapshot
 >>of the UI. Then the player could scroll freely up and down. But, wow,
 >>*huge* memory hog. (Yes, even with the vector graphics.)
 >
 >
 > There's no reason to store it graphically - it can store it as a game
 > state snapshot, and display it using its standard routines.
 > --Denis

Game state snapshots would be best, but can that be implemented 
generically?  Couldn't you just record and replay the message traffic?

This also raises the thought of playing back a whole game's history, 
even if you weren't in it. I'm thinking of software I've seen that 
allows you to step through famous games of chess, go, etc. I don't 
remember if anyone has proposed this feature for Volity, but if not, I'd 
like to request it.

I had been having trouble thinking why the average game developer might 
want to pay for central data storage (Zarf's cool recent suggestion) 
rather than just using their own server...but game histories might be 
such a reason.

I don't think you'd want to keep them *all*, mind. Just notable ones, 
decided somehow - the simplest mechanism is that a game is saved when
(Continue reading)

Permalink | Reply |
headers
Andrew Plotkin | 11 Feb 03:52

Re: Bot speed

On Fri, 10 Feb 2006, Dan Efran wrote:

> Game state snapshots would be best, but can that be implemented generically? 
> Couldn't you just record and replay the message traffic?

That's gotta be the worst of both worlds. Well, no. It can be very 
inefficient, but it's easy and generic. I still think it's not the right 
answer.

(I'm particularly worried about cases where most of the game RPCs turn out 
to *not* be about actually updating the game state. Or not updating it in 
significant ways. If there are RPCs to query the game state, or some kind 
of player-to-player messaging beyond standard Jabber messaging... Or there 
could be a lot of skirmishing details that the (long-view) game history 
doesn't care about. Basically, just because current games have a close 
correspondence between RPC history and game history doesn't mean that it 
will always be that way.)

> This also raises the thought of playing back a whole game's history, even if 
> you weren't in it. I'm thinking of software I've seen that allows you to step 
> through famous games of chess, go, etc. I don't remember if anyone has 
> proposed this feature for Volity, but if not, I'd like to request it.
>
> I had been having trouble thinking why the average game developer might want 
> to pay for central data storage (Zarf's cool recent suggestion) rather than 
> just using their own server...

Because running a database is a big fat pain, that's why.

> but game histories might be such a reason.
(Continue reading)

Permalink | Reply |
headers
Dan Efran | 12 Feb 00:37

Re: Bot speed

Andrew Plotkin wrote:
> On Fri, 10 Feb 2006, Dan Efran wrote:
> 
>> Game state snapshots would be best, but can that be implemented 
>> generically? Couldn't you just record and replay the message traffic?
> 
> 
> That's gotta be the worst of both worlds. Well, no. It can be very 
> inefficient, but it's easy and generic. I still think it's not the right 
> answer.

I was thinking that it's nearly trivial to implement, and automatically 
works for every game, and covers both rewind and save-history at once. 
Also handy for debugging, perhaps. I wouldn't expect it to be 
particularly inefficient for most games. Isn't it just a few messages 
per turn for most games? Mostly the same kinds, too, so it might 
compress well for storage.

> (I'm particularly worried about cases where most of the game RPCs turn 
> out to *not* be about actually updating the game state. Or not updating 
> it in significant ways. If there are RPCs to query the game state, or 
> some kind of player-to-player messaging beyond standard Jabber 
> messaging... Or there could be a lot of skirmishing details that the 
> (long-view) game history doesn't care about. Basically, just because 
> current games have a close correspondence between RPC history and game 
> history doesn't mean that it will always be that way.)

Okay, that's a point. You could have some way of designating RPC's as 
part of the history or not. This is ugly, of course, but if recording 
everything is the default, maybe not too ugly. If you charge for the
(Continue reading)

Permalink | Reply |
headers
Dan Efran | 12 Feb 05:06

Re: Bot speed

Dan Efran wrote:

> This gets you game histories and rewind for *every* game, with a 
> consistent mechanism that's part of the Volity standard (rather than ad 
> hoc) and can thus be parsed by the bookkeeper to some degree, should 
> that ever be desirable. And implementing it would be no more than a few 
> hours' work, if I'm not mistaken.

To be fair, I may have overstated the appeal of this solution. It does 
have significant advantages as quoted above, but I glossed over (i.e. 
didn't mention) its flaws and complexities. For example:

- The scheme must actually be implemented twice: in the referee for 
histories, and in the client for rewind. (It's still a very small amount 
of new code in each, and it's approximately the same code in both.)

- The record isn't random-access - it must be replayed from the 
beginning to any given point. (Zarf's graphical snapshots are better for 
rewind in this regard, but don't apply to game histories. And I still 
think they're less efficient for many games, though not prohibitively, 
I'd guess.)

- It's not the ideal format for a game history. (But it's still the only 
scheme I can think of to get them automatically for all games.)

So I still say it's a pretty good scheme. But it's a compromise, for sure.

I'd say the graphical snapshots are the all-around best technique for 
rewind (being equally generic), but that leaves game histories in the 
hands of each game developer, which seems unfortunate.
(Continue reading)

Permalink | Reply |
headers
Andrew Plotkin | 12 Feb 05:45

Re: Bot speed

On Sat, 11 Feb 2006, Dan Efran wrote:

> - It's not the ideal format for a game history. (But it's still the only 
> scheme I can think of to get them automatically for all games.)

One downside you missed: it makes the game history format dependent on the 
RPC format. If you change the RPCs, your game histories all break. (Unless 
you write a UI that supports both API versions... that sucks.)

Actually, now that I think of it, a game history isn't going to 
*generally* be described by any stream of RPCs that actually occurs during 
play! (Because of hidden information.) The RPCs going to a particular 
client will describe *that seat's* view of the game history. That is 
sufficient for rewinding a game that you-the-player are involved in, but 
it is useless for a final game history. We shouldn't confuse those two 
problems.

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

Permalink | Reply |
headers
Andrew Plotkin | 12 Feb 18:46

UI versioning case study

And by "case study", I mean "I was trying to play Treehouse with Doug and 
he ran into problems."

The problem was caused by a caching web proxy on his network. I had 
upgraded the Treehouse UI in order to fix a cosmetic bug. But the proxy 
kept feeding him the old version of the zip file.

Since it was a cosmetic fix, this was not fatal. However, I could just 
as well have changed the ruleset, and then upgraded the referee and the UI 
at the same time. Doug would then have been trying to play the new referee 
with the old UI, which would have killed the game for him.

This implies two things:

First, our web server might want to throw on more HTTP headers to beat up 
web proxies. (For UI files only! Do we want to move UI files to a common 
directory tree on the server?) Since the client does a HEAD request and 
compares the Last-Modified header -- which we do send -- we can bypass 
other people's caching mechanisms with a clear conscience.

Second, we really need UI versioning. Not just as a "nice to have" 
feature. What we want to be able to do is post the new UI at a new URL, 
and have *both* UIs in the bookkeeper database, with different ruleset 
version numbers.

(I guess that doesn't truly add anything vital for this case -- if I'm 
upgrading the only parlor for a given ruleset, it's just as effective to 
post the new UI at a new URL, and delete the old one. So what we 
*actually* need is the web form to register new UIs. As opposed to the 
"Hey, Jmac" method that we currently support.)
(Continue reading)

Permalink | Reply |
headers
Andy Turner | 14 Feb 21:38

Re: UI versioning case study

On Sun, Feb 12, 2006 at 12:46:30PM -0500, Andrew Plotkin wrote:
> The problem was caused by a caching web proxy on his network. I had 
> upgraded the Treehouse UI in order to fix a cosmetic bug. But the proxy 
> kept feeding him the old version of the zip file.

Yuck!

> First, our web server might want to throw on more HTTP headers to beat up 
> web proxies. (For UI files only! Do we want to move UI files to a common 
> directory tree on the server?)

Or give them a standard extension, which I think I'd prefer.

> Since the client does a HEAD request and compares the Last-Modified
> header -- which we do send -- we can bypass other people's caching
> mechanisms with a clear conscience.

The client should really be doing a GET with an If-Modified-Since
header.  That way it only has to do one request.

--

-- 
Andy <turner <at> mikomi.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&kid=103432&bid=230486&dat=121642
Permalink | Reply |
headers
Andrew Plotkin | 14 Feb 22:03

Re: UI versioning case study

On Tue, 14 Feb 2006, Andy Turner wrote:

> On Sun, Feb 12, 2006 at 12:46:30PM -0500, Andrew Plotkin wrote:
>> First, our web server might want to throw on more HTTP headers to beat up
>> web proxies. (For UI files only! Do we want to move UI files to a common
>> directory tree on the server?)
>
> Or give them a standard extension, which I think I'd prefer.

Okay, they're all ".zip" files.  :)

(I thought ".jar" was a bad idea too. We're advertising these as being 
ordinary zip files. Let's not change the name.)

There will also be resource files which come under the same caching 
control. These may be .zip files, or plain .svg files.

>> Since the client does a HEAD request and compares the Last-Modified
>> header -- which we do send -- we can bypass other people's caching
>> mechanisms with a clear conscience.
>
> The client should really be doing a GET with an If-Modified-Since
> header.  That way it only has to do one request.

That is a good point. Will file bug on that.

However, aren't there headers which are addressed specifically to web 
proxies? Like "Hands-Off-You-Ignorant-Ape"?

--Z
(Continue reading)

Permalink | Reply |
headers
Andy Turner | 14 Feb 23:45

Re: UI versioning case study

On Tue, Feb 14, 2006 at 04:03:57PM -0500, Andrew Plotkin wrote:
> There will also be resource files which come under the same caching
> control. These may be .zip files, or plain .svg files.

Resource files that aren't UI files?  I'm not sure what you mean...

> However, aren't there headers which are addressed specifically to
> web proxies? Like "Hands-Off-You-Ignorant-Ape"?

Well there are definitely server-side headers, and we can add those.
There may be client side headers... I vaguely recall that browsers
send a different set of headers if you hit shift-reload...

--

-- 
Andy <turner <at> mikomi.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&kid=103432&bid=230486&dat=121642
Permalink | Reply |
headers
Andrew Plotkin | 15 Feb 00:18

Re: UI versioning case study

On Tue, 14 Feb 2006, Andy Turner wrote:

> On Tue, Feb 14, 2006 at 04:03:57PM -0500, Andrew Plotkin wrote:
>> There will also be resource files which come under the same caching
>> control. These may be .zip files, or plain .svg files.
>
> Resource files that aren't UI files?  I'm not sure what you mean...

The pluggable art resources. Like an Aquarius deck or an Icehouse set.

>> However, aren't there headers which are addressed specifically to
>> web proxies? Like "Hands-Off-You-Ignorant-Ape"?
>
> Well there are definitely server-side headers, and we can add those.
> There may be client side headers... I vaguely recall that browsers
> send a different set of headers if you hit shift-reload...

Yeah, I see a client-side option for bypassing caches. I'll put that in.

--Z

--

-- 
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
If the Bush administration hasn't thrown you in military prison without trial,
it's for one reason: they don't feel like it. Not because you're patriotic.

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

Permalink | Reply |
headers
Doug Orleans | 14 Feb 22:29
X-Face
Picon
Gravatar

Re: UI versioning case study

Andrew Plotkin writes:
 > However, aren't there headers which are addressed specifically to web 
 > proxies? Like "Hands-Off-You-Ignorant-Ape"?

Are you thinking of Cache-Control?

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9

I think you want must-revalidate, but I'm not really sure.

--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 |
headers
Dan Efran | 12 Feb 01:05

Re: Bot speed

Dan Efran wrote:
 > 2. Have a "review mode" where the UI follows the history instead of the
 > current RPC stream. Be sure the UI can detect this mode, but a typical
 > UI will do *almost* the same things as in the normal mode. (Put the
 > history-navigation buttons in the client, I think, not the game code?)

On further reflection, this issue is a little bit tricky. Hard to keep 
it generic; might be better to let developers write a separate UI for 
replays. But I think you *can* do it completely generically, if you give 
a *copy* of the game UI a replay of the RPCs up to a given turn; this UI 
copy will send outgoing RPCs but the client traps those. (It can even 
validate them against the recorded version, to test a new UI for an 
existing game.)

     -- Dan Efran
         Martian Ambassador
         efran <at> wunderland.com
         http://www.efran.org/embassy/

-------------------------------------------------------
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 |
headers
Andrew Plotkin | 11 Feb 02:54

Re: Bot speed

On Fri, 10 Feb 2006, Denis Moskowitz wrote:

> [Andrew Plotkin]
>> A more general idea -- and this also gets to Doug's comment about rewind
>> -- would be for the UI to mark "save points", each of which is one
>> notional stage of the game, and each of which saves a graphical snapshot
>> of the UI. Then the player could scroll freely up and down. But, wow,
>> *huge* memory hog. (Yes, even with the vector graphics.)
>
> There's no reason to store it graphically - it can store it as a game
> state snapshot, and display it using its standard routines.

That can't be done automatically. Any game could *do* it, but it would be 
up to the individual game developer to implement and debug. My magic 
programmer sense tells me that roughly zero percent of game developers 
will bother.

The reason I suggested the graphical-snapshot idea is that it's much 
easier on the game developer -- he just has to add one line of code, in 
his "new turn" handler (or whatever is equivalent for the game in 
question). The client can then magically handle the rest. We really, 
really like having things magically work.

I'll have to investigate. It might wind up being not such a memory hog 
after all.

--Z

--

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

Permalink | Reply |
headers
Doug Orleans | 10 Feb 05:26
X-Face
Picon
Gravatar

Re: Bot speed

Dan Efran writes:
 > Now Doug says, in part:
 >  > Seems like the problem isn't that it happens quickly, but that there's
 >  > no way to rewind and see what happened
 > 
 > ...and compares this to stepping away from the computer. But I disagree. 
 > If a change happens too fast, it almost becomes invisible, even when 
 > you're watching. (And especially if you're still leaning back from 
 > making your own move when the next one happens.) If you step away, you 
 > *know* you probably missed something; this is a very different 
 > experience from staring at the screen for two minutes thinking "hurry up 
 > and move already" when it's actually your turn.

Right, I'm just saying this difference is a UI problem, and has
nothing to do with the bot speed.  Maybe it could actually pause with
a prompt until you say OK, like some graphical equivalent of "--more--"
in nethack.

Really I just want everything to be like Tivo...

--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 |

Gmane