Scripting:Characters

Character scripting is divided into two areas: creature and NPC behavior is determined by the so-called schedule scripts. The actual character implementation (i.e. the character related parts of the role playing system) is also done mostly via Python scripts.

Character Schedules

Character schedules are a little bit like map view schedules, only more complex. The key differences are:

• Character schedules are event-driven, the map view schedule is executed once per game cycle.
• Character schedules are controlled by a master schedule, the map view schedule is controlled by the map view.

The Engine Architecture has a brief description of the schedule system, but in general, a worker schedule can be compared to one of the small Unix tools (like sed, grep, awk, find and consorts). The master schedule then is e shell (script), that combines these tools to perform the most complex task.

So the trick is to write worker schedules as generic as possible. They should be kept stateless and only need their constructor arguments to parameterise them for the specific task at hand. Master schedules OTOH can be tailored to a specific character or occasion and are allowed to keep track of various attributes between individual runs.

The interface for a master schedule looks as follows:

   def __init__ (self, [world.schedule] schedule, opt_arg1 ... opt_argN):
 
   def run (self):

• The constructor gets passed the schedule object, which can be used to set a worker schedule and to get access to the map and everything on it. Optionally, more arguments can be passed when setting the master schedule. These must be strings or integers only, so that they can be serialized.
• The run has no arguments. It is called whenever a new worker schedule needs to be set.

The interface for a worker schedule looks as follows:

   def __init__ (self, [world.schedule] schedule, opt_arg1 ... opt_argN):
 
   def start (self):
   
   def pause (self):
 
   def resume (self):
 
   def stop (self):
 
   def __del__ (self):

• The constructor gets passed the schedule object, which can be used to stop the current worker schedule. It also provides access to the map and everything on it. Optionally, more arguments can be passed when setting the worker schedule. These must be strings or integers only, so that they can be serialized.
• The start method gets called to activate the worker schedule.
• The pause method gets called when the character should pause whatever he is doing currently. This might be because the player paused the game, started a conversation with that character or for any other conceivable reason.
• The resume method gets called whenever it is fine to resume the schedule.
• The stop method is called when the schedule has been stopped, usually by its own request.
• The destructor is called directly after stop.

It should be noted that a worker schedule should not try to destroy itself. Instead, it must call

 schedule.set_running (0)

to stop itself and cause the manager schedule to determine a new worker. Similarly, a worker schedule can not directly set a new worker while it is running. Instead, it can use

 schedule.queue_schedule ("new_worker", opt_arg0 ... opt_argN)
 schedule.set_running (0)

to queue the next worker schedule. In that case, the schedule system will automatically start the queued worker without activating the master schedule. This allows to split complex actions into multiple smaller scripts. By finishing the current worker before starting the next one, it is ensured that changes to the world state made by the current worker will be available to the next worker too.

Character Implementation

Nothing to see yet