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

Hi!

On 4 Jul 1997 22:14:22 GMT, "Alex Kain" <syntaxlogic AT earthlink DOT net> 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

- Raw text -