Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Item Deptiction questions

28 views
Skip to first unread message

Christopher Richmond

unread,
Sep 24, 2003, 11:13:51 AM9/24/03
to
First of all, let me say that I'm in the "blueprints" stage of design for my
roguelike game. :)

I'm attempting to create a representation of Items. I have a few ideas that
I'm sorting through, and I've even looked at some of the NetHack code to
gain some insight. I'm hoping I can get some feedback from the NG regarding
this issue.

First of all, I would like to represent Items in my game using
object-oriented design. There will be an Item class from which all Item
types will inherit from. That way I can place attributes that apply for all
Items in the parent class and then place type-specific attributes in
subclasses. For example, the class Weapon will inherit from Item, including
all of the Item attributes, and contain Weapon-specific attributes such as
damage modifiers. A well-designed inheritance hierarchy should allow for
all kinds of Item types.

Here's question(s) #1: What specific attributes should all Items have? And
what if my player wants to wield an Item of non-weapon type... how should
the code handle that?

Secondly... I plan on creating ItemComponents which will cover properties
that one-or-more Item types share. For example, the "WearableItemComponent"
will provide an interface for all Item types that are wearable. Since Armor
and Rings are both wearable, the Armor class and the Ring class will
implement the WearableItemComponent interface.

Question(s) #2: Does anyone see any problems with this? I will have to use
run-time type identification to determine if a specific component interface
has been implemeneted. I know that RTTI can get expensive. Does anyone
have any alternate suggestions?

Thirdly... there are little item decorations that could apply to all items.
For example, any item can become "blessed" (and likewise have a "blessed
identified?" indicator). Certainly using inheritance is not the solution
here. I would also like to avoid cluttering the Item parent class with a
lot of bitfields to represent each possibility ("rusted", "rustproof",
"lightsource", etc.). I considered using ItemDecorators to handle this...
as in the previous example, if an Item were to become blessed, it would have
a "BlessedItemDecorator" added to its set of decorations.

Question(s) #3: The first problem that I see is that this will effectively
result in an unorded linked list. Checking for one specific decoration may
result in traversing an item's entire list of decorators, which could be
bad. Also, if an item is _not_ blessed (and also not cursed), I might have
to implement an external functionality just to check for that. Is there a
better way?

These are the ideas I had. Some of it makes sense, but it seems overly
complex (then again, Items in roguelikes tend to be complex). If anyone has
any comments or suggestions on these issues, or can provide alternate
solutions, I would greatly appreciate it.


thanks,
crichmon


Mark 'Kamikaze' Hughes

unread,
Sep 24, 2003, 6:23:27 PM9/24/03
to
Christopher Richmond <crich...@hotmail.com>

wrote on Wed, 24 Sep 2003 15:13:51 GMT:
> First of all, I would like to represent Items in my game using
> object-oriented design. There will be an Item class from which all Item
> types will inherit from. That way I can place attributes that apply for all
> Items in the parent class and then place type-specific attributes in
> subclasses. For example, the class Weapon will inherit from Item, including
> all of the Item attributes, and contain Weapon-specific attributes such as
> damage modifiers. A well-designed inheritance hierarchy should allow for
> all kinds of Item types.

Yep. In Umbra, the hierarchy I use is:

Thing: any physical object
+-Door: opens or closes when triggered
+-Lamp: stationary light source
+-Vehicle: when boarded, a vehicle is moved instead of the party, and
| allows movement over water, etc.
+-Item: any Thing that can be carried
+-Equip: any Item that can be equipped
| +-Melee: any melee weapon
| +-Ranged: any ranged weapon
| +-Defense: any armor/headgear/shield
+-Loot: non-weapon Item
+-Ammo: ammunition for ranged weapons
+-Cash: loose change

Equip, Loot, and Thing are not "abstract" classes, there are instances
of them where I didn't need any specialized methods. I only create new
subclasses if I have to create new behavior.

> Here's question(s) #1: What specific attributes should all Items have? And
> what if my player wants to wield an Item of non-weapon type... how should
> the code handle that?

Every item that can be equipped should have a bitmask of which
equipment slots it can be equipped in. In Umbra, I use abstract slots:
Armor, Headgear, Shield, Melee Weapon, Ranged Weapon, Left Ring, Ring 2,
Accessory 1, Accessory 2. Others like more body-part-specific slots,
but either way, you should only be able to equip an item usable as a
weapon into your killin' hand.

> Secondly... I plan on creating ItemComponents which will cover properties
> that one-or-more Item types share. For example, the "WearableItemComponent"
> will provide an interface for all Item types that are wearable. Since Armor
> and Rings are both wearable, the Armor class and the Ring class will
> implement the WearableItemComponent interface.
> Question(s) #2: Does anyone see any problems with this? I will have to use
> run-time type identification to determine if a specific component interface
> has been implemeneted. I know that RTTI can get expensive. Does anyone
> have any alternate suggestions?

Flags are simpler and faster to use, and do exactly the same thing. I
used to be a hardcore "everything goes through the class hierarchy" OOP
junkie, but Python made me more pragmatic. Flags are also easier to
assign dynamically. I can describe most of my objects in a purely
data-driven format; with classes, that would be much harder (impossible
in most languages, just inconvenient in Python).

> Question(s) #3: The first problem that I see is that this will effectively
> result in an unorded linked list. Checking for one specific decoration may
> result in traversing an item's entire list of decorators, which could be
> bad. Also, if an item is _not_ blessed (and also not cursed), I might have
> to implement an external functionality just to check for that. Is there a
> better way?

Special effects are usually best handled with just an unordered list.
You don't usually scan so many items per turn that it's a problem, and
there's no sense in wasting a hash on them.

--
<a href="http://kuoi.asui.uidaho.edu/~kamikaze/"> Mark Hughes </a>
"The computer is incredibly fast, accurate, and stupid.
Man is unbelievably slow, inaccurate, and brilliant.
The marriage of the two is a force beyond calculation." -Leo Cherne

Kostatus

unread,
Sep 25, 2003, 5:20:11 AM9/25/03
to
On Wed, 24 Sep 2003 15:13:51 GMT, Christopher Richmond wrote:

SORRY ALL! I accidentally sent the previous reply (identical to this one)
with the X-No-Archive attribute on, which means people using google would
not be able to see this. As I said, this message is the same as my
previous reply to this post.

> First of all, let me say that I'm in the "blueprints" stage of design
> for my roguelike game. :)
>
> I'm attempting to create a representation of Items. I have a few ideas
> that I'm sorting through, and I've even looked at some of the NetHack
> code to gain some insight. I'm hoping I can get some feedback from the
> NG regarding this issue.
>
> First of all, I would like to represent Items in my game using
> object-oriented design. There will be an Item class from which all Item
> types will inherit from. That way I can place attributes that apply for
> all Items in the parent class and then place type-specific attributes in
> subclasses. For example, the class Weapon will inherit from Item,
> including all of the Item attributes, and contain Weapon-specific
> attributes such as damage modifiers. A well-designed inheritance
> hierarchy should allow for all kinds of Item types.
>

