From: (Travis S Casey)
Subject: FAQ
Date: 21 Feb 1995 20:26:50 GMT
Organization: Florida State University Computer Science Department
Lines: 639
Approved: news-answers-request@MIT.Edu
Message-ID: <3idiaa$>
Xref: rec.answers:10348 news.answers:35799

Archive-name: games/design-FAQ
Last Updated: Feb. 21, 1994
Version:      1.54

REC.GAMES.DESIGN list of Frequently Asked Questions (FAQs).

This list is posted monthly to, rec.answers, and

The list is maintained by Travis Casey.  Any ideas for changes,
additions, or corrections are exceedingly welcome, and should be
directed to:

Please put "rgd FAQ" or something similar in your subject line, as
this is not the only FAQ I maintain.


TABLE OF CONTENTS  (New or changed items are marked with an * ).

Section 1 -- General Questions

     1.  What is the purpose of this group?
     2.  I'm writing a computer game in the BOGUS language, and I
	 need help!
     3.  Is this group just for RPG's?
     4.  What is proper etiquette for this group?
     5.  Are there any books on game design available?
  *  6.  Where can I find info about games on the net?
     7.  What is the address of company X?
     8.  I'm worried about protecting my ideas.  How do I copyright
	 my game?
     9.  Do you have any advice for a beginning game designer?

Section 2 -- RPG Questions

     1.  What is net.rpg's status?
     2.  What is net.rpg, for that matter?
     3.  What is FUDGE?
     4.  I'm trying to design an RPG.  What advice do you have?

Section 3 -- Computer Games

     1.  What is FRUA?
     2.  What's the best language to write a game in?

Section 4 -- Wargames and Boardgames

     1.  I'd like to get a wargame published.  What should I do?
  *  2.  FTP-able games.


Section 1 -- General Questions

