ftp.pasteur.org/FAQ//ftp-pasteur-org-FAQ.zip/FAQ/games/design-FAQ

Text File | 2004-04-30 | 35KB | 701 lines

Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!newsfeed.stanford.edu!nntp.cs.ubc.ca!torn!snoopy.risq.qc.ca!news.ccs.queensu.ca!spamcop.net!dalamb
From: David Alex Lamb <[e-mail]>
Newsgroups: rec.games.design,news.answers,rec.answers
Subject: Designing Games: rec.games.design FAQ [monthly]
Supersedes: <[e-mail]>
Followup-To: rec.games.design
Date: 30 Apr 2004 09:25:01 GMT
Organization: Computing and Information Science, Queen's University at Kingston, Ontario,  K7L 3N6, Canada
Lines: 681
Approved: [e-mail]
Distribution: world
Expires: 13 Jun 2004 09:25:01 GMT
Message-ID: <[e-mail]>
Reply-To: [e-mail]
NNTP-Posting-Host: highnoon.cs.queensu.ca
Keywords: FAQ, game design
Originator: [e-mail]
Xref: senator-bedfellow.mit.edu rec.games.design:43371 news.answers:270616 rec.answers:86845

Archive-name: games/design-FAQ
URL: http://www.cs.queensu.ca/~dalamb/Games/design/design.html
Version: 3.5
Last-Modified: 2003 February 25 09:21:11 (Tuesday)

Copyright 1997 Travis S. Casey.  Revisions since 1997 Copyright
1998,2002,2003 David Alex Lamb.  Sections 2.4-2.5 Copyright Tom Sloper
(used by permission).

This document is an introduction to the Usenet newsgroup
rec.games.design; it's purpose is to help new readers get up to speed in
the group, by informing them about the group itself and about topics
that have come up often in the group.  It was created by Travis S Casey
<[e-mail]> and is currently maintained by David Alex Lamb
<[e-mail]>; at the moment most of the references to "I" mean
Travis.

The FAQ is posted monthly to rec.games.design, news.answers, and
rec.answers.  The most recent HTML version can be found on the web at
http://www.cs.queensu.ca/~dalamb/Games/design/design.html.  If you don't
have web access, you can contact me at [e-mail] to get a
current copy of this FAQ.  This is also the address for any corrections
or ideas for changes and additions.  Please put "rgd FAQ" or something
similar in the subject line of any mail about the FAQ, to help me sort
through my mail.

1 About rec.games.design
1.1 What's this group for?  Just what is 'game design?'
1.2 Are there any rules I should follow when posting to this group?
2 Questions & Answers about Games and Game Design
2.1 Do you have any advice for a beginning game designer?
2.2 How can I protect my ideas?
2.3 What language/graphics program/etc. should I use?
2.4 How do I get a job in game design?
2.5 Can I get a company to publish my game?
3 Finding More Information
3.1 Game design info on the net
3.2 Books on game design
3.3 Magazines
3.4 Finding games on the net

Section 1: About rec.games.design

1.1 What's this group for?  Just what is 'game design?'  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.
The simplest way to tell whether something is part of "game design" or
not is to ask a question:  If I changed this part of the game, would it
still be the same game?  If the answer is yes, it's not a design
element.

For example, let's take chess.  If you change the shape of the board or
how many squares there are, you've changed the game, so these are design
elements.  However, if you change the shapes of the pieces or the colors
of the squares, it's still the same game, so these aren't design
elements.

For a computer example, take Mortal Kombat.  If you change the results
given by different combinations of moves, you've got a different game,
so this is part of the game design.  Changing the artwork could make it
a different game, depending on how you changed it, so this is part of
the game design.  Writing the program in a different language wouldn't
change the game, so the programming language used isn't part of the game
design.

Note that I consider the artwork for Mortal Kombat part of the game
design, but I don't consider the shapes of the pieces in chess part of
the design.  Why is this?  It's because of a difference in the goals of
the two games:  chess is an abstract game; the associations of certain
pieces with certain movement patterns is arbitrary.  The shapes of the
pieces aren't meant to invoke a mood -- they simply help the players
keep straight which piece can do what.  Mortal Kombat is designed to
invoke a particular mood:  the idea of an ultimate martial arts
confrontation.  There's a lot of leeway in establishing that mood, but
changing the characters to all look like clowns and giving their special
abilities appearances such as throwing cream pies at each other would
change the mood completely.

