Do you practice top-down or bottom-up game design?

[soniCron]

How do you make games? Do you take a top-down or bottom-up approach to game design? Do you have a "neat idea" that you throw together, or do you try to piece together fundamental game mechanics into a cohesive whole, each component carefully complementing one another?

[woo]

Um. Yes :)
The initial design of My Bogle was definitely top down, but I think that was more out of a necessity due to my inexperience in game development. The port of My Bogle to Torque X is definitely test driven, but it's almost out of necessity due to the fact that I'm more doing a port than a whole new concept.

The next Big game will mostly be both as well - top down for the initial prototyping and then throwing that away and starting with a bottom up approach again for the final product.

So, both.

-Andrew Douglas
http://theoreticalgames.com

[bignobody]

It depends on the game, but I'm usually the former. I start with what I think is a neat idea, and get a prototype working. Once I play with it a while, I start to get a feel for what I think it "needs", and add them in layers. It's not always effective as sometimes those layers need to be removed or drastically changed, which is time consuming. But overall, I'm happy with my process.

[DrWilloughby]

I've always been a proponent of top-down design. Designing from a theme rather than designing from a mechanic makes it more likely that you will connect with your audience (Guitar Hero connects not because of the mechanic but because of theme), and more likely that you'll innovate in terms of mechanics (Guitar Hero's mechanics are borne from the idea of playing a guitar).

Designing mechanics first, as most low-risk big-budget games do, leaves you with clones. If you say, I'm gonna make an RTS or I'm gonna make an FPS before you even figure out a theme, chances are the game will be boring! (in my book that is...)

[Bmc]

I'm currently experimenting with a design methodology that is somewhat similar to the High-concept methodology that Hollywood uses to create the stories found in their feature films.

[Bmc]

Designing mechanics first, as most low-risk big-budget games do, leaves you with clones. If you say, I'm gonna make an RTS or I'm gonna make an FPS before you even figure out a theme, chances are the game will be boring! (in my book that is...)

It's usually the other way around. Low-risk, big budget games just put a new theme on existing game systems. If they designed mechanics first most of them would be a much more innovative product.

[JoshuaSmyth]

For my RPG I'm doing a bit of both.

First from the top:
Decide how I want the human/computer interaction and GUI to work. How I want shopkeeper trading and inventory management to work. Decide on a setting and combat mechanisms. And define an overall premise for the game. This is basically all the implementation stuff.

Then once the mechanics are in place go to the bottom and work up:
Setting -> locations -> characters -> motivations -> subplots -> story -> plot
which should then connect back to the premise. (Well, thats the theory anyway)

I'm still in the top down stage at the moment however. Once the engine is finished that will mean for the next game it will be a solved problem and it'll be entirely a bottom up process that determines the story.

I guess thats not really a bottom-up or top-down design but somekind of method that converges in the middle.

[DrWilloughby]

It's usually the other way around. Low-risk, big budget games just put a new theme on existing game systems. If they designed mechanics first most of them would be a much more innovative product.
I disagree, this is my point exactly -- they simply re-theme an existing mechanic, rather than designing the mechanics around the theme. The underlying mechanic (FPS or RTS, etc) shapes their choice of theme rather than the other way around.

If you pick the theme first - "being a rock star", "african ecosystems", "designing a house", the mechanics that follow are more likely to be innovative and interesting.

[Mark Fassett]

I generally practice "bottoms up" game design. Three or four beers, and I'm ready to design a game!

[Edtharan]

I usually use both. I see them as Tools, like a hammer and screwdriver. Sometimes you need the bottom up approach to solve a problem, other times you need to use the top down approach to solve it.

Using only one or the other is like only just using a hammer or a screwdriver, sure, you can put a screw into wood by using a hammer, but it won't hold the two bits together well (if at all), and you can use a screwdriver to hammer in a nail, but is not very good at it.

Top down and bottom up both have their advantages and disadvantages, wher one is poor at the task, use the other. Get the best of both worlds.

[Dan MacDonald]

Neither top down or bottom up design are practices that will enable you to arrive at a complete solution in an effective manner. Both are ways of looking at a problem but neither is entirely sufficient. Often the shortest path to designing a solution involves a combination of both, starting at both ends and meeting in the middle.

It helps to look at the problem top down at the beginning, and then as you understand the problem better start doing some bottom up design and work back to your top down ideas. Both are helpful ways to approach a problem and generate features and requirements.

[princec]

I have no idea how I arrive at my games. Start with some basic idea - usually based around a control system - try to stick some twists on it - then just let it evolve.

Cas :)

[jman2050]

I'm more of a bottom-up guy in the beginning. I'm a huge proponent of good gameplay, so the mechanic is usually what sparks a game idea. I just come up with what I think is fun and go from there. However, I won't ignore the top-down approach, as in everything but most puzzle games (heck, even IN a lot of puzzle games nowadays), there is some sort of justification for the mechanic. So I guess overall a little bit of both.

I have no idea if this approach works best or not, as I haven't had the time or resources to put together a design until now, but it sounds good in theory. Whether it works in practice is another story...

[Coyote]

Earnest Adams on why Bottom-Up Game Design is a "Twinkie Denial Condition":

"The Perils of Bottom-Up Game Design (http://www.designersnotebook.com/Columns/066_The_Perils_of_Bottom-Up_Ga/066_the_perils_of_bottom-up_ga.htm)"

[soniCron]

I'm not sure I'd call that bottom-up game design, so much as bottom-up game development. Notice the distinct lack of attention to Player in his examples--what I imagine to be the real reason for failure in his enumerated games. The fault wasn't bottom-up design, but what I like to call "head-in-bottom" design. (Something that plagues most of us at one time or another!)

[LiquidAsh]

What a great topic... I used to think that understanding bottom-up design was THE path to enlightened game design. The metaphore I had in my head, was that painters need to understand how to mix paints to get the colors they are interested in, and basic rules/mechanics are the game designer's paint. My feeling was that by sufficiently understanding how rules mix, one could lay out a set of rules to elicit a given emotion/experience.

I still think this metaphore is a good one, I just didn't take it far enough. Many good paintings are said to be more than the sum of their parts. By mixing the appropriate colors, shapes, etc, there are emergent properties that are easier to appreciate than they are to deconstruct from a formal elements perspective. Mixing rules results in just as many emergent features in a game. This is why top-down design is so important. A top-down design leads you around the emergent features of bottom-up design. You still need to do some amount of balancing, etc from the bottom-up, but that is always checked against the bigger picture top-down game idea. I think this is why so many people are saying they start with top-down, then move into bottom-up.

One last note on how I fell victom to over estimating the importance of bottom-up game design. In addition to my inexperience at the time, I have always enjoyed games that I consider games for game designers (and game programer/designers in particular). These are games that play off of the rulse of other games, or off of a minimalist or otherwise challenging design constraint. I imagine the painting metaphore for a designer's game, would be one of those minimalist single-shape/line paintings. I have a relatively hard time appreciating paintings like this, just as I imagine that many non-designers have a hard time appreciating the design of a one-button game, or WarioWare, or etc.