Class proliferation is tedious and dangerous.

Many, many of the categories I see here have minimal fundamental variance. Such classes are better served by external metadata that indicates those difference and encodes the logic. This is called data-driven design, and can allow the designers to rapidly prototype and deploy new character classes, etc without programmer involvement, especially if they are given a great tool for doing so (rather than being expected to write script).

Of course, if you're going to be the main programmer and you're not very experienced, then class proliferation and the unavoidable code repetition and redundancy are easier.

Quote:

Original post by sunandshadow Here's a hierarchy of the game modes my RPG will have. Each of the game modes is sort of one of the second level of objects, one below the game as a whole. And then they each contain their owns objects - like puzzle pieces only exist in puzzle mode, and you can only exchange money and objects in dialogue mode. So maybe this will help us brainstorm what objects need to exist as part of each mode. Game -SNIP-

Those "modes" are also refered to as "states" and usually irrevelant to plotting out the classes. Either the controller object (CGame) should be capable of being in one of those states or the program should just barrel right through that state (ie, splash screen and intro). The states that "objects exist in" you should be able to gloss straight over and turn into an implimentation issue -- what do you need to have on-hand when you're implimenting/solving a puzzle? Those objects still exist when/where-ever they're stuck in the controller (or sub-scopes) but shouldn't be focused on so much as you focus on getting just the puzzles together.

(I wonder if you have an organized method for this design)

Quote:

Original post by Sta7ic Quote: Original post by sunandshadow Here's a hierarchy of the game modes my RPG will have. Each of the game modes is sort of one of the second level of objects, one below the game as a whole. And then they each contain their owns objects - like puzzle pieces only exist in puzzle mode, and you can only exchange money and objects in dialogue mode. So maybe this will help us brainstorm what objects need to exist as part of each mode. Game -SNIP- Those "modes" are also refered to as "states" and usually irrevelant to plotting out the classes. Either the controller object (CGame) should be capable of being in one of those states or the program should just barrel right through that state (ie, splash screen and intro). The states that "objects exist in" you should be able to gloss straight over and turn into an implimentation issue -- what do you need to have on-hand when you're implimenting/solving a puzzle? Those objects still exist when/where-ever they're stuck in the controller (or sub-scopes) but shouldn't be focused on so much as you focus on getting just the puzzles together. (I wonder if you have an organized method for this design)

Do I have an organized method? Well, depends what your definition of an organized method is. I think so, but you might disagree. My method is basically the saying 'Form Follows Function.' If I describe what I want the game to do, that should tell me what pieces I need to make and how I need to hook them together to get the desired behavior.

I don't think it's right to say that puzzle pieces still exist when you're not in puzzle mode - they don't have a life of they're own, they're often generated randomly whenever the player attempts a new puzzle. Similarly monsters only exist when you are actually fighting them, and NPCs don't exist when you are fighting monsters, etc.

Quote:

Original post by sunandshadow Do I have an organized method? Well, depends what your definition of an organized method is. I think so, but you might disagree. My method is basically the saying 'Form Follows Function.' If I describe what I want the game to do, that should tell me what pieces I need to make and how I need to hook them together to get the desired behavior.

Well, maybe "design pattern" more than "organized method", I guess.

Though not really a direct element of "OO game design", part of the software design process is to list out the requirements for the program, either as a bulleted list, paragraphs, or series of linked bubbles, and pick out both the key nouns and verbs to identify what should be focused on. Like "the player must be able to drink potions", we snag "player", "drink", and "potion" and decide "we need player and potion objects and a PlayerDrinksPotion(int invslotID)".<br><br><!–QUOTE–><blockquote><span class=smallfont>Quote:</span><table border=0 cellpadding=4 cellspacing=0 width=95%><tr><td class=quote><!–/QUOTE–><!–STARTQUOTE–>I don't think it's right to say that puzzle pieces still exist when you're not in puzzle mode - they don't have a life of they're own, they're often generated randomly whenever the player attempts a new puzzle. Similarly monsters &#111;nly exist when you are actually fighting them, and NPCs don't exist when you are fighting monsters, etc.<!–QUOTE–></td></tr></table></blockquote><!–/QUOTE–><!–ENDQUOTE–><br><br>Well…. whether or not the puzzle pieces and the NPCs and the monsters exist when you're not in the state that uses them is a tossup and full of technical details. It's probably remarkably extraneous, but you could say they exist because they're still in memory, you could say the references exist (even if an instance of a monster isn't), you could say that they don't exist in this scope (in the sense that the fight scope is a subset of the game scope and the NPCs are still in memory and &#111;n the map for when you leave the fight and go back to the zone).<br><br>But, back to objects. Instances and references are Good™. The noun/verb analysis is really &#111;ne of the best ways to try to determine what objects you need (and that design step exists in, oh, thirty different design processes). As TG said, scan UML literature.<br><br>In the meantime, what sort of requirements does you game include? ("the player must be able to run back and forth within predetermined areas", etc)<br><br>