Finally, it should be noted that in general, any game that can be done
on a computer can be done without one.  The only difference in designing
a computer game is that some things that are too slow or prone to human
error for practical play without a computer can be done practically.
(For example, Doom could be done as a non-computer game; however, you'd
have to lose the real-time play, and one or more RPG- style game masters
would need to be involved.)

1.2 Are there any rules I should follow when posting to this group?
There are two basic rules you should follow:

  -  Stay on-topic.

  -  Be polite.

Each of these is a bit more complicated than it sounds, so here are the
detailed versions:

Staying on-topic means that before you post something, you should
consider whether this is the best group for it.  For example, if you
want to talk about game programming, rec.games.programmer is a better
group for it.  If you want to talk about AI in games, comp.games.ai is
better.  If you're asking for cheat codes for a video game,
rec.games.video is better.  If you're talking about how these things
relate to game design, (e.g., "Should cheat codes be left enabled in
release versions of games?  Doesn't it give an unfair advantage to those
players who can get them?")  then you've come to the right place.

Some things that, in a narrow sense, are off-topic are considered OK.
Generally, this applies to any related topic for which there isn't a
more appropriate group.  For example, discussions about game marketing
take place here because there isn't a group for it, and those interested
in designing games are often interested in marketing them.

Just because something's already been posted in the group doesn't mean
you should follow up to it; if it's off-topic, you should either ignore
it, follow up and redirect followups to your post to an appropriate
newsgroup, or reply by email.  This is especially important with
inflammatory posts and ads; usually, the people who post these don't
even read most of the newsgroups they post to, so following up only
creates more trash.

Lastly, if the topic of a discussion changes, but it's still on-topic,
the subject line should be changed.  For example, if the discussion
about whether cheat codes should be left enabled in games branches off
into discussing whether there should be secret move combinations with
special effects, the subject might need a change from "Should games have
cheat codes?"  to "Should games have special moves?"

Being polite includes the normal things:  don't insult people, don't
throw tantrums because someone doesn't like your pet idea, etc.  In a
Usenet context, however, being polite includes several other things:

  -  Use a good subject line.  I can't count how many posts I've seen
     that had subjects like "Questions about game design."  Is this
     someone who's asking questions?  Offering to answer them?  *What*
     questions?  It's impossible to know what the poster's talking about
     without reading the message.  Something that can help is to put the
     general area you're talking about in brackets, followed by a more
     specific subject:
     [rpgs] How many attributes?
     [computer] Is real-time better?
     [marketing] Does anyone have distributor addresses?

  -  Use good spelling and punctuation, including paragraph breaks.
     You're the only one who has to write your message; hundreds or
     thousands of people have to read it.  It's better for one poster to
     take five extra minutes to post something that can be easily
     understood than for a hundred readers to take five extra seconds
     each reading a message; the first uses only 300 people-seconds, the
     second 500.

  -  Conversely, don't flame people on spelling and punctuation.  Asking
     for clarification is OK; saying, "Only an idiot wouldn't know the
     difference between affect and effect" isn't.  People make typing
     mistakes; people post when they're dead tired; some posters are
     dyslexic; others only have English as a second language.  We're all
     only human.

  -  Don't waste bandwidth.  Anything that you post is copied to
     thousands of servers, taking up time to transfer and disk space to
     store.  If you've got something large that you don't think everyone
     will be interested in, put it on a web site or ftp site and post a
     pointer to it if you can.

Above all, remember that your purpose should be to communicate with
others.  Learn to use your software so you can do that.  For example,
some newsreaders by default post an HTML version of your post.  For most
readers, that's harder to read than just plain text, so if your
newsreader does this, you need to learn to turn it off.

Section 2: Questions & Answers about Games and Game Design

2.1 Do you have any advice for a beginning game designer?
Sure. Here's my version of the 10 commandments:

**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.

**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 70 last time I bothered to
count.  I've  played most of these, and GM'ed over 40. 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.

Changing elements in or adding elements to an existing game lets you
play with game design without having to create a game from scratch.
Further, this kind of experience can give you a feel for game balance --
in what ways can you change the game and still have it be fun for all
the players?

**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; it helps to make sure
that the rules of your game or the interface for a computer game is
really as easy to understand as you want it to be.  If you're there,
it's too tempting to tell people what the rule means or show them what
button they need to push.)

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 wargame, 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.

