Re: [Adonthell-devel] Schedules

[Alexandre Courbot]

> First of all, we will not only have NPCs but also 'monsters' that are
> walking on the map. Which means they too need a schedule of some
> sort. I guess we can treat them much like normal NPCs as far as
> schedules go, except that their schedules would probably be much
> simpler. Some might walk around randomly during the day and hide
> somewhere at night, or vice versa. Others would just lure somewhere 'til
> the player passes.

Regarding the map engine, monsters are in no way different from regular
characters. The only difference is that they are not that "persistant",
and when/how to make them appear remains a question.

> A related issue is combat though. How will such creatures be controlled
> during combat? Will there be a combat schedule, or will this be handled
> by completely different code? Of course there will be some AI routines
> in C++ (determine what target to attack and the like), but will a
> creature's combat behaviour be scripted or not? I could well imagine
> that, as it would enable us to let different enemies act completely
> different. Even enemies of the same type could get different behaviours.
> And I can also imagine that the generic schedule can handle combat mode
> as well. Further thoughts on this are neccessary though and welcome. 

Scripted combat behavior makes sense to me as well. Also most AI
algorithms behavior can be modified by parameters (for stronger/weaker
behavior), so I guess we can go that way too. As long as the core
functions are coded in C++, of course. Combat behaviors will probably
require an additional script. Which would not really be a "schedule" to
me, but rather a description of the character's behavior.

> The next issue is the counter for how long a certain schedule is allowed
> to run. I guess the best solution is to revive the gametime class. The
> counter would then count down gametime minutes instead of game cycles.
> That way it'll be completely independent from the machine speed and
> such. It's also much easier to think in (gametime) minutes instead of
> game cycles when setting the counter for a script.

Game cycles are independant from the machine speed. If you want to make
measures in gametime minutes, you'll have to rely on the game cycles
(with approximatively 70 cycles = 1 real second).

Beware with the gametime class though. Some static methods are used in
some core functions. Please make sure it won't depends on external stuff
like it did before with the events, or we'll lose our modularity. Maybe
another class (without static members, I personally dislike classes with
static/non static members and find them confusing) using gametime would
make more sense.

Alex.
-- 
http://www.gnurou.org