5.1.9.2 Action

Une action est une ressource qui dispose d'un block de code d'exécution purement virtuel :

virtual xyzRessource *execute(xyzRessource *_objects) = 0;

Ainsi une action peut agir sur un groupe quelconque de ressources (_objects est une liste contenant des ressources utiles à l'action) de trois façons :

• En modifiant une des ressources d'entrée (_objects),
• En créeant de nouvelle(s) ressource(s) et en les retournant,
• En supprimant les ressources d'entrées.

Il serait d'introduire la notion de niveau d'interactivité ou d'interaction entre utilisateur (joueur) et actions, et, implicitement, ressources.

Basiquement, il n'y a qu'une seule contrainte à respecter concernant les ressources d'entrées : afin de n'avoir à implémenter qu'un appel unique de la méthode d'éxécution execute, j'ai choisit de considérer que les ressources d'entrées sont systématiquement données au travers d'une liste de ressources intermédiaires (Même lorsqu'une seule ressource est requise par l'action).

Pour répondre à cette contrainte inhérente à l'implémentation actuelle, quelques macros facilitant (en théorie ;)) la chose ont été récemment introduites (cf. commits) :

• XYZ_ACTION_ARGS, construit une liste de ressources temporaires à partir d'un nombre quelconques de ressources passées par référence (la dernière ressource etant 0, le pointeur nul),
• XYZ_ACTION_ARG, retourne la ressource numéro number fille de args dont l'identifiant est égal à id.

Cette dernière macro est à utiliser lors de la récupération des variables nécessaires pour le block de code associé à une action quelconque.

Cependant, des contraintes concernant les arguments (ressources) conditionnant l'exécution effective du block de code associé à une action peuvent être formulées explicitement par le programmeur via des méthodes protégées de l'action. Voici un exemple :

addActorNeed(s_mutate);
addObjectNeed(g_any);
addObjectNeed(g_any);
addDelay(XYZ_TIME_DAY(4));

s_mutate représente la capacité (skill) de mutation (``skill_mutate'') et g_any représentant un gène quelconque. Ce block d'instruction définit que l'action ne pourra s'éxécuter que si l'acteur la possédant a la skill de mutation et que les objets passées pour l'action durant l'appel de execute (paramètres _objects) sont deux gènes.

Le addDelay définit que l'action sera complètement réalisée au bout de quatre jours. Depuis la version 0.0.2, il semblerait que seuls deux types d'actions se détachent : les actions atomiques et les actions discrètes. Une action atomique est complètement réalisée au bout d'un temps prédéfinit, ou bien peut être arrêtée avant; dans ce cas là, l'action ne sera pas physiquement exécutée et elle n'aura donc aucun effet (à ce jour, seul ce type d'action est implémentée). Une action discrète peut être partiellement réalisée, même si elle est interrompue.

Considérer action/action.h et les action/action-*.h pour obtenir un peu plus d'informations au sujet des divers appels définissant les contraites (ou besoins (need) des actions.