Capturing a list of user commands

[Stephen Granade]

I'm gearing up for ifcomp, and this year I'm planning on adding the ability to play entered z-code games from the browser via Parchment. One thing I'd like to do is have a version of Parchment that can report back to a listener on ifcomp.org, sending typed player commands. That would let me give authors a list of commands tried by players for later improvement.

You'd probably want to send each command, a sequence number (in case of dropped commands, since Parchment certainly shouldn't sit around waiting for a response from the listener), and a semi-anonymous ID token that only identifies what game is being played by IFID and what session is being played. That way the listener could divide up incoming commands and slot them into transcripts by game and then by session.

Is this a reasonable request, and something anyone wants to take on?

Stephen

[Andrew Plotkin]

And timestamps for each command! (Sort of derivable from the listener's
logs, but it's better to log it client-side.) I'd love to read a
transcript of someone playing my game where the commands are colored
hot-to-cold based on how much time the player spent thinking.

> Is this a reasonable request, and something anyone wants to take on?

Very reasonable, but you knew I was going to say that, since it came up so
often at PAX. :) Naturally I don't dare touch the problem before I finish
the other thousand IF things I need to do. (Thought of more "undo" unit
tests for Parchment!)

--Z

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

[Stephen Granade]

On Fri, Apr 2, 2010 at 12:20 PM, Andrew Plotkin <zgo...@eblong.com> wrote:

On Fri, 2 Apr 2010, Stephen Granade wrote:

You'd probably want to send each command, a sequence number (in case of
dropped commands, since Parchment certainly shouldn't sit around waiting for
a response from the listener), and a semi-anonymous ID token that only
identifies what game is being played by IFID and what session is being
played. That way the listener could divide up incoming commands and slot
them into transcripts by game and then by session.

And timestamps for each command! (Sort of derivable from the listener's logs, but it's better to log it client-side.) I'd love to read a transcript of someone playing my game where the commands are colored hot-to-cold based on how much time the player spent thinking.

Yes, agreed absolutely. In fact, in discussions of adaptive difficulty, I've often wanted to know how fast people were entering commands and not just what commands they've entered. But that's a different discussion for a different time.

 

Is this a reasonable request, and something anyone wants to take on?

Very reasonable, but you knew I was going to say that, since it came up so often at PAX. :) Naturally I don't dare touch the problem before I finish the other thousand IF things I need to do. (Thought of more "undo" unit tests for Parchment!)

Well, hm. In the meantime, why don't we discuss *how* to do it. My first thought was passing this information via HTTP POST to a listener webpage. Especially if we're just logging commands and not a full transcript, the amount of data to pass will be very minimal.

Stephen

[Andrew Plotkin]

I was originally thinking "save it all up, post a transcript at the end".
But people tend to close browser windows at whim, so move-by-move is
better.

For sanity's sake, set a timer so that POSTs happen no more than once
every thirty seconds (or sixty, or some number). Ship off all the moves
that have happened since the last POST.

You'd also want to have some sort of player notification in the page
header that this is going on. Users like to know about "contacting the
mothership" situations.

[Dannii]

When we've discussed this before we thought that having an entry in
the IFiction file of a webpage to post the data to. Unfortunately
Javascript can't send emails, so it would have to be a webpage. Then
once the game has finished, or they close the page, we can ask the
user if they would like to submit a transcript. If the unload event
isn't reliable enough we could transmit them more regularly.

Now if this is for ifcomp especially, will you still be wanting to
receive the transcripts after it has finished? The IFiction entry
could also have a date... so after the comp it wouldn't sent it to the
IFComp website anymore. But authors could always set up their own
transcript receiver, and extend the date as long as they want.

Another thing I thought could be useful for the comp is to have a
timer for those who want it, showing how close they are to the 2 hour
limit.