Juliann says, "Welcome back everyone to our final session. Up next is our esteemed co-organizer, Javelin, speaking on "RP log judging without headaches"."

Juliann goes down the few steps to the seating area.

Juliann comes down the few steps from the stage.

Javelin says, "Running a judged RP MUSH can be a headache. Because judges can't always be online to watch RP as it occurs, many MUSHes ask their players to make logs of RP and to submit those logs to the RP judges or admin. This allows the RP judges to reward players who participate in RP as well as to keep track of ongoing plots."

Javelin says, "At the now closed Riverworld MUSH, I developed an IC logging system that addresses all three of these concerns. The gist of the IC logging system is (1) that the *server*, rather than the *player* maintains the logs, and (2) that server-side scripts periodically sample the logs, choosing those most likely to be noteworthy, and emailing no more than a fixed number of logs (often 1) to each judge."

Javelin says, "Here's how it works. Players use softcoded +log commands to turn logging on or off for the current room (or object interior). The softcoded global also uses an @adisconnect to turn off logging if the last person present disconnects from the logged room, and checks all logging rooms every 15 minutes in order to turn off logging if players are no longer present."

Javelin says, "When logging is activated or deactivated in a location, the server announces this to anyone present in the location; in addition, when logging is on at a location, any player who enters the location is informed by the server that they are in a logged area. Internally, logged rooms and objects have a LOGGING flag set on them which requires royalty privs to set or unset."

Javelin says, "Some areas should never be logged. Admin can set the OOC flag on these areas. The server will refuse to activate logging in a room that is flagged OOC. This flag provides players with further assurances that their OOC conversation will not be recorded."

Javelin says, "So now we have a large log file containing, in chronological order, anything said in any logged room. Because we know time, speaker, and location, we can pretty accurately separate out distinct logs. A perl script, process_iclog, reads the ic.log and separates it into "conversations". It sorts the IC log by room and by time (i.e., chronologically within each room) and assumes that silences of more than 15 minutes constitute the end of a conversation in a room."

Javelin says, "process_iclog then tries to sort the conversations in order of interestingness. What seemed to work well at Riverworld was to compute the interestingness of a conversation by rolling some 10-sided dice for each conversation. The number of dice rolled for a conversation was based on the sum of (1) the number of different players involved in the conversation (more people is more interesting), (2) the log (base 2) of the length of the conversation in lines (longer conversations are more interesting, but at a decreasing rate), and (3) the log (base 2) of the length in words of the longest utterance in the conversation (conversations where people speak at length are more interesting). Using dice introduces some chance elements into the selection, while the formula above seemed to be very good at identifying interesting logs and largely ignoring monologues, short tests of the system, etc."

Javelin says, "For example, a conversation with 3 players that was 64 lines long and had a longest line of 16 words would get to roll 3 + 6 + 4 = 13 10-sided dice, because log2 of 64 = 6 and log2 of 16 = 4."

Javelin says, "process_iclog produces a list of conversations from most interesting to least. Another script, split-n-mail, then begins mailing these conversations, in order, to the judges listed in a file of judge addresses. It limits the number of logs sent to each judge to a fixed number per judge (usually 1), and randomly orders the list of judges each time it's called to keep the distribution of logs even. It prepends each log with a paragraph suggesting how the judge should use the log -- this, obviously, is game-specific."

Javelin says, "Once a week, or at whatever interval works for you, you simply run process_iclog on ic.log, feeding the results to split-n-mail, and then clear ic.log."

Javelin says, "This system works no matter what clients the players use. Players can not modify the logs. And judges receive a manageable number of submissions per period. Although the judges see only a sample of the actual RP on the MUSH, those players who RP frequently, with many others, and at length will tend to be more often represented in the judged logs. The system does require that disk space be available for the ic.log file, which, for security reasons might best be located on its own partition."

Javelin says, "The system has just been made available on ftp.pennmush.org in /pub/PennMUSH/Accessories."

Javelin says, "I forgot to clear the list of question-askers from the last talk, so if you get a message that it's your turn to ask a question, and you don't have one, just page me with 'pass' or something. Let's go to q&a. :)"

Javelin flips through the passes. Sorry for the pause. :)

Dybs says, "Uh, pass."

Dybs says, "Sorry"

Kingpin notes that he passed but then had a question. :)

Trispis says, "raise your hand again."

Kingpin did

Aldur says, "Yeah, two parts. One, where will the logs of this be posted. Two, does this work for TinyMUSH/MUX?"

Javelin says, "The chairs will announce the answer to #1. In re: #2, there's no reason why it shouldn't, except that I didn't do the hardcode patch for those servers. But it's a very simple patch to PennMUSH and I imagine it wouldn't be hard to figure out how to get the same behavior from the other servers."

Kingpin says, "Does conventional logging and your server-side logging noticibly increase RP on a MUSH? If so, does one increase it more than the other?"

Javelin says, "I didn't do a study or anything. :) It's less the logging, I think, than the incentives. If your MUSH rewards people for sending in RP logs, they'll do so. If you're building a MUSH were it's important for the RP staff to know what's going on with the players (e.g., you have flexible story arcs :), you might want to encourage that."

Javelin says, "I know that Riverworld players used the system pretyt happily."

Trispis says, "In testing, what were the disk space requirements for an average week of logging (or some other reference point for measuring disk space needs) ... for the ic.log . . . ?"

Javelin says, "Obviously depends on how many and how active players. I think on a good week we were about 80-100 Kb. But you can always decided to process the logs more frequently or when they get too big for you if you want."

Purple_Guest says, "You haven't had players complain about perceived privacy threats of anything of that sort? I have a few players that are really paranoid about logging."

Javelin says, "Good question, and our last one."
Javelin says, "Initially there were concerns, and I tried to take tho se concerns into the design of the system -- players *always* know if they're i n a room that's being logged. Only room-visible messages are logged -- never pa ges, whispers, etc. They had to trust me on that, obviously, but I'm pretty tru stworthy. That's about all the time I have. thanks for listening. :)"

Kingpin applauds

Juliann says, "Thank you Javelin for that very useful innovation. That wraps up our conference for this evening. Let's have a big round of applause for all of our speakers tonight!"

Dybs rises, and applauds.

Purple_Guest claps, too.

Juliann says, "You are all cordially invited to a reception now, where you can chat with any of the speakers from any of the sessions. And in case you want to catch up on things you've missed in the other room, the conference logs will soon be available on the web at: http://www.pennmush.org/innovations/"

Juliann says, "Thanks again for your attendance, and have a good night."