Bonjour,
Première version non finie du tutorial sur les machines d'états ...ici
Je vais essayer de le mettre à jour en prenant en comptes vos remarques.
Certaines personnes voudront peut être que je rentre dans le détail du code (ou pas)
Ou que je développe plus certaines parties.
J'adapterais en fonction des commentaires.
Mon objectif est de vous faire aimer et utiliser les machines d'états.
4
#47
-
- Moderateur
-
- 2724 messages
Posté 05 November 2012 - 00:07 AM
Je vois des erreurs :
http://fr.wikipedia....i/Automate_fini
Postes ton zip ... stp ...
Citation
- Une classe FiniteMachineState qui stocke les états et définit les transitions d’un état à un autre.
http://fr.wikipedia....i/Automate_fini
Postes ton zip ... stp ...
#48
-
- Members
-
- 214 messages
Ceinture Noire
Posté 05 November 2012 - 20:00 PM
Salut Goabonga,
J'ai ajouté le zip mais je ne comprends par les erreurs avec le lien.
Que veux-tu dire?
J'ai ajouté le zip mais je ne comprends par les erreurs avec le lien.
Que veux-tu dire?
#49
-
- Moderateur
-
- 2724 messages
Posté 05 November 2012 - 21:10 PM
Pour moi une "machine à états" n'est pas une "machine à états finis".
Dans ton cas par exemple ta machine n'a pas de FinalState ... donc elle n'est pas FMS ( finite machine state ).
Un états fini n'est pas le client il ne peux pas relancer la machine !
Un exemple d'une FMS est le grill pain (quand la tranche de pain et éjecter l'automate est dit finit)!
Un exemple de MS est le thermostat numérique de ma chaudière ( c'est ce que tu fais avec le count<=0° alors ++ et count>=5° alors --- )!
Avec un language typé comme l'as je pensais aussi que tu utiliserais des interfaces pour definir les InitialState et FinalState.
Je suis contre le fait d'utiliser des Trigger, EntryAction et ExitAction ( c'est du microsoft ... ).
Aussi tu ne n'expliques pas ce que sont les Transitions (ConditionalTransition, SelfTransition, ...).
En soit, je sais que le tuto doit être accessible à tous, mais la c'est trop vide et je trouve à la lecture des classes que les methodes que t'as rajouté complexifie la lecture.
Est-ce que tu es d'accord avec ce que je raconte ?
Dans ton cas par exemple ta machine n'a pas de FinalState ... donc elle n'est pas FMS ( finite machine state ).
Un états fini n'est pas le client il ne peux pas relancer la machine !
Un exemple d'une FMS est le grill pain (quand la tranche de pain et éjecter l'automate est dit finit)!
Un exemple de MS est le thermostat numérique de ma chaudière ( c'est ce que tu fais avec le count<=0° alors ++ et count>=5° alors --- )!
Avec un language typé comme l'as je pensais aussi que tu utiliserais des interfaces pour definir les InitialState et FinalState.
Je suis contre le fait d'utiliser des Trigger, EntryAction et ExitAction ( c'est du microsoft ... ).
Aussi tu ne n'expliques pas ce que sont les Transitions (ConditionalTransition, SelfTransition, ...).
En soit, je sais que le tuto doit être accessible à tous, mais la c'est trop vide et je trouve à la lecture des classes que les methodes que t'as rajouté complexifie la lecture.
Est-ce que tu es d'accord avec ce que je raconte ?
#50
-
- Community Manager
-
- 7017 messages
Posté 05 November 2012 - 22:26 PM
Citation
Un exemple d'une FMS est le grill pain (quand la tranche de pain et éjecter l'automate est dit finit)!
Un exemple de MS est le thermostat numérique de ma chaudière ( c'est ce que tu fais avec le count<=0° alors ++ et count>=5° alors --- )!
Un exemple de MS est le thermostat numérique de ma chaudière ( c'est ce que tu fais avec le count<=0° alors ++ et count>=5° alors --- )!
Merci Goa
C'est dingue comme une simple comparaison avec un grille pain et une chaudière permettent de mieux comprendre un mécanisme complexe.
FMS : Chauffe le pain, si le pain est chaud, éjecte le pain, fin de l'automate.
MS : Si la température est trop basse monte le thermostat, si elle est trop haute descend le, sinon ne fait rien.
Tutoriels AS3 >> Pong - Taquin - Memory - Tic Tac Toe - Pendu - Snake - Proximity - Cascade - Démineur - Bejeweled - Tetris - Collisions - Raycasting - Plateformes - Mode7 - Starfield - Frogger - Space Invader - Blackjack - Sudoku - Asteroids - Video Poker - Rogue Like (partie 1) - Rogue Like (partie 2) - Mastermind - Rendus 2D - Flixel - Auditorium - Particules - Pacman - Doodle Jump - Course de voiture
Tutoriels Javascript >> Pong - Taquin - Memory - Tic Tac Toe - Pendu - Snake - Proximity - Cascade - Démineur - Bejeweled - Tetris - Collisions -
Tutoriels Javascript >> Pong - Taquin - Memory - Tic Tac Toe - Pendu - Snake - Proximity - Cascade - Démineur - Bejeweled - Tetris - Collisions -
#51
-
- Moderateur
-
- 2724 messages
Posté 05 November 2012 - 22:47 PM
Oui mais y'a une erreur dans ton interprétation du système 
En fait le thermostat et une machine à part entière, elle est dite à états récursif.
En gros le firmware du thermostat tourne en boucle pour faire la relève d'une température (ces états sont dit conditionnel) est ainsi si la température est basse elle passe la main à un état qui allume la chaudière et si elle est égale à la température souhaitée on éteindra la chaudière.
En fait le thermostat et une machine à part entière, elle est dite à états récursif.
En gros le firmware du thermostat tourne en boucle pour faire la relève d'une température (ces états sont dit conditionnel) est ainsi si la température est basse elle passe la main à un état qui allume la chaudière et si elle est égale à la température souhaitée on éteindra la chaudière.
#52
-
- Members
-
- 214 messages
Ceinture Noire
Posté 06 November 2012 - 13:22 PM
Bonjour Goabonga et merci pour ton retour,
Tout d'abord, ton interpréation des machines d'états emblent être plus poussée que la mienne. Mais je ne suis pas d'accord avec tes propos.
Je ne suis pas sur de savoir en quoi différencier une machine à états et une machine à états finis est utile, mais il est bien d'avoir signaler la différence. Cependant, je ne pense pas ajouter cette subtilité dans mon tutorial car je pense qu'il peut porter à confusion et qu'il n'est pas essentiel. Comme tu l'as expliqué si ton système à un début et une fin alors ce sera un finite machine state sinon juste un machine state, dans le fond le mécanisme reste le même. Et je ne pense pas que tu ne puisses plus te reservir de ton grill pain après l'avoir utilisé une fois donc tu peux bien revenir à ton état initial après l'état final (où j'ai mal compris...).
J'aimerais rappeler que mon objectif n'est pas d'expliquer en détail ce qu'est une machine d'état mais de donner une interprétation simple dans un environnement informatique (et non mathématique ou électronique ou robotique présenté dans wikipedia) afin que des non initiés aux machines d'états puissent voir son utilité et s'en servir.
Mon implémentation des Machines d'états est largement inspirée des tutoriaux que j'ai pu lire en anglais sur le net donc si elle n'est pas assez bien réalisée pourquoi pas proposer des évolutions du code. Nous pourrions en discuter et faire des modifications. Après tout le code est open-source. Cependant, j'utilise bien une interface pour les StateA et StateB:
public class StateA extends State{
}
public class State implements IState{
}
public interface IState{
function enter($previousState:State):void; // called on entering the state
function exit($nextState:State):void; // called on leaving the state
function update():void; // called while in the state
function get finiteStateMachine():FiniteStateMachine;
function set finiteStateMachine($finiteStateMachine:FiniteStateMachine):void;
}
Je ne partage pas ton point de vue et surtout je ne sais pas comment tu voufrais implémenter la chose autrement.
En effet, je ne pense pas que cela soit utile à notre niveau de connaitre les types de transition. Dans l'exemple que j'ai donné les transition sont très simples. Si je passe de l'état A à l'état B alors j'appel la méthode exit de l'état A puis la méthode enter de l'état B et je désigne mon état B comme mon état actuel. On pourrait complexifier les choses par la suite.
Je vais attendre d'avoir d'autres retour pour me faire une opinion et j'ajouterais du contenu si j'estime que les lecteurs ne sont pas satisfaits du contenu. Je ne peux prendre en compte que ton seul jugement. Je te propose de comparer mon tutorial à ceux réaliser par richardlord ou d'autres et je pense que tu verras que le contenu est similaire.
Voila je voudrais vraiment qu'on voit ce tutorial comme une alternative aux explications complexes du net. C'est un tutorial pratique
Tout d'abord, ton interpréation des machines d'états emblent être plus poussée que la mienne. Mais je ne suis pas d'accord avec tes propos.
Je ne suis pas sur de savoir en quoi différencier une machine à états et une machine à états finis est utile, mais il est bien d'avoir signaler la différence. Cependant, je ne pense pas ajouter cette subtilité dans mon tutorial car je pense qu'il peut porter à confusion et qu'il n'est pas essentiel. Comme tu l'as expliqué si ton système à un début et une fin alors ce sera un finite machine state sinon juste un machine state, dans le fond le mécanisme reste le même. Et je ne pense pas que tu ne puisses plus te reservir de ton grill pain après l'avoir utilisé une fois donc tu peux bien revenir à ton état initial après l'état final (où j'ai mal compris...).
J'aimerais rappeler que mon objectif n'est pas d'expliquer en détail ce qu'est une machine d'état mais de donner une interprétation simple dans un environnement informatique (et non mathématique ou électronique ou robotique présenté dans wikipedia) afin que des non initiés aux machines d'états puissent voir son utilité et s'en servir.
Goabonga, le 05 November 2012 - 21:10 PM, dit :
Avec un language typé comme l'as je pensais aussi que tu utiliserais des interfaces pour definir les InitialState et FinalState.
public class StateA extends State{
}
public class State implements IState{
}
public interface IState{
function enter($previousState:State):void; // called on entering the state
function exit($nextState:State):void; // called on leaving the state
function update():void; // called while in the state
function get finiteStateMachine():FiniteStateMachine;
function set finiteStateMachine($finiteStateMachine:FiniteStateMachine):void;
}
Goabonga, le 05 November 2012 - 21:10 PM, dit :
Je suis contre le fait d'utiliser des Trigger, EntryAction et ExitAction ( c'est du microsoft ... ).
Goabonga, le 05 November 2012 - 21:10 PM, dit :
Aussi tu ne n'expliques pas ce que sont les Transitions (ConditionalTransition, SelfTransition, ...).
Goabonga, le 05 November 2012 - 21:10 PM, dit :
En soit, je sais que le tuto doit être accessible à tous, mais la c'est trop vide et je trouve à la lecture des classes que les methodes que t'as rajouté complexifie la lecture.
Voila je voudrais vraiment qu'on voit ce tutorial comme une alternative aux explications complexes du net. C'est un tutorial pratique
#53
-
- Moderateur
-
- 5783 messages
Community Jane
Posté 06 November 2012 - 14:46 PM
bon…
Je l'ai lu.
Seulement lu, sans m'accrocher, sans fouiller le net.
Je n'ai pas compris.
Ni à quoi ça sert, ni comment on fait.
L'explication, certes électronique, à coup de machine à laver et de nombreux croquis progressifs m'avait donné l'impression de comprendre et j'avais bien hâte d'en voir l'application informatique, plus précisément AS3
Ah bon ? J'avais compris qu'une machine d'état du point de vue AS3 était une classe.
Scuz, mais pour écrire une classe c'est mieux de comprendre ce qu'elle fait, non ?
Je dis "j'avais compris", en survolant le tuto de richard lord
Il faut arriver à la fin de ton tuto pour savoir que c'est un ensemble de classe.
Par ailleurs, simple question de mise en page, quand au chapitre "définition 2" tu listes :
N'hésite pas, ds le paragraphe qui suit, à bien distinguer chacun des points que tu reprends en retournant à la ligne, voire en utilisant des puces, voire en utilisant des formats de caractère… ce serait plus lisible comme suit :
Tu te serais alors aperçu que tu ne développes pas ds le même ordre que tu listes (c'est un détail, mais c'est l'accumulation de ce type de détails qui fait la qualité d'un document à vocation didatique).
Chapitre "Représentation graphique"
Peut-être que tu simplifies trop.
Une porte qui s'ouvre quand elle est fermée et inversement, ne mérite pas une machine d'état, assurément.
C'est un des arts de la pédagogie, trouver des exemples suffisamment simples pour être accessibles, et néanmoins typiques de ce qu'on illustre.
?? des exemples peut-être ?…
Déjà que tu nous parles d'état et d'action sans qu'on sache encore vraiment ce que c'est (du moins est-ce mon sentiment), voilà que tu nous compliques les choses avec sans doute des exceptions…
Ne jamais donner les exceptions en même temps que la règle, ça c'en est une de règle en pédagogie
Chapitre à quoi ça sert
on est avancé avec ça
Sans compter que tu ne réponds pas à la question que tu poses : "ds quel but" (pour quoi faire) mais à la question quand/ds quel contexte ? c'est pas pareil…
Le quand, c'est le chapitre suivant
ta réponse :
super ! on continue d'être avancé 
Là dessus enfin un peu de code, c'est pour nous montrer ce qu'il ne faut pas faire… Remarque c'est convaincant \O/
On se dit super, enfin ça démarre, je vais commencer à comprendre, et là… fini ?
un vague blabla et un zip ?
Je m'attendais à du code ds le tuto, expliqué, détaillé.
Un exemple d'implémentation avec objectif/consigne. Des considérations sur comment aborder ce genre de consignes, comment les penser puis les mettre en code.
De l'intérêt comparé d'utiliser machine d'état ou d'autres voies
Si l'idée c'est d'ouvrir des sources et de regarder - ce qui est suffisant pour beaucoup - ben pourquoi cet habillage tutoïde ?
J'imagine que ce retour ne te fais pas plaisir, et j'en suis sincèrement navrée. Vraiment.
Je me dis que c'est peut-être parce que c'est ton premier essai…
peut-être parce que je suis dure à la comprenote (en vrai, c'est de la courtoisie, ça. En règle générale je comprends les choses réputées complexes pour peu qu'on me les explique clairement)
peut-être que ce n'est pas fini…
Peut-être qu'à la lumière des retours qui te sont fait tu vas modifier les trois fois rien qui rendent le papier peu convaincant. Quelquefois, il suffit de pas grand chose.
D'ailleurs, entends bien que je ne pose un regard que sur le contenu didactique, pas sur le fond.
D'un point de vue technique, maintenant :
Moi je suis certaine que si deux choses sont différentes alors c'est bien de savoir comment les différencier.
Et tant qu'à me faire un ennemi "Dis-moi-pas que tu as commenté les sources en anglais ?!?!? "
Je l'ai lu.
Seulement lu, sans m'accrocher, sans fouiller le net.
Je n'ai pas compris.
Ni à quoi ça sert, ni comment on fait.
L'explication, certes électronique, à coup de machine à laver et de nombreux croquis progressifs m'avait donné l'impression de comprendre et j'avais bien hâte d'en voir l'application informatique, plus précisément AS3
Citation
il n’est pas nécessaire de comprendre en détail comment fonctionne une machine d’état pour pouvoir l’utiliser
Ah bon ? J'avais compris qu'une machine d'état du point de vue AS3 était une classe.
Scuz, mais pour écrire une classe c'est mieux de comprendre ce qu'elle fait, non ?
Je dis "j'avais compris", en survolant le tuto de richard lord
Il faut arriver à la fin de ton tuto pour savoir que c'est un ensemble de classe.
Par ailleurs, simple question de mise en page, quand au chapitre "définition 2" tu listes :
Citation
Une machine d’état se compose essentiellement des éléments suivants:
- - Actions (ou fonctions)
- - Etats (Un élément de départ et un nombre quelconque d’éléments d’arrivé)
- - Evènements
- - Transition
N'hésite pas, ds le paragraphe qui suit, à bien distinguer chacun des points que tu reprends en retournant à la ligne, voire en utilisant des puces, voire en utilisant des formats de caractère… ce serait plus lisible comme suit :
Citation
• Les actions représentent le travail à réaliser selon les états. Par exemple, si j’appui sur le bouton Power de ma télécommande, la télé s’allumera si elle est éteinte ou s’éteindra si elle est allumée.
• Les évènements déterminent lorsqu’il faut réaliser les actions. Dans l’exemple précédent l’évènement est l’appui sur la touche Power de ma télécommande.
• Les états déterminent le contexte dans lequel sont exécutes les actions. On ne peut être que dans un seul état à la fois (Ex : Allumé ou Eteint).
• Les transitions déterminent comment passer d’un état à un autre (je ne sais pas ce qui se dans la télé lorsque l’on allume ou que l’on éteint mais je suppose beaucoup de choses).
• Les évènements déterminent lorsqu’il faut réaliser les actions. Dans l’exemple précédent l’évènement est l’appui sur la touche Power de ma télécommande.
• Les états déterminent le contexte dans lequel sont exécutes les actions. On ne peut être que dans un seul état à la fois (Ex : Allumé ou Eteint).
• Les transitions déterminent comment passer d’un état à un autre (je ne sais pas ce qui se dans la télé lorsque l’on allume ou que l’on éteint mais je suppose beaucoup de choses).
Tu te serais alors aperçu que tu ne développes pas ds le même ordre que tu listes (c'est un détail, mais c'est l'accumulation de ce type de détails qui fait la qualité d'un document à vocation didatique).
Chapitre "Représentation graphique"
Peut-être que tu simplifies trop.
Une porte qui s'ouvre quand elle est fermée et inversement, ne mérite pas une machine d'état, assurément.
C'est un des arts de la pédagogie, trouver des exemples suffisamment simples pour être accessibles, et néanmoins typiques de ce qu'on illustre.
Citation
RQ : Dans cet exemple il manque les évènements (Quand doit-on fermer ou ouvrir les portes ?) Aussi, à noter dans certaines situations un état peut définir une action d’entrée, une action continue et une action de sortie d’un état.
Déjà que tu nous parles d'état et d'action sans qu'on sache encore vraiment ce que c'est (du moins est-ce mon sentiment), voilà que tu nous compliques les choses avec sans doute des exceptions…
Ne jamais donner les exceptions en même temps que la règle, ça c'en est une de règle en pédagogie
Chapitre à quoi ça sert
Citation
[…]En programmation, l’utilisation d’une machine d’état doit être déterminée par la complexité des actions à réaliser et de leur contexte.
Sans compter que tu ne réponds pas à la question que tu poses : "ds quel but" (pour quoi faire) mais à la question quand/ds quel contexte ? c'est pas pareil…
Le quand, c'est le chapitre suivant
ta réponse :
Citation
Il n’existe pas de situation particulière. Il ne tient qu’à vous de décider d’utiliser ou pas une machine d’état.
Là dessus enfin un peu de code, c'est pour nous montrer ce qu'il ne faut pas faire… Remarque c'est convaincant \O/
On se dit super, enfin ça démarre, je vais commencer à comprendre, et là… fini ?
un vague blabla et un zip ?
Je m'attendais à du code ds le tuto, expliqué, détaillé.
Un exemple d'implémentation avec objectif/consigne. Des considérations sur comment aborder ce genre de consignes, comment les penser puis les mettre en code.
De l'intérêt comparé d'utiliser machine d'état ou d'autres voies
Si l'idée c'est d'ouvrir des sources et de regarder - ce qui est suffisant pour beaucoup - ben pourquoi cet habillage tutoïde ?
J'imagine que ce retour ne te fais pas plaisir, et j'en suis sincèrement navrée. Vraiment.
Je me dis que c'est peut-être parce que c'est ton premier essai…
peut-être parce que je suis dure à la comprenote (en vrai, c'est de la courtoisie, ça. En règle générale je comprends les choses réputées complexes pour peu qu'on me les explique clairement)
peut-être que ce n'est pas fini…
Peut-être qu'à la lumière des retours qui te sont fait tu vas modifier les trois fois rien qui rendent le papier peu convaincant. Quelquefois, il suffit de pas grand chose.
D'ailleurs, entends bien que je ne pose un regard que sur le contenu didactique, pas sur le fond.
D'un point de vue technique, maintenant :
Citation
Je ne suis pas sur de savoir en quoi différencier une machine à états et une machine à états finis est utile, mais il est bien d'avoir signaler la différence.
Moi je suis certaine que si deux choses sont différentes alors c'est bien de savoir comment les différencier.
Et tant qu'à me faire un ennemi
"Dis-moi-pas que tu as commenté les sources en anglais ?!?!? "
Le savoir est le seul bien qui s'accroit quand on le partage
une tartine de tutos
une tartine de tutos
#54
-
- Community Manager
-
- 7017 messages
Posté 06 November 2012 - 15:29 PM
Yop,
Bon je vais y aller aussi de ma petite critique constructive
On vois que tu connait le sujet, mais que tu ne semble pas le maîtriser suffisamment pour l'expliciter clairement, et ce qu'on sait expliquer simplement est compris et maîtrisé. Pour ma part je préfères des exemples simples dans la vie de tous les jours, quand Goa parlais de grille pain un peu plus haut j'ai fait exprès d'intervenir, bah oui une simple explication du genre me permet de saisir très rapidement le concept.
Quand Nathaly parle de classes à la sortie de ton tuto par exemple, je pense que c'est une erreur type, les machines d'états ne sont en aucun cas des classes, mais une logique d'architecture pour un programme sensée simplifier sa conception, quelque soit le langage et sa forme, un grille pain n'utilise pas un langage précis, il est mécanique et en cela représente une machine à état fini (ou automate fini). Que son implémentation en AS3 passe par une série de classe c'est autre chose, ça c'est la manière dont on construit l'automate pour ce langage
Pour moi ton tuto est trop court et survole trop certaines choses, par exemple la différence entre FMS et MS qui a mon sens est indispensable à la compréhension des automates, puisque justement c'est le sujet principal. A mon avis il faut beaucoup plus insister sur la définition claire de la chose, quitte à la décliner en plusieurs paragraphes appuyés sur des exemples précis (liens vers des ressources externes acceptés), pour simplifier la compréhension quelques schémas (animés si possibles) seraient un gros plus, des comparaisons avec des éléments du quotidien aussi (exemple du grille pain).
Une fois le sujet bien cerné (définition, règles, exceptions, schémas et exemples) tu peux te lancer dans l'implémentation en AS3, et là aussi un petit peu de détail serait profitable plutôt qu'une source commentée, autant aller au bout et expliquer chaque stade de la conception et pourquoi tel choix plutôt qu'un autre, car c'est aussi ça qui est important, nous montrer pourquoi tel choix de conception est mieux qu'un autre pour des situations types. Tu ne peux pas dire aux gens "à vous de voir si vous en avez besoin", il faut les aider à comprendre pourquoi ils en ont besoin et dans quel cas, qu'ils aient au moins une base de réflexion sinon ils ne se poseront jamais la question.
Je trouve que les deux objectifs ne sont pas remplis, si c'est une alternative aux explications complexes alors tu dois donner des exemples précis et simplifier les définitions avec des schémas et des images tirées du quotidien afin que tout le monde puisse comprendre et suivre, techniquement ta définition devrait être plus longue que celles dites "complexes" car justement tu es obligé de passer par des exemples plus nombreux. Quand au deuxième objectif (le tutorial) ce n'en est pas un, là ça se rapproche plus du TP ou l'implémentation d'un automate en AS3 avec une brève définition, ce n'est donc pas un tutorial dont le but est de nous guider pas à pas vers la compréhension d'un sujet et son implémentation
On est chiants je le reconnais mais c'est pour le bien de tous, en l'état je considérerai plus ce que tu as écrit comme un exemple d’implémentation d'un automate, mais je n'en sais pas beaucoup plus sur le fond. Le sujet est pourtant très intéressant, avec un peu plus de développement et quelques illustrations je pense que tu va y arriver.
Bon courage.
Bon je vais y aller aussi de ma petite critique constructive
On vois que tu connait le sujet, mais que tu ne semble pas le maîtriser suffisamment pour l'expliciter clairement, et ce qu'on sait expliquer simplement est compris et maîtrisé. Pour ma part je préfères des exemples simples dans la vie de tous les jours, quand Goa parlais de grille pain un peu plus haut j'ai fait exprès d'intervenir, bah oui une simple explication du genre me permet de saisir très rapidement le concept.
Quand Nathaly parle de classes à la sortie de ton tuto par exemple, je pense que c'est une erreur type, les machines d'états ne sont en aucun cas des classes, mais une logique d'architecture pour un programme sensée simplifier sa conception, quelque soit le langage et sa forme, un grille pain n'utilise pas un langage précis, il est mécanique et en cela représente une machine à état fini (ou automate fini). Que son implémentation en AS3 passe par une série de classe c'est autre chose, ça c'est la manière dont on construit l'automate pour ce langage
Pour moi ton tuto est trop court et survole trop certaines choses, par exemple la différence entre FMS et MS qui a mon sens est indispensable à la compréhension des automates, puisque justement c'est le sujet principal. A mon avis il faut beaucoup plus insister sur la définition claire de la chose, quitte à la décliner en plusieurs paragraphes appuyés sur des exemples précis (liens vers des ressources externes acceptés), pour simplifier la compréhension quelques schémas (animés si possibles) seraient un gros plus, des comparaisons avec des éléments du quotidien aussi (exemple du grille pain).
Une fois le sujet bien cerné (définition, règles, exceptions, schémas et exemples) tu peux te lancer dans l'implémentation en AS3, et là aussi un petit peu de détail serait profitable plutôt qu'une source commentée, autant aller au bout et expliquer chaque stade de la conception et pourquoi tel choix plutôt qu'un autre, car c'est aussi ça qui est important, nous montrer pourquoi tel choix de conception est mieux qu'un autre pour des situations types. Tu ne peux pas dire aux gens "à vous de voir si vous en avez besoin", il faut les aider à comprendre pourquoi ils en ont besoin et dans quel cas, qu'ils aient au moins une base de réflexion sinon ils ne se poseront jamais la question.
Citation
Voila je voudrais vraiment qu'on voit ce tutorial comme une alternative aux explications complexes du net. C'est un tutorial pratique
Je trouve que les deux objectifs ne sont pas remplis, si c'est une alternative aux explications complexes alors tu dois donner des exemples précis et simplifier les définitions avec des schémas et des images tirées du quotidien afin que tout le monde puisse comprendre et suivre, techniquement ta définition devrait être plus longue que celles dites "complexes" car justement tu es obligé de passer par des exemples plus nombreux. Quand au deuxième objectif (le tutorial) ce n'en est pas un, là ça se rapproche plus du TP ou l'implémentation d'un automate en AS3 avec une brève définition, ce n'est donc pas un tutorial dont le but est de nous guider pas à pas vers la compréhension d'un sujet et son implémentation
On est chiants je le reconnais mais c'est pour le bien de tous, en l'état je considérerai plus ce que tu as écrit comme un exemple d’implémentation d'un automate, mais je n'en sais pas beaucoup plus sur le fond. Le sujet est pourtant très intéressant, avec un peu plus de développement et quelques illustrations je pense que tu va y arriver.
Bon courage.
Tutoriels AS3 >> Pong - Taquin - Memory - Tic Tac Toe - Pendu - Snake - Proximity - Cascade - Démineur - Bejeweled - Tetris - Collisions - Raycasting - Plateformes - Mode7 - Starfield - Frogger - Space Invader - Blackjack - Sudoku - Asteroids - Video Poker - Rogue Like (partie 1) - Rogue Like (partie 2) - Mastermind - Rendus 2D - Flixel - Auditorium - Particules - Pacman - Doodle Jump - Course de voiture
Tutoriels Javascript >> Pong - Taquin - Memory - Tic Tac Toe - Pendu - Snake - Proximity - Cascade - Démineur - Bejeweled - Tetris - Collisions -
Tutoriels Javascript >> Pong - Taquin - Memory - Tic Tac Toe - Pendu - Snake - Proximity - Cascade - Démineur - Bejeweled - Tetris - Collisions -
#55
-
- Members
-
- 238 messages
Ceinture Noire
Posté 06 November 2012 - 17:08 PM
il faudrait que le sujet soit déplacé dans un autre topic plutôt non ? 
#56
-
- Members
-
- 214 messages
Ceinture Noire
Posté 06 November 2012 - 19:33 PM
Bonjour,
Je suis d'accord avec pas mal des retours que vous avez fait. Je ne vais pas tout reprendre mais les points marquant sont les suivants:
- La définition est trop évasive
- L'organisation du contenu est à revoir
- Le sujet est peut être à redéfinir (je m'expliquerais plus en détail par la suite)
- Les exemples sont mal choisis (besoin d'exemple plus complexe à mon goût non pas tiré du quotidien mais des exemples dans le domaine de la programmation et plus précisément du jeux vidéo)
- Le code devrait être expliqué dans le tutorial
- Les sources sont en anglais
- Définir plus précisément l'utilité et les cas d'usage d'une machine d'état
J'espère n'avoir rien oublié. Tout d'abord merci pour vos retours constructif et argumentés. Comme je l'ai annoncé je partage beaucoup de vos sentiments. Je confirme ne pas être un expert en automate fini et long d'être un spécialiste en pédagogie, mais sur ces deux points je pense pourvoir m'améliorer (grâce à votre aide tout au moins).
Ce que je ne vais pas faire:
Le point sur le quel je souhaite revenir qui je pense est la source du problème est le sujet que je pense à voir mal défini et pas assez limité.
N’étant pas un expert en automate fini, je ne souhaite pas l'expliquer de bout en bout mais donner une définition utile en programmation pour pouvoir saisir le concept et l'utiliser. J'insiste sur ce point car je ne vais malheureusement pas définir en détail un automate fini en expliquant les type d'automates, les types de transitions et autres détails car je ne pense pas qu'ils soient utiles. J'ajouterai des liens en fin de tutoriel pour les gens qui veulent allez plus loin dans le technique mais pour la programmation je n'y vois pas d'utilité (je me répète dsl).
Malheureusement, faute de temps je ne vais pas traduire les sources en français (elles seront cependant expliqué dans le tutoriel en détail)
Ce que je vais faire:
Je souhaite donc renommer le titre de ce tutoriel de la manière suivante Machines d'états et programmation (est-ce une bonne idée?)
Je vais reprendre la définition d'une machine d'état être plus précis et fournir des exemples claires dans le cadre de la programmation
Je vais décrire chacune des classes as3 du source.zip
Me fixer des objectifs, à la fin de la lecture du tutorial vous devriez pouvoir savoir expliquer ce qu'est une machine d'état en général, en informatique dans quel contexte elle est utilisée et savoir utiliser les sources pour créer votre propre machine d'état.
J'espère que malgrès tout le tutoriel sera intéressant. N'hésiter pas à me reprendre je ne suis pas du tout susceptible au contraire l’engouement autour de ce sujet m'encourage à prendre sur mon temps pour enrichir ce tutoriel. Merci encore à tous.
Je suis d'accord avec pas mal des retours que vous avez fait. Je ne vais pas tout reprendre mais les points marquant sont les suivants:
- La définition est trop évasive
- L'organisation du contenu est à revoir
- Le sujet est peut être à redéfinir (je m'expliquerais plus en détail par la suite)
- Les exemples sont mal choisis (besoin d'exemple plus complexe à mon goût non pas tiré du quotidien mais des exemples dans le domaine de la programmation et plus précisément du jeux vidéo)
- Le code devrait être expliqué dans le tutorial
- Les sources sont en anglais
- Définir plus précisément l'utilité et les cas d'usage d'une machine d'état
J'espère n'avoir rien oublié. Tout d'abord merci pour vos retours constructif et argumentés. Comme je l'ai annoncé je partage beaucoup de vos sentiments. Je confirme ne pas être un expert en automate fini et long d'être un spécialiste en pédagogie, mais sur ces deux points je pense pourvoir m'améliorer (grâce à votre aide tout au moins).
Ce que je ne vais pas faire:
Le point sur le quel je souhaite revenir qui je pense est la source du problème est le sujet que je pense à voir mal défini et pas assez limité.
N’étant pas un expert en automate fini, je ne souhaite pas l'expliquer de bout en bout mais donner une définition utile en programmation pour pouvoir saisir le concept et l'utiliser. J'insiste sur ce point car je ne vais malheureusement pas définir en détail un automate fini en expliquant les type d'automates, les types de transitions et autres détails car je ne pense pas qu'ils soient utiles. J'ajouterai des liens en fin de tutoriel pour les gens qui veulent allez plus loin dans le technique mais pour la programmation je n'y vois pas d'utilité (je me répète dsl).
Malheureusement, faute de temps je ne vais pas traduire les sources en français (elles seront cependant expliqué dans le tutoriel en détail)
Ce que je vais faire:
Je souhaite donc renommer le titre de ce tutoriel de la manière suivante Machines d'états et programmation (est-ce une bonne idée?)
Je vais reprendre la définition d'une machine d'état être plus précis et fournir des exemples claires dans le cadre de la programmation
Je vais décrire chacune des classes as3 du source.zip
Me fixer des objectifs, à la fin de la lecture du tutorial vous devriez pouvoir savoir expliquer ce qu'est une machine d'état en général, en informatique dans quel contexte elle est utilisée et savoir utiliser les sources pour créer votre propre machine d'état.
J'espère que malgrès tout le tutoriel sera intéressant. N'hésiter pas à me reprendre je ne suis pas du tout susceptible au contraire l’engouement autour de ce sujet m'encourage à prendre sur mon temps pour enrichir ce tutoriel. Merci encore à tous.
#57
-
- Members
-
- 214 messages
Ceinture Noire
Posté 06 November 2012 - 20:24 PM
Encore une chose, car je ne voulais pas au départ débattre avec Goa sur son interprétation d'une machine d'état mais je pense qu'il y a peut être des information portant à confusion.
Notamment la différenciation entre les termes FMS et FM
Je rappel donc qu'une machine d'états est parfois appelé machine à états, automate fini, machine à états fini ou machine avec un nombre fini d'états, finite state machine et que tous ces termes désignent la même chose. Par abus d'usage? Oui mais pas seulement. Celon moi la raison pour laquelle on ne différencie pas les machines fini et suposés infini, c'est qu'en informatique il n'est pas possible de représenter l'infini.
Dès lors comparer les termes machines d'états et machines à états finis n'a pas beaucoup de sens.
Il serait plus sur d'utiliser le terme Machines à états finis dans l'intitulé du titre pour ne pas qu'il y ai de discussion.
Wikipedia:
Une machine à états finis (FSM) ou automate à états finis (pluriel: automates), ou tout simplement une machine d'état, est une mathématique modèle de calcul utilisé pour concevoir les programmes informatiques et logiques séquentiels circuits. Il est conçu comme une machine abstraite qui peut être dans l'un d'un nombre fini d' états . La machine est dans un seul état à la fois; l'état où il est, à tout moment donné est appelé l'état actuel. Il peut passer d'un état à un autre lorsque déclenchée par un événement déclencheur ou d'une condition, c'est ce qu'on appelle une transition. Un FSM particulier est défini par une liste de ses états, et la condition de déclenchement pour chaque transition. (wikipedia)
Je ne comprends pas du tout ce que tu veux dire par là. Je pense que tu à surment mélanger les définitions des automates finis déterministes et non déterministes, mais je ne suis pas sur. Une machine d'état peut avoir un Etat final ou pas mais cela reste tout de même une machine d'état appelé aussi automate fini, ou machine à états finis car le nombre d'état est tout simplement fini (opposé à infini).
Je ne comprends pas ce que tu veux dire
Notamment la différenciation entre les termes FMS et FM
Goabonga, le 05 November 2012 - 21:10 PM, dit :
Pour moi une "machine à états" n'est pas une "machine à états finis".
Je rappel donc qu'une machine d'états est parfois appelé machine à états, automate fini, machine à états fini ou machine avec un nombre fini d'états, finite state machine et que tous ces termes désignent la même chose. Par abus d'usage? Oui mais pas seulement. Celon moi la raison pour laquelle on ne différencie pas les machines fini et suposés infini, c'est qu'en informatique il n'est pas possible de représenter l'infini.
Dès lors comparer les termes machines d'états et machines à états finis n'a pas beaucoup de sens.
Il serait plus sur d'utiliser le terme Machines à états finis dans l'intitulé du titre pour ne pas qu'il y ai de discussion.
Wikipedia:
Une machine à états finis (FSM) ou automate à états finis (pluriel: automates), ou tout simplement une machine d'état, est une mathématique modèle de calcul utilisé pour concevoir les programmes informatiques et logiques séquentiels circuits. Il est conçu comme une machine abstraite qui peut être dans l'un d'un nombre fini d' états . La machine est dans un seul état à la fois; l'état où il est, à tout moment donné est appelé l'état actuel. Il peut passer d'un état à un autre lorsque déclenchée par un événement déclencheur ou d'une condition, c'est ce qu'on appelle une transition. Un FSM particulier est défini par une liste de ses états, et la condition de déclenchement pour chaque transition. (wikipedia)
Goabonga, le 05 November 2012 - 21:10 PM, dit :
Dans ton cas par exemple ta machine n'a pas de FinalState ... donc elle n'est pas FMS ( finite machine state ).
Goabonga, le 05 November 2012 - 21:10 PM, dit :
Un états fini n'est pas le client il ne peux pas relancer la machine !
#58
-
- Members
-
- 214 messages
Ceinture Noire
Posté 07 November 2012 - 00:06 AM
Bonsoir,
J'ai fait une petite update c'est pas encore fini mais je pense que c'est déjà mieux.
J'ai fait une petite update c'est pas encore fini mais je pense que c'est déjà mieux.
#59
-
- Moderateur
-
- 5783 messages
Community Jane
Posté 07 November 2012 - 10:44 AM
ah oui ! c'est déjà bien mieux !
j'ai survolé, vu du code, des exemples bien clairs voire ludiques (le loup, la chèvre et le chou) , des croquis et autres diagrammes… Tout ça est franchement encourageant.
Ravie de constater que tu n'as pas pris ombrage de nos retours un peu rudes.
Perte en matériel humain : 0, gain en tuto digne de ce nom : 1 \o/
Je le lierai et testerai quand tu l'auras fini. Prends ton temps, chez moi on dit "vite et bien ne rime à rien".
D'ailleurs, les prérequis : niveau intermédiaire, POO et interface, je crois que ça suffit. J'ose espérer qu'un niveau intermédiaire sait gérer les événements clavier
Et,
…si ce n'est déjà fait, précise quelque part (voire en intro) qu'il s'agit en fait d'un modèle de conception, ce que d'autres nomment 'design patern'
Allez ! je te laisse bosser !
j'ai survolé, vu du code, des exemples bien clairs voire ludiques (le loup, la chèvre et le chou) , des croquis et autres diagrammes… Tout ça est franchement encourageant.
Ravie de constater que tu n'as pas pris ombrage de nos retours un peu rudes.
Perte en matériel humain : 0, gain en tuto digne de ce nom : 1 \o/
Je le lierai et testerai quand tu l'auras fini. Prends ton temps, chez moi on dit "vite et bien ne rime à rien".
D'ailleurs, les prérequis : niveau intermédiaire, POO et interface, je crois que ça suffit. J'ose espérer qu'un niveau intermédiaire sait gérer les événements clavier
Et,
…si ce n'est déjà fait, précise quelque part (voire en intro) qu'il s'agit en fait d'un modèle de conception, ce que d'autres nomment 'design patern'
Allez ! je te laisse bosser !
Le savoir est le seul bien qui s'accroit quand on le partage
une tartine de tutos
une tartine de tutos
#60
-
- Moderateur
-
- 5783 messages
Community Jane
Posté 08 November 2012 - 19:05 PM
re
Ça me démange cette histoire.……
Par exemple,
Un distributeur de boissons, genre : je mets une piece, je peux alors tourner la poignée et récupérer un bonbon, ou éjecter la piece (retour à la case "je mets la pièce") ; en considérant qu'on ne peut mettre une pièce que s'il reste des bonbons…
Ça entre bien dans le cadre de ce dont tu parles ?
Ça me démange cette histoire.……
Par exemple,
Un distributeur de boissons, genre : je mets une piece, je peux alors tourner la poignée et récupérer un bonbon, ou éjecter la piece (retour à la case "je mets la pièce") ; en considérant qu'on ne peut mettre une pièce que s'il reste des bonbons…
Ça entre bien dans le cadre de ce dont tu parles ?
Le savoir est le seul bien qui s'accroit quand on le partage
une tartine de tutos
une tartine de tutos
#61
-
- Community Manager
-
- 7017 messages
Posté 08 November 2012 - 19:07 PM
Citation
Un distributeur de boissons, genre : je mets une piece, je peux alors tourner la poignée et récupérer un bonbon, ou éjecter la piece (retour à la case "je mets la pièce") ; en considérant qu'on ne peut mettre une pièce que s'il reste des bonbons…
Un distributeur de boissons qui distribue des bonbons, il est cassé !
(désolé du HS j'ai pas pu me retenir....)
Tutoriels AS3 >> Pong - Taquin - Memory - Tic Tac Toe - Pendu - Snake - Proximity - Cascade - Démineur - Bejeweled - Tetris - Collisions - Raycasting - Plateformes - Mode7 - Starfield - Frogger - Space Invader - Blackjack - Sudoku - Asteroids - Video Poker - Rogue Like (partie 1) - Rogue Like (partie 2) - Mastermind - Rendus 2D - Flixel - Auditorium - Particules - Pacman - Doodle Jump - Course de voiture
Tutoriels Javascript >> Pong - Taquin - Memory - Tic Tac Toe - Pendu - Snake - Proximity - Cascade - Démineur - Bejeweled - Tetris - Collisions -
Tutoriels Javascript >> Pong - Taquin - Memory - Tic Tac Toe - Pendu - Snake - Proximity - Cascade - Démineur - Bejeweled - Tetris - Collisions -
#62
-
- Moderateur
-
- 5783 messages
Community Jane
Posté 08 November 2012 - 20:02 PM
[edit]
… je viens d'arriver au bout du chapitre de la machine à
Je m'auto-réponds donc : oui, c'est en plein ds le sujet (… je crois)
Le savoir est le seul bien qui s'accroit quand on le partage
une tartine de tutos
une tartine de tutos
#63
-
- Moderateur
-
- 5783 messages
Community Jane
Posté 10 November 2012 - 17:14 PM
Goabonga, le 26 October 2012 - 14:52 PM, dit :
Slt,
Tu peux me dire si on peut modéliser le truc comme :
state_dp.png
Si oui j'ai pleins de questions
Tu peux me dire si on peut modéliser le truc comme :
state_dp.pngSi oui j'ai pleins de questions
d'où j'en suis de mon apprentissage, je ne vois pas pourquoi on pourrait pas… peut-être justement parce que c'est bien trop frais
tu vois quoi toi qui empêcherait
Le savoir est le seul bien qui s'accroit quand on le partage
une tartine de tutos
une tartine de tutos
#64
-
- Members
-
- 214 messages
Ceinture Noire
Posté 13 November 2012 - 20:34 PM
Bonjour,
Nataly j'ai pris en compte tes retours et ajouté quelques précisions.
J'espère que le tutorial va plaire.
Dans le cas contraire je modifierais selon les retours.
Nataly j'ai pris en compte tes retours et ajouté quelques précisions.
J'espère que le tutorial va plaire.
Dans le cas contraire je modifierais selon les retours.
#65
-
- Members
-
- 224 messages
Ceinture Noire
Posté 13 November 2012 - 22:38 PM
Il est très bien ce tutorial, royal même, vous pinaillez vachement quand même
@angelstreet : tu as de bons exemples dans le bouquin de Mat Buckland (http://www.amazon.co...d/dp/1556220782), mais je trouve ça aussi didactique et bien expliqué dans ton tuto. Et son bouquin est terriblement bien écrit, une référence majeure.
Après le problème c'est que visiblement tu as appris ça de développeurs console/C (corrige-moi) qui utilisent effectivement ça pour de l'UI. En réalité ça ne sert plus trop à l'UI, donc tu prends des exemples pas forcément très actuels : un langage objet + MVC sont une bien meilleure solution pour faire de l'UI. D'ailleurs Flash et son API évenementielle sont majoritairement utilisés "as-is" dans les GUI de jeu (via Scaleform) et sont un standard de-facto dans l'industrie (haters gonna hate).
Comprendre : state-machine = pis-aller si langage pas objet et pas possible d'implémenter des pattern plus vastes.
Aujourd'hui, j'ai vu utiliser plutôt des states-machines :
- pour gérer les grand états d'un jeu à une échelle très "macro" (comprendre "menu -> jeu -> game over"),
- dans le code de gameplay (coffre ouvert-fermé)
- dans l'IA.
Un exemple d'IA eût permis d'atteindre le degré de pédagogie extrême désiré, et eût été peut être plus démonstratif : là effectivement on voit directement le nombre de lignes de code fondre.
Petit élargissement : définir des états/des transitions, ça revient à définir ... un langage informatique. En réalité, un compilateur ne fait que : parser du code dans un langage A, le représenter selon le même type de graphe que les illus du tuto, puis relire ce graphe et remplacer chaque instruction A pour une instruction du langage B. C'est pour ça que c'est important, les FSM, savoir les rendre déterministe (ou pas), etc. Ce tutoriel est donc méga-super-important en terme de compétences pro pour un développeur un peu désireux d'aller plus loin que le simple statut d'usager d'un langage et d'une API.
My 2 cents.
@angelstreet : tu as de bons exemples dans le bouquin de Mat Buckland (http://www.amazon.co...d/dp/1556220782), mais je trouve ça aussi didactique et bien expliqué dans ton tuto. Et son bouquin est terriblement bien écrit, une référence majeure.
Après le problème c'est que visiblement tu as appris ça de développeurs console/C (corrige-moi) qui utilisent effectivement ça pour de l'UI. En réalité ça ne sert plus trop à l'UI, donc tu prends des exemples pas forcément très actuels : un langage objet + MVC sont une bien meilleure solution pour faire de l'UI. D'ailleurs Flash et son API évenementielle sont majoritairement utilisés "as-is" dans les GUI de jeu (via Scaleform) et sont un standard de-facto dans l'industrie (haters gonna hate).
Comprendre : state-machine = pis-aller si langage pas objet et pas possible d'implémenter des pattern plus vastes.
Aujourd'hui, j'ai vu utiliser plutôt des states-machines :
- pour gérer les grand états d'un jeu à une échelle très "macro" (comprendre "menu -> jeu -> game over"),
- dans le code de gameplay (coffre ouvert-fermé)
- dans l'IA.
Un exemple d'IA eût permis d'atteindre le degré de pédagogie extrême désiré, et eût été peut être plus démonstratif : là effectivement on voit directement le nombre de lignes de code fondre.
Petit élargissement : définir des états/des transitions, ça revient à définir ... un langage informatique. En réalité, un compilateur ne fait que : parser du code dans un langage A, le représenter selon le même type de graphe que les illus du tuto, puis relire ce graphe et remplacer chaque instruction A pour une instruction du langage B. C'est pour ça que c'est important, les FSM, savoir les rendre déterministe (ou pas), etc. Ce tutoriel est donc méga-super-important en terme de compétences pro pour un développeur un peu désireux d'aller plus loin que le simple statut d'usager d'un langage et d'une API.
My 2 cents.
Je suis dispo en free-lance. Et j'ai un blog.
#66
-
- Moderateur
-
- 5783 messages
Community Jane
Posté 14 November 2012 - 09:39 AM
Contente de ce retour positif.
Je peux donc parler en mon nom, en tant qu’apprenant.
Je ne savais pas avant.
Je connais bien sûr les principes de composition, délégation et autre encapsulages.
Il n'empêche que je ne comprends pas. Ni à quoi ça sert, ni quand s'en servir, ni comment.
Depuis je me suis intéressée au patron d'Etat (design patern). Je ne sais toujours pas si Machine d'Etat, finie ou non, a à voir…
Le tuto (voiture) que tu mets en lien, en revanche, est plutôt très bien foutu (c't'un comble pour une plateforme francophone que ce soit le tuto d'un autre, ailleurs et en anglais qui permette de comprendre
)
Question d'objectif sans doute, ou de public.
Il n'est pas destiné à expliquer à ceux qui ne savent pas. J'en témoigne.
Désolée de ne pas pouvoir faire un retour plus enthousiaste. Souhaitons que je sois peu représentative (ce qui est à envisager )
Et merci tout de même : le modèle de conception d'Etat que je n'aurais sans doute pas fouillé tout de suite est une sympa découverte que je te dois sans conteste.
Je peux donc parler en mon nom, en tant qu’apprenant.
Je ne savais pas avant.
Je connais bien sûr les principes de composition, délégation et autre encapsulages.
Il n'empêche que je ne comprends pas. Ni à quoi ça sert, ni quand s'en servir, ni comment.
Depuis je me suis intéressée au patron d'Etat (design patern). Je ne sais toujours pas si Machine d'Etat, finie ou non, a à voir…
Le tuto (voiture) que tu mets en lien, en revanche, est plutôt très bien foutu (c't'un comble pour une plateforme francophone que ce soit le tuto d'un autre, ailleurs et en anglais qui permette de comprendre
)Question d'objectif sans doute, ou de public.
Il n'est pas destiné à expliquer à ceux qui ne savent pas. J'en témoigne.
Désolée de ne pas pouvoir faire un retour plus enthousiaste. Souhaitons que je sois peu représentative (ce qui est à envisager
)Et merci tout de même : le modèle de conception d'Etat que je n'aurais sans doute pas fouillé tout de suite est une sympa découverte que je te dois sans conteste.
Le savoir est le seul bien qui s'accroit quand on le partage
une tartine de tutos
une tartine de tutos
#67
-
- Members
-
- 214 messages
Ceinture Noire
Posté 14 November 2012 - 20:22 PM
Merci Frangois et Nataly pour vos retours,
Comme l'a précisé Frangois on ne peut vraiment voir l'utilité des machines d'états dans les exemples simplistes que j'ai utilisé.
Et effectivement, je me suis trompé en indiquant que j'utilise les machines à états pour les interfaces je voulais indiquer comme Frangois l'a précisé les états d'un jeux. Je ne voulais pas utiliser un exemple d'AI comme exemple car c'est très complexe. Il faut expliquer tout d'abord ce qu'est une AI, qu'elles sont les comportements de bases (seek, pursuit, flee etc...) et ensuite réalisé et commenté un exemple avec du code. Ce pourrait être un sujet pour un prochain tutorial, Déplacement d'un personnage (AI, Machines à états, etc...).
Nataly je suis désolé que mon tutorial ne te permettes pas d'être plus à l'aise avec le concept des machines à états.
Je ne suis pas sur à 100% mais je pense que ton pattern état représente une machine d'état (Frangois?).
Comme l'a précisé Frangois on ne peut vraiment voir l'utilité des machines d'états dans les exemples simplistes que j'ai utilisé.
Et effectivement, je me suis trompé en indiquant que j'utilise les machines à états pour les interfaces je voulais indiquer comme Frangois l'a précisé les états d'un jeux. Je ne voulais pas utiliser un exemple d'AI comme exemple car c'est très complexe. Il faut expliquer tout d'abord ce qu'est une AI, qu'elles sont les comportements de bases (seek, pursuit, flee etc...) et ensuite réalisé et commenté un exemple avec du code. Ce pourrait être un sujet pour un prochain tutorial, Déplacement d'un personnage (AI, Machines à états, etc...).
Nataly je suis désolé que mon tutorial ne te permettes pas d'être plus à l'aise avec le concept des machines à états.
Je ne suis pas sur à 100% mais je pense que ton pattern état représente une machine d'état (Frangois?).
#68
-
- Members
-
- 224 messages
Ceinture Noire
Posté 14 November 2012 - 21:15 PM
Citation
Je ne suis pas sur à 100% mais je pense que ton pattern état représente une machine d'état
Les différences sont que dans l'exemple canonique du pattern State :
- seul l'état interne de l'objet est pris en compte pour passer d'un état A à B, le contexte externe n'est pas pris en compte (= d'autres objets).
- enter() exit() update() pour une FSM, au lieu de insérerPièce() tournerBouton() prendreBonbon() pour un pattern State
Après dans les 2 cas les transitions sont plus ou moins explicites et les états sont découplés. Un objet implémentant un pattern State est une implémentation (trop) concrète d'une FSM.
über-pinaillage la question, j'ai dû ouvrir des livres.
Je suis dispo en free-lance. Et j'ai un blog.
#69
-
- Community Manager
-
- 7017 messages
Posté 14 November 2012 - 21:19 PM
Citation
über-pinaillage la question, j'ai dû ouvrir des livres.
Sinon, j'ai re-parcouru le tuto dans sa nouvelle version, très rapidement pour le moment, je m'y plongerai plus avant sous peu.
Rien à voir avec la première version que tu nous avais proposé, là c'est complet et bien documenté, je pense que je vais me faire plaisir à le dévorer sous peu, merci à toi Angelstreet.
Tutoriels AS3 >> Pong - Taquin - Memory - Tic Tac Toe - Pendu - Snake - Proximity - Cascade - Démineur - Bejeweled - Tetris - Collisions - Raycasting - Plateformes - Mode7 - Starfield - Frogger - Space Invader - Blackjack - Sudoku - Asteroids - Video Poker - Rogue Like (partie 1) - Rogue Like (partie 2) - Mastermind - Rendus 2D - Flixel - Auditorium - Particules - Pacman - Doodle Jump - Course de voiture
Tutoriels Javascript >> Pong - Taquin - Memory - Tic Tac Toe - Pendu - Snake - Proximity - Cascade - Démineur - Bejeweled - Tetris - Collisions -
Tutoriels Javascript >> Pong - Taquin - Memory - Tic Tac Toe - Pendu - Snake - Proximity - Cascade - Démineur - Bejeweled - Tetris - Collisions -
#70
-
- Members
-
- 214 messages
Ceinture Noire
Posté 16 November 2012 - 20:24 PM
Merci à vous ce tuto est a évolué grâce à vos critiques constructives c'est plus un travail qui a été fait en collaboration.
Le mois prochain j'essayerai de créer un nouveau tuto selon les envies de la communauté bien sur.
@ bientot
Le mois prochain j'essayerai de créer un nouveau tuto selon les envies de la communauté bien sur.
@ bientot
#72
-
- Moderateur
-
- 5783 messages
Community Jane
Posté 01 February 2013 - 18:08 PM
Comme quoi t'as bien fait de rester bosser chez toi (private joke), cet article est très intéressant et super documenté (liens)
Le savoir est le seul bien qui s'accroit quand on le partage
une tartine de tutos
une tartine de tutos
1 utilisateur(s) li(sen)t ce sujet
0 membre(s), 1 invité(s), 0 utilisateur(s) anonyme(s)