Pulsipher Game Design

There are some typical questions that come to mind in people who want to design games but haven't really done so yet.  One of these is "how do you actually start a game"?

I have written about how games originate, what element starts the thought process.  http://www.gamecareerguide.com/features/662/idea_.php  This time I want to focus on questions you can ask yourself, lists you can make, techniques you can use, rather than on specific aspects of the game.

I am supposing that you don't want to make a game that's just like some published game.  This can be good practice, but unlikely to result in a commercially viable game.   I'd rather spend less time modifying an existing game rather than make a clone from scratch.  No, that's not commercially viable, but it's good practice. 

There are various ways to approach game design, for example as problem-solving to create something that succeeds mechanically, or secondly as a way to find interesting things for people to do (play).  The first doesn't always result in a particularly-interesting game, and playtesting can show this.  The second may have a potential to be interesting, but you may never be able to figure out how to make it happen, how to have the game provide the interesting things to do.

Some designers are very cerebral, some design from the gut, and the rest are somewhere in between.

The extreme gut method is "I've got some notions written down, can quickly make a 'kind of' prototype, let's play and make the rest of the rules as we go along" method.  This might be called the "seat of the pants" method or "winging it" method.  This reminds me of a D&D referee who prepares almost nothing before an adventure and makes it up as he goes along.  Some game designers can manage to do this occasionally and get good results, some make a hash of it.  But there usually has to be a partial game as a starting point.

What it reminds me of is a painter staring at a canvas, about to paint something, he has a vague idea of what.  I'd call it the "artist" method of creating a game, as opposed to the more "scientific" method that many use.   My guess is that people who are making commercial games rather than art games would rarely proceed this way.

The beauty of paper prototypes is that this can be done pretty quickly.  It doesn't work for video games unless you are a dynamite programmer and aiming at a quite limited game.



If you're lucky, and if you have experience, another way a game may start is that it all leaps pretty clearly into mind, and it works when played about like you thought it would.  But that still means there's a long, long process of playtesting and modification to be done.

This "leap forward" may be preceded by a long gestation period when you're trying to get your ideas to fit together, and then suddenly it all comes together.  You nibble at it like a dog chewing a bone (and sometimes dogs bury them or just forget about them for a long time).  Once again, you usually have to have something in mind to start with, so it's one step beyond "the start".


Now let's look at some things you can do to organize your thoughts, to be more "scientific" in your method, and to help you avoid making games that are purely derivative.  Recognize that it's still going to take a while. A game isn’t built in a day.

Likability of Games
Make a list of games you really like.  List the three or four outstanding reasons why you like the games, each one in turn.  Do some of the reasons occur again and again? 

Now do the same for games that you really don’t like.  This time, list three or four things you do like along with three or four that you don’t like.  Do some of these “bad” games nonetheless have some “good” characteristics?  This will often be the case; a really good game succeeds not only by having good characteristics, but by avoiding bad ones.

At some point you may want to list of three or four things you’d really like, that you want in a game you’re working on.

The Essence of games
Another approach is to write the essence of games you like.  The essence is a two or three sentence description that gets to the heart of what the game is about.  Do the same for some games you don't like.  Then try to do it for a game you want to design.  I've written about this separately: http://pulsiphergamedesign.blogspot.com/2011/04/essence-of-game.html

What is the player going to do?
You might find that the things you like about games are often related to what the player does.  One of the most important aspects of game design is the question, “What is the player going to do?”  Try making brief lists again of what the player(s) do in games you really like, and what they do in games you dislike.  Then make a list of what you want players to do in a game you’re working on.

What’s going to happen?
Another way to look at a game is, “what happens”?  A way to approach this in game design is to make a list of events you’d like to have occur in your game.  Some of these events may occur many times, some only once, some may not occur in every play of the game.  You can make such lists forever if you go into enough detail.  Try to end up with a list of 10 to 20 events at roughly the same level of detail (“granularity”).  (Those familiar with Systems Analysis will recognize that the Event List is an important part of analysis.)

The two methods above are both aspects of what legendary video game designer Chris Crawford says in his First Law of Software Design, “Always start by asking, ‘What are the verbs?’”

Answer a "what if" question
This seems to be the start of many science fiction stories.  Do you have, or can you think of, any "what if" questions that can be turned into games?  These are legion for alternative history ("what if Napoleon had died in one of those early battles in Italy").   And many historical games can be designed to allow exploration of alternate histories.  Or it may be as simple as "what if chess pieces had differing combat strengths".