[Adonthell-devel] Interaction on the map

[Kai Sterker]

With the dialogue widget in place, it's time to think about the topic
of interactions on the map. Those include

- initiating dialogue (that's what we'll need now)
- manipulating switches or doors
- disarming traps
- picking up items
- attacking

and possibly more.

These would be triggered by different keys (or by a common action key
depending on context/game mode/whatever). Since the game controls will
eventually end up in the Player schedule script on Python side, it
should be fairly easy to change to something that's convenient and
easy to use. Don't want to go into this yet, but there have been
suggestions already. See
http://lists.nongnu.org/archive/html/adonthell-devel/2002-02/msg00050.html


Depending on the action, the player character or an item or spell
wielded by the PC determine the area that is potentially affected by
the action. We can use this to retrieve a list of potential targets
for the action. Targets are all "named" objects on the map, which will
be backed by an actual RPG instance (more or less a Python script
wrapped by a C++ stub ... see
http://cvs.savannah.gnu.org/viewvc/adonthell/src/rpg/item.h?revision=1.5&root=adonthell&view=markup
respectively 
http://cvs.savannah.gnu.org/viewvc/adonthell/test/data/items/item.py?revision=1.1&root=adonthell&view=markup
for example). The Python script will implement object behavior and the
specific instance will contain the object state.


If the PC is executing the action directly (i.e. initiating dialogue,
pushing levers, opening doors), we determine the nearest/topmost
object and let it execute the action.

If a weapon or spell is involved, we will let the weapon/spell
implementation filter the object list to determine which objects could
possibly be affected. Only afterward, we determine which object(s)
will execute the action. (This might involve the player actively
choosing between possible targets, depending on the combat model we'll
implement).


To sum it up in pseudo code, we'd have something like this:

on button pressed:
   action_type = calculate_action_type_for_button_and_mode()
   if (action_type == combat)
       weapon = player.get_active_weapon_or_spell()
       area_of_effect = weapon.get_area_of_effect()
   else
       area_of_effect = player.get_area_of_effect()

   object_list = map.objects_in_area (area_of_effect)

   if (action_type == combat)
      object_list = weapon.filter_objects (object_list)
      if (object_list.size() > 1)
         object_list = player.handle_object_selection_for_combat_here()
   else
     if (object_list.size() > 1)
        object_list = get_nearest_object (object_list)

   for object in object_list
     object.perform_action (action_type, player)


I guess this would all be pretty neat and automatic. We could actually
generalize this code to handle NPC actions as well. So in the Player
schedule we'd have something like

on_button_pressed:
   action_type = calculate_action_type_for_button_and_mode()
   perform_action (action_type, player)

For an NPC or Creature we'd simply do
   perform_action (action_type, NPC)
instead.

The difference would be the implementation of
handle_object_selection_for_combat_here(). For the PC, we could
implement whatever our combat model requires for the specific attack.
I.e. hit everything in range, pick a target manually or anything in
between. For different creatures we'd have here their various
AI-routines for picking a combat target.

Action_type would be one of NORMAL, SNEAK and COMBAT.


This should be pretty generic. The implementation for most of the
actual logic would sit on python side. That includes the methods:

get_area_of_effect()                                    // both
character and item (weapon or spell) class
filter_objects (object_list)                            // item
(weapon or spell) class
handle_object_selection_for_combat_here()  // character class
perform_action (action_type, player)             // item class

That might mean that stuff like switches or doors would be implemented
as items (or we'd have an extra category for those). But we can
determine that later.


Any comments? Improvements?

Kai