Path: bloom-beacon.mit.edu!hookup!news.mathworks.com!news.duke.edu!convex!cs.utexas.edu!howland.reston.ans.net!gatech!mailer.fsu.edu!sed!casey
From: casey@sed.cs.fsu.edu (Travis S Casey)
Newsgroups: rec.games.design,rec.answers,news.answers
Subject: rec.games.design FAQ
Followup-To: rec.games.design
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$g3b@mailer.fsu.edu>
Reply-To: casey@nu.cs.fsu.edu
NNTP-Posting-Host: sed.cs.fsu.edu
Xref: bloom-beacon.mit.edu rec.games.design:7316 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.games.design, rec.answers, and
news.answers.
The list is maintained by Travis Casey. Any ideas for changes,
additions, or corrections are exceedingly welcome, and should be
directed to:
casey@cs.fsu.edu
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
help!
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 rec.games.programmer.
3. Is this group just for RPG's?
No. As mentioned above, all sorts of games can be discussed
here.
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
below)
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
DESIGN.
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:
http://wcl-rs.bham.ac.uk/GamesDomain
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
jrboeke@uci.edu. It is generally posted once a month to
rec.games.board and rec.games.design.
Johnathan Sari (sruge@buck.cqs.washington.edu> 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 rec.games.frp.misc.
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
good:
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
damages.
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:
1. WRITE GAMES YOU LIKE.
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.
2. EXPERIENCE IS THE BEST TEACHER.
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
games.
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.
3. TEST, TEST, AND TEST SOME MORE.
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.
4. LEARN YOUR BACKGROUND.
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?
5. FORMAL EDUCATION.
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
closed.
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
time.
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.
8. DON'T FORGET THE INCIDENTALS.
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.
9. REMEMBER, IT'S ONLY A GAME.
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
magnus@ii.ui.no)
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. (sos@oz.plymouth.edu)
FUDGE is available from Wild Mule Games and via FTP
from ftp.csua.berkeley.edu, 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
wildmule@delphi.com
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
won't.
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
it.
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
permission.
---- QUOTED TEXT BEGINS ----
From: kanderso@nofc.forestry.ca (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
immediately.
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 sunbane.engrg.uwo.ca as /pub/postscript/bseps.zip.
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 archive.umich.edu, 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 rec.games.design