Designing Games: rec.games.design FAQ

Last-Modified2003 February 25 09:21:11 (Tuesday)
Version3.5
MaintainerDavid Alex Lamb (dalamb@spamcop.net)

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 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.cs.queensu.ca/~dalamb/Games/design/design.html. If you don't have web access, you can contact me at dalamb@spamcop.net 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.

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:

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:

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:

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

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

Web Resources for game designers:

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.

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.

3.4 Finding games on the net