[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Adonthell-devel] What's next?
From: |
Kai Sterker |
Subject: |
[Adonthell-devel] What's next? |
Date: |
Thu, 27 Nov 2003 14:56:45 +0100 |
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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Adonthell-devel] What's next?,
Kai Sterker <=