OO paradigm in practice

> If the defender creature is chosen to decide how the sword affects
> it, it must be aware of all types of swords (we may have, in addition to
> normal swords, fire and frost brnad, etc.). If the aggressor is chosen to
> know how its attack affects the defender, it must take into account all
> possible creature types, armoury, weapon characteristics, etc.
There's an easier solution. To have a Damage class that according to
some flags on itself (flaming, poisonous, stuning, cutting, ...), some
flags of the recipient of the attack (petrifying resistant, undead,
....) and some more little data, it decides how many hit points it deals
to the intended target, which special effects to apply to it, how much
damage is left for blowthrough and wether the damage is stopped or not.

Example 1:
A attacks B with a sword (S).
if (A.Attack(B) && !B.Dodge(A)) //yeah, rudimentary pseudocode
D = A.Damage(S); //or (A.GetWeapon()).Damage(A), it depends on who
decides the damage
D2 = B.ReceiveDamage(D)
if (D2.ContinueDamage())
Then you can look for people behind B if it's an arrow or whatever
suits you for an excessive damage
and finally check for living conditions and such things

B.ReceiveDamage
D.PreDamageEffects(B) <- paralize, ...
foreach(amor in B of the location or whatever you prefer)
Armor.ReceiveDamage(D) // D can altered here
D.DealDamage(B)
D.PostDamageEffects(B) <- tell it's poisoned,...

D.DealDamage <- long function full of if with the special effects
[...]
if (m_cutting && !B.resistcutting)
m_damage=1.5*m_damage
if (m_fire)
switch(B.fireresist)
case none: m_damage = 2*m_damage; break;
case negative: m_damage = 4*m_damage; break;
case percent: m_damage = B.fireresistperc*m_damage; break;
case ignite: B.infire = TRUE; break; //or D.m_ignites = true for the
after damage effects
[...]
B.hitpoints -= m_damage
m_damage -= B.stoppage //this is the damage stopped by B, because B
can be an armor

I hope this helps you, either directly or giving you something to think
about. Have fun.
 >> Stay informed about: OO paradigm in practice 

On 2006-05-24 09:55:04 -0400, Simon Richard Clarkstone
<s.r.clarkstone.TakeThisOut@durham.ac.uk> said:

