description d'un graphe de tâches

Bonjour,
j'ai depuis un petit moment commencé ce projet de moteur de jeu qui ne comporte pas une boucle principale au sens usuel du terme. La façon dont le code "progresse" est par l'éxécution d'une tâche qui, lorsqu'elle est terminée, declenche l'éxécution de la tâche suivante (ou des tâches suivantes). certaines de ces tâches peuvent être divisées en plus petites tâches (la majorité des tâches sont minuscules et indivisibles, comme par exemple "lire le clavier", "verifier les messages sur la fenêtre Windows" etc etc. Lorsque ces petites tâches sont terminées alors l'update du jeu devrait se déclencher, puis lorsque c'est fini retour à la case départ.
certaines tâches peuvent très bien etre bloquantes (attendre un message windows avant de continuer) ou même deux tâches bloquantes peuvent être éxécutées en parallèle.

Pour faire une pause dans le jeu, on peut insérer une tâche sur laquelle la boucle principale dépend. Cette tâche va alors empecher la boucle principale de redémarrer tant qu'elle est bloquante.

Ce ne sont que quelques exemples, l'éditeur lui-même est fait de la même facon
tout le framework d'éxécution des tâches, de division, etc marche déjà.

mais je suis confronté a un problème de design: comment décrire ce graphe de tâches de manière lisible? je ne souhaite pas vraiment que chaque composant rende publique ses tâches (ce sont des membres privés et personne ne devrait y accéder), de plus le code devient un peu spaghetti et difficile a suivre lors de la création de ce graphe. Qui plus est le graphe doit pouvoir être généré différemment pour le jeu et pour l'éditeur, donc il pourrait être de préférence decrit sous forme de "données" et pas en code.
J'ai pensé déjà que lorsque le graphe est créé il pourrait s'auto-ecrire dans un fichier a parser avec l'outil de Doxygen pour générer des graphes; il pourrait alors y avoir une bonne doc du graphe des tâches.


le graphe est plutôt statique, les tâches elles_mêmes ne s'insèrent pas au milieu du déroulement comme ca. Ce sont plutôt les tâches qui sont paramètrables.

Comment pensez vous que je devrais décrire ce graphe ?

Pour décrire un graphe, en général, on utilise une liste des arcs (c'est d'ailleurs ce que fait dot).

Et effectivement, perso, je recommanderai de l'externaliser par rapport à ton application.

en fait, les noeuds sont des tâches et les arcs sont les dépendances entre les taches
je m'oriente vers une description un peu pyramidale, a savoir qu'un composant va publier un Job (qui est une forme de tache). ce job est vu comme une tache simple, on peut lui attacher des dependances etc etc
mais pas besoin de connaitre la bouillie interne

donc le composant "physique" va publier un job, le composant "graphique" va publier un job (composé de plusieurs taches qui dependent les unes des autres)
et l'application se chargera de creer un job de plus haut niveau qui utilise ces deux jobs.

Ca ressemble à un moteur de workflows décrit comme ça. Ce que tu appelles job est un workflow, et tu as plusieurs workflows dans ton application, en fonction du choix initial tu choisis le workflow qui s'exécute.

pour moi c'est plus une affaire de design que de choix, en gros qui est responsable du flow?
si on a un objet responsable a lui tout seul du flow alors on se retrouve avec une classe qui connait toute les autres

Ça ressemble à la même problèmatique que factory, et on doit pouvoir y appliquer la même solution.

Tu as un "task manager" qui est connu de tous, agit comme une factory, et auprès duquel s'enregistre toute tâche prête à être utilisée dans un workflow. Le flot est lu depuis un fichier, et la factory sait à partir du fichier (grâce à une sérialisation ad-hoc, et une map identifiant <-> fonction de création) quel type d'objet créer, comment le créer, et ensuite les lier entre eux.

Personne n'a besoin de connaître l'ensemble des classes, le lien est effectué au runtime (toutes les classes de tâches s'enregistrent à l'exécution auprès du task manager).

cela passe par une certaine connaissance de la logique interne. Decrire les dépendances, c'est connaitre la soupe interne. D'une certaine facon tout du moins.

Qu'est-ce qui te choque à ce que cette dépendance soit dans un fichier lu à l'exécution ?

À un moment, il faut bien que tu le crées, ce graphe, et à mon avis, il vaut mieux avoir l'information regroupée que des petits bouts épars.

je ne suis pas certain pour les bouts epars.
En fait ce qui me gène c'est que quelque part quelqu'un aura connaissance de toute les taches a exécuter

voila a quoi ressemble le graphe des taches (certaines taches ont été simplifiées mais le principal est la)
http://img693.imageshack.us/img693/1194/jobs.png
il y a en fait plus de taches que ca, mais en gros :
- update des stats
- copie du monde en cours
- en parallèle, rendu de "l'ancien" monde, update du "nouveau" monde
- a la fin, le "nouveau" monde devient l'ancien
- rebelotte (on attend pas la fin du rendu)

or, même si il est possible de decrire ce graphe dans un fichier de description (je viens de le faire, apres tout), je me vois mal devoir stipuler dans ce fichier comment le rendu fonctionne; c'est pourquoi je pensais le casser en petits morceaux, en sous-graphe (c'est aussi comme ca que je l'ai ecrit). un fichier decrit comment effectuer un rendu, un fichier decrit comment la mise a jour du monde se fait, un fichier decrit comment ces deux taches doivent s'effectuer en parallèle et effectue la copie avant et le swap apres, et enfin un fichier decrit comment la frame commence et se termine.

Dans ce cas, il te faut un hypergraphe. C'est à dire un graphe dont les noeuds peuvent eux-mêmes être des graphes.

Mais auquel cas, ça change un peu ton modèle je pense. Parce qu'actuellement, si j'ai bien compris, c'est la dernière étape de "copy world", par exemple, qui va lancer les autres. Si tu passes par un hypergraphe, la dernière étape de copy world sera une terminaison, et c'est le graphe/noeud qui se chargera d'exécuter les étapes suivantes.

ca rentre plutot bien dans le design actuel des tâches, donc c'est parfait
une tache contient des callbacks, qui sont appelées automatiquement lors de l'exécution
le job (l'hypertache) se contente de les brancher ensemble :)