Test even dumb ideas.  You may think that no one in their right mind
would have their character take on a master swordsman armed only with a
spoon, but there are lots of gamers who aren't in their right minds.  If
your game lets characters do things that couldn't possibly work in real
life, you have holes to fix.

**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?

**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.

**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.

**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.

**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.

**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.
**There Is No Number 10. :-)**.  And, here's some extra advice from Tom
Lehmann, president of Prism Games (thanks Tom!):

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.

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.

2.2 How can I protect my ideas?  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 be
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.

For more information, try these web sites:

  -  Ten Big Myths About Copyright Explained
     (http://www.clari.net/brad/copymyths.html)

  -  The Copyright Website (http://www.benedict.com/)

2.3 What language/graphics program/etc. should I use?  Please note:
rec.games.design is not the place to discuss game programming;
rec.games.programmer is for that.  In spite of this, these questions are
asked here so often that some of them are answered here in this FAQ.

Language:

You're almost always best off to program a game in whatever computer
language you already know best; that way, you can spend more time on
your game, and less reading manuals.  A secondary consideration is the
tools that are available for your chosen language; it's much easier to
find game programming tools if you're using BASIC or C than if you're
using Fortran or COBOL.

Always keeping the preceding in mind, C is generally considered to be
the preferred language for game programming today.  It's a powerful
language, good implementations exist on many platforms, there are many
tools available for it, and most implementations allow easy interface to
assembly language routines for any functions that need the highest
possible speed.  Once you're comfortable with C, you may want to learn
C++ as well; object-oriented techniques can be useful in programming
games.

Graphics Programs/Art:
Again, whatever you use, you need to be comfortable with it.  You'll
also need to consider what graphics file formats your graphics program
can work with, and what format or formats any game toolkit you're using
will work with.

If you're producing your game as a demo to show to a game company, you
don't have to worry too much about art; the art will almost certainly be
changed anyways.  What you're really trying to do is give them an idea
of what kind of art the game should have.  Thus, you could use clip art,
modified pieces of art from other sources, and similar resources.

A couple of hints:  It's often a good idea to draw your art larger than
you're going to need it to be, then reduce it.  If you're as hopeless at
drawing as I am, you can use 3D modeling software to create and render
models, and then make your artwork from those.

2.4 How do I get a job in game design?

Design some games. Execute the designs into awesome-looking
presentations.  Together with a well-written resume, your designs will
help you get your foot in the door for an interview.  Interview for any
job that's available and for which you are qualified -- you just want to
get into the industry.

It's unlikely that anybody will want to actually make your ideas into
games, or give you the title "game designer," if you don't have any
finished released games under your belt.  But once you get hired, you're
in the biz -- and you can learn & grow within it, and eventually make
other original designs.

Research game companies the hard way: go to the library, search the
internet, read newsgroup posts.  Don't bother asking newsgroup readers
to spoonfeed you the information -- you won't like the taste of the
stuff on the spoon.  Game designers are more resourceful and creative
than that.  Do the research yourself.  You'll get better results.  And
it's part of what game designers do anyway.

Focus on companies that make the kind of games you want to work on.  If
there are no such companies in your area, you will have to consider
moving.  If there is an area where there are many companies of the kind
you want, perhaps you should move there.  But unless you've been hired,
it would be unwise to move to an area where there's only one such
company -- you might not get hired!  If the interview involves travel,
you may have to pay for the travel yourself.  Game companies are
unlikely to offer to pay travel expenses for novice designers.

Let's also consider for a moment what it's like to be a designer.  Some
people think designers sit around dreaming up ideas, then they get to
work out the details of their own brainchildren.  And get paid to boot!
Well, it's not quite like that.

It IS possible to attain a point in life in which you can have total
freedom to create the things you dream up, and make money at that.  But
it's rare.  And it takes a long time of establishing yourself as a
megastar before you can attain that point.

It is much more normal (and attainable) to work your way into a creative
position in which you deliver "creativity on demand."  Most game
designers are creative people who are given an assignment.

It's a lot like playing a game.  A game is like an artificial reality.
Each game has its own rules, restrictions, freedoms, and abilities built
in.  The players get their enjoyment from the creative way that they
deal with those rules, restrictions, freedoms, and abilities to try to
achieve a goal.

So the designer may not be the person who came up with the idea for the
game he is working on, necessarily.  But if he is professional, he puts
his soul and his creativity into taking someone else's concept and
making it fun.  He might put a little of his own footprint in it
somewhere, but if he's professional, he subjugates his ego for the goal
of making the project a success.  You need passion, perseverance, &
perspiration.  And a good attitude.  You'll need to be a team player, a
professional.

2.5 Can I get a company to publish my game?

No. You probably can't.  See Tom Sloper's article
(http://home.earthlink.net/~theblues/sloper.html) for more details about
why, and about what you can do instead.

Section 3: Finding More Information

3.1 Game design info on the net

For computer games, the best site that I currently know of is the Games
Domain (http://www.gamesdomain.com/) 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 more.

For RPG's, try woodelf's RPG site (http://dax.cs.wisc.edu/~woodelf/RPG).

If you're looking for other newsgroups, here's a few you can try:

  -  comp.ai.games (news:comp.ai.games)
     A forum for the discussion of artificial intelligence in games.

  -  rec.games.frp.advocacy (news:rec.games.frp.advocacy)
     Originally meant to hold flamewars about RPGs, this group has
     recently undergone an astonishing transformation. Now, most of the
     discussion is on the nature of RPGs, gamemastering RPGs, etc.
     Please note that this forum is about pencil-and-paper RPGs, not
     computer RPGs.

  -  rec.arts.int-fiction (news:rec.arts.int-fiction)
     A newsgroup for discussing interactive fiction and associated
     tools; that is, text adventures such as the old Infocom games
     (though such games need not be text-only).  The FAQ is available
     via FTP (ftp://ftp.gmd.de/if-archive/rec.arts.int-fiction/FAQ) and
     via the web (http://speedracer.nmsu.edu/~jholder/intfiction.html).

Web Resources for game designers:

  -  Greg Costikyan's essay, I Have No Words and I Must Design
     (http://www.crossover.com/~costik/nowords.html)

  -  The Computer Game Developers Association web site
     (http://www.cgda.org)

3.2 Books on game design

Note: most of the information here has come from posts in the newsgroup.
Since I didn't write most of it, I'm not responsible for any
inaccuracies.

If you have more complete or up-to-date information on any of these
books, please contact me.  Also, if you disagree with an assessment of a
book in here, please contact me; I'm willing to make room for
alternative opinions.

  -  Avedon, Elliot M., and Sutton-Smith, Brian.  *The Study of Games*.
     J. Wiley, 1971.
     A collection of articles mostly by other authors; somewhat
     scholarly.  Avedon is the Director/Curator of the University of
     Waterloo's Museum and Archive of Games in Waterloo, Canada.

  -  Crawford, Chris.  *The Art of Computer Game Design*.
     Out of print, but available on the web
     (http://www.vancouver.wsu.edu/fac/peabody/game-
     book/Coverpage.html).

  -  *Balance of Power*.  Microsoft Press.  ISBN 0-914845-97-7
     Talks about this classic game of international diplomacy. Important
     if you are going to make a global-political game.

  -  Dunnigan, James.  *The Complete Wargame Handbook*.  William Morrow
     and Co.  ISBN 0-688-10368-5
     An excellent book; focuses mainly on pencil-and-paper wargames, but
     does have some coverage of computer wargames.

  -  Dunnigan, James.  *How to Make War, 3rd. Ed.*.  William Morrow and
     Co.  ISBN 0-688-12157-8
     Focuses heavily on real-world weapons and tactics; the discussions
     of weaponry and tactics are good fodder for wargames and modern-day
     RPGs. The sections on the psychological effects of combat are good
     background reading for anyone interested in writing a wartime RPG,
     especially those with no combat experience.

  -  Dupuy, T.N.  *Numbers, Predictions, and War*.  Hero Books.  ISBN
     0-915979-06-3
     Discusses the HERO system of combat simulation developed by the US
     military.  Highly mathematical, but with emphasis on empirical
     validation of the methods.

  -  Ellington, Henry; Addinall, Eric; and Percival, Fred.  *A Handbook
     of Game Design*.  Nichols Publishing Co., 1982.  ISBN 0-89397-134-0
     Geared towards classroom and corporate simulations, but has
     separate chapters on designing card, board, "manual", and computer
     games.

  -  Epstein, Richard A.  *The Theory of Gambling and Statistical
     Logic*.  Academic Press, 1967.
     The Bible of gaming probabilities.

  -  Katz, Arnie, and Yates, Laurie.  *Inside Electronic Game Design*.
     Prima Publishing.  ISBN 1-55958-669-9

  -  Levy, David.  *Computer Gamesmanship: Elements of Intelligent Game
     Design*.  Simon & Schuster.  ISBN 0-67149-532-1
     Focuses on chess, checkers, and poker algorithms.

  -  Peek, Stephen.  *The Game Inventor's Handbook*.  Betterway Books.
     ISBN 1-55870-315-2

  -  Perla, Peter.  *The Art of Wargaming*.  Nav. Inst. Press.  ISBN
     0-87021-050-5

  -  Prados, John.  *Pentagon Games*.  Harper & Row.  ISBN 0-06-096130-9
     Gives insight into the kinds of simulations the military creates,
     and includes 3 original games by the author.
  -  Sackson, Sid.  *A Gamut of Games*.  Castle Books, 1969.
     Not actually about game design, but it does give some insights and
     covers a wide variety of games.

  -  Schuessler, Nick, and Jackson, Steve.  *Game Design: Volume One:
     Theory and Practice*.  Steve Jackson Games.
     No longer in print, no further volumes were produced. Nevertheless,
     if you can find a copy, this is an excellent resource. It mostly
     focuses on wargames, but there is a chapter on RPGs, and some
     material about printing and distributing games.

  -  Schmittberger, R. Wayne.  *New Rules for Classic Games*.  John
     Wiley & Sons, Inc.  ISBN 0-471-53621-0
     Includes variants on games from chess to Monopoly, plus ideas for
     creating your own variants. (Which, in turn, can provide ideas for
     original games).

  -  Strategy and Tactics Magazine.  *Wargame Design*.  SPI.  ISBN
     0-917852-01-X

  -  Zocchi, Lou.  *How to Sell Your Game Design*.  Gamescience.
     catalog # GS 10404

3.3 Magazines The only two we've heard of are no longer published.
Please let me know if you know of any others! Again, these reviews come
from others -- I'm not responsible if they're wrong.

  -  *Interactive Fantasy (IF)*.  A magazine of games design, theory and
     criticism<br> Five issues were published.
     Published in paperback-book format, IF discusses the issues and
     meta-issues of games design, focussing primarily on RPGs. Writers
     include big names such as Greg Costikyan and Jonathan Tweet, and
     issues from #4 onwards had a section devoted entirely to design
     matters.

  -  *Interactive Entertainment Design*.  This magazine was published by
     computer-games guru Chris Crawford, who also supplied 90% of its
     contents. It's no longer in print, but back volumes are available
     for $25, or you can get the entire 9-volume set for $150 (prices
     are US dollars). The address is:
     Interactive Entertainment Design
     5251 Sierra Road
     San Jose, CA 95132, USA

or by email from: [e-mail]

3.4 Finding games on the net

  -  gamelet.com (http://www.gamelet.com) lists many free Java games

  -  Peter Drake's games page
     (http://www.cs.indiana.edu/~pedrake/games.html), currently
     including an extensible space combat simulation, Astromachia, and
     several reviews of games.

  -  Mike Petty's free games
     (http://www.geocities.com/TimesSquare/Battlefield/1173/index.html)
     (New World Games)
--
"Yo' ideas need to be thinked befo' they are say'd" - Ian Lamb, age 3.5
http://www.cs.queensu.ca/~dalamb/   qucis->cs to reply (it's a long story...)