I've already implemented item handling and equipping the right items into
the
right equipment slots, it work great in all aspects and is easy to use and
implement, so I'll just tell you what I've done. I think it's somewhat
similar to Angband.

For items I have two structures. One is called "Item" and the other is
called "Item_kind". The Item structure holds the specific information
about
a specific item - eg how many uses it has left, what is the magnitude of
the
effects it does (in my game the magnitudes are randomly generated), the co-
ordinates of the item in the dungeon (your coords maybe stored differently,
so you may not need this). The Item structure also holds a variable with
an
index value pointing to an Item_kind structure.

The Item_kind structure holds information about the general kind of an item
- eg Standard health potions, Silver long swords, orcish round shields.
Here
the general information about the kind of item is stored - eg the dice to
generate the magnitude of the effect, the type of the effects that it does,
the type of item it is (potion, body armour, boots, gloves, weapon etc),
whether it has been identified by the player.

When the game starts, all the different item kinds that I have are
initialize. That is I put different Item_kind structures into an array
with
their position in the array being determined by the index of the item kind
to
which each Item created from the Item_kind references to (eg and Item_kind
structure holding information about the "standard health potion" item kind
is
stored in my array of Item_kind structures under the index 5 (arr[5]), when
a
"standard health potion" is created the program reads arr[5] and gets the
information about the item).

> Here's question(s) #1: What specific attributes should all Items have?

This should depend on what you want your items to do and how you implement
them in your code. Start with only the basic features and add to these as
you progress through your project.

> And what if my player wants to wield an Item of non-weapon type... how
> should the code handle that?

With my project, each Item_kind stores a number indicatig what type of item
it is (more general than "silver long sword 1d5" or "standard health
potion"
eg sword, weapon, potion), and when you try to equip an item into a slot
the
program checks whether it is the right type of item for the slot - to equip
something on your head it has to be of the "hat" type.

> Secondly... I plan on creating ItemComponents which will cover
> properties that one-or-more Item types share. For example, the
> "WearableItemComponent" will provide an interface for all Item types
> that are wearable. Since Armor and Rings are both wearable, the Armor
> class and the Ring class will implement the WearableItemComponent
> interface.
>
> Question(s) #2: Does anyone see any problems with this? I will have to
> use run-time type identification to determine if a specific component
> interface has been implemeneted. I know that RTTI can get expensive.
> Does anyone have any alternate suggestions?

If you do insist on using OOP (which I do not suggest for items at least),
you could make your own function that, when called returns a value
specifying
what type of object it is.

I used this for the creatures in my game. First of all I had a generic
creature class from which I publicly derived a "hero" class and a
"monster"
(monsters are treated like items - with a monster_kind class), I only used
this (instead of structures as in items) because heros are not the same as
monsters - and cannot be initialized using the same structures, but they
have
a lot in common - the way that they are displayed on the map, many of the
attributes, inventory etc. The following is a C++ example of what I used
(simplified of course):


class creature
{
protected:
// protected variables and functions...
public:
// public variables and functions...
virtual bool isHero() = 0; // don't forget "virtual" here!
}

class monster : public creature
{
private:
// its own private variables and functions...
public:
// its own public variables and functions...
bool isHero() { return false; }
}

class hero : public creature
{
private:
// its own private variables and functions...
public:
// its own public variables and functions...
bool isHero() { return true; }
}

When a function calls isHero() from a pointer to hero, true is returned if
the object is a hero and false if the object is not. In your case you
could
have it return an integer, if it's a 1 then it's a potion, if it's a 2 then
it's a weapon etc.


> Thirdly... there are little item decorations that could apply to all
> items. For example, any item can become "blessed" (and likewise have a
> "blessed identified?" indicator). Certainly using inheritance is not
> the solution here. I would also like to avoid cluttering the Item
> parent class with a lot of bitfields to represent each possibility
> ("rusted", "rustproof", "lightsource", etc.). I considered using
> ItemDecorators to handle this... as in the previous example, if an Item
> were to become blessed, it would have a "BlessedItemDecorator" added to
> its set of decorations.

In my case, I can have (have not implemented blessed/cursed yet) a "bool
bBlessed; " variable, or I could use flags.

> Question(s) #3: The first problem that I see is that this will
> effectively result in an unorded linked list. Checking for one specific
> decoration may result in traversing an item's entire list of decorators,
> which could be bad. Also, if an item is _not_ blessed (and also not
> cursed), I might have to implement an external functionality just to
> check for that. Is there a better way?

You could use maps from the Standard Template Library, they sort your list
according to index, and you can access them randomly (ie using square
brackets).

> These are the ideas I had. Some of it makes sense, but it seems overly
> complex (then again, Items in roguelikes tend to be complex). If anyone
> has any comments or suggestions on these issues, or can provide
> alternate solutions, I would greatly appreciate it.

As I said, I recomend you try what I'm using for items (I think its quite
similar to Angband, but the Angband code seems very confusing to me), it
works great for me. OOP is too complex and it would get too complicated
with
a new class for each item type. Feel free to ask me any questions if you
don't understand what I've written here.


--
Kostatus
kostatus001 at ihug co nz

The Sheep

unread,
Sep 25, 2003, 6:57:53 AM9/25/03
to
Dnia Wed, 24 Sep 2003 15:13:51 GMT, Christopher Richmond napisal(a):

> Secondly... I plan on creating ItemComponents which will cover properties
> that one-or-more Item types share. For example, the "WearableItemComponent"
> will provide an interface for all Item types that are wearable. Since Armor
> and Rings are both wearable, the Armor class and the Ring class will
> implement the WearableItemComponent interface.

I'm doing it in quite a different way. There is an `Item' object, that have
all the information necessary to handle it within inventory (weight, price,
danger level, looks, etc.) and it holds a list of `Usages'. The usages are
the ways you can use the item and they hold appropriate parameters.
For example, let's consider `Wear on head' usage. It would have all the armor
attributes, together with any resistances, etc. It would inherit after
`Wearable' interface and have `wear' and `take_off' methods.
Examples of other usages are: `Wield one handed', `Wield two handed', `Drink',
`Eat', `Wear on feet', `Wear as cloak', etc.

