The Forge Archives

I'm curious what approaches people here take on the systematic processes they use to design their game.  How do you go about actually figuring out how to create your game?  For example:

Do you develop the setting and game world first, then construct the game system around it?

Do you devlelop quick and dirty prototype games that allow you to get a feel for how the game might play, and then constantly tweak it to improve it?

How do you decide what elements of the system you are trying to model will be important?

Do you design a particular section or subsection first...say for example combat before magic, or determining skills before attributes?

Do you do any hard statistical analysis of your game mechanics, or do you simply playtest and find out where the abnormalities might be?

Are the game mechanics approached as simply as a way to resolve tasks that is easy and/or fun, or are they considered as a statistical analysis tool that tries to capture some verisimiltude of the game world you are trying to create?

Do you not worry about what media your game will be marketed from, or is this an initial design consideration and affects the layout of the game (for example, if you know from the start that you are going to do PDF publishing, do you stylize the layout for computer screen readability?)?

Basically, I'm interested in systematic approaches to game design rather than intuitive gut feeling approaches.  Well, actually, I am interested in that too, but I'm curious to see if people take a disciplined approach with forethought, or if things just sort of get added together in an adhoc yet creatively inspired fashion.

I think what gets suggested alot around here is that your develop a conceptual framework before you start on specifics. That framework is basically about what you want to get out of the finished game, though it may include a few specific ideas such as a particular mechanic or setting.

The idea is that if have a developed and complete framework first, you can sculpt the rules around the framework. If you get ahead of yourself and start designing rules and sub-systems without a complete idea first, you may end up with mix of subsystems that don't work together and/or don't support the vision you had of the game.

I wanted to bring up this thread from a while ago: Streamlining Design. It suggests a number of preliminary questions that I think are very helpful to consider when starting a project. It's not a 'how-to,' but if you can answer all the questions, then you're definitely on your way.

Hey Dauntless, I write out a kind of question and answer analysis for myself as in this thread I did ages ago for Theme-Chaser. Answering one question brings up more questions, and I find that a lot of the important structures of the game begin to take shape through that process, and holes quickly become apparant. A game I'm working on just now, Wonderful Imaginary, has a lot of wonky dice stuff going on it. I like to explore probabilities and stuff as they come up in terms of "How does this solution answer my question?" rather than coming up with a dice system and then fleshing out a game around it.

Next I'll do something great that I got from the Forge, imagine and write out a sample of actual play. Then I try to match the game mechanics to the imaginary play transcript and see if my rules are not only helping the people in the transcript get the play they want, but are pushing them towards it. For Wonderful Imaginary I've got about eight A4 pages of this, I find it really useful.

Tony

Over in Indie Game Design there is a thread that is stickied: Structured game design.  I highly recommend it as a potentially powerful way to look at game design.

This is directly related to Tony's above idea of figuring out what actual play should look like and then tailoring your mechanics to make that play happen.

Thomas

I addressed this almost a year ago in http://www.gamingoutpost.com/GL/index.cfm?action=ShowProduct&CategoryID=54411&ProductID=77990&publisherid=54849">Game Ideas Unlimited: Songs, by analogy.

As a songwriter, I've often been asked whether I write the words or the music first; I've heard other songwriters get the same question. The answer, generally, is no. Some songs start with a clever line, some with a fragment of melody, some with a chord progression. With some, you have a pretty complete idea of the lyrics before you have even an inkling of the music, while others will have the music fully written before you've any idea what the words should be. The best songs in my experience have words and music created together, but some great songs have been written other ways. Sometimes a chorus will sit by itself for months, and then suddenly the verses will come. Sometimes you'll have one or two lines sitting on the back burner that ultimately lead into something complete surprising. Sometimes it all happens at once. On one occasion, I dreamed the song--sang it, played the guitar, heard the lead part--and woke up and played it.

It's the same with game development. You don't know where it will start, or how it will progress. You might have a setting idea that needs a good supporting mechanic. You might have a neat mechanic around which you build a game. You might hammer away at a problem for a long time until a solution arises, or set it aside and come back to it later with fresh eyes.

