Re: [Adonthell-devel] Schedules

[Alexandre Courbot]

> The ideal solution would be schedules that only concentrate on one
> thing. This thing might be more complex than any schedule we've written
> so far, but at the same time generic enough that practically every NPC
> can be given this schedule.

This is probably the way to go. Adopting the same design that for items.
That is, not one schedule per character, but one schedule per kind of
behavior (like we did for the items: not one description per object, but
one per kind of object). Using, why not, inheritance and such stuffs (if
applicable). In Waste's Edge's schedules, there is a lot of code that is
redundant, or that at least would if it was using parameters.

> And like that it works:
> The manager schedule is special for each character. It basically
> describes what he does during the day or on special events. It might get
> pretty big and CPU consuming, but as it only runs occasionally that
> shouldn't matter. Task of the manager schedule is to set a new character
> schedule whenever the character has none. (So all a generic schedule
> needs to do at the end is setting 'active' to false. The next iteration,
> the schedule manager spots this and can run the manager schedule to set
> the actual schedule, depending on such things as time of the day,
> location or quest flags.

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.

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.

> As an addition, the schedule manager might contain a counter that can be
> set, and when it reaches zero it'll run the manager schedule without any
> further action from outside.

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

> * let characters react to goings-on in their neighbourhood. If a fight
>   breaks out for example, some might attack others might escape and call
>   for help. That in turn might attract other NPC's or scare them away, 
>   so that suddenly a crowd gathers, or guards appear or whatever.

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.

> Even our highly specialized, generic schedules are not generic enough.
> There are tasks that are part of many different schedules, like locating
> and picking up a certain item. Activities like those can be put into
> helper modules that are used by the schedules then. CPU intensive code
> could even by implemented on C++ side for efficiency.

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.

> And finally, here is a little example that came to my mind:
[...]

Sounds really great. :)

> We could probably create a small economy that way: peasants could bring
> fruits and stuff to the market, or grain to the miller. The Dwarves
> mining ore, refinning and smithing stuff, and finally bringing it to
> town. And so on and on and on ...

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.

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

> So, if there are no objections (or better ideas), I'll concentrate on
> that part from now on.

Please go on! :) No game I've seen proposed such impressive behaviors.

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