Re: logically weird loop

On 21.11.2024 12:01, fir wrote:

 
there is a question qhat would be more logical (prone, suitable) here
 
for example it is a movement and say takes 200 mikroturns then logicall
would be to not do this as Setup() in turn 0 and finalize(0 in turn 200
but add 1/200 of distance in each turn.. but the rogualike is in
discrete space on tiles so i think setup() and finalize() is probably
better
 
more yet in things like fight ..say one character was Setuping() a hit
which takes like 90 microturns to finalize and the defender could be
able to setup() a shield blocking or something or decide to setup a
hit too
 
i dont tested it yet but my [previous approach without the actions that
spans in time was much simpler and you only eventually check what last
action of given bot waas bot not which next or current is
 
some would say tehe simpel would suffice but in fact if soeme want model
more nice system you need that spaning action time imo...sadly the
division of myriads of this actions on setup() and finalize() is worse
to code

My opinion on that...

For a roguelike, don't model it too detailed or too "realistic"; it
happens too often that you're getting lost in unnecessary complexity.

Keep it time-discrete (as you indicated above), define an integer of
sufficient length, don't use numeric types with fractions, define a
sensible base unit (that conforms probably to your 1/200 unit).

The start of action is the primary point in time. With "elementary"
actions (place a hit, quaff, read, loot, etc.) it's not worth to
complicate things; just consider the actual environmental situation
of the dungeon installations or individuals that affect your action
in any way.

It is an issue when _long lasting actions_ (like learning spells,
eating, etc.) will get "interrupted". Here I suggest to inspect the
Nethack code (obviously being still the "standard" roguelike), or
have a look into GnollHack (which IMO may have a more sophisticated
way to handle such interrupts). - I've not looked into the code so
I cannot give you concrete information; it's just from observation.

Practically I'd have, for example, an eating character put into a
queue at the time when its eating is supposed to get finished. In
case another actor or event pops in to affect the player (or the
[user-perceivable] environment) the player object will be taken
from the queue, its status (e.g. unfinished food consumption)
updated, and rescheduled. The actual activation-time for that may
be immediately (after) the triggering event source, or delayed
(e.g. after gotten hit by sleep or paralysis) to the time it is
required for the effect to wear off.

I think such event-queues on a time-scale makes things more easier
and more consistent to implement.

(I also think that using C for such a task is not the best choice.
C++ at least provides classes to keep things together. - But that
just aside, to not angering the audience too much.)

Janis

REACTIVATE this.player DELAY meal_time (food_item.nutrition)