When people ask me how much I need in a setting, I tell them that you need exactly as much as the referee will need to run it, no more and no less. Some settings need maps, and some do not. Some settings must have stats on a significant number of characters or creatures, while others just need some basic description of the kinds of encounters that are likely.

It's the same with game design more generally. You start wherever the inspiration arises, and look to see what has to be answered for it to progress. Sometimes that means you'll develop the entire framework of a mechanical system before you have a clue what the setting would be like, sometimes it has you shifting back and forth between expanding the setting and improving the system to support it, and sometimes it will all come together as a piece.

It's an art, really, a creative process. If you could produce a formula by which to do it, it would cease to be an art to a significant degree. Yes, there are many tricks and techniques that go a long way to help, and many people will have preferences concerning what works for them, but I know for me, and in those I have seen, it's always changing. Whatever the game needs for you to do to make it work, that's how you approach it.

--M. J. Young

Boy, those're a lot of links to digest. Well, I'll call that homework. To answer your questions:

Do you develop the setting and game world first, then construct the game system around it?

Not me. My focus is always on the engine; I guess, task resolution.

Do you devlelop quick and dirty prototype games that allow you to get a feel for how the game might play, and then constantly tweak it to improve it?

Not really. I react to frustrations with other systems or poor play experiences. Those lead to further mechanics via free association. I tend to remove pieces when I return to the draft, after I've captured my thoughts to their furthest winding.

It's sloppy, but design by exhaustion is a valuable exercise. Everyone should do it once.

