This article is about my first exposure to PBM, and how it inspired me to develop the game Olympia. I also mention a few of Olympia's features, and explain why Olympia can be played only via electronic mail.
Olympia's rulebook is up to 97 pages, not counting the lore sheets, so obviously there's a lot I don't mention here. For more information about Olympia, send a note to: info@pbm.com.
My first exposure to PBM was in college, when I saw a friend's turn report for a game (long since gone) called T'Nyc, which he was playing via electronic mail. His turn was huge. The printout looked like it was a half-inch thick.
I learned that he was in control of several entities who lived in a vast simulation. His units could move, study, fight, explore, ride on ships, and talk to other characters. He provided a list of orders to each of his units, which they would follow when the turn ran each week. There was even a game newsletter, where players wrote (surprisingly passionately, I thought) about the lives of their characters.
The scope of the simulation was massive. I had trouble getting my mind around it. My friend controlled several units, but there were thousands more, some controlled by other players, some by the game itself. The game's map was so large, my friend explained, that there was no way a player could hope to explore it all. Characters could learn skills, but they were expensive, and took time to acquire, so one could never learn them all, only specialize in a few areas.
As a boy I built model train sets. Planning the layout, making scenery, laying track, and building mountains -- one could play god, and watch the result come to life when it was finished.
Moving parts. Complexity. I would always cram as much track into the layout as would fit. I used any accessories I could get my hands on. Automated track switches, a remote control crane, a car with a milkman who came out and delivered a jug of milk, an electric coal loader.
But here, in the computer, was a virtual world with 100 times as many parts as my model railroad. And rather than just playing with one or two friends, as I had with my toy trains, the PBM format allowed interaction with hundreds of players at once. My mind reeled at the potential. I knew that I had to create a PBM simulation of my own.
It took several attempts before I got a working PBM off the ground. Although I had experience programming multiplayer text adventures, in many ways creating a PBM turned out to be harder. In addition to the challenge of creating a balanced game design, the project required coding feats to implement synchronized order processing, NPC driven markets, realistic weather, and complex movement mechanics (travel by foot, horse, carrying possessions on oxen or carts, sailing on ships).
Olympia (a name suggested by the college friend) grew in size, and quickly became the largest program I had ever written.
Finally it was complete enough for players to enter. I posted a call for playtesters, with a stern warning that there would be many bugs, that it would be no fun to play, and that I would intentionally ruin player turns.
Of course I had no intention of ruining turns (on purpose, anyway), but I wanted to prepare my playtesters for the worst. To my astonishment, I had 30 players within the first week, and the number soon swelled to 140, at which point I stopped accepting signups. Apparently demand for fantasy PBEMs was not lacking. Olympians waged war, founded guilds, slayed monsters, built fortunes, and chronicled it all with detailed prose in the weekly Olympia Times.
Then the economy blew up. Some players, exploiting exponential growth tricks, found themselves making more money than they knew how to spend. Units became so common that players stopped bothering to name them. Several fixes were tried, but none did the job. After a year of testing, I shut Olympia down and embarked on a rewrite and redesign.
Fred Brooks describes in his book The Mythical Man Month what he calls the "second system effect". A designer, fresh off the success of his last project, decides to create the system he really wanted to make the first time. The first time he was unsure of himself, and so was cautious with the design, leaving out difficult features. Now, rich with experience, he loads the new design with every feature imaginable, all but assuring failure.
I was aware of the second system effect. In fact, I was haunted by the very specter of the game which had launched my interest in PBM. T'Nyc shut down after similar imbalances caused its economy to spin out of control. Its designers withdrew to devote their effort to T'Nyc's successor, but were never heard from again.
Furthermore, without the enthusiasm of players in a running game to encourage me, I was concerned that I would lose interest or become discouraged.
Nevertheless, I felt that I had learned much about game design and PBM coding from the first Olympia, and was certain that another attempt, from scratch, would produce a much better game.
Experience did not make the rewrite easier. In fact, the goal to improve upon the design of the first game was a heavy burden. A year passed before the new Olympia was ready for players to enter, and many months of playtesting before it gained polish and maturity.
The result, however, was everything I had hoped for. Veterans of the earlier version declared the new Olympia a great improvement. The troublesome economic flaws were gone. And the game world was more detailed and intricate than ever.
Since I originally approached Olympia as a simulation, not as an abstract game, I wanted to model time realistically. Many games use "phases" to order the events of the turn. Production phase, movement phase, item transfer phase, etc. This is easier to code, but realism and many interesting play options are lost in the abstraction.
Instead of phases, Olympia has 30 game days per turn. Orders may take anywhere from one day or less to 60 days or more. Giving an item to another character takes no time; characters can do as many GIVEs each turn as they like. Time for movement varies from several days to several 7-day weeks. The turn report shows the day-by-day progress of the player's units. Orders which don't finish by the end of the turn simply continue into the next.
Olympia's map consists of locations called provinces, arranged on a grid. The rewrite added the ability for interior locations, such as cities, sacred groves, ruins, graveyards, etc. to exist within provinces. These sublocations may be hidden, requiring exploration to find.
Several nice rule mechanics naturally follow from the existence of sublocations. An army can lay siege to a city by occupying the surrounding province. Characters may enter hidden interior locations and observe units in the outer province, while not being seen themselves. A character can lay claim to a valuable sublocation, such as a mine, without having to control the entire province. Units just passing through a province won't learn all of its secrets. Knowledge of a province's features comes only from spending time and effort at exploration.
Recently several areas of the world not directly connected to the regular map were added. These include Hades, Faery, and the Cloudlands. Certain magical skills are offered only in these regions, so finding the ways into these strange lands is an important challenge.
In the first Olympia, characters were hired with gold. Rich players therefore ended up controlling many units -- too many. This is not surprising in hindsight, but at the time I didn't forsee the difficulty balancing ways to earn money with ways to spend it. Any limits I placed on the rich players hurt poor ones even more. Olympia's cities became crowded, life was cheap, and the atmosphere of the game suffered.
A playtester suggested that Olympia should adopt the model used in popular Hollywood movies, where the focus of attention is on a few well-developed foreground characters, with other less detailed people in the background. In this way, players could invest their effort into a few key units, but still control large groups of soldiers and workers.
These foreground characters are called nobles. There are tight limits on their creation, so new players generally have 3-5 nobles, while an advanced player will have 15 or so.
Nobles lead common men into battle. The noble uses his skills, spells, and any rare magical weapons or armor he has, while the accompanying fighters possess varying combat ratings depending on the amount of training, weapons and armor invested in them.
Units in T'Nyc were arranged into a chain of command. Each character reported to another character, with the player character at the top of the pyramid, or "faction tree". Successfully bribing a character got every other unit sworn beneath that character as well. Learning the identity of the player behind a character required tracing the chain of command to the top.
I fell in love with the idea of the command hierarchy. It was wonderfully complex, yet simple to understand and implement. However, many playtesters detested the faction trees, arguing that they forced players to perform mindless busywork to keep track of chains of command.
I was convinced they were right when I learned that some players, who were talented programmers, had written a tool to automatically keep track of the faction trees for any units they encountered. These players had a natural advantage over others who were not willing to do the work manually. Instead of emphasizing diplomacy or strategy, faction trees favored those with the best report analysis tools.
I eliminated the command hierarchy, and replaced it with a system where characters could have one of several loyalties to the player (oath, fear or contract). The more invested in a unit's loyalty, the less likely it was to succumb to bribery or persuasion attempts. This kept open play options based on loyalty, and preserved the atmosphere, but eliminated tedious bookkeeping.
Email has natural advantages over paper mail. It's fast, cheap, and if you already use a computer to type your letters, easier to send.
For a play-by-mail game, the benefits are even greater. Orders don't have to be typed into the computer, eliminating a costly and error-prone step. Turn reports don't have to be printed and stuffed into envelopes. Olympia sends an automatic acknowledgment seconds after receiving orders from a player, listing any errors found. This helps to catch simple mistakes which might otherwise ruin turns, and the fast acknowledgments let the players know their orders arrived safe at pbm.com in time for the turn.
The advantages aren't only for the moderator, however. Player diplomacy enjoys these benefits too. Electronic mailing lists let every member of an alliance stay informed and participate in discussions. Olympia also provides an email forwarder, so a quick note can be sent to any character, even if the identity of the character's player isn't known.
A pace of one turn per week is comfortable for on-line players (or even a bit slow). A similar pace with paper mail would be difficult to maintain, especially in a game with simultaneous turn processing.
Metrics such as program line-counts are of dubious merit, but since many are often curious about these details, I will mention them here.
The Olympia engine is written in C, is approximately 45,000 lines long, and runs under Unix. The map generator is another 3,000 lines. A playtest game with 40 players runs in about 5 minutes on a 486/33, and consumes 12 megabytes of RAM.
During a turn run, the engine loads the entire database into memory, works through the turn, then saves all of the player events and the updated database back to disk. A back-end processor generates the final turn reports which the players see.
The program tries to avoid imposing arbitrary limits (or at least ones not suggested by the game rules). A strong enough character could hold every item in the game, for instance. Every unit in the game could move into the same province, and even band together into one huge army. The Olympia engine is bounded only by Unix's virtual memory (I currently have 40MB configured, but this can easily be expanded.)
Shadow Island Games
info@pbm.com
P.O. Box 390983
Mountain View, CA 94039-0983