Skip to main content
gamedev.net
🔒 Locked

RPG Design Process

Started by The Reindeer Effect Dec 30, 2006 at 4:28 PM 3 replies 1.5k views
Original Post
The Reindeer Effect
The Reindeer Effect
What sort of design process do you go through when you make an rpg (not necessarily a crpg, although that is what I am most interested in)? I'm not really talking about the story and content creation, but the actual design of the game mechanics / rule systems. So far I see two general approaches... top-down vs bottom-up. The top-down approach is this: imagine how you want your actors to interact with the world. What sort of activities will they participate in? You go from this set of activities and decide what is necessary to model performance in each... you try to get down to a set of atomic attributes that are sufficiently diverse to account for all the activities in your game. For some, this could just be strength, agility, intelligence. Other games, for example, those having more complicated social interactions, would need other attributes to be a part of the model (personality, for example). The disadvantage of this is that the very core mechanics of your game (attributes, for example) are never set in stone until you exhaustively investigate all possible interactions. The bottom-up approach is to start from a set of attributes and explore what possible features there are. You don't have a particular style of interaction in mind, rather you just have a basic model and through experiment you figure out what you can do with it. This is a process of growth, and you have the benefit of solid feedback all along the way. But what you don't necessarily have is a single unifying theme that would be comparable to what you would get with the top-down approach. On any given project, it is probably in your best interest to use both of these approaches concurrently, and try to converge on some solution. But I think that this sort of game design is fundamentally difficult, because there is this hierarchy of complexity, where at the root you have the very core elements of the game and at the leaves you have all the possible interactions. Change the root and your leaves may all be broken; change the leaves and your root may not be sufficient to match your vision. These are just the opinions of somebody without much experience, so feel free to disagree. And I'm interested in hearing about any aspect of the design process, not just this top/bottom dichotomy that I mentioned.
erissian
erissian
I don't think any one of those ways is best. I suppose I start thinking from the top, but then work from the bottom.

For games, or any program in general really, you have to know what you want to make. If your idea is as developed as "I want to make an RPG," then it doesn't really matter how you work out the details, because they should lead to an acceptable solution no matter what. If you want a class based RPG, then get an idea of a few different classes, decided what's unique, and what they have in common, then work out the details.

Put more succinctly, the concept is the most important, so don't let your implementation ruin it.

Often times, I don't necessarily have a complete game worked out, I have just a concept; something I think would be damn neat. I start with the geography, and how it could be populated. I work out a history, and how it's changed the world. If I want special elements, I work them in, and use them in the history. I try to work out the needs that people have, and then their solutions. The world fleshes itself out, and I try to get it towards the end I envisioned. (I know you weren't looking for story info, but bear with me...)

It's the solutions to the problems the people encounter in my manufactured world that I'm most interested in. I work those out in detail, trying to think about what makes different implementations unique. This helps me work out the parameters I have. After all, what's the point of a strength stat if everyone has firearms? What good is charisma if you're controlling a spaceship?

The same principle applies here; do you have fighters and magi? What makes them who they are? What is it they struggle to achieve? Are there any natural talents that make them better than another person at their task? Are there conditions that weaken them?

Let's look at a hand-to-hand combat type. Obviously, strength helps to inflict damage, but speed and intelligence is more important. Being able to react and take opportunities is what wins a fight. Knowing the right places to strike makes you more effective. Being strong helps.

More narrowly, there's traditionally been a constitution stat. What does that mean? Healthy? Does being a big fat guy slow you down? What if you're sickly? Are there any advantages to either of these conditions? Is constitution really descriptive, or is too abstract? Can a guy who works out every day, goes for runs, and eats his vegetables take a knife to the belly that much better?

Try to figure out, for a particular type, what things can be ignored, and what things don't need to be explained. Some things you can consider universal. There's rarely a stat for how many fingers you have left. On that same note, does it matter if the dragon trying to immolate you thinks you're charming or not?

Stat-wise, I think that it's best to keep generic stats few in number, and abstract as possible. More useful and specific stats are better. Maybe have no more than three numbers describing the physical condition, but have a broader range of values that describes specific qualities and abilities.

Maybe your wizard is good at natural magic, and specifically good with tree related spells. Does it take intelligence? Maybe. Maybe it takes repeated study, or repeated use to get good. Just because they're smart doesn't mean they'll have a superb fireball the first time around.

I'm sorry this is getting so long :)

In the end, use what fits your concept. Don't feel compelled to use tried-and-true but meaningless attributes. Really think about the people you have, and what's important to them, what's unique and what's shared. Also, being a programmer, I try to think about what could be used in another setting, and how.

So what's the concept you have anyways?
We''re sorry, but you don''t have the clearance to read this post. Please exit your browser at this time. (Code 23)
Aik
Aik
I recommend having a poke around the articles (especially System Does Matter) on this site: www.indie-rpgs.com
It's concerned with PnP RPGs, but some (most? all?) of the concepts can be ported.

The key questions they use over there while developing a system are these:
1. What is the game about?
2. What do the characters do?
3. What do the players do?

1 and 2 are probably relevant to you. When you have those you can design the system to specifically suit these goals, rather than just using the normal generic stats and stuff (well, unless they fit your goal).
WeirdoFu
WeirdoFu
Actually, I think the best is to use both top-down and bottom-up at the same time. Probably have a group of engineers and producers sit down and just ping-pong ideas until something is decided. This is because producers and designers have a tendency to think top-down, while engineers have a tendency to think bottom-up. Neither way by itself is bad, it's just that sometimes top-down people tend to get carried away and specify things that can't be done, while bottom-up people have a tendency to lose sight of the big picture, when it comes to obsessing over details.So, putting the two groups together makes for some better results as one group stays grounded, while the other don't get too obsessed with unimportant details.

It is very easy and common for producers and designers to come up with crazy ideas, throw it at the engineers who then strip it down to something implementable, but get some end result that is completely differebt from what the producers wanted.
The Reindeer Effect
The Reindeer Effect
Quote:
Original post by erissian
So what's the concept you have anyways?


I don't even plan to make an rpg (though the thought has crossed my mind), this is just a thought experiment. Making an RPG is a huge undertaking... so how do teams cope with all this complexity? What's the critical path to from concept to gold, and what steps are taken to assure that the game is actually good? There are so many dependencies between content and mechanics that it's expensive to change your mind about gameplay late in the development, and yet on the other hand, it's difficult to figure out if you are doing things right until you are late into the development.

I just asked about gameplay because it seemed that there are really 2 key elements to an rpg: the gameplay, and the story. And gameplay design is still a pretty young field, at least compared to story/scriptwriting.

I agree completely with what you said. Neither approach (top down, bottom up) is sufficient without the other in some regard. And the overall driving force for an rpg is concept.

Quote:
Original post by Aik
I recommend having a poke around the articles (especially System Does Matter) on this site: www.indie-rpgs.com
It's concerned with PnP RPGs, but some (most? all?) of the concepts can be ported.


Thanks!

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.