Then, you don't have really equipment slots for items. The things you put
into your equipment slots are usages -- some of them are exclusive, like
most `wear' commands, and some are not, like `use as tool' and `wield'.
(You can have the same item in your weapon and tool slots at the same time).

You can only use given item in some way if it has appropriate usage. Some
item classes may have `automatic' usages included, for example
`wield as improvised mace' would calculate the weapon attributes from item's
weight and size. Similarilly with `improvised missile' and so on.

Some usages may become active or inactive depending on item's state (blessed,
damaged, etc.) and character's skills.

> Question(s) #2: Does anyone see any problems with this? I will have to use
> run-time type identification to determine if a specific component interface
> has been implemeneted. I know that RTTI can get expensive. Does anyone
> have any alternate suggestions?

You just make some enum in your parent class and make sure all the constructors
fill the enum apropriately with the object's name. Or maybe flags would be
more appropriate, for multiple inheritance?
I would advise you not to use RTTI -- you don;t need it anyways when your
project is trurly OO, not hybrid.

> Thirdly... there are little item decorations that could apply to all items.
> For example, any item can become "blessed" (and likewise have a "blessed
> identified?" indicator). Certainly using inheritance is not the solution
> here. I would also like to avoid cluttering the Item parent class with a
> lot of bitfields to represent each possibility ("rusted", "rustproof",
> "lightsource", etc.). I considered using ItemDecorators to handle this...
> as in the previous example, if an Item were to become blessed, it would have
> a "BlessedItemDecorator" added to its set of decorations.

These things go into main `Item' class, and the usages may check for them.
Eventually you might have some additional blessed usages that will get enabled
when the item is blessed (and eventually replace the `normal' usages). Making
a default `blessed' usage (that would use normal usage but add to it's
attributes) and replacing it sometimes with a special one seems a good idea here.

> Question(s) #3: The first problem that I see is that this will effectively
> result in an unorded linked list. Checking for one specific decoration may
> result in traversing an item's entire list of decorators, which could be
> bad. Also, if an item is _not_ blessed (and also not cursed), I might have
> to implement an external functionality just to check for that. Is there a
> better way?

Yes. Make it an ordered list. Or a heap. Or use any predefined set type your language
has (either in Java or STL). They are quite optimized, you know...