1.  What is the purpose of this group?

     This group is meant for discussion of the design aspects of
     games--board games, computer games, role-playing games (RPG's),
     card games, or any other sort of game.  This is the place to
     post ideas for games, thoughts about systems, questions about
     how something should work in a game, or anything else about
     designing games.

2.  I'm writing a computer game in the BOGUS language, and I need

     This isn't a good place to look for help with computer
     languages.  The main focus of this group is on *design*, not
     *implementation*.  Try the *.lang.* and *.programmer groups
     first, especially

3.  Is this group just for RPG's?

     No.  As mentioned above, all sorts of games can be discussed

4.  What is proper etiquette for this group?

     It's basically the same as for any other group:  use informative
     subject lines, if you're posting about a specific thing, include
     what it is in the Subject: field (e.g. "FUDGE:" at the start of
     a Subject line for an article discussing the FUDGE game; see

     Don't get mad if someone doesn't like your pet idea:  listen to
     them and try to answer their points.  Remember, the purpose of
     this group is for us to discuss our ideas and improve upon them.

     Some of the things that shouldn't go here include announcements
     that you've made a new game (unless you're posting it up for
     review), questions about what a specific rule in a specific game
     is supposed to mean, announcements of things that don't relate
     to designing games (e.g., role-playing BBS's, FTP sites for
     games, etc.), and anything else that doesn't relate to game

5.  Are there any books on game design available?

     Some books that may be of assistance are:

     Crawford, Christopher; _The Art of Computer Game Design_
	  Osborne/McGraw-Hill.  No longer in print, but available
	  by writing the author c/o Osborne/McGraw-Hill.

     Dunnigan, James; _The Complete Wargame Handbook_
	  William Morrow and Co., ISBN 0-688-10368-5

     Dupuy, T. N.; _Numbers, Predictions, and War_
	  Hero Books, ISBN 0-915979-06-3

     Levy, David.  _Computer Gamesmanship_
          Simon & Schuster.  ISBN  0-67149-532-1
          Focuses on chess, checkers, and poker algorithms.

     Peek, Stephen; _Game Plan: The Game Inventor's Handbook_
	  Betterway Publications, ISBN 1-55870-315-2

     Perla, Peter; _The Art of Wargaming_
	  Nav. Inst. Press, ISBN 0-87021-050-5

     Prados, John; _Pentagon Games_

     Schuessler, Nick and Steve Jackson; _Game Design:  Volume One:
	  Theory and Practice_.  Steve Jackson Games.  No longer
	  in print, no further volumes were produced.

     Schmittberger, R. Wayne; _New Rules for Classic Games_

     Strategy & Tactics Magazine; _Wargame Design_
	  SPI, ISBN 0-917852-01-X

     Zocchi, Lou;  _How to Sell Your Game Design_
	  Gamescience (GS 10404)

     Note that these references have been garnered from the net, and
     I make no guarantee as to their accuracy.

6.  Where can I find info about games on the net?

     The best site that I currently know of is the Games Domain
     site on the Web.  There, you can find FAQ's for plenty of
     games, links to WWW sites for specific games, including ones
     run by the companies that put out the games, FTP links for
     games, a link to a list of RPG companies, and much, much
     more.  The address is:

7.  What is the address of Company X?

     Two lists of game company addresses are kept on Usenet, as far
     as I know; here's the info:

     The "Wargame Company E-mail Addresses" list is kept by  It is generally posted once a month to and

     Johnathan Sari (> maintains a
     "Complete Role-Playing Game Companies List," with the snail mail,
     email, and fax/phone numbers of most RPG companies.  This list
     is periodically posted to

8.   I'm worried about protecting my ideas.  How do I copyright
     my game?

     Well, I've got good news for you, and bad news.  First the

     If you're in the US, England, any Western European Country,
     Canada, or Australia, anything you write is automatically
     considered to by copyrighted under the terms of the Berne
     convention that all these countries adhere to.

     Now, the bad news:  a copyright does NOT protect your ideas.
     All a copyright does is protect the _expression_ of an idea.
     Thus, it's perfectly legal for someone to take all the rules
     of, say, Advanced Dungeons & Dragons, paraphrase them, and
     eliminate references to Dungeon Master and a few other terms
     TSR has trademarked, and sell the resulting product.

     That said, including a copyright notice in your work does
     give you one benefit:  it makes it easier to collect damages
     if someone does copy your material.  If there is no copyright
     notice, the copier can claim "innocent infringement" (that
     is, "I didn't know I couldn't copy it") and get off with a
     slap on the wrist.  In addition, you may want to look into
     registering your copyright.  In the US, at least, this
     provides definite proof that you wrote your material first,
     and allows you to collect money from copiers beyond simple

     To protect the ideas of a game, a patent would be necessary.
     In general, though, it's probably not worth the effort.  To
     qualify for a patent, a game must include physical components
     beyond simple board, dice, and rules, so that it can qualify
     as a "machine."  Thus, most games won't be eligible.  In
     addition, obtaining a patent is a long and complicated process
     which will almost certainly require you to hire a patent
     attorney, pay his/her large fees, and pay a large (and
     nonrefundable!) amount of money for a patent application.

     In my opinion, though, you needn't worry about protecting
     your ideas.  Chances are that if you've thought of it,
     someone else has as well.  Thus, refusing to discuss aspects
     of your game in order to protect your ideas isn't likely to
     keep anyone else from using that idea, and will prevent you
     from getting feedback which might help you improve the idea.

     (A bit from my own experience:  a few years ago, I came up
     with an idea for a die-rolling method for an RPG which I had
     never seen before and which greatly simplified the system I
     was making.  Since then, I've encountered at least three
     systems which also use the same method, none of whose authors
     could possibly have seen my work.)

     In general, games do not succeed because of any single "neat
     idea;" in fact, innovative games are less likely to succeed
     because most people do not want to learn large amounts of
     unfamiliar material.

9.   Do you have any advice for a beginning game designer?

     Sure.  Here's my version of the 10 commandments:


	 Never put something in a game or take something out just
	 on someone else's say-so.  If you and your friends like
	 it, chances are somebody else will too.

	 In the same vein, don't write a game on subject X just
	 because it's the current "hot topic."  Write games on
	 the things YOU like and hopefully your enthusiasm will
	 come through.


	 The best way to learn game design is to read a lot of
	 games, play a lot of games, analyze those games, and
	 design your own games or game extensions.  Since my
	 main experience is with RPG's, my examples will come
	 from them, but the idea is applicable to all kinds of

	 I've read tons of RPG's:  somewhere over 50 last time
	 I bothered to count.  I've played most of these, and
	 GM'ed over 30.  In addition to playing and gamemastering,
	 though, I also analyze games.  What makes this game good?
	 What's bad about it?  How would I modify it to make it
	 do this instead?  What areas does it represent well?
	 What areas does it represent poorly?  Why?

	 Having played and analyzed other games, I use this
	 knowledge to help with my own games.  For example, both
	 Champions and DC Heroes had good results using an
	 exponential attribute scale for superhero gaming.  Thus,
	 if I were going to design a superhero game, I would know
	 that an exponential scale can work very well.  This kind
	 of analysis gives you a bank of "proven" concepts to
	 work with.


	 Playtest your games.  Play them as much as possible;
	 get other people to play them, preferably without you
	 around, and talk to them afterwards.  (Having other
	 people play the game without your presence is called
	 blind-testing, BTW.)

	 In addition, think about your rules.  Consider
	 hypothetical situations and work out the probabilities
	 involved.  For example, if you're making an RPG, try
	 figuring out the percent chance an average person has
	 of hitting a man-sized target with a bow at a range of
	 1 meter, 5 meters, 10 meters, 50 meters, and 100 meters.
	 For a WWII game, examine your CRT and figure out the
	 probability that a small infantry unit will damage a tank
	 unit.  Repeat the calculations under different conditions;
	 different terrain, at night, etc.  This will help you
	 find places where you've made a mistake in your math or
	 made a bad assumption.


	 If you want to write a medieval fantasy game, read
	 medieval literature and history.  Read books about magic.
	 Read existing medieval fantasy games.  Similarly for
	 any other type of game; if you're making a game set
	 in the Vietnam war, read official histories of the war,
	 unofficial histories, and especially analyses of strategy
	 and tactics.

	 All this background is useful in several ways:  for one
	 thing, it will help you in creating realistic rules.  For
	 another, it lessens the chance that you will make a major
	 mistake in terminology or background.  And, of course,
	 the material is often interesting in itself.  If you're
	 not interested in learning about X, why are you writing
	 a game about it anyways?


	 Take a class in introductory probability and statistics.
	 Try reading some on the mathematical theory of games;
	 you probably won't find it useful, but it does provide
	 some perspective.  Polish your English (or whatever
	 language you plan to publish your game in); games are
	 much easier to learn when they're well-written, or at
	 least don't have a lot of grammatical errors.

	 If you want to do computer games and haven't already
	 taken any programming classes, take a few.  You may not
	 learn anything about how to program, but a good class
	 will teach you some things about how to organize a
	 program to make maintenance and bug-finding easier.

	 While you're at it, build up a "reference library."
	 This is a set of games and books on whatever subject
	 you're making your game on.  This will help immensely
	 when inspiration strikes at 3 AM and the library is

     6.  TAKE TIME OFF.

	 A game is like a child; when it's first born, it's
	 parents think it's perfect.  Take some time away from
	 your game to keep from getting burnt out and to get a
	 fresh perspective on it.  Repeat this from time to

     7.  KEEP RECORDS.

	 Make sure you have more than one copy of your game.  If
	 you're typing the rules on a computer, keep one copy on
	 the hard drive, one on a floppy, and a printout of a
	 fairly recent version (say, print it out once a month,
	 or once a week if you're working really fast).  You can
	 never have too many copies, since if it's any good,
	 friends will want copies to borrow/keep, and having all
	 these copies will greatly reduce the chance of losing it
	 all to a hard drive crash/lost notebook/whatever.

	 In the same vein, keep copies of older versions as well.
	 You may find in playtesting that your new idea isn't as
	 good as the old one was, and what are you going to do
	 now if you've trashed the old copy?  Keep at least one
	 copy of the last version around, in addition to the
	 copies of the current version.


	 Great rules and writing are nice, but a good visual
	 presentation will do wonders for your sales.  If you're
	 doing it yourself, learn something about desktop
	 publishing, and either find some ready-made illustrations
	 (for example, in the Dover clip art stuff or US
	 government publications) or find someone to draw a few
	 illustrations for you.

	 Find a printer and talk to him/her; discuss ways to do
	 what you want as inexpensively as possible.  A lower
	 price will help sales some, and lower expenses will
	 help your profits.


	 Don't ignore real life to work on your game.  If someone
	 doesn't like your game, don't take it personally.  Don't
	 get worried about people stealing your ideas.  Remember
	 rule #1 and have fun with what you're doing.

     10. THERE IS NO NUMBER 10.  :-)

     And, here's some extra advice from Tom Lehmann, president of
     Prism Games (thanks Tom!):

     A.  Incremental innovation often works best.  If everything in
	 your game is familiar, it will feel stale.  If everything is
	 very different, it may feel strange.  A single clever twist
	 on a familar theme is good but may result in your game being
	 viewed as a "variant"; TWO clever twists on familiar ideas
	 makes a game feel fresh while still easily accessible.  So
	 don't try to re-invent the wheel.  Instead, try to present
	 existing ideas cleanly and simply while extending a few key
	 concepts in new and interesting directions.

     B.  Revise and Polish your game ideas.  Testing serves not only
	 to clean up bugs in the game system and rules presentation
	 but also as the forum in which the game designer may
	 discover the game that he or she *really* wanted to put
	 forth, as opposed to the one they actually have put
	 together.  If you leave testing to the end, this discovery
	 may not do you any good.  If you test early and often with
	 an eye towards trying to figure out just what the game
	 really is about, you can often improve a game considerably.

	 "Alpha" testing can be viewed as asking the questions: "Is
	 there a game here?" and "Have I found it yet?"  "Beta"
	 testing can be viewed as asking the questions: "Is this the
	 best way to achieve this effect?", "Is this game mechanic
	 essential -- or can it be simplified or eliminated?" and
	 "Are all the major game systems working together to impart
	 the game experience I want?" "Gamma" testing asks the
	 question: "How can I improve game balance and presentation?"
	 Too many designers stop after Alpha (producing an intriguing
	 but shoddy game) or go from Alpha to Gamma, skipping Beta
	 (producing games that are ok but not great).  Often it is
	 neccessary to go beyond your immediate friends / local
	 gaming group early on to get enough critical analysis for
	 you to figure out what needs to be done to improve an
	 already pretty good game.

     And some more from me:

	 I've never had clear-cut "stages" of game testing when I
	 made games; instead, I tend to do a bit of each at every
	 stage.  I rework some systems, toss out some and replace
	 them, and improve the balance and presentation of others,
	 all more or less simultaneously.  Part of this comes from
	 the type of the main game that I'm working on... when doing
	 a universal RPG, you have to work on a piece at a time.

	 The key, though, is to find whatever works best for you.
	 Try it different ways until you find one that's comfortable,
	 then stick with that.


Section 2 -- RPG design

1.  What is net.rpg's current status?  [use net.rpg: in headers]

     Net.rpg is basically dead.  A net.rpg FAQ is kept by Magnus; 
     it contains a summary of some of the discussion that took
     place about net.rpg.  (Magnus can be reached at

2.  What is net.rpg, for that matter?

     Net.rpg isn't really anything yet.  The idea is to try to hammer
     out a free role-playing game using the gathered game design
     talent here on the net.

     There was a large amount of discussion at first, but almost no
     one could agree with anyone else on what net.rpg should be like.
     Thus, after some time, the discussion died down.  The general
     consensus now seems to be that net.rpg is an impossible dream;
     you're never going to get that many game designers to agree on
     anything, unless you use some type of committee approach ... and
     we all know how good things designed by committee usually are!

     However, the net.rpg discussion did generate a fair amount of 
     good ideas.

3.  What is FUDGE?  [use FUDGE: in headers]

     FUDGE is one of the products of the net.rpg discussion; not THE
     net.rpg, but a net.rpg.  FUDGE stands for Freeform Universal
     Donated Gaming Engine.  It's author is Steffan O'Sullivan, who
     semi-regularly posts a FUDGE FAQ.  (

     FUDGE is available from Wild Mule Games and via FTP
     from, in /pub/fudge.

     Wild Mule Games can be reached via snail mail at:

        P.O. Box 838
        Randolph, MA 02368-0838

     or via e-mail at

4.  I'm trying to design an RPG.  What advice do you have?

     1.  Don't think you're going to make money.  Chances are you

     2.  Don't think you're going to sell it to any established RPG
	 company; most of them don't want to dilute the market even
	 further by releasing yet another game.

     3.  If you are trying to create a game for sale, don't make it
	 too much like any established system... there are already
	 far too may AD&D look-alikes out there.  Try to come up with
	 something different.

     4.  Do make something *you* like... chances are that if you like
	 it, someone else will too.  However, if you try to listen to
	 the "experts" and follow their advice about how realistic
	 the game should be, how long combat should take, etc. and
	 end up with a game you don't like a lot, chances are no else
	 will like it too much either.  Besides, if you're going to
	 spend months or years writing something, shouldn't you have
	 fun doing it?

     So, what does that leave?  Well, if you're doing it for your own
     use, or your friend's use, go right ahead.  If you're trying to
     break into the RPG business, you'd probably do best writing
     articles for RPG magazines and sending them in to them.  The
     industry is pretty close-knit, and word does get around about
     who does good work (and does it on time!).


Section 3 -- Computer Games

1.  What is FRUA? [use FRUA: in headers]

     FRUA is short for Forgotten Realms Unlimited Adventures, a
     program from SSI for creating computer adventures like their
     AD&D series.  FRUA is not shareware or freeware; you should be
     able to order it from just about any software store.  There is
     a mailing list devoted to FRUA (address?).

2.  What's the best language to write a game in?

     That's a complicated question.  It depends on several things:
     your knowledge of computer languages, what kind of game you're
     writing, what computer you're writing it for, and what tools you
     have access to.

     My first advice would be to program it in a language you are
     familiar with, and the more the better.  There's nothing worse
     than spending most of your time looking in manuals instead of
     writing code.  Second, go with something widely used (e.g., C).
     The more widely used your language is, the better the chance is
     that you'll be able to find someone who can help you if you need

     With the preceding in mind, if you're writing a game for PC,
     Unix, or Macintosh platforms, I'd recommend C.  It's a powerful
     language, good implementations exist for all three of these
     platforms, and there are large numbers of C programmers out
     there who can help you.


Section 4 -- Wargames and Boardgames

1.  I'd like to get a wargame published.  What should I do?

     Here's some advice from Kerry Anderson, quoted with his

     ---- QUOTED TEXT BEGINS ----

     From: (Kerry Anderson)

     I've published three games through other companies.  These are
     MARINE:2002 (Yaquinto,1980), MOONBASE CLAVIUS (Taskforce, 1982),
     and CLASH OF EMPIRES (Wargamer issue 58?).  It's not easy and
     you're at the mercy of the company if they decide to publish.

     The first step is to write the best letter you can to these
     companies, giving the impression you know what you know what
     you're doing and that the game suits their line and that it will
     be a hot seller.  Expect to get no answer from some, "thanks but
     no thanks" from most, and "yes, send us a copy to evaluate" from
     a few.

     If you get the chance to send in the game, put every effort into
     producing a polished, final copy.  Give them the feeling that
     you are a professional and that you know what you are doing.
     Put great effort into the graphic quality of the game to catch
     their eye.  Write and edit the rules to death and print up the
     final product on a laser printer.  You must make the game as
     appealing as you can.  If the game is poorly put together, they
     might not want to bother trying to figure it out and reject it

     If the game is accepted, expect the worst in the final product.
     Let me describe my experiences:

     MARINE:2002 was my first game and admittedly was poorly put
     together.  They accepted it, but changed it inside and out.  I
     got bumped from "game designer" to "game concept".  Admittedly,
     it was a slick product when they finished it but it doesn't
     always turn out that way.

     MOONBASE:CLAVIUS was a polished game.  I got someone to edit and
     type the rules.  I sent it to Avalon Hill (who, by the way,
     rarely look at unknown designers) and it was rejected.  I sent
     it to Taskforce who immediately accepted it.  After about a
     year, they put it into one of their pocket games and decided to
     throw in a few changes like reversing the sequence of play to
     fight-move.  It destroyed the game but what could I do now?

     AUGUST 1914 was left virtually intact.  They even used my rules
     for the final text (with a couple of small changes).
     Regrettably, The map was abysmal and the counters hard to read.
     It drifted off into obscurity.

     As you can see, trying to sell games to other companies can be
     disheartening.  Expect a lot of rejection.  While I do have
     three games published, I've had several of my games rejected,
     such as VIMY RIDGE (for being too realistic) and THE BATTLE OF
     ARMAGEDDON (for not being apocalyptic enough) by XTR - both game
     prototypes UNPLAYED (am I bitter?).  You may be better off
     trying to do it yourself.  This is something I'm seriously
     thinking about now.

     Kerry Anderson

     ---- QUOTED TEXT ENDS ----

2.  FTP-able boardgames.

     There are a few boardgames available by FTP.  Among them are:

     BARNARD'S STAR, by Kerry Anderson

       Available from as /pub/postscript/
       This is a pkzipped set of EPS files which contain all the
       components of the game.  To use it, you'll need something which
       can unzip files and a postscript printer.
       BARNARD'S STAR is a science fiction game on an attack on an 
       outpost on a moon in the Barnard's Star system.  Units are company
       sized and the scale is 100 km per hex and 10 hours per turn.  The
       game contains lots of neat SF chrome including bombardment from
       space, planetary defenses, jump troops, teleporation, etc.

     BARONS OF FYN, by Joshua Howard

       Available from, in directory mac/game/card.
       The file is a mac compressed postscript archive.

       Barons of Fyn is a card game, produced by Bone Games, which
       also has other ftp-able games.
Travis S. Casey  		 		   
FAQ maintainer for