It really depends on what you mean by top-down and bottom-up. I''m gonna take them as meaning "goal-driven" and "system-driven". By this, I mean that with top-down you start with an abstract goal (eg. "I want a space exploration game"), and gradually refine it until it does exactly what you need. And with bottom-up, you have a set of useful components or subsystems, and can join them together to make something more useful in turn.

Therefore you could start off with a rough idea for a game, and develop a bit in top-down style by deciding the vague things that you need, and then switch to bottom-up by brainstorming a list of cool aspects and making a sub-system out of it.

The disadvantage of this is that it''s not very methodical, and it can be hard to stay on track. Equally, it''s hard to know when your design document is complete.

The advantage is that you don''t start off with a grand idea and then only realise that it''s worthless when you get to the details. Or have a few great systems that you just can''t seem to make into a coherent game.

[ MSVC Fixes | STL Docs | SDL | Game AI | Sockets | C++ Faq Lite | Boost
Asking Questions | Organising code files | My stuff | Tiny XML | STLPort]

quote:

---

Original post by Xgkkp

quote:

---

Original post by adventuredesign
I was just wondering why it had to be one or the other, and not both? I do both, and I get the best of both approaches for the benefit of my player, and I get the benefit of having each influence the other so that a better experience is had in the interaction.

---

how do you do both? i mean, i''d assume they were mutually exclusive?

---

I don''t believe so. The top down would be an approach of designing the gameworld, it''s physical parameters and laws, environmental choices and varieties, and some of the rules would emerge from those limitations.

The bottom up design would have a character, his mechanical and utilitarian abilities and limitations, his or her in game relationships to friendly and antagonisitc NPC''s an other AI''s and his emotional/psychological makeup in characteristic view of the world itself.

As you test your interactvity matrix of objects and entities (this is object by object and entity by entity, as well as object entity interaction testing, a precursor to playtesting), these two sets of finite data will grind up against each other colliding incongruently here, and too easily there, giving you a sense of modification for each, depending on what the results of the interaction tests were, immproving the integration of the avatar, the avatar''s abilities and the fixed limitations of the world. Fixed in this case done not mean rigid and inflexible, though some fixed physics of course, like gravity, light, mass, force, acceleration have constants, and can be changed by case for variations of the play experience design.

Thus, the bottom may change the top and vice versa to a degree, but by this comparison and contrasting method, you integrate the dynamic and fixed elements more tightly, in fact, as tightly as they can be, and you will clearly see what works and does not work in the game world, and potential discoveries later in the process of playtesting where play value is low is weaned out in the design stage, not the more expensive testing stage. This leads to a more homogenistic play and world integration. Can you give me some understanding why they would be mutually exclusive?

Adventuredesign

quote:

---

Original post by adventuredesign
Can you give me some understanding why they would be mutually exclusive?

---

Right, what I meant by that was that I took Top-down and Bottom-up ''s meaning to the literal extreme, and you can''t attack a problem from two ways at once... I guess that''s a bit of a limited view, and I''ll think of things differently for the main game.

For now I''m going to create small test apps for designing general aspects of the game (built on a central framework) and somehow integrate them to the main thing.

No doubt I''ll have to do several system re-writes, but I guess I''ll learn from my mistakes.

At the same time, I''ll try and write a design document (something I have rarely even thought about) and take into mind the advice given previously..

thanks,
Nick

Get a CS degree then you''ll know.

From what others have said, and my own (woefully limited) experience, a good design has a metaphorical tree structure - with a single "high concept" at the top and many detailed sub-sub-(sub...)systems at the bottom. How you generate that tree is up to you - top down designs start with the single concept and branch downwards, while bottom up designs start with the actual systems and interfaces (one step away from actual code) and merge them to derive a unifying theme, but those are just a couple of possible paths through the tree (and the top-down could go depth-first - develop each subsystem in detail before moving on to the next, or breadth-first - maintain the sub-systems at roughly equal detail levels). The important thing is not to become to wedded to a particular process, but remain flexible enough to recognise when you have to go back and revise earlier steps, or even when you''re better off abandoning the whole thing.

The answer I keep getting to queries about the correct way to design and write a game is that there are plenty of bad ways to create a game - sometimes they''ll work, but you shouldn''t expect it - but there is no one right way to go about it, and within certain general guidelines (things like making sure people can keep up with the current design and know what they''re supposed to be working on) the right way to tackle it is whichever method works for you (and the rest of the team!) for that particular project.