> I know that Python can fake multimethods quite well (using an object
> with __call__), and newer Pythons can do even better with the decorator
> syntax. Possibly ADA can use a similar trick to simulate multimethods?
> (Although for this Python relies on its dynamic typing, not a feature
> which ADA is known for.

Or you could use a language that has multimethods. They do exist you know.

I think the real problem here is actually OOP. It is often an incredibly
limiting techcnique that has the unfortunate side effect of taking code
that should be in one spot and scattering it all over the place.

But it is what all the cool kids are using these days so it must be okay.

Novus
 >> Stay informed about: OO paradigm in practice 

Krice wrote:
> Novus wrote:
> > limiting techcnique that has the unfortunate side effect of taking code
> > that should be in one spot and scattering it all over the place.
>
> Why the code should be in "one spot"?

It's the universal software design principle of module cohesion and
coupling: code with the same purpose should be all together, and code
with different purposes should be separated.
If good modularization is impossible, the language being used isn't
expressive enough for the chosen program design (or the design is
inappropriate for the chosen language).
describing interactions between objects is a self-caused problem that
most OO languages don't address.
 >> Stay informed about: OO paradigm in practice 

gatti.DeleteThis@dsdata.it wrote:
> It's the universal software design principle of module cohesion and
> coupling: code with the same purpose should be all together

Class was designed for that purpose, but it doesn't mean the
source code is in the same spot (worst case is everything
stuffed in one function. See: Crawl for reference).

> describing interactions between objects is a self-caused problem
> that most OO languages don't address.

If you have strong modular stucture then the interactions
will be harder to design and that's the whole point of modularity.
If everything is reachable from every place then you don't
have modularity at all.
 >> Stay informed about: OO paradigm in practice 

GreenNight wrote:
> > If the defender creature is chosen to decide how the sword affects
> > it, it must be aware of all types of swords (we may have, in addition to
> > normal swords, fire and frost brnad, etc.). If the aggressor is chosen to
> > know how its attack affects the defender, it must take into account all
> > possible creature types, armoury, weapon characteristics, etc.

> There's an easier solution.

There is an even easier solution :
-->'Reasonable Defaults'<--

If the defender creatures is specially vulnerable to a damage type, you
code. If it is impartial to the other types, you use standard damage
routines.

T.
 >> Stay informed about: OO paradigm in practice 

Jeff Lait wrote:
> Tapio Kelloniemi wrote:
>
>>I have not read sources of any roguelikes that are written in
>>Object-Oriented languages, but perhaps someone could suggest a game for me.
>>Also I'm interested in all techniques that could be used to solve the problem.
>
>
> My own personal conclusion is that this shows that the obvious OOP
> approach - have a "Weapon" class which has "Long sword" as a subclass -
> is incorrect for roguelikes. As you point out, the real interesting
> bits aren't with the weapons, but with the interaction of the items.
> The solution I use is to have a flat object hierarchy - an Item class
> that handles all types of items, and a Mob class that handles all types
> of creatures - and to use data-driven approaches to handle the
> interactions.
>
> This, of course, means that you end up with a bunch of if statements
> somewhere.

It's an excellent approach. I started out making a datatype
distinction between lots of different things, but insofar as
each and every thing can be misused for the purpose of another
(or at least the misuse can be attempted) I eventually decided
that "type errors" were a serious problem and made everything
that has physical existence in the dungeon the same type,
including monsters, the player character, and magic items.
In my code they are all "actors" and there is nothing to stop
you from, for example, using an unwilling tied-up gnome as
catapult ammo.

OO only makes sense for roguelikes, IMO, if you can specialize
methods on more than one parameter and you can do "identity
specialization" for unique objects. You don't really need a
whole bunch of if statements to find the right method, though.
You can handle it instead with callbacks and looking up the
"correct" function pointer in a datastructure. In C, this sort
of amounts to rolling your own OOP because C++ is too limited;
but it's way easier if you have experience with data-directed
code.

> It is important to note that this is no different from any
> OOP embedding. The OOP embedding disperses the if statements
> throughout your code which can be disadvantageous in understanding the
> code and detecting useful factorizations.

Actually, it mostly hides the "if statements" in the virtual
method tables.
Bear
 >> Stay informed about: OO paradigm in practice 

"Jeff Lait" <torespondisfutile RemoveThis @hotmail.com> wrote:
> Tapio Kelloniemi wrote:
>
>> I have not read sources of any roguelikes that are
>> written in Object-Oriented languages, but perhaps
>> someone could suggest a game for me. Also I'm
>> interested in all techniques that could be used to
>> solve the problem.
>
> My own personal conclusion is that this shows that
> the obvious OOP approach - have a "Weapon" class
> which has "Long sword" as a subclass - is incorrect
> for roguelikes. As you point out, the real
> interesting bits aren't with the weapons, but with
> the interaction of the items. The solution I use
> is to have a flat object hierarchy - an Item class
> that handles all types of items, and a Mob class
> that handles all types of creatures - and to use
> data-driven approaches to handle the interactions.

It is that idea that made me realize the difference between the object model
and the data model. A long sword is a weapon, yes... but an item is an item
is an item.


crichmon
 >> Stay informed about: OO paradigm in practice 

In article <447e2fa5$0$96946$742ec2ed@news.sonic.net>, bear.TakeThisOut@sonic.net
says...
>
> It's an excellent approach. I started out making a datatype
> distinction between lots of different things, but insofar as
> each and every thing can be misused for the purpose of another
> (or at least the misuse can be attempted) I eventually decided
> that "type errors" were a serious problem and made everything
> that has physical existence in the dungeon the same type,
> including monsters, the player character, and magic items.
> In my code they are all "actors" and there is nothing to stop
> you from, for example, using an unwilling tied-up gnome as
> catapult ammo.

I'm going to be a bit less flexible than that - I think it's only
important if you are a simulationist. I have an inheritance hierarchy
Creature->Monster->Player

Creature: basic position and time elements for a living (or undead or
robotic) thing, used when moving it around the dungeon.

Monster: It has a name, hitpoints, allegiance, poison status etc., and
has read-only access to a single-instance of a MonsterData class which
can tell it how many hits a typical specimen specimen has, what sort of
AI it uses if under automatic control, etc. (How MonsterData
initialises itself remains an open question - for now it uses switch
statements to fill in the instance.)

Player: It has an (optional) inventory, skills etc. (Pets are players
but essentially use only Monster functions.)

I'm not big on polymorphism - I have a vector of Players and a vector
of Monsters. If a monster is tamed it will be eradicated on the
monster vector. A Player with the appropriate allegiance and the same
characteristics will be created and added to the Player vector (and the
square on which it stands will have its occupant index set to the
appropriate value). Note: even without lists, you can upcast a Player
reference to a Monster reference, so I do have polymorphism in that
sense.

Over time, the Monster vector will become populated with dead and
eradicated monsters. I'm not worrying about that for now; I can add
garbage collection or apply some other kludge if necessary. Both
vectors will be recreated at the start of a new level. Using vectors
mean I can avoid pointers and use the indexes instead. There are
theoretically better ways of doing this, but at least it keeps things
simple.

Turns are sequential. When the game window is finished displaying any
visible animation data, it tells the Level to go onto the next
creature. The Players are cycled through in order, then the Monsters,
and so on. Creatures that are dead are skipped over. Some creatures
may perform a 'Wait' action. Some Players will probably have to wait
for mouse or keyboard input. If an event results in 'Animation' data
structures being sent to the window, it determines whether they are
visible on-screen, and if so it displays them before going on to the
next creature. (Otherwise they are just discarded.)

I haven't thought much about items yet. I'm only allowing one per
floor square - this is an aesthetic preference of mine, but it also
makes my coding life slightly easier.

> OO only makes sense for roguelikes, IMO, if you can specialize
> methods on more than one parameter and you can do "identity
> specialization" for unique objects. You don't really need a
> whole bunch of if statements to find the right method, though.
> You can handle it instead with callbacks and looking up the
> "correct" function pointer in a datastructure. In C, this sort
> of amounts to rolling your own OOP because C++ is too limited;
> but it's way easier if you have experience with data-directed
> code.

So far I haven't had any need for pointers except a few single-instance
classes such as Level and LevelWnd which have permanent pointers to
each other set at startup. As for callbacks... GAH!

I intend to base everything on vectors and enum-friendly indexes.


- Gerry Quinn
 >> Stay informed about: OO paradigm in practice 

Brent Ritchie wrote:
> I just have to add my two cents in. This is describing logical diferences in
> a universal sense. What must be done is look at the actual differences
> between a creature and a player. If you can think of at least 3 extra
> methods or at least 5 extra attributes then I might consider it.
>
> The only thing that really stands out as being different between a player
> and monster to me is the type of control that is used to "drive" them. With
> this you could just create a Controller interface, make one for AI and
> another for Keyboard. With this you could just add the cotrollers to the
> creatures and when it is the creatures turn they call their controller.

Maybe his AI controlled monsters have no inventory system, a smiplified
LOS, fewer actions they can take, and so on. Think Angband monsters.
However, I do agree with you in that I think the Creature superclass is
unnecessary.

Gamer_2k4
 >> Stay informed about: OO paradigm in practice 

> I have an inheritance hierarchy Creature->Monster->Player

I just have to add my two cents in. This is describing logical diferences in
a universal sense. What must be done is look at the actual differences
between a creature and a player. If you can think of at least 3 extra
methods or at least 5 extra attributes then I might consider it.

The only thing that really stands out as being different between a player
and monster to me is the type of control that is used to "drive" them. With
this you could just create a Controller interface, make one for AI and
another for Keyboard. With this you could just add the cotrollers to the
creatures and when it is the creatures turn they call their controller.

It really bugs me when I see lot's of inheritance in a model. Inheritence is
useful but it is not a silver bullet. I have learned this the hard way,
while working on contract for a few clients.

Well, that's all I really have to say about that.

Brent Ritchie
 >> Stay informed about: OO paradigm in practice 

Brent Ritchie wrote:
> Inheritence creates very
> tight coupling among objects that makes the whole program very hard to add
> to or change in the future.

Really? I never experienced that. For me (virtual) inheritance pretty
much removed the manual if-else hell for object types.

> With that said, I just hope someone thinks carefully before they decide to
> inherit in the future. It can bite you!

You don't need to think carefully if you use the inheritance properly.
You know, it was designed to help, not to bite you.
 >> Stay informed about: OO paradigm in practice 

"Gamer_2k4" <gamer2k4 RemoveThis @gmail.com> wrote in message
news:1149288270.186850.260010@c74g2000cwc.googlegroups.com...
>
> Brent Ritchie wrote:
>> I just have to add my two cents in. This is describing logical diferences
>> in
>> a universal sense. What must be done is look at the actual differences
>> between a creature and a player. If you can think of at least 3 extra
>> methods or at least 5 extra attributes then I might consider it.
>>
>> The only thing that really stands out as being different between a player
>> and monster to me is the type of control that is used to "drive" them.
>> With
>> this you could just create a Controller interface, make one for AI and
>> another for Keyboard. With this you could just add the cotrollers to the
>> creatures and when it is the creatures turn they call their controller.
>
> Maybe his AI controlled monsters have no inventory system, a smiplified
> LOS, fewer actions they can take, and so on. Think Angband monsters.
> However, I do agree with you in that I think the Creature superclass is
> unnecessary.
>

I was really just hinting that the OP should rethink their object hierarchy.
But Just because the LOS is simplified and the inventory may be non
functional that doesn't mean he can't have a single class. An interface
would be perfect for this example. Both Monsters and Player would act like a
single class, and you can add different funtionality. Another better way
could to be function pointers or what ever they are called in the particular
OOP language (Events or Delegates maybe?). This would allow for one class
and functionality could be changed at runtime.

There are many other ways to handle these problems. It's just a pet peeve of
mine that people automaticlly jump to inheritance. Inheritence creates very
tight coupling among objects that makes the whole program very hard to add
to or change in the future. Inheritence is not a silver bullet, It has it's
uses but it is also very easy to abuse as well.

With that said, I just hope someone thinks carefully before they decide to
inherit in the future. It can bite you!

> Gamer_2k4
>

Brent Ritchie
 >> Stay informed about: OO paradigm in practice 

Gerry Quinn wrote:
> [discussion of his OO structure for entities]

For what it's worth, the approach I'm working on at the moment (in
Python) is very similar.

A.
 >> Stay informed about: OO paradigm in practice