adonthell-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Adonthell-devel] Schedules


From: Kai Sterker
Subject: Re: [Adonthell-devel] Schedules
Date: Wed, 1 May 2002 13:47:08 +0200

On Tue, 30 Apr 2002 15:17:24 +0000 cirrus wrote:

> Oh right, I wasn't thinking of maps - I thought in the whole game -
> that could easily be like 1000+ eventually.

I only hope we don't need to write 1000+ dialogues then ;).


Anyway, here are some more thoughts about this topic in general.

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.

If we find a method to allow NPCs to communicate in some way, we could
also have monsters that go after the player and 'call' their likes to
aid them. Imagine a pack of wolves for example. That's stuff for the
future though. Right now I'd be already happy if NPCs/monsters show
life-like behaviour on their own.

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. 

See Josh, we can flood you with work! ;)


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.


That about is it. Guess I start to code a little now.

Kai



reply via email to

[Prev in Thread] Current Thread [Next in Thread]