--
Radomir `The Sheep' Dopieralski
Sanity test, one, two, three... five?

Jeff Lait

unread,
Sep 25, 2003, 12:05:54 PM9/25/03
to
"Christopher Richmond" <crich...@hotmail.com> wrote in message news:<Pwicb.423439$Oz4.217384@rwcrnsc54>...

> First of all, let me say that I'm in the "blueprints" stage of design for my
> roguelike game. :)
>
> I'm attempting to create a representation of Items. I have a few ideas that
> I'm sorting through, and I've even looked at some of the NetHack code to
> gain some insight. I'm hoping I can get some feedback from the NG regarding
> this issue.

Now that is a hard problem...

> First of all, I would like to represent Items in my game using
> object-oriented design. There will be an Item class from which all Item
> types will inherit from. That way I can place attributes that apply for all
> Items in the parent class and then place type-specific attributes in
> subclasses. For example, the class Weapon will inherit from Item, including
> all of the Item attributes, and contain Weapon-specific attributes such as
> damage modifiers. A well-designed inheritance hierarchy should allow for
> all kinds of Item types.

I still believe that inheritance isn't what will work best. I believe
you will be better off working with aggregation.

> Here's question(s) #1: What specific attributes should all Items have? And
> what if my player wants to wield an Item of non-weapon type... how should
> the code handle that?

Items should have ALL attributes. Thus, the code doesn't have any
problems wielding a non-weapon item.

> Thirdly... there are little item decorations that could apply to all items.
> For example, any item can become "blessed" (and likewise have a "blessed
> identified?" indicator). Certainly using inheritance is not the solution
> here. I would also like to avoid cluttering the Item parent class with a
> lot of bitfields to represent each possibility ("rusted", "rustproof",
> "lightsource", etc.). I considered using ItemDecorators to handle this...
> as in the previous example, if an Item were to become blessed, it would have
> a "BlessedItemDecorator" added to its set of decorations.

This is a good approach for all your item attribute problems, IMO.
You can have a MeleeDamageDecorator and a ThrownDamageDecorator, etc.
You don't need an inhertiance structure then, but rather can go data
driven.

Instead of:
if (item->isWeapon())
{
WEAPON *weapon = (WEAPON *) item;
// apply damage using the weapons special functions.
}

You have:

MeleeDamageDecorator *melee =
item->getDecorator(MELEE_DAMAGE_DECORATOR);

if (!melee)
// User bashes with a non-weapon
else
// apply damage from melee's special functions.

Now, if you want spiked boots that can be held in the hand to smash
people, it is just a question of applying the right decorators.

> Question(s) #3: The first problem that I see is that this will effectively
> result in an unorded linked list. Checking for one specific decoration may
> result in traversing an item's entire list of decorators, which could be
> bad. Also, if an item is _not_ blessed (and also not cursed), I might have
> to implement an external functionality just to check for that. Is there a
> better way?

This is not a problem. Either:
1) Most items have few decorators, so a linked list is fast enough
2) Some decorators are in all items, so can be special cased & avoid
the look up.
Finally, it doesn't matter at all, as you can always place a hash
table or other structure if this becomes a bottleneck. After all, all
your decoration tests are:
if (item->hasDecoration(BLESSED_DECORATION))
// Blessed.
What the hasDecoration() and getDecoration() might do is factored into
one single place.

> These are the ideas I had. Some of it makes sense, but it seems overly
> complex (then again, Items in roguelikes tend to be complex). If anyone has
> any comments or suggestions on these issues, or can provide alternate
> solutions, I would greatly appreciate it.

I recommend you go with an all-decoration driven approach. I
recommend you avoid building inheritance on the ITEM or MOB
(creature). I recommend you insted do the inheritance in your
DECORATION class. These are all just recommendations, YMMV :>

In POWDER, I'm sort of doing this. First, I don't subclass ITEM or
MOB at all. Secondly, the data for items and mobs is defined
externally. This data format allows for the specification of default
values. Thus, while every item has an attack value, the vast majority
just take the default so I don't have to keep specifying it. The
closest I have to the proper decorations approach is the count down
timers for intrinsics.

I don't have:
MOB::MOB
{
bool myConfused, myWaterWalk, myInvisible...;
}

Instead, I have:

MOB::MOB
{
u8 myIntrinsics[(NUM_INTRINSICS + 7)/8];
INTRINISC_COUNTER *myCounters;
}
mob->hasIntrinsic(INTRINSIC_CONFUSED);
mob->setTimedIntrinsic(INTRINSIC_INVISIBLE, 100);

Thus the hasIntrinsic test can just check the bitfield of all possible
intrinsics, and the setTimedIntrinsic can add the appropriate counter
to the linked list.

The advantage here is that I can replace the back end of how
intrinsics work with a smarter, more space/time efficient one, without
having to change any other code.

- Jeff Lait
(POWDER: http://www.zincland.com/powder)

Christopher Richmond

unread,
Sep 26, 2003, 12:29:05 AM9/26/03
to
Thanks for all of your comments, they've been helpful.

--
crichmon


Archibald

unread,
Sep 26, 2003, 7:43:55 AM9/26/03
to
In article <Pwicb.423439$Oz4.217384@rwcrnsc54>, crich...@hotmail.com
says...

> First of all, I would like to represent Items in my game using object-oriented design.

There are two areas where you definitively shouldn't use OOP. Items and
monsters. These things should share ALL abilities and parameters. If you
do it other way you will be sorry sooner or later...

BTW read source codes first, there are lots available open source
roguelikes. This will help you a lot during development phase.

--
Archibald

Paul Pekkarinen

unread,
Sep 26, 2003, 9:59:59 AM9/26/03
to
"Christopher Richmond" <crich...@hotmail.com> wrote in message
> Here's question(s) #1: What specific attributes should all Items have?

First ask what attributes should objects have in common.

> And what if my player wants to wield an Item of non-weapon type...
> how should the code handle that?

My code will rule out all but weapons, so you can't wield anything
but weapons (why should you anyway?). It's the fast way to do it,
but I was thinking of another way, using some "physics" simulation:
how the object will work as weapon is determined by its material
and shape (and weight). The shape can be an abstract list of shapes
like "pointy" or "pick-axe-like" etc.

Christopher Richmond

unread,
Sep 26, 2003, 4:33:21 PM9/26/03
to

"Jeff Lait" <torespon...@hotmail.com> wrote in message
news:774acfb8.03092...@posting.google.com...


> I still believe that inheritance isn't what will work best. I believe
> you will be better off working with aggregation.

> ...


> This is a good approach for all your item attribute problems, IMO.
> You can have a MeleeDamageDecorator and a ThrownDamageDecorator, etc.
> You don't need an inhertiance structure then, but rather can go data
> driven.
>
> Instead of:
> if (item->isWeapon())
> {
> WEAPON *weapon = (WEAPON *) item;
> // apply damage using the weapons special functions.
> }
>
> You have:
>
> MeleeDamageDecorator *melee =
> item->getDecorator(MELEE_DAMAGE_DECORATOR);
>
> if (!melee)
> // User bashes with a non-weapon
> else
> // apply damage from melee's special functions.
>
> Now, if you want spiked boots that can be held in the hand to smash
> people, it is just a question of applying the right decorators.

> ...


> I recommend you go with an all-decoration driven approach. I
> recommend you avoid building inheritance on the ITEM or MOB
> (creature). I recommend you insted do the inheritance in your
> DECORATION class. These are all just recommendations, YMMV :>

I think I like your comments the best. The main thing I want to achieve is
building Items from various components or decorators, and be able to do it
dynamically. That way I can design specific Items at object creation, and
by designing the Item class to be able to handle all components or
decorators, I can add and remove attributes when necessary. This also helps
with handling user commands (the command "wear" can be applied to Items that
have the "wearable" decorator, other Items without return an error). So
when my archaeologist is digging using the tool "pick-axe", a default weapon
decorator can be added to handle combat with it.


thanks,
crichmon


Christopher Richmond

unread,
Sep 26, 2003, 4:49:51 PM9/26/03
to

"Archibald" <-@-.-> wrote in message
news:MPG.19dd6f2cb...@news.tpi.pl...

> There are two areas where you definitively shouldn't use OOP. Items
> and monsters. These things should share ALL abilities and parameters.
> If you do it other way you will be sorry sooner or later...

I disagree. One extreme argument against: why seperate Items and Monsters
into seperate classes? Why not make a general GameObject class and include
all attributes and parameters and such? Because they're two different types
of things. The same argument can be made about Items: are weapons and suits
of armor the same? Then why let your weapon include an AC modifier when it
doesn't apply? Why let your armor include speed factors and damage dice
when they don't apply?

Object-oriented design and programming is a good thing. There may be more
overhead required, but for a turn-based game with simple graphics such as
roguelikes and with today's fast computers, I don't think the overhead is
really an issue.


> BTW read source codes first, there are lots available open source
> roguelikes. This will help you a lot during development phase.

I have read a majority of the NetHack code. While there is a lot to learn
from open source roguelikes, I think there's also a lot to learn about what
not to do. NH is very monolithic in nature. Not to knock it at all here,
it is an impressive piece of software. I may be considered an "OOP-junkie",
but I'd rather have nicely organized code that's easy to read and makes
sense. OOP code is just easier to work with and upgrade, IM_V_HO.


crichmon


Kostatus

unread,
Sep 26, 2003, 7:16:16 PM9/26/03
to
On Fri, 26 Sep 2003 20:49:51 GMT, Christopher Richmond wrote:

>> There are two areas where you definitively shouldn't use OOP. Items
>> and monsters. These things should share ALL abilities and parameters.
>> If you do it other way you will be sorry sooner or later...
>
> I disagree. One extreme argument against: why seperate Items and
> Monsters into seperate classes? Why not make a general GameObject class
> and include all attributes and parameters and such? Because they're two
> different types of things. The same argument can be made about Items:
> are weapons and suits of armor the same? Then why let your weapon
> include an AC modifier when it doesn't apply? Why let your armor
> include speed factors and damage dice when they don't apply?

In my project every item structure has several variables labelled mEffect1,
mEffect2, mEffect3, etc. These hold the magnitude of the effect. Also, for
each effect there's an mEffectType variable, which holds information about
the type of effect that the corresponding effect does. This way there's no
need for multiple classes (or even OO), no need for weapons to include an
AC modifyer when it doesn't apply or any other items include unnecessary
modifyers. Also, this still gives me the freedom of having a sword which
would increase your AC if I need one (magical sword of defensive force
field or something).

As I've said earlier in this thread, I have used some basic OO for my
monsters though. Because monsters are very similar to Heroes, they have
many of the same attributes, perform many similar actions and are handled
in the exactly the same way by my dungeon display. However, I could not
make them share the same class/structure because they also have differing
attributes and functions. So I had a "monster" class and a "hero" class
both derived from a "creature" class. However, I do not use different
classes for every different type of monster.

<snip>

Ray Dillinger

unread,
Sep 26, 2003, 9:12:38 PM9/26/03
to
Kostatus wrote:
>
> As I've said earlier in this thread, I have used some basic OO for my
> monsters though. Because monsters are very similar to Heroes, they have
> many of the same attributes, perform many similar actions and are handled
> in the exactly the same way by my dungeon display. However, I could not
> make them share the same class/structure because they also have differing
> attributes and functions. So I had a "monster" class and a "hero" class
> both derived from a "creature" class. However, I do not use different
> classes for every different type of monster.

I made heros and monsters the same type of struct. The differences,
finally,
are very minor. The monster has an AI that calls a procedure to see
what the
monster will do next, and it gets called whenever the monster has a
decision
point.

That procedure is the first point of difference. It checks to see if
this
particular monster is the player, and dispatches to GetMonsterAction or
GetPlayerAction. GetPlayerAction puts up a dungeon screen, takes an
input
keystroke (or more than one -- it may go through several screens if the
player consults map, inventory, etc), translates the keystroke into a
game
action, and returns the action, which is then processed exactly the same
for all monsters. There are some actions, such as quitting the game,
saving, etc, that monster AI simply never picks.

If a monster dies, a routine called burymonster is called, and that
makes
the second point of difference. It removes the monster from the
timequeue
and the map - then it checks to see whether the monster is the player,
and if it is, it invokes QuitGame.

The rest is just setup, bookkeeping, and teardown. While the game is
running, those two routines are the only difference.

Bear

Jeff Lait

unread,
Sep 27, 2003, 1:32:09 PM9/27/03
to
"Christopher Richmond" <crich...@hotmail.com> wrote in message news:<PD1db.593868$o%2.272857@sccrnsc02>...

>
> The same argument can be made about Items: are weapons and suits
> of armor the same? Then why let your weapon include an AC modifier when it
> doesn't apply? Why let your armor include speed factors and damage dice
> when they don't apply?

1) It might apply.
2) By your own statement, performance is not a justification with
todays computers. Thus, there is no reason decry the "waste" of
having an attack speed modifier on a suit of chain mail. Of course,
this comes down to design - it is quite possible to have a generic
ITEM class that APPEARS to have all the data for all attributes, but
just returns defaults for undefined values.



> Object-oriented design and programming is a good thing. There may be more
> overhead required, but for a turn-based game with simple graphics such as
> roguelikes and with today's fast computers, I don't think the overhead is
> really an issue.

I agree it is a good thing. But IMHO, for ITEM & MOB, it is a
slippery slope. For a correct OOP approach to ITEMs, I'd put the
inheritance part in the attributes, not in the container.

As for the question of separating monsters from the player? Here I am
now divided. I started POWDER with the player being just another
monster. My theory was this would provide discipline in ensuring that
whatever the player can do, monsters can do, and vice versa.

However, for gameplay reasons, I've found myself with numerous special
cases for the hero. If the hero falls through a hole in the ground,
the active map must change, while if a grid bug falls through the
hole, the active map stays the same. The AI is similar - for good
gameplay it is useful to have monsters single out the player for
eradication. And, for efficiency, it is a lot easier just to grab the
player object and make that a default target than search all available
targets and use some complicated weighting to determine the next
victim.

My current solution is to have a static MOB::getAvatar() which gets
the active player. Thus, one can check if one is the player (if (this
== MOB::getAvatar())) or get the active avatar (mob =
MOB::getAvatar()). This avoids the need for deriving the avatar, but
means that the functions that must be different have:
if (this == MOB::getAvatar())
// Do A
else
// Do B
Which is disgusting, IMHO. Of course, that encourages me to minimize
these cases :>

I think the answer to this should depend on how far along the spectrum
of "programmer roguelike" you want to fall. This is one area in which
POWDER is slipping into the "Make it a fun game rather than ensure
everything is properly orthogonal".

Christopher Richmond

unread,
Sep 28, 2003, 12:54:51 PM9/28/03
to

"Jeff Lait" <torespon...@hotmail.com> wrote in message
news:774acfb8.03092...@posting.google.com...
> "Christopher Richmond" <crich...@hotmail.com> wrote in message
news:<PD1db.593868$o%2.272857@sccrnsc02>...
>
>> The same argument can be made about Items: are weapons and suits
>> of armor the same? Then why let your weapon include an AC modifier when
it
>> doesn't apply? Why let your armor include speed factors and damage dice
>> when they don't apply?
>
> 1) It might apply.

Might. By the design discussed, these modifiers could be added later and
don't necessarily need to exist for all Items.

> 2) By your own statement, performance is not a justification with
> todays computers. Thus, there is no reason decry the "waste" of
> having an attack speed modifier on a suit of chain mail. Of course,
> this comes down to design - it is quite possible to have a generic
> ITEM class that APPEARS to have all the data for all attributes, but
> just returns defaults for undefined values.

I wasn't focusing on the waste of having the extra value, simply the lack of
a need for them. Default values can work fine, but I thought it might be
easier to just skip the modification code for an undefined value rather than
making a modification of zero.


>> Object-oriented design and programming is a good thing. There may be
more
>> overhead required, but for a turn-based game with simple graphics such as
>> roguelikes and with today's fast computers, I don't think the overhead is
>> really an issue.
>
> I agree it is a good thing. But IMHO, for ITEM & MOB, it is a
> slippery slope. For a correct OOP approach to ITEMs, I'd put the
> inheritance part in the attributes, not in the container.

I think I may make the attempt to use inheritance in defining the items. I
don't necessarily want to argue which design is better, just discuss what
works best for the particular developer.


> As for the question of separating monsters from the player? Here I am
> now divided. I started POWDER with the player being just another
> monster. My theory was this would provide discipline in ensuring that
> whatever the player can do, monsters can do, and vice versa.
>
> However, for gameplay reasons, I've found myself with numerous special
> cases for the hero.

Perhaps you could create a "player" or "hero" class which has a reference to
the hero's "monster." If one of your special cases occurs, the monster
would notify the hero object, which would handle the special cases such as
changing the active map.


crichmon


Joseph Giroux

unread,
Sep 28, 2003, 11:49:14 PM9/28/03
to
> My code will rule out all but weapons, so you can't wield anything
> but weapons (why should you anyway?).

Well, maybe:

You want to smash that orc over the head with your potion of
paralysis.

Or that wand of fire might not have any more bolts left in it, but
maybe if you shove it in that troll's ribs and shatter it, it would
have enough spark left to do him in.

Or you can't hurt that shade with your sword, but a silver ring could
do the trick. (Nethack, natch)

Or you find a cockatrice corpse. (...)

Or you get saddled with an iron ball. (...)

Or you are cornered with nowhere to go and your weapon was disarmed,
but you do have this heavy spiked helmet you found earlier.

Or.... gosh, I dunno, you have a bear fur and it just so happens the
sorceror you're about to face is allergic to bears. Whatever.

As always, it's a matter of deciding how much work you want to put
into allowing flexibility in the future, for features you don't
envision now, and might not even ever want to implement.

The Sheep

unread,
Sep 29, 2003, 10:31:34 AM9/29/03
to
Dnia Fri, 26 Sep 2003 23:16:16 +0000 (UTC), Kostatus napisal(a):

> On Fri, 26 Sep 2003 20:49:51 GMT, Christopher Richmond wrote:

> In my project every item structure has several variables labelled mEffect1,
> mEffect2, mEffect3, etc. These hold the magnitude of the effect. Also, for
> each effect there's an mEffectType variable, which holds information about
> the type of effect that the corresponding effect does.

Woudn't it be more convenient to use arrays? ^^)))

Christopher Richmond

unread,
Sep 29, 2003, 4:23:42 PM9/29/03
to

"Joseph Giroux" <smil...@lycos.com> wrote in message
news:c782f75.03092...@posting.google.com...

>> My code will rule out all but weapons, so you can't wield anything
>> but weapons (why should you anyway?).
>
> Well, maybe:
>
> You want to smash that orc over the head with your potion of
> paralysis.
> ...

> Or.... gosh, I dunno, you have a bear fur and it just so happens the
> sorceror you're about to face is allergic to bears. Whatever.
>
> As always, it's a matter of deciding how much work you want to put
> into allowing flexibility in the future, for features you don't
> envision now, and might not even ever want to implement.

How do you suggest implementing the representation of items then? just
curious.


crichmon


Ray Dillinger

unread,
Sep 29, 2003, 6:01:33 PM9/29/03
to
Christopher Richmond wrote:
>
> > As always, it's a matter of deciding how much work you want to put
> > into allowing flexibility in the future, for features you don't
> > envision now, and might not even ever want to implement.
>
> How do you suggest implementing the representation of items then? just
> curious.

He's recommending DD rather than OO programming. For what it's
worth, I agree with him in this case: I don't think OO (unless used
with *extreme* care to fiddly corner cases) will really give folk
enough flexibility to do a roguelike.

Object-Oriented programming focuses on subtype/supertype relationships,
and tries to build a hierarchy of descriptions where each "method"
applies only to the "appropriate" subtypes. The problem with this
approach in a roguelike is that "inappropriate" use is frequently
crucial to realistic or fun play.

Data-Directed programming focuses on object attributes, and defines
functions (not methods) that will work on any thing that has some
particular set of attributes.

The classic OO approach would be to define "Physicalthing" as
having some attributes generic to all physical things, such as
a size, mass, possibly a monetary value, classification name,
identified name, description and a material. Then the OO guy
would subype "weapons" off of physicalthing inheriting all of
those attributes and adding more like attackval and attackspeed
and so forth. Then subtype "armor" off of physicalthing again,
with armor attributes like "defval" and "speedpenalty" and so
forth in addition to the inherited stuff.

Each of these subclasses then has "methods" such as
Physicalthing.PickUp or Physicalthing.Drop or Weapon.Attack or
Armor.Defend that allows it to be used and allow different
types or kinds of it to be used differently.

A Data-Directed approach to the same problem defines
"physicalthing" as having some relatively large number of
attributes, including (but not necessarily limited to) the
union of all the attributes that the OO program would have
for armor, weapons, and physicalthings, and then has a bunch
of functions (not object methods) called PickUpThing and
DropThing and AttackWithThing and DefendWithThing and so
on. You can use any function with any physicalthing. The
function itself has to check for type-inappropriateness if
you want to, eg, refuse to allow anyone to throw a ring for
damage.

In a DD program, different kinds of things will be differentiated,
not by their data representation, but by the kind of function
that creates them. So when I CreateRing (material, stone,
decoration) I don't have to worry about attackval and attackspeed
and size and mass and so on; but the constructor function knows
about rings, and it will fill in default values for size and
mass, then call something else that calculates default values
for attackspeed and attackval given size and mass and material,
and before it returns it will fill in "default" values for
all of the stuff that wasn't worth specifying in the case of
rings.

Now my "AttackThrow" function can take a tomahawk, which was
designed for throwing (ie, has nondefault values for most of
the stuff that's important for throwing and defaults derived
from its size/mass/material for other stuff) or it can take
a ring, which wasn't designed for throwing, but can still be
thrown for some tiny amount of damage (and maybe a nice bonus
if it happens to be made out of silver and you happen to be
throwing it at a vampire).

Likewise, if I run out of ammo for my sling, I can use
potatos from my food supply or rubies from my treasure sack
or even dead mice as sling bullets if necessary, because the
"FireFromSling" function is going to look at a physicalthing,
find that it's a reasonable size and mass, and not have a
problem. Likewise if someone wants to wield a helmet as a
meelee weapon, or whatever else, that's okay too; not as nice,
probably, as a knife, but okay and at least minimally useful.

Achieving the same kind of flexibility in an OO style is
going to take a lot more work, in terms of checking for all
the corner cases and providing specialized error methods and
messages for a bunch of different (and frequently unnecessary)
type errors.

And that is one reason why I think that roguelikes suit a DD
style much better than they suit an OO style of programming,
and why I'm using C for the roguelike instead of an OO-fascist
language like Java. Don't get me wrong, Java is nifty; it's
just not the best fit for this problem because it's too
dependent on OO and classes.

Bear

Moah, full time turnip.

unread,
Sep 29, 2003, 7:42:06 PM9/29/03
to
Mark 'Kamikaze' Hughes wrote:

> I've written multiple roguelikes and CRPGs using detailed OOP
> hierarchies, so that's very much not the case. Basically, what you're
> recommending is the use of a 30-year-old programming model, which has
> been abandoned by every professional programmer for very good reasons.

Actually, having skimmed what he wrote, he's recommending to try and
build an OO model without OO tools.

Moah, full time turnip.


Ray Dillinger

unread,
Sep 29, 2003, 10:11:40 PM9/29/03
to
Mark 'Kamikaze' Hughes wrote:
>
> I've written multiple roguelikes and CRPGs using detailed OOP
> hierarchies, so that's very much not the case. Basically, what you're
> recommending is the use of a 30-year-old programming model, which has
> been abandoned by every professional programmer for very good reasons.

Hey. Do whatever you're most comfortable with. :-)

I use OO where I think it's appropriate; but it ain't the
universe, at least not for me. Some problems are OO; some
are DD; some are functional; some are unification. It's
all a matter of picking the tool in my bag that fits the
shape of the problem best.

Roguelikes are, at least so far, on a border area; you can
do it well using OO, but I think you're going to wind up
having to care about a lot of things you don't have to care
about in DD programming. And you can do it well using DD,
but you're not going to have the kind of separation of ideas
that would enable a large herd of people to work on it without
getting in each other's hair.

Since I don't have a large herd of people to work on it, I
don't see any advantage to OO in this case.

Bear

Joseph Giroux

unread,
Oct 1, 2003, 12:28:39 PM10/1/03
to
"Christopher Richmond" <crich...@hotmail.com> wrote in message news:<ix0eb.632754$Ho3.121625@sccrnsc03>...

>
> How do you suggest implementing the representation of items then? just
> curious.

Warning, long winded post ahead:

Well, you said you wanted to use OO, I'd suggest to shift some of your
item data upward in the hierarchy. All items could have an attack
value, which simply represents the order of damage the item does to a
physical creature by smacking into it, along with the "type" of
physical damage, if you use some sort of bash/slash/pierce system
or other physical damtype distinction.

If you plan to have items like trees or statues that won't be
picked up by any means, you might have a HoldableItem subclass
which will contain attack values, so you don't have to calculate
those values for items the player will never hold.

This only applies if you don't want to allow the player to polymorph
into a titan and rip trees out of the ground and beat things with
it. (Or even set it on fire and swing it around.) If you want
to allow this, well, just treat those items like any other item,
just heavier.

When an item is constructed, it derives its own attack value. There
should be a default constructor which will derive an attack value based
on weight and mass (and probably give it a bludgeoning damtype), while
item types that will be handled differently have their own values
in their constructor: i.e. a potion might have an abnormally high
attack value for its weight, as well as doing pierce or slash damage
from the broken shards. (Or maybe not, see below)

For special effects, I think it'd be convenient to use bitflags
in the item class to reflect certain magical/elemental properties
that any item might conceivably hold. You have FLAG_FIRE, FLAG_ICE,
FLAG_POISON, FLAG_LIGHTNING, whatever. This makes it easy for you
to have a spell that will endow a weapon or other item with that
property temporarily, and give it all the associated effects. It
also sets the groundwork for the titan swinging around the burning
tree.

So, you then need ItemAttack type functions. A default can easily
be put together that will do damage based on the attack values given
it, then call a DoElementalEffectsToMe function in the target monster
(or player) with the item's property flags. This will handle regular
weapons simply but adequately, and allow instrinsic special effects
in any item.

For fancy weapon moves, or breaking potions, or stabbing with wands,
you need a particular ItemAttack for each such item type. You can
get as frilly as you want here. Maybe you have to have a good
enough swing (STR check) to actually break the potion (otherwise it
will be like a very poor club) or snap the wand (very poor relatively
pointy object). If the break is successful, then you can
PhysicalDamageMe to the monster, and call your HitMeWithSpell or
whatever, using the effect the wand or potion has. Note that even if
you just do a DoElementalEffectsToMe when the item breaks, as long as
you have set things like FLAG_POISON for a poison potion, or FLAG_FIRE
for a wand of fire bolt, you will get the basic effects very cheaply
in terms of work time. (or even FLAG_HEALING for a healing potion?
Note that then it would also be a simple matter to make a weapon that
heals when it hits. Then a somewhat less simple but very much doable
matter to give you a spell to cast on a monster which will give their
weapon healing magic! The cuts might still hurt, but you'll get
some healing with every hit. An intelligent monster might notice,
etc.)

Your functions DoElementalEffectsToMe and HitMeWithSpell can also
take arguments defining the strength of the attack, which can vary
based on whether the potion was drunk or merely splashed on you,
whether it was ultra healing or lesser healing, whether it was poison
or concentrated cobra venom, or how many charges the wand had.
(Happy balancing!)

Weapons might also be able to hold specific spell effects. You
might create an artifact weapon that casts a very weak slow monster
spell with every hit. Hmmm, now that's a weapon I'd like to see in
a RL.

So already, you have a wide range of tactics at your disposal:
Maybe that Great White Wyrm can heal itself too fast for you
to take it down with fire bolts from your wand, but if you can
safely get close enough to successfully shove a few fully
charged wands in its side, you might be able to take it down,
even though it's less efficient and more dangerous.

For the burning tree (and all sorts of other burning items, even
a staff or club or whatever), you'd probably need a new FLAG_BURNING.
This would be distinguished from FLAG_FIRE because it's not a
magical effect, the thing is just burning up. The item could
decrement its condition every time it's updated when it has
FLAG_BURNING, until it is all gone. (If you want really sophisticated
effects that would allow fires to go out if they aren't strong enough,
you would need a separate value for the flame's strength. The strength
of elemental effect as well as the speed of degradation of the item
would be determined by that value, which would in turn determine the
relative flame strength of any items subsequently ignited. The
strength could be increased by certain factors, and decreased slowly
over time. But that's a tangent.) DoElementalEffectsToMe then
would give them the chance of lighting on fire or freezing or what
have you. DoElementalEffectsToMe would treat FLAG_BURNING much the
same way as FLAG_FIRE for purposes of damaging creatures and objects.

So, envision this. Monster casts fire bolt. DoElementalEffectsToMe
burns you, then calls DoElementalEffectsToMe on some of your items. Your
quarterstaff of health lights on fire. But, instead of the
disappointing ADOM-style "The quarterstaff is consumed by the flames,"
You have a quarterstaff of health (burning). You can hit your foe
with it, or dip it in a potion of water to salvage it (although
with some damage taken. A scroll would go up much quicker.
In general, this would be nice for giving the player a chance to use
his/her head some more, instead of always being at the whim of
unforeseeable item destruction.

Anyway, I did wander off on a tangent, but if I was writing fantasy
type items using OOP, that's how I'd approach it. However, I don't
even particularly like OOP, just as a matter of personal preference,
so my li'l project is in regular C, and although it doesn't deal
with that specific sort of item system, I use many of the same
principles to allow a wide range of variation and flexibility in
NPCs.

Jeff Lait

unread,
Oct 1, 2003, 6:12:17 PM10/1/03
to
smil...@lycos.com (Joseph Giroux) wrote in message news:<c782f75.03100...@posting.google.com>...

> "Christopher Richmond" <crich...@hotmail.com> wrote in message news:<ix0eb.632754$Ho3.121625@sccrnsc03>...
> >
> > How do you suggest implementing the representation of items then? just
> > curious.
>
> Warning, long winded post ahead:
>
> Well, you said you wanted to use OO, I'd suggest to shift some of your
> item data upward in the hierarchy. All items could have an attack
> value, which simply represents the order of damage the item does to a
> physical creature by smacking into it, along with the "type" of
> physical damage, if you use some sort of bash/slash/pierce system
> or other physical damtype distinction.

However, when you follow this to its logical conclusion, you end up
with no OOP subclass tree at all. After all, you may say that you
should have:
ITEM -> SWORD
where sword overrides the 'do melee damage' to specify how much damage
to do. However, at that point you are putting into code what should
better reside in an external database.

The purpose should be to minimize cut & paste code. Thus, if I have
my lightning bolt effect coded, I don't want to have to instantiate
the code twice, once for the sword which can be zapped for lightning,
and once for the wand of lightning. The standard OOP hierarchy
defeats this sort of reuse - the wand and sword are in different
trees, so it is difficult to share the code.

A pure data driven approach would be to add a flag which specifies
what effect should occur when the object is zapped. If it is None,
the zap does nothing. If lightning, the lightning effect is
generated.

What frustrates me in this discussion is this overlying thought that
the two systems are incompatible, that data driven implies 1930's
style C coding.

Consider instead:
ITEM
{
DECORATOR *getDecorator(const char *dectype);
}

ZAP_EFFECT : public DECORATOR
{
doZap(MOB *zapper, ITEM *zappee);
}

Then we have...
// the mob "mob" wants to zap his sword:
ZAP_EFFECT *zap;
zap = (ZAP_EFFECT *) sword->getDecorator("zap_effect");
if (zap)
{
zap->doZap(mob, sword);
}
else
mob " cannot zap " sword;

This is very rough - you'd want to have a system with more robust type
checking, standardized item decorators, the potential for multiple zap
effects per item, etc. However, it has the advantage that one can
have as an external .text file:

ATTACK lightning
{
range 5
damage 3d5
shape ray_bounce
element lightning
}

ATTACK longsword
{
range 1
damage 1d8
element physical
}

ZAP_EFFECT lightning
{
require_direction true
attack lightning
}

ITEM wand_of_lightning
{
name "wand of lightning"
charges 3d5
zapeffect lightning
itemclass wand
}

ITEM sword_of_lightning
{
name "lightning sword"
attack long_sword
zapeffect lightning
itemclass weapon
}

As you can see, I have no objection with your MELEE_ATTACK_DECORATOR
being a complicated OOP inheritance diagram. Nor with your
ZAPPABLE_EFFECT class hierarchy being similar. I do have something
against trying to build a hierarchy right at the ITEM level - it is
tempting, but IMHO, inefficient *IF* your goal is to have multi-use
items. Even without, I think a seperation is still beneficial.
Otherwise you have to decide whether (silver sword, silver spear)
should be grouped together, or (silver sword, sword). And if you
DON'T split at that level, but stop at WEAPON, I can't help wonder why
you didn't roll it right back to ITEM.

konijn

unread,
Oct 6, 2003, 4:00:47 AM10/6/03
to
Ray Dillinger <be...@sonic.net> wrote in message news:<3F78BC66...@sonic.net>...

> Christopher Richmond wrote:
> >
> > > As always, it's a matter of deciding how much work you want to put
> > > into allowing flexibility in the future, for features you don't
> > > envision now, and might not even ever want to implement.
> >
> > How do you suggest implementing the representation of items then? just
> > curious.
>
> He's recommending DD rather than OO programming. For what it's
> worth, I agree with him in this case: I don't think OO (unless used
> with *extreme* care to fiddly corner cases) will really give folk
> enough flexibility to do a roguelike.

I find that also DD roguelikes need/use extreme care.

<SNIP>



> The classic OO approach would be to define "Physicalthing" as
> having some attributes generic to all physical things, such as
> a size, mass, possibly a monetary value, classification name,
> identified name, description and a material. Then the OO guy
> would subype "weapons" off of physicalthing inheriting all of
> those attributes and adding more like attackval and attackspeed
> and so forth. Then subtype "armor" off of physicalthing again,
> with armor attributes like "defval" and "speedpenalty" and so
> forth in addition to the inherited stuff.

<SNIP>



> Now my "AttackThrow" function can take a tomahawk, which was
> designed for throwing (ie, has nondefault values for most of
> the stuff that's important for throwing and defaults derived
> from its size/mass/material for other stuff) or it can take
> a ring, which wasn't designed for throwing, but can still be
> thrown for some tiny amount of damage (and maybe a nice bonus
> if it happens to be made out of silver and you happen to be
> throwing it at a vampire).

The OO guy would give the Throwable interface to the Ring class.
The damage from throwing variable would not be defined in the Ring
class,
so it would be derived from the Thing class which uses weight/size.
Also the material can be defined in Thing and be retrieved in the
damage() method.

> Likewise, if I run out of ammo for my sling, I can use
> potatos from my food supply or rubies from my treasure sack
> or even dead mice as sling bullets if necessary, because the
> "FireFromSling" function is going to look at a physicalthing,
> find that it's a reasonable size and mass, and not have a
> problem. Likewise if someone wants to wield a helmet as a
> meelee weapon, or whatever else, that's okay too; not as nice,
> probably, as a knife, but okay and at least minimally useful.

That is nice, now you said yourself that the base class would contain
size & mass, so shouldnt this also work without any effort in OO ? It
does in Tyrant (java roguelike).

> Achieving the same kind of flexibility in an OO style is
> going to take a lot more work, in terms of checking for all
> the corner cases and providing specialized error methods and

I would really like some examples of these corner cases, just so I can
see if Tyrant needs improvement there.

> messages for a bunch of different (and frequently unnecessary)
> type errors.
>
> And that is one reason why I think that roguelikes suit a DD
> style much better than they suit an OO style of programming,
> and why I'm using C for the roguelike instead of an OO-fascist
> language like Java. Don't get me wrong, Java is nifty; it's
> just not the best fit for this problem because it's too
> dependent on OO and classes.

I dont know. I feel that using Java decreases the need of reinventing
the wheel all the time. You know you will never have to look for
pointer errors, image file formats, sound file formats, data
containers etc etc.

This is of course IMHO. I have downloaded Tyrant I and trying to make
it a better roguelike. During this task I'm every now and then amazed
by how clever it is written. I never felt like that when looking at
Angband code.

>
> Bear

0 new messages