PBEM v93 n01 (15Jan83)

======================================================================
Converting Face-to-face games into PB(e)M's              Mel Nicholson
======================================================================

[ Preface: Sorry I missed a few issues. Thanks to all those who sent
in fan mail wondering where I'd gone.  Here is the long-awaited game
conversion article. Enjoy. ]

There are many times when it would be nice to have your favorite
face-to-face games available in an email format.  Sometimes you've
moved to a new area and don't have anyone around to play with, or
perhaps you have schedule conflicts which make it too hard to get
together for a gaming session with your friends. Maybe you want a
wider venue of opponents, or perhaps you're under quarantine at the
local hospital or sanatorium.

Whatever the reason, it *is* possible to make your favorite game into
a PBEM, and this article is designed to show you how.  Before you get
too excited, though, I should warn you that there is a lot of work
involved.  Start by imagining largest amount of time that this process
could possibly take.  Double that, and unless you're a lot more
pessimistic than I was, you still are going to be short.  So unless
you have a *lot* of time available, you will need to think twice about
running a game, as the cost in time and enthusiasm is very real, and
it really hurts the gaming community when a person starts a game in a
half-assed way, and later is forced to abandon his players, who become
frustrated with the PBEM concept as a whole.

Despite the hurdles, it *is* possible to run a successful PBEM game,
and many people have been able to do so quite successfully, as my own
game (SPARF) and many converted games (Mark Purtil's Republic of
Rome(tm) comes to mind as one of the successful conversions) attest
to.  Nevertheless, there have been some disastrous failures,
and there are many choices which go into deciding whether *your*
game will stand or fall.

The first and most important choice, when deciding which game to put
into PBEM form, is the choice of game.  Some games just weren't cut
out for PBEM.  One feature to avoid when selecting a game for PBEM
form is a game in which there is involved trading or negotiations
which require detailed interactions in a sequential form.  For
example, if a game has an important trading phase in which large
numbers of items change hands, and in which small details of the
trades are significant, and which lead to further trades, then this
game is probably a poor choice. Negotiations among players in which
only a single item need be resolved, rather than an ordered sequence
of transactions, is much easier.  This is why Diplomacy, in which a
single set of orders result from the negotiations, is so successful in
PBEM form while other games which involve many ordered transactions
have failed.

Another danger is a poorly designed set of rules, with loopholes and
ambiguities that each gaming circle will have solved in its own way.
Because PBEM audiences generally draw from a wide base, wherever
ambiguity exists, contradictory solutions will exist.  For this
reason, it is important that you be familiar with the game.  You
should also have a good eye for ambiguity, so that these sorts of
problems can be headed off and reduced.  I personally have seen a game
of PBEM Pax Brittanica turn into a total disaster because of
arguments. Also, if the moderator has a good feel for justice and an
ample supply of patience and tact, he or she can often reduce the blow
which these problems inflict by keeping a level head.

There are also some problems with live gaming that vanish in the PBEM
format; this makes some games good candidates, and perhaps even
improve them with the transition.  Since the pace of PBEMs is slower,
problems which arise from having to sit and wait for other players to
hurry up and make their move just don't arise.  Also, since the players
need not all be present for the whole game, one player being
eliminated early doesn't pose the awkward social situation common to
face-to-face gaming.  Finally, since the transactions are done on a
computer, the automation of bookkeeping which might otherwise bog the
game down is much easier to accomplish.

After the game selection is made, the primary questions facing the
converter involve HOW the player will interact with the moderator
(whether that be a person or program). A good starting strategy for
this is to consider the sequence of play of the game and think of all
the situations in which a player has a choice. For each choice,
determine all the information which the player may use to help make
that choice, and identify all the cases where some other player's
choice provides that information. If this is an interesting game, it
is likely to be a very long list with many interactions.  An
example should help to clarify the dark art of list-making.  The game
we will use is the board-game Monopoly, which all of our US readers
should be familiar with, and which is available elsewhere in the world
under other names. The object of the game is to acquire the most
money, and the players do this by moving around the game board, buying
properties, and building buildings on the properties to charge the
other players rent.

Here is our first draft of the list of player choices:

	Buy an unowned property when it is landed upon.
	Bid on an unowned property which is up for auction.
	Mortgage or unmortgage a property.
	Build or demolish buildings on a monopoly.
	Pay to get out of jail.
	Collect or refuse rent.
	Make a binding deal or transaction with another player.

Gee.  There are "only" seven things a player can do.  Sound simple?  I
can guarantee it won't be, because wherever the word "deal" shows up,
you have a major problem. Deals in Monopoly must be valid and are
binding, and so keeping track of them would be a nightmare in a PBEM
form. I'm afraid that this problem is going to take more time to solve
and involve more philosophical questions than fit into the scope of
this article, so for the sake of expediency, we'll pretend all deals
are illegal.

Next, we make a list of the information which must be available to all
the players:

	Position on the board of all markers
	Who just moved, and whether they rolled doubles
	$$$ owned by each player
	Ownership and mortgage status of all property
	Current high bid for a given property (during auctions)

Furthermore, there are things a player must NOT know before a given
decision is made.  Rather than going through the whole list, I will
just give one example: a player may not know his or her dice roll
before deciding whether to pay to get out of jail.

Using the list to determine when information may be released, plus the
timing constraints asserted by the rules, we can write a general
timeline for the game.  Once this timeline has been worked out, group
as many decisions as you can into blocks (which we'll call
"interactions" for want of a better name), making sure that no
decision in a block requires a player to have information that another
decision in the same block prevents him from having. For example, the
decision whether to buy St. James at face value cannot be grouped into
the same interaction with the decision of whether to pay to get out of
Jail, as the former requires knowledge of the die roll, while the
latter requires ignorance of the die roll.

Once you have all of the interactions and timing considerations worked
out, and you have developed any needed protocols for communication and
automated whatever functions you want computer help with, you are
ready to get your players and go, right?  Well, almost.  Next, you
need to document all those considerations and protocols for your
players. Trust me, you NEED to do this, especially in a game with lots
of players, or else you'll end up answering the same question
repeatedly. Once you've answered it twice, you might as well have
written it down once in the rules.

All in all, the experience of preparing a game and converting it for
PBEM play is a good exercise in game design and may yield a lot of
insight into how games work and why they fail or succeed.  In
particular, this is a very good way to force yourself to break a set
of rules down into the bare essentials of how the game proceeds and
how the rules interact at the level of player interaction and timing.
Good luck, and see you next issue, when I'll try to talk about some of
the principles of game modification, especially when issue of
continuity arise with a pre-existing database.