Discussion :

[alecool]

Bonjour,

Je vous présente aujourd'hui un petit projet réalisé et finalisé depuis quelques semaines : instantFSM.

Il s'agit d'une bibliothèque sous forme header-only qui permet d'instancier facilement des machines à états finis suivant (plus ou moins lâchement) la norme UML.

L'intérêt pour vos projets est de rassembler la logique de façon explicite dans une structure localisée de votre code source, et ceci dans un formalisme expressif et clair.

Le fonctionnement repose sur l'injection d'évènements dans la machine, déclenchant les transitions éligibles, et le code utilisateur est appelé sous forme de callbacks, et plus spécifiquement dans l'optique d'utiliser des lambdas.

Je vous invite à jeter un oeil au projet sur Sourceforge. N'hésitez pas non plus à regarder les exemples sur le wiki ainsi que les tutoriaux.

Que pensez-vous de mon projet? Avez-vous des remarques et suggestions sur l'utilisation ou les fonctionnalités?

[LittleWhite]

Bonjour,

Je rajouterai des diagrammes des FSM modélisé pour accompagner les exemple de code.

Avec votre bibliothèque si je veux faire un jeu, ou les différents écrans (pause, menu, game over, game, title) sont des états, comment vous y prendriez vous ?

[alecool]

Pour répondre à votre question, j'ai ajouté un sample dans le wiki : gamestate

Explication de texte : je suis parti de 5 états : splashscreen, menu, loading, ingame et paused.

Dans ce genre d'application, on a besoin que la scène activée à un moment soient rafraichies régulièrement (pour faire du rendu, en particulier). Ce rafraichissement est réalisé par l'émission d'un évènement "update" dans la machine d'état, qui sera capté par une transition différente selon l'état courant. Cette transition à son tour appelle la méthode de rafraichissement de la scène spécifique.

En réalisant cet exemple, une limitation à laquelle j'avais déjà pensé se faire plus présente : l'impossibilité de passer des données avec les évènements (temps d'update, nom de la sauvegarde à charger). Je n'ai pas encore décidé de la solution à apporter à ce problème (type erasure, template pour le pushEvent à matcher avec les callbacks, ..., si vous avez des suggestions, je suis tout ouïe!). Dans cet exemple, je capture les données, membres de la classe Application, dans les lambdas et les mets à jour quand nécessaire, mais cette technique nécessite d'avoir une variable toujours instanciée pour toutes les données à passer... pas très économe en mémoire.

Suivant votre suggestion, j'ai fait un statechart pour le gamestate, j'en ajouterai un pour l'audioPlayer à l'occasion.

PS: l'écriture de la state machine effectuée hier, je trouve quand même ma synthaxe assez appréciable, mais ca doit être l'effet "c'est mon bébé!"!