The dead and the alive - or what to pick up?
Hansjörg Malthaner
I'm unsure what the player shoudl be allowed to pick up.
Big unfriendly beings like orcs surely refuse to be picked up and being put
into you backpack. Small animals can be picked up and put into a bag, even
against their will (i.e. catch some spiders and bring them to the village
shaman to get some reward). A dead orcs body may also be picked up.
Most items should be easy to pick up, some might magically refuse being
picked up.
Asides from the obvious checks (player strength vs. object weight) I'm
unsure about the pickup action. What things and beings should the player be
allowed to pick up?
Then the technical part of the question:
I could everything just give a 'can_be_picked_up' flag and check it. This
flag could be preset in config files and later changed programmatically.
I.e. a living orc is produced with can_be_picked_up=false, but when he dies,
his corpse gets can_be_picked_up=true
Or I could make a complex derivation rule:
if( (is_living && size < size_threshold) ||
(is_living && is_friendly && weight < wight_threshold) ||
// ... more checks here
(is_living == false) {
// can be picked up
}
Which solution do you prefer? And why?
c.u.
Hajo
cropt
> Big unfriendly beings like orcs surely refuse to be picked up and
> being put into you backpack.
I think anything being picked up should get free attacks against whoever
is picking them up. So you could pick up an orc, but at low levels you'd
die quickly.
> Small animals can be picked up and put into a bag
You might be able to sustain a squirrels bites until you got it into a
container, but you probably wouldn't want/be able to hold it in your
hands for a long amount of time.
> (i.e. catch some spiders and bring them to the village shaman to get
> some reward).
Picking up poisonous spiders can be deadly even if they are very small.
> Which solution do you prefer? And why?
I don't like the flag idea. Characters shouldn't do things because
they're bad ideas, not because they're not allowed.
Artur Biesiadowski
> Hansj?rg Malthaner <hansjoerg...@danet.de> wrote:
>
>>Big unfriendly beings like orcs surely refuse to be picked up and
>>being put into you backpack.
>>
>
> I think anything being picked up should get free attacks against whoever
> is picking them up. So you could pick up an orc, but at low levels you'd
> die quickly.
If you would like to pick me up, I can avoid this without killing you.
Basically, I don't see a possibility to 'pick up' anything of comparable
size/strength. You probably can pick up a small child, but other men ?
Artur
cropt
> size/strength. You probably can pick up a small child, but other men ?
It should be easy to break free if you don't want to be picked up. But
I think you should be able to carry around someone if they're willing.
Like finding a dwarf with a broken leg or something.
i0lanthe
> > Basically, I don't see a possibility to 'pick up' anything of comparable
> > size/strength. You probably can pick up a small child, but other men ?
Fireman carry, maybe... people have picked me up that way on a lark
(warriors/athletes can pick up spellcasters/geeks at least.)
If you want to get really detailed, it would depend on what the picked-up
person expects you to do and whether they are a thinking being (if they're
not expecting to be attacked, they are disoriented/startled and have wind
knocked out of them; if they think, they wonder briefly whether to struggle
now and get dropped on their head, or to wait and escape later from a
better position). Perhaps they can get a bonus to hit or damage, because
they are attacking your back. Meanwhile you are fully occupied and can
only carry them for a short distance, or drop them (stunning them briefly,
but boy are they peeved on the next combat round); can't defend yourself,
so maybe you get a penalty to being attacked by anything. Lots of good
reasons not to pick up a man-sized creature even though you can.
> It should be easy to break free if you don't want to be picked up. But
> I think you should be able to carry around someone if they're willing.
> Like finding a dwarf with a broken leg or something.
Cute idea.
I was flipping through _The Two Towers_ recently so this reminds me of
the hobbits Pippin and Merry being carried by various larger beings,
sometimes willingly, and sometimes while tied up. (It also reminds
me of the Fable of the Poisonous Creature Of Your Choice and the
Benevolent But Doomed Creature Of Your Choice that was persuaded to
carry it somewhere. There appear to be several instances.)
-Bridget
R Dan Henry
Biesiadowski <ab...@pg.gda.pl> transmitted thus:
>Basically, I don't see a possibility to 'pick up' anything of comparable
>size/strength. You probably can pick up a small child, but other men ?
If he's unresisting or willing, you can carry a human larger than
yourself, at least if you are minimally fit enough to think about
adventuring. Trying to lift someone your own size who is struggling is
another story.
R. Dan Henry, Grand Pashah of Small Miscellaneous Objects
rdan...@earthlink.net
"Lately, the only thing keeping me from being a serial
killer is my distaste for manual labor." -- Dilbert
R Dan Henry
Malthaner <hansjoerg...@danet.de> transmitted thus:
>Hi,
>
>I'm unsure what the player shoudl be allowed to pick up.
>
>
>Big unfriendly beings like orcs surely refuse to be picked up and being put
>into you backpack. Small animals can be picked up and put into a bag, even
>against their will (i.e. catch some spiders and bring them to the village
>shaman to get some reward). A dead orcs body may also be picked up.
>
>Most items should be easy to pick up, some might magically refuse being
>picked up.
Like slaying weapons might refuse to even be carried by races they
slay? Or the Swift Sword of Justice refuse to be picked up by anyone
who hasn't done the Three Great Quests of Law? Yeah, I can see some
uses for that.
>Asides from the obvious checks (player strength vs. object weight) I'm
>unsure about the pickup action. What things and beings should the player be
>allowed to pick up?
Well, if the other doesn't want to be picked up you need surprise or
superior speed or some other factor to prevent running away/ducking.
>Then the technical part of the question:
>
>I could everything just give a 'can_be_picked_up' flag and check it. This
>flag could be preset in config files and later changed programmatically.
>
>I.e. a living orc is produced with can_be_picked_up=false, but when he dies,
>his corpse gets can_be_picked_up=true
>
>
>Or I could make a complex derivation rule:
>
>if( (is_living && size < size_threshold) ||
> (is_living && is_friendly && weight < wight_threshold) ||
> // ... more checks here
> (is_living == false) {
>
> // can be picked up
>}
>
>Which solution do you prefer? And why?
The second, because then you can bring the Flowers of Delight and the
Candy Box of Wooing to the Silver Princess, get her is_friendly and
carry her off. Or feed a squirrel to make it your friend or whatever.
If you try to pick up someone that doesn't want to be picked up, he
should get a free attack if aware. "Animal Handling" skill could allow
you to snag a Jade Scorpion before it knows you are there and tuck it
into a cage (restraints on unwilling, active carries or they try to
escape), but if you don't know what you are doing, or fail your skill
check the Jade Scorpion will try to sting your hand and its terrible
poison will leave you blind and impotent, which will rather hurt your
chances with the Silver Princess.
Neil Stevens
> Most items should be easy to pick up, some might magically refuse being
> picked up.
And if you want to be really tricky, you can add to this an option to make
items refuse to be dropped, too.
My precious...
Philip Swartzleonard
For a programatic solution relying only on data files and algorithims...
well i don't know. I think i might prefer the second somehow. But the first
thing I do think about in this case is the 'verDoPickup(actor)' from TADS.
When you, the player in the text adventure, type 'pick up orc', the orc's
function is called and you are the actor (not dissimilar, i now realize,
from the example of messaging i gave earlier in it's information). It can
find out anything about you with the paramater (TADS is at least a loose of
an OO system as python), and then it can basically abort (by printing a
message) or allow (by doing nothing) the action.
If you were going to have some kind of scripting system (and if you were, i
would have to say that embedded python would not be unworthy of
consideration if you are using c or c++ as a base language especially -- no
i do not work for them ;), that would allow you to futher refine the
actions and responses of various objects, than a system like this may be
right for you, and as the world-system of TADS relies mostly on programming
objects to react to various ah.. 'stimuli', it may be worth taking a look
at it's structure.
</ramble> (start tag: implicit ;)
--
Philip Sw "Starweaver" [rasx] :: www.rubydragon.com
Hansjörg Malthaner
[...]
> > Small animals can be picked up and put into a bag
>
> You might be able to sustain a squirrels bites until you got it into a
> container, but you probably wouldn't want/be able to hold it in your
> hands for a long amount of time.
Some people know how to hold animals so that they can't bite and scratch
you. But you're right that is a specialy skill and the average player will
get hurt. A beastmaster may know how to hold squirrels :)
> > (i.e. catch some spiders and bring them to the village shaman to get
> > some reward).
>
> Picking up poisonous spiders can be deadly even if they are very small.
Guess why the shaman isn't hunting them by himself :)
> > Which solution do you prefer? And why?
>
> I don't like the flag idea. Characters shouldn't do things because
> they're bad ideas, not because they're not allowed.
I'm just afraid the if(...) is getting big quickly and it'll be hard to
consider all cases without mistakes in a single nested condition.
c.u.
Hajo
Corey Woodworth
>
> I could everything just give a 'can_be_picked_up' flag and check it. This
> flag could be preset in config files and later changed programmatically.
> I.e. a living orc is produced with can_be_picked_up=false, but when he dies,
> his corpse gets can_be_picked_up=true
No way. If the PC is a Giant he could easily pick up a man, but if the
PC was a hobbit he couldn't even pick up a dwarf.
Philip Swartzleonard
>> Then the technical part of the question:
>>
>> I could everything just give a 'can_be_picked_up' flag and check it.
>> This flag could be preset in config files and later changed
>> programmatically. I.e. a living orc is produced with
>> can_be_picked_up=false, but when he dies, his corpse gets
>> can_be_picked_up=true
>
> No way. If the PC is a Giant he could easily pick up a man, but if the
> PC was a hobbit he couldn't even pick up a dwarf.
Er, wouldn't you imagine that the size/weight/whatever of the dwarf corpse
would be too high for the hobbit's capacity (unless it's the strongest
hobbit ever with a steroid addiction ;). There would be further checks; the
can_be flag just determines weather it MAY be picked up, some futher
algorithim would determine weather it CAN be picked up. (Can anyone pick
up, say, dragon corpses in nethack? adom? i know adom has variable corpse
weight)
B. Waite
In my project, what your character can pick up and carry is determined by a
function that includes both volume and weight. The bigger either of those
values is, the more difficult it is to pick up.
For example, a character may be able to lift a 200 pound rock without
problems, but 200 pounds of feathers might be too bulky/awkward to move.
(Stupid example, I know, but I hope that it illustrates my point).
I give animate objects a higher volume rating than inanimate objects. This
represents that they are moving, kicking, and in general, not happy to be
carried around in anyone's pocket.
If your character is strong/big enough to pick up another creature, then
that object is "contained". Contained objects cannot move until they are
set free. However, being contained doesn't stop them from taking other
actions.
The AI code for creatures makes them attack any object they are contained
in. Therefore, if you stuff a hamster into your backpack, the hamster would
scratch it until it was destroyed (thereby freeing him).
"Philip Swartzleonard" <st...@pacbell.net> wrote in message
news:Xns91A7789228...@130.133.1.4...
David Damerell
>algorithim would determine weather it CAN be picked up. (Can anyone pick
>up, say, dragon corpses in nethack? adom? i know adom has variable corpse
>weight)
NetHack's corpses have variable weight; a horse corpse is about as much as
anyone can manage.
--
David Damerell <dame...@chiark.greenend.org.uk> flcl?
cropt
> There would be further checks; the
> can_be flag just determines weather it MAY be picked up, some futher
> algorithim would determine weather it CAN be picked up.
If you're making the other checks anyway why would you need the flag?
Hansjörg Malthaner
In a first glance it seemed to be simpler to just use a can_be_picked_up
flag, and let the various portions of the game just check this flag instead
of implementing the complex logig several times.
But as it was pointed out can_be_picked_up is not only dependent on the
target state but also on the actors state and action. This way seen, a flag
is far too simple.
I thionk, I'll give the item class a method like
bool can_be_picked_up_by(being_t *actor) {
// does the calculations
return result;
}
to determine if a particular item can be picked up by a particuler being.
Another way could be to give the actor a method bool can_pick_up(item_t
*thing)
Somehow there seems to be symmetry here. I don't know how to decide which
option is better? Implement the method in the item_t class or in the being_t
class?
IMO implmenting the method in the item_t class seems to be more natural, but
don't ask me why.
c.u.
Hajo
Hansjörg Malthaner
>
> There are simpler solutions...
>
> In my project, what your character can pick up and carry is determined by a
> function that includes both volume and weight. The bigger either of those
> values is, the more difficult it is to pick up.
>
> represents that they are moving, kicking, and in general, not happy to be
> carried around in anyone's pocket.
Looks like a hack to work around a design weakness, but it might work :)
What about having a separate modifier - I mean using the volume as volume,
and check 'is_animated' to determine the extra difficulty to pick them up?
> If your character is strong/big enough to pick up another creature, then
> that object is "contained". Contained objects cannot move until they are
> set free. However, being contained doesn't stop them from taking other
> actions.
>
> The AI code for creatures makes them attack any object they are contained
> in. Therefore, if you stuff a hamster into your backpack, the hamster would
> scratch it until it was destroyed (thereby freeing him).
This implies some kind of hitpoints for the container. How did you implement
that?
What about a steel container? The hamster couldn't damage it, even in a long
time. An acidic blob could corrode it quickly and escape.
c.u.
Hajo
B. Waite
news:3C5ABD4B...@danet.de...
> "B. Waite" wrote:
> >
> > There are simpler solutions...
> >
> > In my project, what your character can pick up and carry is determined
by a
> > function that includes both volume and weight. The bigger either of
those
> > values is, the more difficult it is to pick up.
> >
> > I give animate objects a higher volume rating than inanimate objects.
This
> > represents that they are moving, kicking, and in general, not happy to
be
> > carried around in anyone's pocket.
>
> Looks like a hack to work around a design weakness, but it might work :)
> What about having a separate modifier - I mean using the volume as volume,
> and check 'is_animated' to determine the extra difficulty to pick them up?
A hack? Yeah, I suppose I can agree to that ;-) I guess it all comes down
to how you want to model your world. An animated flag could do the same
thing, but volume comes in handy for other things as well.
Volume is what determines how much of something can exist in one tile, or in
one container. It affects what can fit through holes, doors and hallways.
It also affects line of sight--you can see a dragon behind a mouse, but not
a mouse behind a dragon.
> > If your character is strong/big enough to pick up another creature, then
> > that object is "contained". Contained objects cannot move until they
are
> > set free. However, being contained doesn't stop them from taking other
> > actions.
> >
> > The AI code for creatures makes them attack any object they are
contained
> > in. Therefore, if you stuff a hamster into your backpack, the hamster
would
> > scratch it until it was destroyed (thereby freeing him).
>
> This implies some kind of hitpoints for the container. How did you
implement
> that?
>
> What about a steel container? The hamster couldn't damage it, even in a
long
> time. An acidic blob could corrode it quickly and escape.
Any object in the game that inherits the "BaseObject" class will have HP, AC
and damage resistance properties.
Anyway, it's not a perfect system--How do you measure the volume of a 10ft.
pole? Can more than one fit in a tile? Will it fit in your pack?--but,
it's the best I could do without things getting complicated. Any ideas?
> c.u.
> Hajo
Take care,
- B
Hansjörg Malthaner
[...]
> Anyway, it's not a perfect system--How do you measure the volume of a 10ft.
> pole? Can more than one fit in a tile? Will it fit in your pack?--but,
> it's the best I could do without things getting complicated. Any ideas?
Instead of the scalar 'volume' I decided to use width and height, and
implicit some depth. That measn my backpack has a widths and a height, and a
10ft high pole clearly exceeds the height of the backpack, even if the width
fits intot he backpack.
The depth is implictely given by a stack count maximum - the reason is that
my UI is 2D too. I can represent width and height well as a 2D area, but the
depth isn't really displayabale and thus I used the 'stacking with limited
stack size' apporach.
It's more complex to check 3 numbers (withs, height, stack count) but it
allows to consider some details, the scaler volume cannot represent.
> Take care,
> - B
c.u.
Hajo
Hansjörg Malthaner
just to write a short conclusion:
Most roguelikes work well with the simple rule "Only dead things (=items)
can be picked up"
The fact that eggs are considerd to be items, displays that this rule has
its weaknesses. But I think I'll use that rule too. If I'm going to
implement 'picking up living things' I'll use a different command 'catch' or
'fetch' that works differently from the usual pickup action.
c.u.
Hajo
Artur Biesiadowski
> Most roguelikes work well with the simple rule "Only dead things (=items)
> can be picked up"
>
> The fact that eggs are considerd to be items, displays that this rule has
> its weaknesses.
I think that you are too picky here. For me carrot is a lot more
'living' than egg, but this does not give you a problem ?
I would rename this rule to item==thing not capable of action. Thus
moving monsters, psi-mushrooms and traps are different category.
Artur
Hansjörg Malthaner
>
> Hansjörg Malthaner wrote:
>
> > Most roguelikes work well with the simple rule "Only dead things (=items)
> > can be picked up"
> >
> > The fact that eggs are considerd to be items, displays that this rule has
> > its weaknesses.
>
> I think that you are too picky here. For me carrot is a lot more
> 'living' than egg, but this does not give you a problem ?
I just forgot to think about plants entirely ... but actually I'd put both,
eggs and plants, into the 'living' category.
> I would rename this rule to item==thing not capable of action. Thus
> moving monsters, psi-mushrooms and traps are different category.
Do you know a good word that expresses "capable of action"?
"animate" implies living - skeletons and zombies aren't living, but are
capable of action.
"active" maybe?
or better "acting"?
> Artur
c.u.
Hajo
mannix
"Hansjörg Malthaner" wrote:
: Do you know a good word that expresses "capable of action"?
:
: [...]
:
: "active" maybe?
If you're fishing for a duality here, might
I suggest "active" and "passive" as rather
concise terms to use?
- don
Hansjörg Malthaner
I'm searching a term that subsums the usual monster-item distinction. Some
attribute every monster has, but no item has.
Artur said it correctly - monster are 'capable of action' while items are
not.
My english is just not good enough that I can judge if 'active' is the
proper word for this distinction. Is a sleeping monster 'active'? Usually
not, but it's still no item.
Sould I use 'is_being' instead? Are skeletons or zombies considered to be
beings?
And what about the eggs and plants? They can't act, for sure. If they are
considerd to be 'beings' I cannot use 'is_being' for the distinction.
I'm still searching a short term for 'being capable to act'.
> - don
c.u.
Hajo
B. Waite
> My english is just not good enough that I can judge if 'active' is the
> proper word for this distinction. Is a sleeping monster 'active'? Usually
> not, but it's still no item.
>
You were right; animate is the correct word. It literally means "possessing
life," but it can be used figuratively as well.
For example, both the living dead and Mickey Mouse are "animated"--brought
to life. Different magic, same word.
Hansjörg Malthaner
Thank you for this explanation :)
c.u.
Hajo
mannix
"B. Waite" wrote:
: > [...] a short term for 'being capable to act'.
:
: You were right; animate is the correct word.
: It literally means "possessing life," but it
: can be used figuratively as well.
True. I see now where I may have drifted off-topic
(likely because I didn't really follow the original
thread): What of unconscious beings, for example?
A [heavily, magically] sleeping orc* could be picked
up and carried about. The orc remains animate, if
anything, in the literal sense of the term 'animate'
as given above.
However, being unconscious, the orc can no longer
capitalize on the possession of its animating "spirit"
(or whatnot) and could be described as having been
incapacitated, rendered inactive, or as passive in
nature for the duration of its unconsciousness.
So things may be "animate" or "inanimate" insofar
as they possess a "life" embodying the potential
to act. On the other hand, things may be "active"
or "passive" depending on whether they presently
possess the power to cause change or merely receive
it -- as in the case of resisting or succumbing
to another thing hauling them around.
This may be more of a muddle than it's worth,
essentially hinging on a distinction between
the modifiers "animate" and "animated" as
applied to any given object. An unfinished,
four-cell typology results:
ANIMATE | INANIMATE
------------------------
| |
standard | [undead | ACTIVE
orc | orc?] |
-----------------------|--
| |
sleeping | dead-ish | PASSIVE
orc | orc |
| |
------------------------
|
So: Luggable? = ( PASSIVE? )
I guess it's debatable whether ACTIVE, INANIMATE
things exist (in which case, the cell would be
empty) or exist and cover cases such as the
undead ... I'm swayed by the above notion of
animation as a figurative concept, but I hate
to see a cell go empty. :P
In case that particular cell ought to remain
empty for lack of qualifying candidates, the
relationship is more tree-like:
"THING"
/ \
ANIMATE INANIMATE
/ \
ACTIVE PASSIVE
So: Luggable? = ( INANIMATE? || ( ANIMATE? && PASSIVE? ) )
----
From my vantage, raw as it is, what determines
luggability is not an animating spirit, per se,
but the ability of an object to capitalize on
said spirit.
Have I gone too far with this?
* Should you consider your average orc to
heavy, uncomfortable, or smelly to lift and
tote, feel free to substitute with Disney's
Tinkerbell in the discussion following.
Hansjörg Malthaner
>
> "B. Waite" wrote:
>
> : > [...] a short term for 'being capable to act'.
> :
> : You were right; animate is the correct word.
> : It literally means "possessing life," but it
> : can be used figuratively as well.
>
> True. I see now where I may have drifted off-topic
> (likely because I didn't really follow the original
> thread): What of unconscious beings, for example?
>
> A [heavily, magically] sleeping orc* could be picked
> up and carried about. The orc remains animate, if
> anything, in the literal sense of the term 'animate'
> as given above.
Agreed. But first I need a rough, coarse distinction. Basically to determine
a default action or behaviour in the game.
"Animate" serves this purpose well.
Later on, I can add exceptions like "animate but
[petrified|sleeping|frozen|paralyzed|very heavyily wounded|mind controlled
by player]" to define a more fine-granular behaviour. "Animated" will help
to get the programm getting off the ground. The details will be added later.
[snip matrix and decision tree]
> Have I gone too far with this?
IMO no. I'd rearrange the decision tree a bit, having 'animate' as the root
node, but I think later on something like that is required.
That's also the reason why I was really picky about the word, because I want
to connect semantics with every node of the decison tree. In the first step
the root node 'animate' will be all that's required, but it must be chosen
very carefully.
Thanks again!
c.u.
Hajo
Greg McIntyre
> For example, both the living dead and Mickey Mouse are
> "animated"--brought to life. Different magic, same word.
Yah. And a necromancer can "animate the dead". Works for me.
--
Greg McIntyre
gr...@puyo.cjb.net
http://puyo.cjb.net
mannix
"Hansjörg Malthaner" wrote:
: Agreed. But first I need a rough, coarse distinction.
: Basically to determine a default action or behaviour
: in the game.
:
: [...]
:
: Later on, I can add exceptions like "animate but
: [petrified|sleeping|frozen|paralyzed|
: very heavily wounded|mind controlled by player]"
: to define a more fine-granular behaviour.
Idle question: wouldn't there be a benefit to
abstracting the bracketed states above under
a single, larger rubric or a set of rubrics
that determine outcome based on presence,
absence, and/or joins of sibling terms?
- don
Hansjörg Malthaner
I'm not sure. Looking at other roguelikes I find huge switch() statements
anmd large if() cascades so I guess just testing all conditions is ok.
I don't want to join those conditions, even if they have similar meaning for
the pick-up action. In other circumstances the conditions have very
different effect, and thus I think they need to be kept as separate values.
> - don
c.u.
Hajo
Artur Biesiadowski
> I'm not sure. Looking at other roguelikes I find huge switch() statements
> anmd large if() cascades so I guess just testing all conditions is ok.
I would draw different conclusion. For me this means that
a) roguelikes are written in incremental fashion
b) a lot of people writing roguelikes are bad programmers
I cannot say really so much about roguelikes, but I have seen A LOT of
muds code (and IMHO, developers of both are quite similar in many aspects).
Basically, no other distinct subculture I have seen, writes so bad code.
Terrible, really terrible. I will give an example:
char * direction_to_string(int dir)
{
if ( dir == 0 )
return "north";
if ( dir == 1 )
return "east";
if ( dir == 2 )
return "south";
if ( dir == 3 )
return "west";
return "unknown";
}
I have typed it from my head, but this looked almost exactly like this.
This is my favorite example of bad programming.
a) no const on return value - crash on modify
b) plain integers instead of predefined constants
c) if cascade instead of switch
d) hardcoded instead of using table
e) not using structures, so going other direction requires another
function like this
and probably few more.
In fact original code included also string_to_direction function...
Yes, coding it this way is easiest. Let's suppose that we have even
corrected a,b,c. Now we want to add directions like ne,sw etc. Add code
in every place. Up and down ? Now we have 10-long switch. Named exits ?
Ouch... need to do some ugly special cases or rewrite from scratch.
Fact that something is done in particular way in existing roguelikes
should not be a hint that it is good - it should be a hint that this is
probably worst possible way of doing it. If you see 4-pages long
function of checking for special cases, do not say "It is ok, they have
done so and nethack is most popular roguelike out there", say "How can I
learn on their mistakes and make it generic?".
Every time you add a single if/switch case it is innocent. But after
some time it starts to be monstrous enough to make any attempt at
correction doomed to fail.
Sorry to sound so harsh, but this comes from fact that I was maintaining
merc-based mud for almost a year... In fact learn some C during that -
for about 2 months, later spend few months trying to unlearn bad
practices and later spend hours of coding saying quite bad words, while
trying to workaround design limitations of code... I have done wonders
:), but how ugly it was...
Artur
Philip Swartzleonard
> Hansjörg Malthaner wrote:
>
>> I'm not sure. Looking at other roguelikes I find huge switch()
>> statements anmd large if() cascades so I guess just testing all
>> conditions is ok.
I know what you mean here. Just look at... oh, the do_cmd_drink_potion (or
whatever it's called) in angband. The effects for every damn potion in the
game are switched out right there, and wands, staves, rods, scrolls, and
maybe artifacts too. They do use some helper functions, and not every
single value is hard coded, but still... makes me whant to find the
do_cmd_run_in_terror(far) :)
> I would draw different conclusion. For me this means that
> a) roguelikes are written in incremental fashion
Not just incremental but long. I don't know if Angband actually absorbed
code from Moria or was just inspired, but it itself has been around for
what, ten years or more now? (*looks at own copy, but can't find any dates
except current build and old moria*). There might still be a few bits of
code that haven't been touched since then, but more importantly the design
itself (how to model the world with what data where and in what format)
probably hasn't changed much at all, only grown to fit new components.
In 1990, what, C had just been standardized, and given that back then space
and speed still mattered _a lot_, it was probably the one of the few
choices if you wanted to make things that ran on a variety of old and aging
(at _that_ time) systems. C++ was probably still considered a toy prototype
by a lot of people (if it was widely known), and the languages we think of
as being extremly portible today (Java, Python, and things like that)
didn't even exist and would be seen even more as unaffordabe baggage then
they are today.
Given that such a thing was started at a time when things like OO and
encapsulation (and other 'good programming practices') weren't nearly as
common, and people were working with worse constraints on speed and
space... well i didn't mean to write a theoretical history of programming.
:)
> b) a lot of people writing roguelikes are bad programmers
I don't think it's just that they're bad, i think a lot of times it has to
do with being inexperienced and not knowing how to deal with the various
issues that you have to deal with... it would be very hard to do everything
in the best way (or even a good way) the first time through, because you
often don't have a clue what the long term problems/advantages are going to
be, or can't see very well how you will need to deal with it in the future.
Writing a good program, i think, either requires a lot of rewriting, as you
figure out how to do things by stabbing at them in some seemingly
appropriate way, or a lot of experience, which just means the same thing
except you're writting a different program instead of remaking the first :)
The problem is, when it doesn't get rewritten... or the person can't see
that it's bad (which does make him bad).
> I cannot say really so much about roguelikes, but I have seen A LOT of
> muds code (and IMHO, developers of both are quite similar in many
> aspects).
>
> Basically, no other distinct subculture I have seen, writes so bad
> code.
> Terrible, really terrible. I will give an example:
>
>
> [Ugly function]
Eew. This is kinda how my input code looks right now -- dealing with a
framework i didn't know well, and knowing that I would for sure have to
redo it at some point if for no other reason than i need to make the
bindings user-settable somehow.
Here's an abbriviated piece of it .. there are at least six entries under
each mode, and a few other assorted keys.
def wxOnKeyDown( self, event ):
"""Extremly hackish event handling. Eew... """
a = event.GetKeyCode()
if a == WXK_NUMPAD_ADD:
self.mode = loopcrement(self.mode,1,3)
print self.modedesc[self.mode]
if self.mode == 0: #control 3d eye position
if a == WXK_LEFT: self.panx = capcrement(self.panx, -1.0,
-30.0)
elif a == WXK_RIGHT: self.panx = capcrement(self.panx, 1.0,
30.0)
elif self.mode == 1: #control 3d rotatoin
if a == WXK_LEFT: self.theta = loopcrement(self.theta, -5.0,
-1, 355.0)
elif a == WXK_UP: self.phi = loopcrement(self.phi, -5.0,
-1, 355.0)
elif self.mode == 2: #control player motion
d=-1
if a == WXK_LEFT: d = Dir.w
elif a == WXK_RIGHT: d = Dir.e
if d > -1:
world.player_brain.move( Dir(d) )
self.triggerRedraw(1)
> I have typed it from my head, but this looked almost exactly like this.
> This is my favorite example of bad programming.
>
> c) if cascade instead of switch
I'll just note that python dosen't have a switch construct, so elif chains
are pretty much the standard way of doing this :)
>
> In fact original code included also string_to_direction function...
>
> Yes, coding it this way is easiest. Let's suppose that we have even
> corrected a,b,c. Now we want to add directions like ne,sw etc. Add code
> in every place. Up and down ? Now we have 10-long switch. Named exits ?
> Ouch... need to do some ugly special cases or rewrite from scratch.
I don't think its even easiest that way, at least if you know another way.
Typing out lots of if's or case's is a drudgery bitch.
> Fact that something is done in particular way in existing roguelikes
> should not be a hint that it is good - it should be a hint that this is
> probably worst possible way of doing it. If you see 4-pages long
> function of checking for special cases, do not say "It is ok, they have
> done so and nethack is most popular roguelike out there", say "How can
> I learn on their mistakes and make it generic?".
Trying to work with angband told me what not to do. I had lots of ideas for
that game, but it's too much to keep track of. Not only the special cases,
but the distribution. I migrated stacking wands from Z and let met say,
every single place where a wand is dropped, taken, sold, bought, used,
destroied, or whatever, there has to be a check to distribute charges
properly. I missed the sold one for a while... made some good money there
(have two wands totaling 20 charges, sell one, have 1 wand w/ 20 and the
shop has 1 w/ 20 :)
Hm, i think i have an example of a good method too. Here are a pair of
interrelated classes that have worked absolutly great ever since i first
wrote them:
class Pos:
# This is a constrcutor in python
def __init__(self,x=0, y=0, z=0):
self.x = x
self.y = y
self.z = z
def displace( self, dir ):
# Use the table from the dir class to figure out the difference
a,b,c = dir.disp
return Pos( self.x + a, self.y + b, self.z + c )
# The 26 cardinal directions of 3d space (and none)
class Dir:
def __init__(self, dir):
# You typically make one of these with a 'x = Dir(Dir.nw)' kind of
# construct.
if dir > 42 or dir < 0:
raise Dir_out_of_range
self.dir = dir
self.disp = self.displacement[dir]
# i should probably add a set function that updates disp,
# but haven't needed it.
# everything else is basically static class data... or if it isn't
# that's how it's used and i need to tweak something :)
# Asign unique bits to each direction, basically
none = 0
n = 1
s = 2
e = 4
w = 8
ne = n + e
nw = n + w
se = s + e
sw = s + w
u = 16
d = 32
un = n + u
us = s + u
ue = e + u
uw = w + u
une = n + e + u # could be 'ne + u' .. oh well :)
# etc
dsw = s + w + d
# a basic vector that gives you the numbers to get to a cell
# one step in the direction (assuming it's a map we're talking
# about...)
displacement = {
none:( 0, 0, 0),
n: ( 0, +1, 0),
s: ( 0, -1, 0),
e: ( +1, 0, 0),
w: ( -1, 0, 0),
ne: ( +1, +1, 0),
nw: ( -1, +1, 0),
se: ( +1, -1, 0),
sw: ( -1, -1, 0),
u: ( 0, 0, +1),
d: ( 0, 0, -1),
un: ( 0, +1, +1),
us: ( 0, -1, +1),
# ...
dsw:( -1, -1, -1),
}
Sorry for the length, but i wanted some of the patterns to show. Here are a
couple of creature's helper functions that make use of this. (at is a
function of map, it returns a reference to the actual cell named by the
pos's coords).
def pos_to( self, dir ):
return self.pos.displace(dir)
def cell_to( self, dir ):
return self.loc.at( self.pos_to(dir) )
... Hope there's something useful in all of this :)
--
Philip Sw "Starweaver" [rasx] :: www.rubydragon.com
"ALLMOST! Events work. I have five orcs. Timing works. Just need a fireball
command, a different ai (i just have 'hit wall turn right', need 'do that
unless player is close, then attack' or something"), and... something to
show how message filters could work. Oops, long sig. Oh well :)"
Ray Davis
finding that in my own code-base, all of my 'bad' habits are cases of
needing to get something to work, with the intention of going back and
making it 'pretty', and just not getting a chance to do so because the next
item on the list pops up.
And AFAIK, currently the only bad section of my project is the file-parsing
(basically degenerating into a bunch of if-else-if), but my excuse is that
file-parsing by nature is ugly. :)
How do you propose to make everything so generic as to eliminate
ifs/switches? I'm not defending the 20+ case switch statement, but I find
that sometimes it's not worth the overhead to make everything generic and so
modular that I can plug it into functions to get the results I need. Using
the directions example... I have a simple enum with all my wonderful
directions, and whenever I need an opposite direction I use a little cheat
and just offset the value, due to the way I setup the enum. Is it really
worth making each direction it's own object, with it's own routines to
figure out wtf the opposite direction might be? Or storing which direction
is resultant from a 90 degree rotation? Why create all that extra work and
objects to maintain?
In my own project, I'm using C++ (if it isn't obvious already), and at first
I was trying to be very adamant in defining my interfaces and hiding my data
and all that... but then I realized that a) nobody else is ever going to
touch this code but me so I don't need to protect it from them, and b) this
is a hobby project that is in development for fun, not necessarily to
practice 100% good programming techniques (and who's to say what's good or
bad in the first place).
Damn judgemental bastards... :)
-Ray
cropt
> b) this is a hobby project that is in development for fun, not
> necessarily to practice 100% good programming techniques (and who's to
> say what's good or bad in the first place).
If you find it helpful it is good. Those good programming techniques are
suppose to be making your life easier, though it doesn't always turn out
that way.