Re: [Adonthell-devel] Schedules

[Kai Sterker]

On 01 May 2002 14:04:56 +0200 Alexandre Courbot wrote:

> > 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.

I guess we'd have some places on the map where monsters will be
generated. Once they are on the map they'll be persistant until killed.
Further, each map should have an upper limit of monsters and each
generator a respawn rate.

The generator could be scripted as well, btw. I could imagine some sort
of monster pool, where each monster type has a number of equipment sets
and combat behaviour scripts associated. Those would be combined to make
the actual monster. The generator script would just pick a monster from
the pool and place it on the map.

Actually, one monster generation script per map would already be enough
for this purpose. It could be run periodically, depending on the respawn
rate and whether the monster limit has been reached or not.


Other monsters ("bosses" for example) could be placed on the map just
like NPCs, and quite a few might actually be NPCs that turn hostile at
some point.

 
> 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.

Right. But I guess it can be treated much like a schedule. I.e. it would
run periodically to test some conditions and either continue with the
current action or do something else. Switch target, retreat, etc ... 


> 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.

That's right. The best is to have a static gametime class and some
time_event class that makes use of gametime then. Anyway, for now we
shouldn't need time_events at all.

Game cylces are not really independant from machine speed btw. Since
there is an upper limit to the number of frames to skip, you'll get a
slowdown on older hardware (like my P200). However, it might be best to
have the gametime slow down as well in that case :).

Anyway, if the counter depends on gametime instead of game cycles it'll
be independant from the game cycles. So if we ever decide to change the
number of cycles per second, there will no need to adapt that counter.

Kai