rhetorical question (mb)
Xecutor
When I found that I'm struggling for more than 10 minutes I decided to
make this post.
It's not that I hope that someone will answer something good...
But when I'm trying to formulate question in a form that someone else
will (probably) understand it,
there is a high chance to find an answer during this process...
I'm trying to add Disease effect to my rl.
This effect should prevent health regen.
Easiest solution - go to health regen action and check if unit have
disease effect on it - do not add hp.
But than if I'll decide to add another effect that have health regen
prevention as side effect,
I'll have to add it to check too and so on.
I don't think that there will be a lot of such effects, but still ...
I just don't like this kind of solutions.
Another easy solution - at the moment when Disease effect is attached
to unit,
add negative hp regen bonus equal to current hp regen.
Pretty easy and pretty straight forward, but if unit will equip item
with additional hp regen, or
use jar with regenerating ointment, effect will be somewhat
incorrect... but easy to do :)
Another possible solution: add possibility to set regen handler that
can modify regen value.
Another possible solution: add special counter to unit. Effect that is
preventing hp regen will
increment it on attach and decrement it on detach. If counter is
greater that zero, health is not regening.
Another (pretty easy) solution: deal damage equal to current hp regen
value with the same delay as hp regen.
I fill myself like Buridan's ass.
corremn
Rhetorical hey? Do I know what rhetorical is?
Easiest solution is often the best, but then again its often the
hackiest.
I have found that effects are one of the hardest things to get right,
there are so many ways to do it.
My first solution was in the regen function check to see if unit has
disease, then no heal. Sounds familiar right?
My rewrite involves generic effects, that contain properties, i.e
no_heal. Then in the regen function I would loop through all the
effects and see if one has the no_heal flag or whatever. Much better
I say, until 100s mobs are cycling through their loops, not only in
the regen function, but lots of places, looping through the movement
phase looking for speed effects, etc, etc. Besides that why we have
these beefed up processors for now-a-days.
Still I like it, even though it is not simple. I recomend simple for
most rl developers though. So the correct answer is.... *click.
dominik...@gmail.com
Do you have such thing as regeneration rate? I haven't coded this yet,
but I was thinking of giving the PC a certain regeneration rate, say
value 10 for "1 HP each MAX-10 turns", where MAX would be something
like 100 or maybe 50. Effects might add modifiers to this: 10 natural
(1HP per 100-10=90 turns), -50 disease effect (1HP per 90+50=140
turns, which is a lot, the regeneration isn't completely stopped
though), +80 ring of regeneration (1HP each 140-80=60 turns). How's
that?
Mingos.
Slash
> Hi all.
SNIP
>
> I fill myself like Buridan's ass.
<fancy>
What is causing the regeneration effect in your game world? if it is
caused by a god, model such god as an Actor and have him increase the
health of the subject by artificially modifying its metabolism.
Likewise, what is a disease? why not model diseases as a separate
hierachy so you can plug them into an actor and then fire all their
effects?
Such artificial modification would then be countered if the target is
subject to a disease with NEGATE_HEALING flag
</fancy>
--
Slashie
Radomir 'The Sheep' Dopieralski
corremn wrote:
> Rhetorical hey? Do I know what rhetorical is?
I do't want to pick on details, but I was taught that
a rhetorical question is a question asked while already
knowing the answer, just for the purpose of attracting
the attention of the audience to a partcular problem...
--
Radomir `The Sheep' Dopieralski <http://sheep.art.pl>
"Whenever you find yourself on the side of the majority,
it's time to pause and reflect." -- Mark Twain
Krice
> I just don't like this kind of solutions.
> Another easy solution
You don't like easy solutions? In this case they probably
are what they seem - easy. Don't worry, it's very much
possible that you run into harder problems when you are
creating a roguelike.
Jeff Lait
> Hi all.
> When I found that I'm struggling for more than 10 minutes I decided to
> make this post.
> It's not that I hope that someone will answer something good...
> But when I'm trying to formulate question in a form that someone else
> will (probably) understand it,
> there is a high chance to find an answer during this process...
>
> I'm trying to add Disease effect to my rl.
> This effect should prevent health regen.
> Easiest solution - go to health regen action and check if unit have
> disease effect on it - do not add hp.
> But than if I'll decide to add another effect that have health regen
> prevention as side effect,
> I'll have to add it to check too and so on.
Don't check for the disease, check for the health regen prevention.
In POWDER, I have a NOREGEN intrinsic that I can add to a monster to
stop it regenerating. The health regeneration just checks for that
one intrinsic. Diseases could, as part of their effect, set that
timed intrinsic.
> I don't think that there will be a lot of such effects, but still ...
> I just don't like this kind of solutions.
> Another easy solution - at the moment when Disease effect is attached
> to unit,
> add negative hp regen bonus equal to current hp regen.
> Pretty easy and pretty straight forward, but if unit will equip item
> with additional hp regen, or
> use jar with regenerating ointment, effect will be somewhat
> incorrect... but easy to do :)
This is a very dangerous approach. It is doing a very different thing
than your disease description. What if you get two diseases? Do you
start losing health every turn?
--
Jeff Lait
(POWDER: http://www.zincland.com/powder)
Darren Grey
> On Oct 2, 6:12 am, Xecutor <konstantin.stup...@gmail.com> wrote:
>
> > Hi all.
> > When I found that I'm struggling for more than 10 minutes I decided to
> > make this post.
> > It's not that I hope that someone will answer something good...
> > But when I'm trying to formulate question in a form that someone else
> > will (probably) understand it,
> > there is a high chance to find an answer during this process...
>
> > I'm trying to add Disease effect to my rl.
> > This effect should prevent health regen.
> > Easiest solution - go to health regen action and check if unit have
> > disease effect on it - do not add hp.
> > But than if I'll decide to add another effect that have health regen
> > prevention as side effect,
> > I'll have to add it to check too and so on.
>
> Don't check for the disease, check for the health regen prevention.
>
> In POWDER, I have a NOREGEN intrinsic that I can add to a monster to
> stop it regenerating. The health regeneration just checks for that
> one intrinsic. Diseases could, as part of their effect, set that
> timed intrinsic.
What if you have NOREGEN set from an equipment piece, and also from a
timed disease? If you unequip the item, does the system check through
all other possible sources of NOREGEN before unflagging it?
I mean these questions rhetorically of course :) The "NOREGEN"
intrinsic is the best approach in my opinion, but you have to be
careful that you think through how it's all going to work.
The other sensible option, having regen as a numerical stat that is
modified up or down (both permanently and temporarily), also requires
careful planning, especially if you have any min or max values to it.
--
Darren Grey
David Damerell
>Another possible solution: add special counter to unit. Effect that is
>preventing hp regen will increment it on attach and decrement it on
>detach. If counter is greater that zero, health is not regening.
This sort of dead-reckoning approach can be a bit error-prone - if it goes
wrong once (like NetHack's full-moon luck bonus) it goes totally wrong. Of
course it would be nice to have no bugs, but...
What about a can-regenerate() function or preprocessor macro, or a more
general function to check if beastie X has property Y?
--
David Damerell <dame...@chiark.greenend.org.uk> flcl?
Today is First Stilday, September - a weekend.
Ray Dillinger
You don't want a specific check for disease in your
regeneration function. Eventually you'll have a bunch
of things that affect regeneration, and you don't want
to have to check for each one. So begin as you mean to
go on and make NO_REGEN into a status of its own.
My actors have "properties" which are stored in a hash
table keyed by actor id and property key. Applying that
approach to your case, the property key would be NO_REGEN.
So the regen function can look in the table (fast) to
find out if there's a NO_REGEN property for this actor.
Each property has a "because" field that tells why the
actor has that property. In this case, "because" would
be the property key DISEASE. The actor would also have
a DISEASE property in the same table, with its "because"
field set to "until" some moment in the future. When
the status DISEASE is over, the next check of NO_REGEN
gives a "because" that points to a property the actor
no longer has, and the NO_REGEN property is removed.
Other possibilities for "because" include the actor ID of
some particular equipment, codes for racial, class, and
stat-based bonuses, magic spell, etc - any status which
can be revoked or change.
Because I do "open" hashing, each entry in the table
is actually a "hash bucket" implemented as a linked list.
So if the character gets another NO_REGEN property, it can
just go in the linked list, chained with the first one,
with its own "because" field giving a different key.
Bear
konijn_
> When I found that I'm struggling for more than 10 minutes I decided to
> make this post.
> It's not that I hope that someone will answer something good...
> But when I'm trying to formulate question in a form that someone else
> will (probably) understand it,
> there is a high chance to find an answer during this process...
>
> I'm trying to add Disease effect to my rl.
> This effect should prevent health regen.
Have an effect class with a properties list.
When calculating regen rate, go through all attached effects,
equipments, gods, race, class, birthsign what not which should all
have this properties list.
If the key is say 'regen_modifier' you could then retrieve both
regular bonus/malus and multipliers.
You throw it all together and end up with a final regen rate.
Easier said then done of course.
T.
jot...@hotmail.com
> Have an effect class with a properties list.
> When calculating regen rate, go through all attached effects,
> equipments, gods, race, class, birthsign what not which should all
> have this properties list.
> If the key is say 'regen_modifier' you could then retrieve both
> regular bonus/malus and multipliers.
>
> You throw it all together and end up with a final regen rate.
>
> Easier said then done of course.
>
> T.
In my design, regen is modeled by a component. When something wants to
stop regen, it just disables that component.
Jotaf
corremn
<n...@sheep.art.pl> wrote:
> At Thu, 2 Oct 2008 03:52:25 -0700 (PDT),
>
> corremn wrote:
> > Rhetorical hey? Do I know what rhetorical is?
>
> I do't want to pick on details, but I was taught that
> a rhetorical question is a question asked while already
> knowing the answer, just for the purpose of attracting
> the attention of the audience to a partcular problem...
Just poorly quoting an episode of the simpsons.
Mother Simpson: [singing] How many roads must a man walk down before
you can call him a man?
Homer: Seven.
Lisa: No, dad, it's a rhetorical question.
Homer: OK, eight.
Lisa: Dad, do you even know what "rhetorical" means?
Homer: Do I know what "rhetorical" means?
Xecutor
wrote:
> Quoting Xecutor <konstantin.stup...@gmail.com>:
>
> >Another possible solution: add special counter to unit. Effect that is
> >preventing hp regen will increment it on attach and decrement it on
> >detach. If counter is greater that zero, health is not regening.
>
> This sort of dead-reckoning approach can be a bit error-prone - if it goes
> wrong once (like NetHack's full-moon luck bonus) it goes totally wrong. Of
> course it would be nice to have no bugs, but...
error.
Since 'increment by one' actually means that there is property NOREGEN
with value 1 and source "Disease effect".
Whenever any effect is removed from unit, all associated properties
are removed too.
> What about a can-regenerate() function or preprocessor macro, or a more
> general function to check if beastie X has property Y?
As I stated I want to manage effects with noregen property only in
this effects only,
not somewhere else.
It's very bad if you have to dig thru many sources when you want to
add one feature :)
Xecutor
I actually like easy solutions.
I don't like solutions with possible side effects.
As for this issue...
I have found that except for resistance, resulting value of all other
properties
cannot be negative (after applying all bonuses).
So at least for now I made Disease as pretty big negative hp regen.
1) It does prevent hp regen.
2) If unit have GODLY hp regen, he can overcome disease :)
P.S. Non negative properties came from quite funny bug.
Bug in a cold effect stacking lead to negative speed of monster.
Which means that his movement actions were scheduled in the past.
i.e. his movement was the only action executed in the world for a
while :)
David Damerell
>On Oct 2, 11:09=A0pm, David Damerell <damer...@chiark.greenend.org.uk>
>>What about a can-regenerate() function or preprocessor macro, or a more
>>general function to check if beastie X has property Y?
>add one feature :)
If you think it's very bad to have a general-purpose function to check if
beastie X has property Y, and instead to duplicate very similar code all
over the place whenever you want to check if a beastie has a property,
you're probably doomed.
--
David Damerell <dame...@chiark.greenend.org.uk> flcl?
Today is Gorgonzoladay, September - a weekend.
David Damerell
>In my design, regen is modeled by a component. When something wants to
>stop regen, it just disables that component.
Short-lasting effect A disables it. Long-lasting effect B disables it.
Short-lasting effect A ends and... ?
Radomir 'The Sheep' Dopieralski
David Damerell wrote:
> Quoting <jot...@hotmail.com>:
>>In my design, regen is modeled by a component. When something wants to
>>stop regen, it just disables that component.
>
> Short-lasting effect A disables it. Long-lasting effect B disables it.
> Short-lasting effect A ends and... ?
Segmentation fault :P
--
Radomir Dopieralski, http://sheep.art.pl
jot...@hotmail.com
wrote:
> At 03 Oct 2008 15:26:09 +0100 (BST),
>
> David Damerell wrote:
> >>In my design, regen is modeled by a component. When something wants to
> >>stop regen, it just disables that component.
>
> > Short-lasting effect A disables it. Long-lasting effect B disables it.
> > Short-lasting effect A ends and... ?
>
> Segmentation fault :P
>
> --
> Radomir Dopieralski,http://sheep.art.pl
I dunno what you mean, enable/disable is just a "pause", a disabled
component simply stops listening to events. Changing the current state
to the same state does nothing :)
Also, I'm becoming more and more inclined towards associating unique
IDs to objects so that referencing a deleted object is not a problem
(which shouldn't happen now, but might become an issue in the future).
I think I'll wrap these long-term references in a handy class that, on
request, searches for the object in question and returns a (short-
term, error-prone -- but fast) pointer.
Jotaf
Ray Dillinger
> On 3 Out, 15:54, Radomir 'The Sheep' Dopieralski <n...@sheep.art.pl>
> wrote:
>> >>In my design, regen is modeled by a component. When something wants to
>> >>stop regen, it just disables that component.
>> > Short-lasting effect A disables it. Long-lasting effect B disables it.
>> > Short-lasting effect A ends and... ?
>> Segmentation fault :P
> I dunno what you mean, enable/disable is just a "pause", a disabled
> component simply stops listening to events. Changing the current state
> to the same state does nothing :)
He was referring to a bug where the end of an effect
restores conditions to how they were before the effect began -
in this case causing healing to start working again even though
the long-term state would have it stopped. Later, in systems
with this bug, when the long-term effect ends, healing would be
restored to the way it was when the long-term effect started -
ie, healing would be halted.
> Also, I'm becoming more and more inclined towards associating unique
> IDs to objects so that referencing a deleted object is not a problem
> (which shouldn't happen now, but might become an issue in the future).
> I think I'll wrap these long-term references in a handy class that, on
> request, searches for the object in question and returns a (short-
> term, error-prone -- but fast) pointer.
I recommend doing this. It is a good idea and I think most games
when they get past a certain level of complexity demand it. Actors
(monsters, items, etc) can be referenced for many reasons and you
don't want a situation where a reference-holder can wind up with
a blue pointer and no way to tell that it's blue.
Bear
Pata...@gmail.com
Make NOREGEN an integer instead of boolean. If an effect comes on
which prevents regen, increase it by 1; if it goes away, decrease it
by 1.
Then check for NOREGEN being > 0 in the regeneration code.
Xecutor
> Quoting Xecutor <konstanti...@gmail.com>:
> >On Oct 2, 11:09=A0pm, David Damerell <damer...@chiark.greenend.org.uk>
> >>What about a can-regenerate() function or preprocessor macro, or a more
> >>general function to check if beastie X has property Y?
> >It's very bad if you have to dig thru many sources when you want to
> >add one feature :)
>
> If you think it's very bad to have a general-purpose function to check if
> beastie X has property Y, and instead to duplicate very similar code all
> over the place whenever you want to check if a beastie has a property,
> you're probably doomed.
Probably there is a misunderstanding...
I just do not want function like this:
bool canRegenerate()
{
if(haveEffect(diseaseEffect) || haveEffect(doomedEffect) ||
haveEffect(someOtherEffect) || haveEffect(yetAnotherEffect))
{
return false;
}
return true;
}
Martin Read
>Probably there is a misunderstanding...
>I just do not want function like this:
> bool canRegenerate()
> {
> if(haveEffect(diseaseEffect) || haveEffect(doomedEffect) ||
> haveEffect(someOtherEffect) || haveEffect(yetAnotherEffect))
> {
> return false;
> }
> return true;
> }
N.B. the following has not been tested or debugged. Also,
CamelCaseIsUgly.
/* In C style */
enum Status_code
{
Status_diseased,
Status_held,
Status_confused,
/* ... */
Status_doomed,
Number_of_status_effects
};
struct Status_effect
{
struct Status_effect *next;
enum Status_code category;
int duration;
};
#define Status_flag_noregen 0x00000001u
#define Status_flag_nomanaregen 0x00000002u
struct Status_details
{
/* conceivably we'd need more than 32 bits, but this'll do for
* pedagogical purposes. */
uint32_t flags;
const char *name;
};
struct Status_details[Number_of_status_effects] =
{
{
Status_flag_noregen,
"diseased"
},
/* ... */
};
int player_can_regenerate(struct Player *pptr)
{
struct Status_effect *septr;
for (septr = pptr->first_status; septr; septr = septr->next)
{
if (status_details[Status_code].flags & Status_flag_noregen)
{
return 0;
}
}
return 1;
}
// In C++ style
class Status_effect
{
public:
// ...
virtual bool prevents_regeneration() const { return false; }
};
class Disease : public Status_effect
{
public:
// ...
bool prevents_regeneration() const { return true; }
};
bool Player::can_regenerate()
{
std::list<Status_effect *>::iterator i;
for (i = status_effects.begin(); i != status_effects.end(); ++i)
{
if (i->prevents_regeneration())
{
return false;
}
}
return true;
}
--
\_\/_/ turbulence is certainty turbulence is friction between you and me
\ / every time we try to impose order we create chaos
\/ -- Killing Joke, "Mathematics of Chaos"
Xecutor
That's why question is mostly rhetorical - when you don't know
architecture and general structure of the game it's quite hard to
give sensible advice.
For now I ended up with negative hp regen bonus as effect of disease.
With some really good gear it could be overcame.
For some reason I remembered ice/fire/lightning immunity in Diablo 2.
Immune mobs have >100% resistance in corresponding element.
But pal+necro can remove immunity by big enough resistance reduce.
Negative hp regeneration in my system do not lead to hp loss ;)
David Damerell
>Make NOREGEN an integer instead of boolean. If an effect comes on
>which prevents regen, increase it by 1; if it goes away, decrease it
>by 1.
Congratulations, this is where we came in.
--
David Damerell <dame...@chiark.greenend.org.uk> Distortion Field!
Today is Second Brieday, September.
David Damerell
>David Damerell:
>>If you think it's very bad to have a general-purpose function to check if
>>beastie X has property Y, and instead to duplicate very similar code all
>>over the place whenever you want to check if a beastie has a property,
>>you're probably doomed.
>Probably there is a misunderstanding...
>I just do not want function like this:
> bool canRegenerate()
And that's a good idea as soon as there's two or more places you need to
check if something can regenerate. Better yet, if your function is a
generic check-beastie-properties affair (used for regeneration and lots of
other things), you're going to want it in two or more places right off the
bat.