I have to disagree with the people that say that up front design is a bad thing. Taking the time to do a proper analysis and design will save you a great deal of time in the long run. Chances are you will have to make a few changes to your class structures as development commences but with experience both the number and scale of those changes will decrease. Also the more people you have working on a project the more important class diagrams and tech specs become. If you have one person developing the combat classes and another working on the character classes then those people might have very little interaction with each other but if they have a clearly defined classes and interface then they can do their jobs regardless of the others implementation.

sunandshadow your list of game modes are really more of screens and user interactions rather then objects. For instance all of your screen will be derived from a base screen class, which will have all the common rendering code and input handling. Try thinking about classes in terms of performing functionality.

Take an object like CharacterBase. What common functionality would belong in this class and what would other objects need to know about it? What is unique about the player character, NPC, and RNPC.

When creating object it is good to think in terms of inheritance, irrelevance, and interactions.

If several classes share a common functionality can that functionality be contained in a base class or super class? Ex. RNPC inherits from NPC, which inherits from CharacterBase.

Does a piece of functionality belong in the class you are trying to include it in? Or is it a separate object on its own? Ex should a Character know how to render itself or merely contain a reference to the rendered object?

How will the class interact with the other classes what do they need know about each and would will they need to do to each other? Ex. How is damage dealt? And which class determines how much damage is dealt? Is it the combat class? The weapon class? Or the character class?

Quote:

Original post by TechnoGoth I have to disagree with the people that say that up front design is a bad thing.

What people are these?!

So far, all I've seen is people saying too much up-front design tends not to survive contact with production code. Everyone knows that a project typically gets refactored and redesigned when it comes to games, largely because the key ingredient - fun - is a by-product and not something you can explicitly engineer into the concept/design. Designing a spreadsheet is very different than designing a small dungeon crawl, because the former behaves in mathematically deterministic ways always, and doesn't need to be "fun" to use. Easy, yes, but that's a matter of HCI.

It's those darn qualifiers that always get you! [smile]

Quote:

Original post by sunandshadow I'm trying to study how the philosophy of object oriented programming applies to game design. Apparently, everything is made out of objects. The whole game is the largest object, and it is made out of other smaller objects. But what are these smaller objects? Does anybody know of a diagram showing all the classes and objects an example RPG is made out of?

Hi sunandshadow,

Your question is a bit ambiguous.

Everyone else seems to have interpreted it as "How do I use OO Software Engineering techniques to design the code structure for my game from my RPG Game Design Document?"

Is this really what you were asking? You seem to be a writer/designer, and so I'm surprised if this is what you meant (unless you're learning to program now too). Perhaps you could clarify.

I interpreted your question as asking how Object Orientated principles could be applied to Game Design.

I guess the confusion may stem from one of definition. For me Game Design is the process of specifying the Game Play Elements, Story, Characters, Menu Flow, Game Modes etc that make up the game. This is a seperate process than the Software Engineering problem of converting the Game Design into actual code.

Appologies if I'm missing the point.

WillC - I am a writer/designer, but due to continuing frustrating problems with team members wandering away, and other problems with not being able to get a job as a game designer without knowing any programming, I decided to take a stab at learning Java by way of creating a programming plan (object chart) for Xenallure.

Quote:

Original post by Sta7ic In the meantime, what sort of requirements does you game include? ("the player must be able to run back and forth within predetermined areas", etc)

Linky to Xenallure's Design Doc (in progress)

Feeling a bit better today, hopefully this will make a bit more sense...

Designing a program is a bit like designing a game, except in this case you have to think through what you want the computer to do, rather than how the game will run.

Two basic approaches for program design in general are the "top down" and "bottom up" design strategies. With "top down" you take the system as a whole and define what you want it to do without going into any detail about the internal implementation. Then you divide that top level into a series of smaller components and perform top down design on each component (define what they do at this level, and divide again). Keep going until the whole thing is designed.

With "bottom up" you start with the small individual parts and define in detail what they will do. Then you link together parts that go together to make larger components, and keep going until the whole thing is designed.

Usually I take the top down approach, unless I already have some small components, in which case I combine the two and do a bit of bottom up design for those componenets. I try to build a series of UML(-esque) diagrams which break down the whole project into a series of boxes representing each part, with links showing how they communicate between each other. An example of the first level of how I'd break a problem like this was the series of classes I listed in my first post in this thread, something like a Video controlling class, an Audio controlling class, an Input controlling class, some World class for controlling all the game logic, and then maybe some logging or error handling classes, or something for communicating between the classes (it's the methods for classes to pass information between each other that makes this difficult, at least for me).

Hopefully that was of some help. Breaking up a big project such as an RPG into a set of classes is a daunting task.

I don't know of any example RPGs, but I have code available for two of my projects on my website. Any questions, feel free to email.

I wrote a longer response earlier but stupid computer crashed.