rec.games.design FAQ

Archive-name: games/design-FAQ
URL: http://www.qucis.queensu.ca/home/dalamb/Games/design/design.html
Version: 3.1
Last-Modified: 1998 June 21 06:36:49 (Sunday)

Copyright 1997 Travis S. Casey.  Revisions Copyright 1998 David Alex
Lamb.

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
 and is currently maintained by David Alex Lamb
; 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.qucis.queensu.ca/home/dalamb/Games/design/design.html.  If
you don't have web access, you can contact me at dalamb@qucis.queensu.ca
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?
     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

  -  The Copyright Website

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?

2.5 Can I get a company to publish my game?

Section 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
-- 
"Yo' ideas need to be thinked befo' they are say'd" - Ian Lamb, age 3.5
http://www.qucis.queensu.ca/home/dalamb/
Discuss this article in the forums
Date this article was posted to GameDev.net: 7/16/1999
(Note that this date does not necessarily correspond to the date the article was written)
See Also:
Game Design