[Adonthell-devel] What's next?

[Kai Sterker]

Now that I managed to get things running on OS X, it's time to think 
about the next steps.

For one, there are a few bits and pieces of v0.3 that we will also need 
in v0.4. Among those are

* gametime: in-game time and date classes, used to trigger scripts and 
actions.
  It'll sit on top of the timer class, but it will belong to the event 
system.

* event system: the connection between engine and event scripts. While 
I do not
  want to touch the foundations of that, I am thinking of a different 
approach
  for the interface between event system and Python:

Right now, one event matches one python script, which means that each 
event contains a complete python class instance. That will get quite 
inefficient if a map contains plenty of scripts.

Take the simple teleport script, for example:

  class teleport:
      def __init__ (self, eventinstance, smdest, xdest, ydest, destdir):
          self.smdest = smdest
          self.xdest = xdest
          self.ydest = ydest
          self.destdir = destdir

      def run (self, submap, x, y, dir, name):
          events.switch_submap (adonthell.gamedata_get_character (name),
              self.smdest, self.xdest, self.ydest, self.destdir)

A new instance is constructed for each exit that exists on a map, and 
that will be quite a few, especially for buildings. The reason for that 
is that the data for the script is stored in the script itself. That 
means it cannot be reused very well.

But if we'd store the event data with the event and pass it to the 
script at runtime, we could do with a single instance of the script 
that'll work for all teleports. Like this:

class teleport:
    def teleport (self, loc, dest):
        events.switch_submap (adonthell.gamedata_get_character 
(loc.name),
            dest.smdest, dest.xdest, dest.ydest, dest.destdir)

- loc (location) is a structure containing the current position and 
name of the
  character triggering the event.
- dest (destination) is the same structure, containing the place that 
character
  should be teleported to.

To register a method with the event system, you'd use a event::register 
(string script, string callback) method. It will load the script into a 
pool, if neccessary, and connect the callback. That means, one python 
class can contain many different callbacks. That way, all special 
events of a map could be placed into a single script instead of having 
plenty scripts per map. That'll help keeping the game_events directory 
tidy, which is quite a mess at present. It should also speed up 
loading, as no script will be loaded twice. And it will simplify the 
event system, which only needs to store python callbacks, instead of 
both classes and callbacks.

* characters: that includes everything from base character to 
inventories, items
  and also combat related things. While inventories and items shouldn't 
need any
  changes, I'll have to review the combat related code (character stats 
and
  such) somewhat. Help with that will be greatly appreciated :-).

* character schedules: like the event scripts, the character schedule 
system of
  v0.3 should undergo some considerable changes. As I wrote earlier, 
NPC actions
  should become more realistic. That can be achieved with the following 
methods:

  - Each character will have a master schedule that defines its actions 
during
    the day (or another period of time).
  - Each action is detailed in a script of its own, so that actions can 
be
    reused between characters. (That means, the parameters for actions 
are
    defined in the master schedule)
  - Characters can receive messages that override the master schedule. A
    message will simply start a certain action. Messages may come from 
game
    events, other NPCs, etc ...

  Alltogether, NPCs will be able to act much more diverse on their own, 
but they
  will also be able to interact much more with their environment. And 
as a
  whole, writing character scripts should become much easier, as the 
master
  schedules can rely on the available action scripts. So a few simple 
actions
  (goto, take, put, speak, ...) can be easily combined to form 
individual NPC
  behaviour or more complex actions (guard, entertain, chase, ...).

* dialogue engine: no need to change that, I think. What needs the 
change is the
  the gui which received some criticism in the past. I'd like to have 
something
  where players can review the whole conversation if they want, and 
where it is
  also clear how many choices there are. All that should work with just 
the Up
  and Down key + Enter/Space.

  What will be further refined is the dialogue editor, however. If I 
manage,
  I'll finally implement the subdialogue feature, which means that 
pieces of
  dialogue can also be reused, either for different dialogues of the 
same
  character or even for different characters. But that'll come last ...


Okay, I think that covers everything I have originally worked on. 
Porting it to v0.4 may take a while, as there are a few things to 
rewrite. But once it is done, we'll have a good foundation for building 
the v0.4 demo.

As for the organization, I intend to add two more modules: event and 
rpg. Further will contain the gametime and event stuff. Latter the 
character related things: items, inventories, schedules, dialogues. The 
python script cache/pool will of course become part of the python 
module.


As usual, comments and suggestions are welcome. Once everything is 
clear, I'll start at the top and work my way down the list. So watch 
the CVS for updates, that will hopefully come reqularly. (Man, I'm 
really motivated to do some proper work again :-)!)

Cheers,

Kai