From: sma AT kiel DOT netsurf DOT de (Stefan Matthias Aust) Newsgroups: alt.msdos.programmer,comp.os.msdos.djgpp,rec.games.design,rec.games.programmer Subject: Re: Object Oriented Design for RPG Date: Sat, 05 Jul 1997 09:07:03 GMT Organization: commercial link systems Lines: 155 Message-ID: <33bdfdef.685896@news.cls.de> References: <01bc892c$33071600$b5a42499 AT syntaxlogic DOT earthlink DOT net> NNTP-Posting-Host: pppm14.kiel.netsurf.de To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Precedence: bulk Hi! On 4 Jul 1997 22:14:22 GMT, "Alex Kain" wrote: >Does anyone have any advice on what faq I can get on the objected oriented >design of a role playing game? I know all the basics of programming all >types of scrolling game and doing demo effects. And I know what objects >are and how to use them. But I don't know how to design games or programs >with them. Please help. I don't see why designing games would be very different to - say - designing a general accounting program. Therefore any good book of object oriented analysis and design would help, I think. I'd recomment Nancy Wilkinson's book "Using CRC Cards" (by SIGS books) for the beginning. The key to successful OO is IMHO the ability to "think in objects." Most design methods perform two (interchanging) steps. First you've to identify possible objects of your problem domain. Later, you will work with this list - adding or removing objects - when thinking about the object behavior and/or relationships. Common relationships are is_a, has_a or holds_a. Now I'd suggest to go through some scenarios to learn more about your problem domain. Think of a certain start situation and ask yourself how your objects must behave and interact to fullfil its requirements. Some objects, which immediately come in mind for a Hack-style RPG are: the surrounding * dungeon * room * corridor * trap the player * hero (or character) * attributes * illness effect * magical effect the things * weapon * armor * spell * wand * potion * gold the enemies * orc * troll * dragon Comments: Always use the singular form, not plural, if single instances of the object can exist. Try to omit different names for the same object (hero <-> character). This will happen in the beginning when you collect everything. You can remove them later. Think about whether you enumerate properties instead of objects. "attributes" is such a case. They are in fact properties of a hero object. Sometimes the difference is very vague but try to resist the instict to optimize here. Similar argument against "gold". Gold (as a value) seems to be the property of a goldpile. Identify abstract objects now. They've no real counterpart in your problem domain, but help to structure your objects. Monster, as common name for orc, troll and dragon might be a good object. Other objects might be valuable object (a common name for goldpile and chest) or creature, which summarizes the common behavior of hero and monster. This specialization is a "is_a" relation. Now think about the behavior of your objects. Do some statements: A dungeon consists of a (hold_a) number of rooms, which are interconnected by corridors. No corridor exists without adjected rooms and each corridor connects exactly two rooms. Here the question raises whether rooms are always connected with corridors or whether they could adject each other. Solve this design decission. I'll assume that corridors are needed. How to integrate traps? A room can hold a number of trap objects, I'll define here. More formal: dungeon holds_a list of rooms (1..n) room holds_a list of corridors (1..n) holds_a list of traps (0..n) corridor has_a room has_a room [and so one] Finally on scenarios: We'll consider a very basic one to begin with. We want our hero to move one step forward. Suddenly, we notice that we haven't any idea how to issue that command. Therefor we'll introduce a new object, a commander, which shall be able to translate a player's (is the player also an object? Is the player the commander? I'll left this as an exercise for the reader :-) command into an appropriate order for the hero objects. Our hero needs a service like "move forward" which can be issued by the commander. But what means moving forward in a world which consists of rooms and corridors only? One solution would be to part rooms and corridors into fields (as Hack does). But I'd like to look at the other (simpler) solution to redefine moving forward as either leaving a room (if the hero is inside a room) or entering a room if she's currently in a corridor. Wait, we've found a new property of our hero: the current location (which can be either a corridor or a room). We've also to solve the problem to pick the right corridor or room. Here's the usual solution in OO: Let's delegate the problem to somebody else. Therefore, we'll define that the commander has to issue a command like "move to a certain corridor" or "move to a certain room" which can be rewritten as "leave room through a corridor" and "enter a room". But is the commander responsible in issuing always correct commands? I'll define we've to check this, as the hero is probably the better object to know of the world, she's "living" in than the somewhat abstract commander. We can assume that corridors and rooms exist, though. This means, if the hero is ordered to leave a room through a certain corridor, he has to ask the room (room? wait, it can be also a corridor, perhaps we should find a common name for both?), he's currently located in, whether it knows that corridor. In that case, he changes the location property. Otherwise she raises an error condition, the commander is responsible to handle. What I wanted to show in this example is the dynamic of that process, which one should be afraid of. It's a very good way to learn a lot of things of your problem domain, you probably didn't thought of at the beginning. You've sometimes to reconsider your current design and adapt it to new situations. After some scenarios, your design should become more stable. This is also a proof of your design. It's a good idea to go through the first scenarios again, then. When solving problems, think about the collaboration of objects, try to delegate everything complicate to other objects. Try to break complicate situations into more basic ones, let others do the dirty work. Introduce more objects if needed and don't try to optimize. Don't restrict yourself because of your implementation language. I'd suggest to use a true OO language to implement your design, as it gives you the needed flexibility. I will not start a religious war (even if that might be fun :->) but only recommend to look at Smalltalk, which is IMHO one of the best OO languages (because it's the first (besides Simula)) Finally, to answer Alex' question: I'm not aware of any FAQ, sorry :-) [I'm reading only rec.games.design so it would be nice to crosspost follow-ups to that group, too. Thanks] bye