Jump to content
  • Advertisement
  • 07/16/99 05:58 PM
    Sign in to follow this  

    rec.games.design FAQ

    Game Design and Theory

    <%Topic="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
    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
    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
    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
    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
    **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
    **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
    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
    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.
    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
    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

      Report Article
    Sign in to follow this  

    User Feedback

    There are no comments to display.

    Create an account or sign in to comment

    You need to be a member in order to leave a comment

    Create an account

    Sign up for a new account in our community. It's easy!

    Register a new account

    Sign in

    Already have an account? Sign in here.

    Sign In Now

  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!