Re: [Adonthell-devel] Schedules

[Kai Sterker]

On 30 Apr 2002 14:27:43 +0200 Alexandre Courbot wrote:

> If I see it correctly, it would be a collection of "if <condition> use
> <schedule>", right? This makes sense, and would be quite easy to
> implement, probably. The character editor could let you fill these
> conditions and associate one schedule to them, with some parameters.
> 
> > Of course that's not the only way to switch schedules. This may also
> > be triggered from events or dialogues or even from certain character
> > schedules themselves.
> 
> I'd even say that this way of switching schedules should be used very
> rarely. You can't, on each cycle, decide which schedule to use. My
> approach would be, when the manager assign a schedule, this schedule
> should keep the hand until it is finished or has failed. Then the
> schedule manager would choose another task to go, depending on the
> current conditions.

That's a bit of misunderstanding, I think. The manager schedule will not
run very often. Only if a script sets 'running' to false. Depending how
detailed a character will be scripted, this will happen once every
couple hours of gametime. Certainly not every cycle. Not even every 1000
cycle.  
> Maybe it's a bit early for talking about the implementation, but I'd
> see the manager coded in C++, and executing the Python conditions by
> launching their code snippets in C++ side.

With the above in mind, I don't think it is neccessary to code the
manager script partly in C++. And although the basic script will be a
series of if statements, some might be more complex. That's why I'd like
to make it proper python module. Anyway, once we have something running,
we can always improve upon it :).


> Good idea. Very handy for time-limited tasks. But performances would
> awfully drop if this isn't done in C++.

Yeah, that would be done on C++ side. A simple increment (or decrement)
in the function that runs the actual schedule.

 
> In this case, characters should be able to launch "messages" to each
> others, so we can interrupt the schedule if necessary, instead of
> testing the conditions on each cycle. Say a fight occurs. The
> character that is attacked could launch a "HELP" message to all
> characters that are 4-5 squares around. Depending on their behavior
> (and the schedules they inherit from), they may not react to this
> message, run away, or enter the fight. Something like this. This is,
> once again, a work for the schedule manager.

I haven't thought at all how this would be implemented. But it would
possibly involve setting flags (== sending messages) of NPC's that are
nearby.  

> Agreed. Some middle-level functions should definitely be implemented
> in C++. Short list:
> -locating an item/character in a certain area
> -finding and following a path (already done in 0.3, but pixel by pixel
> movments will make it much harder)
> -....
> 
> This is still "generic" enough to be coded in C++ to me.

Exactly.


> Certainly, but you can't make the whole world and all the maps live in
> the same time. When no player is on a map, it can't continue to run
> for evident efficiency reasons. So maybe we can "simulate" dwarves
> mining and such, but the real "economy" (if any, because that
> shouldn't yet be our short-term objectives :)) shouldn't be directly
> dependant of these schedules. Another problem will be to find where
> will a character be and what will he do when the player enters a map.

That's right. What happens to NPC's on other maps once the player enters
is a very good question. Guess there should be a way to 'teleport' them
straight to the place where they should be, depending on their manager
schedule. From then on they can start their normal schedules. When I go
about coding stuff, maybe I'll find a nice way to accomplish this
without too much side-effects with the regular code.


> > Writing those interacting schedules probably takes a while, but a
> > lot of them will contain mainly the same things: pick that up here
> > and deliver it there. With a way to let NPC's determine where they
> > should go for what, this won't be too difficult.
> 
> Maybe not such a while, I'd say. Once again, we should be able to
> combine existing behaviors to create new ones.

Of course. That's what it is all about :). It's really a matter of how
perfect we want everything to be.

Kai