I edit mostly at the conceptual level. I live for breakthroughs in lowering handling time through integrated capture. I take great inspiration from non-RPG games and try to apply their best elements. (e.g. Ken's failed Ha Dou Ken turning into a Shou Ryu Ken.)

How do you decide what elements of the system you are trying to model will be important?

Mostly by intuition. I'm mainly trying to please myself; to express a kind of beauty of purpose in play. My inner sense is fed by a love and practice of gaming. I prioritize system elements which best support my fantasy life.

Do you design a particular section or subsection first...say for example combat before magic, or determining skills before attributes?

Combat's my main thing. Generally, I want to provide structure and meaningful choices. Forge focus on advancing doom and story-driving mechanics really fascinate me.

Neel Krishnaswami's Daedalus article, "Causality and Choice: Getting Rid of {TECH} in RPG's," suggests a method for the lay person to provide structure for exploring non-combat subsystems.

Do you do any hard statistical analysis of your game mechanics, or do you simply playtest and find out where the abnormalities might be?

Play to break. Usually by myself. Another (sneaky) thing I do is test out mechanics as mod's to whatever other system I'm running. (Heh, heh.)

Are the game mechanics approached as simply as a way to resolve tasks that is easy and/or fun, or are they considered as a statistical analysis tool that tries to capture some verisimiltude of the game world you are trying to create?

Funny you should ask. I begin with the motivation to fix something or be realistic. I hone the mechanic until it works. What I end up with is a fun way to resolve something that would collapse like a house of cards if it were extended (via physics or sensibilities) beyond its purpose. But god, it's fun.

Most of my ideas amount to . . . entrapment.

Do you not worry about what media your game will be marketed from, or is this an initial design consideration and affects the layout of the game (for example, if you know from the start that you are going to do PDF publishing, do you stylize the layout for computer screen readability?)?

Not even slightly. There's nothing pretty about anything I do. And I doubt it will ever be shared by many. But you can jump up and down on it.

Good lord! I finished reading all those links (minus two linked links). Tony Irwin's design by self-interrogation kicks like a mule! I mean, it's on the level of Chris Lehrich's edit by outline.

Thanks for the links everyone, I still haven't had time to digest the discussions yet since it's midterms time, which means I have no time :(

What prompted me to ask the question is that I'm a senior in computer science, and I'm taking a class called The Principles of Software Engineering.  I've noticed many parallels between what is suggested as methodologies to create programs and how I approach my own game design.  Fundamentally, engineering is a problem solving process where you try to create a product that provides a service for people.  However, while games do need to provide services, it's what I call an open-ended goal rather than a close-ended goal.  Traditional engineering discplines train engineers to solve close-ended problems in which the exact details of what needs to be solved is specified.

However, software engineering is somewhat unique in that it too has a open-ended problem to solve, which makes it the most creative and artistic of all the engineering discplines (and why some say it's even a mistake to say that there's such a thing as software engineering).  In effect, you learn procedures, techniques and methodologies to discipline and organize your creative thoughts.  The ability to be spontaneous is necessary because of the open-ended "moving target" aspect of software design.

So it's the same with games.  So I've taken many of the approaches I've learned so far in the software engineering discipline and applied it to my own game design methodology.

My design process usually involves first thinking of some centrepiece that I want to use in my game. Thic can be a mechanical widget, a certain instance of play, a very specific relationship between inputs and outputs, or something else. I stop and consider what I want gameplay to look like  before I go any farther.

Then I start building the rest of the game around it; I decide what needs to be quantified and how I want to go about that, the specifics of dice mechanics, the engine that will provide impetus for play, and so on. Often, at this point, I will realize that I was originally chasing a red herring, and will refocus the game around a feature that I feel is more important to the desired gameplay. This stage of the design process often results in a game with too many little widgets attached; that's where the next step comes in. It goes very quickly; lots of things end up examined briefly and abandoned; others are attached and forgotten.

Here is where I write up a coherent document that describes the game in its entirety, and sit down to examine it. I check the causal relationships between things, see if they're interacting the way I want them to be, and so on. I also have to ask myself, "Is this part necessary? Does it do something that I need it to do? Will the game be significantly different without it?" If I can't convince my editor-self of this, then my designer-self has to find a way to remove it.

I'm a programmer by training.  I recognize the artistic and engineering strength of the mindset.  I feel that it is insidious for game design.  Not necessarily bad, in itself, but it can be taken too far.

Programming proceeds by breaking apart a desired behavior into smaller and smaller sub-behaviors until you find pieces restricted enough that you can create step by step instructions for how to force the computer to do each of them.  If you find a special circumstance then you write a special-purpose bit of code.

That's fine for a computer, which can remember libraries and never (well, hardly ever) gets bored or rebellious.  But the operating hardware for an RPG is people.  Standard programming practice can easily create a roleplaying game so laden with rules and special cases that few actual human beings would want to (or be able to) play it.

Every programmer should know Conway's Game of Life.  It is the classic example of emergent properties in a simple system.  Creating a simple system that generates a desired behavior as an emergent property is a whole different kind of programming.  It is much harder.  I think it is far more suited to roleplaying game design.  

So here's my design process:  Take a few simple rules and provide a framework for them to be applied to a large and varied "problem space".  Then see what patterns and behaviors emerge in the problem space as it is changed by repeated applications of the same simple rules.  That means playtesting, and lots of it.  Change your simple rules until you get the behaviors you're looking for.  Only add new rules when there is absolutely no other option.

The trick is keeping the rules simple and few.  In my opinion, if you can easily imagine a game session where the rule wouldn't be used then the rule shouldn't be in your system at all.

As an extension to Tony's thought about integral design:

I find that it helps to draw out a diagram of the rules, showing how each takes input and feeds its results into the other rules. If there is a rule whose output doesn't feed into another rule, it's probably either superfluous or incomplete.

The way I look at it is I design whatever I feel like doing at any particular moment, and I do not move on to another section until I have what I am working on at a level that I am comfortable with for the time being.  Usually, I'll start with a gameworld (or worlds) concept and develop the system before the actual world is developed.  So, I basically create the range of needs the system should cover, and then I'll satisfy those needs with the system, and then I'll create the world that makes use of the system.  Its a split process that has the potential for generating lots of notes and trash, but I think it helps me to develop a better system than I could do so otherwise.

I'll still have to try that mass design thing, though.