PBEM v92 n04 (15Oct92) ====================================================================== The Game Administrators' Corner Mel Nicholson ====================================================================== Game Automation for PBEM As promised, I'll be talking about game automation this issue. The PBEM game has a huge potential for automation and autonomy, often near the point of removing the need for game master intervention. First, I'll make a few comments about the technical issues in getting such a monster to work, and then I'll go on to some qualitative issues about user interface and getting it to work nicely. For a UNIX/BSD based PBEM, the key to everything from a technical standpoint comes from one simple feature: the mail pipe. The way this works is to redirect an entire mail message to a given account to a program. The program must be setuid (use "chmod 4700 filename") so that it will run as the program owner, because (for obvious security reasons) the kernel will refuse to run such a program as root. The way to make a redirection using the mail pipe is to either create a .forward file with "|/usr/myaccount/myprogram" (actually include those quotation marks) in an account used for no other mail than the game, or to make /usr/lib/aliases include a line with the above pipe in it like so: alias-name: "|/usr/myaccount/myprogram" So if anyone mails alias-name@your.machine, they run your program with their mail as standard input. From there, getting their address and parsing the mail is pretty easy, and the sort of technical detail that is likely to vary from games to game, so I won't discuss it in any detail. What is important is the way the user interacts with the machine. It's hard to mention this sort of thing without mentioning the Judge. To start, I have to say that this program is really an excellent example of a well-designed and well-implemented user interface. In case anyone doesn't know, the Judge is a Diplomacy PBEM server, the most popular of which runs as "judge@u.washington.edu". I'm going to use it as a contrast to munch@soda.berkeley.edu (which runs the game SPARF) to highlight many of the design decisions which come from implementing a game interface. First off is the decision about where the commands go. The Judge beat me cleanly on this one. It uses the entire body of the letter as a series of commands... one per line. When I made munch, I'd never used the Judge and made the decision to use the subject line to direct commands. The direct result of this is there is now a very strong restriction on munch of "one email message is one command" The big flexibility comes in when the user is looking for info retrieval and wants several files. Using the Judge's method this is simple, since the desired requests can just be listed, whereas with munch several letters must be sent. The only real benefit of this method is that automatic .signatures are never mistaken as commands. The next consideration is making a user-friendly format for orders. SPARF was designed with the PBEM format in mind, and does quite well at allowing brief, concise, orders. The most important factor here is that upon reading the order, it should relatively easy to tell what the order states. In SPARF, the only real memorization is to recall the order in which the four skills are listed for training. All other information, like the position a player is assigned to, is explicit. This verbosity makes the onus on the user greatly reduced, but should not be extended by including numerous mandatory null words which are always the same. In short, everything in an order should be meaningful, and that meaning should be readily obvious. Things which are not explicit in their meaning and need to be memorized should be kept to an absolute minimum. User feedback is the last big concern. In general, EVERY order should be responded to, an errors reported immediately so the user can correct them, or at least rest assured that everything is okay. One big space for user friendliness here is send the orders back in a more verbose format than received. For example, the Judge expands all abbreviations when acknowledging order receipt. SPARF uses this possibility extensively, responding to a successful training order with the post- training status of the team, and responding to a correct lineup submission with a scouting report of the team as it would appear to the opponent facing that lineup. Aside from the above questions which depend on the particular game, all games have a few general things in common: 1) security. There should be some protection that orders which arrive actually come from the right person. A simple password will work for this, as is used in both munch and the Judge. Also, this password need not be nearly as secure as an account password, since you are mostly guarding against idle temptation and accidental misfiling --- if you have someone actively trying to break security you can just crush them on a per-person basis. 2) mail forwarding. Especially in a game like Diplomacy where the mail between players is so important, it is good to maintain a method for sending to the player, rather than the person. This is especially useful when the games last long enough for many of the players to change addresses --- the others need only remember the teamcode, not the individual (changing) address. 3) status reports. Users *will* lose their turn reports. Give them a way the use the server to get a copy of any information they need without your intervention --- this will save you *lots* of time, and give them quicker response. 4) help files. You will never have too many help files or too much indexing. As long as the most important information is presented in an easily accessible way, and the indexing is user friendly, this can no only save you the time of answering lots of beginner questions, but also will make it a lot easier for new players to learn the game and become involved. Automation gives the player the satisfaction of quick response, and when used well, save the moderator time and lets the players spend more time on strategy and less time worrying about whether the moderator will botch their most recent orders completely, as so often happens to the poor, overworked moderator of a non-automated game. This week focused on the issues in automating a game which already works in PBEM format. Next week I'll talk about conversion issues, and how to make a non-PBM game suitable for PBM and PBEM play.