PBEM Fanzine, v92n1 From: gl8f@fermi.clas.Virginia.EDU (Greg Lindahl) Date: Thu, 16 Jul 1992 22:19:23 +0000 ====================================================================== ###### ###### ####### # # # # # # # ## ## # # # # # # # # # ###### ###### ##### # # # # # # # # # # # # # # # # ###### ####### # # ====================================================================== A Fanzine for Free Computer-Moderated Play-By-Electronic-Mail Wargames ====================================================================== volume 92, number 1 (yes, volume 92 is the first) july 15, 1992 ====================================================================== Greg Lindahl, Editor gl8f@virginia.edu ====================================================================== Table of Contents: Opening Stuff o The Editor's Corner Articles o The Search For The Holy Grail Columns o The Game Administrators' Corner, by Mel Nicholson Regular Features o Game Descriptions & Information o Hints about sending electronic mail to other networks o What's this "ftp" thing anyway? o Archives and subscriptions by email SUBMISSIONS are highly encouraged. Contact the editor at: gl8f@virginia.edu ====================================================================== The Editor's Corner ====================================================================== Welcome to the first issue of PBEM, a magazine for free computer- moderated play-by-electronic-mail wargames. Quite a mouthful, isn't it? Well, there is a point to all these words: they define a class of games that I hope will revolutionize the field of play-by-mail (PBM) wargaming. The field of PBM gaming was started, at least in the USA, by Rick Loomis and his company, Flying Buffalo Inc., nearly 20 years ago. These days there are quite a few commercial companies offering a huge number of games. They offer advantages over face-to-face gaming to many players: larger games, more highly-qualified opponents, etc. However, these games are generally very expensive, especially games for which turns are submitted through the postal mail. It's expensive to type in a turn, print, and mail the result, not to mention write the programs and answer questions. On the other hand, we have hobby gamers, who find it fun to spend hundreds of hours running games for other people. These days the computer power needed to run a computer-moderated game is probably sitting in your bedroom. Electronic mail has also come down in price, to the point where most people associated with universities can get free email access. So why can't a hobbyist offer the same sort of game that commercial companies offer, only for free? The answer is, they can. For the same amount of effort that you might put into running a role-playing campaign, you can offer a game to an audience of hundreds or thousands of players. And there are people who want to do this. I've wanted to do this for many years but haven't actually gotten anything done; instead I decided to advertise the efforts of the people who have gotten things done. I hope that this magazine will be published twice a month, on the first and 15th. However, it will only flower if the readers contribute. Tell me about games I haven't heard of yet, write articles about games, reviews of games, post-mortem evaluations of the closed-ended games, and so on. I look forward to hearing from you. -- Greg Lindahl gl8f@virginia.edu ====================================================================== The Search For The Holy Grail Greg Lindahl ====================================================================== For many players, the Holy Grail of PBM gaming is the open-ended game. While designing a good closed-ended game seems to be about as difficult as producing a good traditional boardgame (i.e. hard, but possible), players seem to want things out of open-ended games that make them virtually impossible to design. I'd like a game that I can play the same instance of forever, that is always interesting, that admits new players constantly who might, through luck and skill, climb to be rich and powerful, that makes it easy for me to move my units in concert with 100 other players when attacking and defending, and while it's at it, that orders a free pizza to be delivered when I get my results, which must be comprehensive and yet concise. Of course, you probably can't have all of the above, but some games do have some really neat features. One game that I've been thinking a fair bit about recently is Olympia, which is a free fantasy PBEM (for more details about Olympia, look in the game descriptions section at the end of this fanzine.) Olympia features simultaneous movement -- all players submit their turns by the same date, and then each day's orders for each player are processed in lockstep. If I am chasing another player, for example, and he leaves for the next province 2 days before I do and we move at the same speed, he will arrive 2 days before I do and has 2 days to make preparations before I show up to attack him. In contrast, many older games have processed entire turns when they arrive in the mail. So, if I am chasing another player, either my turn is run first and I catch him, or my turn runs second and he ends up very far away. Another Olympia feature is stacking. When you stack your units under the units of another player, the stack leader's attack and movement orders will affect the entire stack. This allows coordinated effort by many players, although a certain amount of trust is required. These two features, while not unique to Olympia, certainly make it much more playable than the first few commercial games in this genre, of which I played Universe II and Beyond the Stellar Empire. Maybe someday I'll even find the Holy Grail. ====================================================================== The Game Administrators' Corner Mel Nicholson ====================================================================== Game Administration of Semi-Automated Games To the player, especially in a well-run game, it may seem that the task of administration is a very simple, or even non-existent one. You just send in your orders and the game just sorta takes care of itself, right? Unluckily for the game administrator, there is still plenty of work to do in most semi-automated games. The biggest job is maintaining a player base. The details may vary depending on the size of the game and how much the sudden departure of one player affects things. The one constant that remains is that there are a lot of net gamers whose access is sporadic or who vanish during college vacations or suddenly find themselves changing jobs and losing access, to say nothing of the effects of computer downtime and the intrinsic quirkiness of e-mail. As administrator of SPARF (a sports simulation of Australian rules football), I've noticed a few strategies for dealing with this and other problems that arise in game administration, and hope to pass on my experience here. The first and biggest thing I can say about game administration is to know your players as well as possible. Are half of them from Australia, and need breaks around their calendar? Do many of them have jobs that make weekend response time slow? Or perhaps they can only log in on weekends? Whatever the case, it's best to understand your players' limitations, as it will help you with those regular scheduling decisions that always come up. The biggest (or at least most common) scheduling decisions revolve around holidays. In most games you should plan on having to deal with this, and will need to provide some manner for players to submit orders in advance when leaving for a period of time, or at the very least provide an autopilot which does not play too badly for short periods of time. Also, the players aren't the only ones who will go on breaks, so try to leave room for your own absence from the game. In this situation especially, a little communication will give you a lot of flexibility. Other than holidays, the other major scheduling problem is the battle over pacing changes. There are a few people, especially in military simulations, who will lobby for faster and faster updates until you are running a realtime simulator (which gratefully leaves the scope of this magazine --- I don't have time for those games). Counter to these people will be those who worry (justifiably) that they will be unable to compete (or even participate) at faster update rates. While there is no hard and fast answer to the question, it is a good idea to keep things slightly slower than what the majority of your players can handle, if for no other reason than to leave some slack for emergencies (like email servers gone mad). The tradeoff you are deciding is one between overworking your players by moving too fast, or boring them by being too slow. At either extreme, you kill the game, so look for a medium. The next biggest problem non-developmental games have is player dropout. Unsurprisingly, player/moderator communication is a big help here. Some games don't have to deal with this problem, as players can drop out without too much in the way of ripples, but for those that can't, it is important to know who is likely to disappear. For this type of game, it is a very good idea to make a few hoops for the newcomers to jump through, like submitting a couple of "practice" orders or else having to respond to several rounds of email. I base this suggestion on the fact that about 80% of mid-season dropouts in SPARF are during the first two weeks. By creating a three week pre-season which is played out for new players, but submitted all at once for old players who have other things to do during this time, I can screen out many players who will drop out early on before they have a chance to negatively affect the game. This sort of game also works better with a healthy waiting list/player ratio (though in practice the ratio always seems to be too small). I hope these hints help you if you're planning on running or writing these monsters. Direct any questions or feedback to me at my account, nicholso@pioneer.arc.nasa.gov, and I'll try to respond. Next issue, I'll try to write some notes on the game-in-development or "How to get the most out of your playtesters without making them hate you". ====================================================================== Game Descriptions and Information ====================================================================== Galaxy -- Galaxy is a closed-ended strategic economic/military space simulation. The game takes place on a 100x100 2D map, with a few hundred planets and 20 to 50 players. Players compete to capture planets, which can be used for economic expansion. You may purchase technology in many areas, allowing your ships to fight harder and move faster. The author, Russell Wallace, is currently running 3 games, Rob McNeur is running 4 games, and a few other people are running a few other games. Watch for announcements of new games here. The rules and source code are available for ftp on ftp.erg.sri.com, directory /pub/pbm/galaxy. ---------------------------------------------------------------------- Star Empires -- Star Empires is a simple closed-ended strategic space-opera-style game. Every star system is adjacent to every other star system, so good communications with all other players is the key to staying alive. The author, Roger Lincoln, is currently working on version 3, which will hopefully include a new combat system and a 2D universe to replace the current trivial topology. When he starts a new game, we'll announce it here, or you can contact rhl@mbunix.mitre.org for more information. ---------------------------------------------------------------------- Celestial Empire -- Celestial Empire is a closed-ended strategic economic/military space simulation. Empires compete to capture worlds which produce many different types of resources, of which different amounts are needed to manufacture various items. Two games are currently in progress, and the author, Dougal Scott, plans to start 3 more games soon. The rules may be ftp-ed from yoyo.cc.monash.edu.au in the directory /pub/celemp. After you've read them, if you want to join a game, send your name to Dougal.Scott@fcit.monash.edu.au. ---------------------------------------------------------------------- Olympia -- Olympia is an open-ended economic/military simulation in a fantasy setting, with a little role-playing thrown in for good measure. The game is currently in beta-test, with turns running weekly and about 120 players involved, and it's been going for a little over 6 months now. For more information, send email with the word "HELP" to server@olympia.rt.com. You can retrieve the rules and back-issues of the Olympia Times newsletter from this server. I believe that the GM, Rich Skrenta, has a large number of requests to join the game that he has not processed yet, so don't hold your breath waiting to be added. ---------------------------------------------------------------------- Diplomacy -- The Diplomacy Adjudicator is a fully-computer moderated gamemaster for Avalon Hill's Diplomacy boardgame. To get more information from the moderator, send email with the word "HELP" in it to judge@u.washington.edu. Some information is available via FTP from milton.u.washington in the public/misc subdirectory. All of the information up for ftp is also available via the email server. As of June 1992, there are roughly 110 games in progress, and 675 players are registered. In addition to standard Diplomacy games, several variants are available for either normal or anonymous play. Diplomacy is covered by its own on-line magazine, which you can subscribe to either by reading the newsgroup bit.listserv.dipl-l, or by sending email with the phrase: subscribe dipl-l Your Name to the address listserv@mitvma.mit.edu ---------------------------------------------------------------------- Upcoming games: FTL: Space combat in a universe where Faster Than Light transport is possible but expensive, and where the Faster Than Light radio was never invented. The main challenge comes from dealing with information lag and delay reactions from units. Ship types are deliberately simple to keep other complexity from obscuring the main point of the game. A secondary consideration is resource management with the games only resource: fuel. Author: Melvin Nicholson. Tictactics: A repeat of Anthony Lovell's first net.game, with enhancements -- kind of like multi-player tic-tac-toe, only zanier. If you've never played in one of Tony's games, you won't understand, but you should join. ---------------------------------------------------------------------- I hope to start carrying information about available standby positions next issue. ====================================================================== Hints about sending Electronic Mail to other networks ====================================================================== OK, so now you're wondering, "I'm using FidoNet or CompuServe or FoobieBlech and those email addresses he keeps on talking about sure look funny to me!". Welcome to the modern world of networking. See, there's this big amorphous network called the Internet that lots of other networks, like FidoNet and CompuServe (but not GEnie, yet) are hooked up to. And you can send email between all of them, if you know the right incantations. Often size or cost limitations will keep you from being able to play games on another network, but at least you can send me letters to the editor. Compuserve: If your ID is [76515,1122] then your canonical Internet address will be 76515.1122@compuserve.com. The comma is replaced by a period, and that's your username. Compuserve.com is the name of your site. The .com on the end means that Compuserve is a business, and also generally means it's in the USA. This address is the one that non-compuserve people will use to talk to you. To send mail from CompuServe to the Internet, you use this sort of address: >INTERNET:gl8f@virginia.edu In this example, the ">INTERNET:" part indicates that the email is going to the Internet, and gl8f@virginia.edu is a normal Internet address (mine). Compuserve users have to pay extra for mail to or from the Internet. If you're a flat-fee user, the cost is 5 cents per 2500 characters, minimum 15 cents, and the first $9 per month is free. This can add up to a bit of money if you're playing Olympia, where a typical player might get 500k of email per month in 100 messages. In addition, the maximum size for a given message is 50kbytes, and most Internet games do not split their game turns into pieces if they are too large. But you can try. Diplomacy, for example, should be fine. To go from FidoNet to the Internet and back is a similar process. Actually, it's not so simple. I have a document that describes this, but since FidoNet seems to be a bit of an anarchy, you can't even send netmail from some nodes and others may not be configured properly to send mail to and from the Internet. And, when you send email, someone is paying to send it, or maybe there is a local gateway and it's free. So, you should probably talk to your sysop first to figure out what's going on. Anyway, the long and the short of it is this: FidoNet users can send mail to the Internet by sending normal netmail to the user UUCP, and then on the first line of the message, put the line: To: gl8f@virginia.edu To send email from the Internet to FidoNet, you take an address such as "Dale Webber at 1:105/55.0", and turn that into dale.weber@p0.f55.n105.z1.fidonet.org. Again, this is subject to the same caveats above about the gateway and the costs involved. From what I've gathered (but I haven't asked recently), they ask that you keep messages under 10k bytes and to only send two or three a day. This is a fairly small amount that would limit your ability to play Internet games, but you can still submit articles to this fanzine (hint, hint). If you want to avoid the limitations, yet don't know how to get directly on the Internet, I can mail you a list of public-access Unix sites with Internet email capabilities. Just send me a short note, using the above info, to "gl8f@virginia.edu", and I'll mail a copy back. ====================================================================== What's this "ftp" thing anyway? ====================================================================== ftp is an acronym for "file transfer protocol", and it is only directly available to the privileged few who are directly hooked to the Internet using heavy-duty hardware. There is a way to use ftp via email, but I haven't been able to find the information recently, mostly because I'm lazy. Check next issue. ====================================================================== Archives and subscriptions by email ====================================================================== PBEM will be eventually archived at "ftp.erg.sri.com", but this issue won't appear there until the end of this month. I will also be setting up a mailing list to distribute this magazine, but keep in mind that it will be posted on a regular basis to at least Usenet and probably CI$, so if you're reading it now, you probably won't need to get on the mailing list to receive it in the future. ====================================================================== PBEM is published twice monthly (I hope) by Greg Lindahl. Please redistribute it far and wide, but do not modify or delete any articles. PLEASE CONTRIBUTE! Our focus is primarily on free wargames, but we're interested in articles about anything relevant. Up