Forum FFL-ASL
Discussions et questions-réponses concernant ASL => VASL => Discussion démarrée par: Hervé le 03 Décembre 2004, 21:17
-
Salut tout le monde !
Je suis sur le point de me lancer dans la programmation d'un ASL sur le PC.
Est ce que quelqu'un s'y est déjà essayé ?
Jouer par exemple a ASL Starter Kit contre l'ordinateur....Ca doit être génial !
Mais est ce faisable ? Je ne sais pas encore.
Bonne soirée à Tous,
A bientôt,
Hervé
-
Oui Hervé, y'a déja eu une tentative à ma connaissance pour jouer à ASL contre la machine.
Je coirs qu'il s'agit de JASL, ca ressemble de très très près à VASL, mais apparemment avec une intelligence artificielle, mais je n'en sais pas plus.
-
Pour JASL, il y a un group yahoo "JASL".
-
Stubaf Erick, tu connais JASL ? Comment ca marche ? Que vaut l'intelligence artificielle ? Et..... Si tu connais t'en penses quoi ???
PS : Je mets toujours mon képi au soleil :!: :!: :!: :wink: :wink: :wink:
-
Salut;
JASL est loin d'être au point...
Le programmeur / joueur l'a commencé il y a plus de 5 ans (il y a un article dans le FT 5 ou 6, je ne me souviens plus!).
Et se lancer dans un truc comme ça.... chapeau bas, mais je n'y crois pas. Vous vous imaginez un peu le boulot que ça représente?....
-
Développer une intelligence artificielle pour un jeu aussi complexe. :shock:
Rien que la métaheuristique doit être chaude à pondre... J'opterais pour un truc genre "Réseau Neuronal" ou "Génétique", mais le voisinage sera la MORT à concevoir...
S'ajoute à ça le temps de calcul pour la faire fonctionner... Pour chaque unité... Pour chaque phase...
Mon pauvre, j'espère que tu t'y connais dans le domaine de la RO et des métaheuristiques...
greuh. :?
EDIT: RO=Recherche Opérationelle (optimisation, ordonnancement, théorie des graphes et métaheuristiques, entre autres).
-
Effectivement, il y aura du boulot, mais la tentation d'essayer est grande !!
En fait, il faut rapatrier une carte avec son scénario et ses pions (pour commencer) avec du darkbasic ou autre langage "objet". Ensuite, les règles du starter kit ne sont pas trop complexes à interpréter.
Par contre, apprendre à la bécane toutes les possibilités d'interaction necessite une grosse réflexion sur la carte définie... Intéressant non ?
Reste à me creuser les méninges...
Hervé
-
Mais bon .... Rien ne vaut une bonne partie en face à face avec son ami (3 étages en dessous) !!
Hervé
-
Bon courage... et bonne chance....
-
Merci Xavier !
-
Bon, ben si tu tiens à t'y lancer, essaie d'utiliser un 'simple' recuit simulé. C'est ce qu'on avait utilisé pour le ministère de l'agriculture lors du projet l'an dernier.
Ta seule grosse difficulté sera d'établir ce qu'est un voisinage... Afin de paramétrer correctement ta métaheuristique.
En gros, les étapes:
Définir l'espace des solutions (visiblement, c'est -je dis ça à vue de nez- l'ensemble des "mouvements" (en fait, déplacement d'un Hex, ou tir, ou autre action) des pions du camp de l'ordi lors d'une phase donnée -à mon avis, ça marchera mieux en travaillant sur un tour complet, mais c'est uberchaud- ).
Définir un voisinage dans cet espace de solutions (intervertissement de deux "mouvements", insertion d'un mouvement, etc)
Etablir la liste des contraintes, leur affecter un poids.
Après, l'algo de la métaheuristique est simple en lui même...
Si ça t'intéresse, je m'étends sur le sujet (assez passionant), mais je ne sais si cela a sa place ici.
greuh.
-
Merci greuh pour tes conseils... Oui vas y ! Je pense que tout le monde sera intéressé par tes explications ! Et puis, rien ne vaut un travail d'équipe !
-
Mes respects!!!
C'est dans le dictionnaire tous ces mots là?
Je renouvelle mes voeux de bon courage et bonne chance Hervé!!! ;)
-
En attendant, je viendrai jouer au club pour apprendre davantage ! :wink:
Alors a Dimanche !
Je viendrai avec freefrench (mon prof)
Hervé
PS. : Et merci pour vos encouragements et votre gentillesse !
:)
-
Métaheuristique: méthode opérationnelle n'aboutissant pas toujours, à contrario des algorithmes, car basés sur une méthode utilisant une part de hasard. Utilisé essentiellement dans l'optimisation de problèmes complexes n'ayant pas forcément de solutions "totalement idéale", e.g. l'optimisation des actions de ses unités à ASL (qui en plus subissent une part de hasard dûes aux dés).
Pour essayer de comprendre comment fonctionne une métaheuristique (j'abrège en MH), va vous falloir un peu d'imagination , vu que je peux pas vous faire de schéma.
D'abord, il faut définir un espace de solutions. C'est en fait la somme de tous les "arrangements" possibles d'actions.
En gros, vous voyez bien ce qu'est un Rubik's Cube?
Sinon cliquez là: http://www.arrrr.com/photos/rubiks/3.jpg
Cet objet est un espace de solution à lui tout seul. En effet, en l'occurence une solution est une disposition des facettes. Et le cube (dans tous les arrangements possibles) est l'espace des solutions.
Ok?
Bien. Ce que je cherche à faire, c'est trouver l'arrangement optimal d'actions (la meilleure combinaison d'actions pour mes pions, les facettes ordonnées pour mon cube).
Je vais donc d'abord définir les contraintes qui font qu'une solution est meilleure qu'une autre (un pion ne termine pas son mouvement dans la LOS d'une KEU, les 9 facettes d'un coté sont de la même couleur).
Quand j'ai la totalité des contraintes, je leur affectes un poids. Quand la contrainte est violée, ce poid est ajoutée à la "valeur" de la solution. On cherche donc à minimiser cette valeur.
Suite au prochain message, je veux d'abord savoir si cette première partie est bien intégrée.
greuh.
-
Les explications sont claires !! merci ! je lirai le reste demain car je vais dormir ! En tout cas, merci greuh ... Je suis impatient d'arriver à demain pour lire tes messages....
A bientôt,
Hervé
-
Ok. Merci!
Hervé a pigé, c'est celui pour qui je désirais être clair.
Donc, maintenant, on sait calculer à quel point une solution "est pas bonne", puisque la solution idéale aurait une valeur de 0 et que chaque contrainte violée augemente cette valeur.
Après l'espace des solutions et la contrainte, le dernier point essentiel est le Voisinage. C'est le point CLEF d'une bonne MH, car ce sont les paramètres qu'on va lui donner qui feront ou non la bonne solution.
Un voisinage est une liste d'opérations unitaires que l'on peut effectuer sur l'espace des solutions. Une opération unitaire (O.U.) permet de passer d'une solution à une autre.
Pour reprendre l'analogie du cube du vieil erhno rubik, une OU est un mouvement du cube, c'est à dire "faire tourner" l'une des "roues" du cube...
Dans le cas d'ASL, il s'agit d'un tir, d'un mouvement, d'une réparation, etc. Mais l'important est le mot unitaire (vue l'immense possibilité d'actions dans ASL, va falloir soit segmenter le problème en sous problèmes avec une MH dédiée, soit concevoir la MH la plus complexe que je connaisse).
( J'y repense maintenant, mais on a pondu un site lors de notre projet avec des fiches explicatives moins claire mais plus péchues: http://membres.lycos.fr/projetdi/ )
Maintenant qu'on a ces OU, on leur affecte une probabilité.
On fait telle OU avec telle probabilité, telle OU avec telle autre, etc.
La somme des probas faisant 1 (ou 100% de chances).
C'est l'élément aléatoire du truc, et il doit être créé avec énormément de soin.
Maintenant, que fait on? Ben c'est très simple!
On définit une "température" (le 'recuit simulé' est à l'origine une simulation du mouvement des atomes dans un métal en train de refroidir).
Soit le nombre d'itérations $i.
A chaque itération, on lance un tirage au hasard donnant une OU.
On l'applique sur l'ordonnancement qu'on avait au départ (qui est à définir aussi, mais c'est une autre histoire, aussi complexe que la MH).
On calcule le poid de la solution générée.
Si elle est meilleure que la précédente, on la garde et on incrémente $i.
Si elle est moins bonne, on l'accepte quand même, selon une probabilité qui suit une courbe descendante en fonction du nombre d'itérations. Plus $i est grand, moins on accepte les mauvaises solutions.
Pourquoi? Parce qu'on veut éviter les minimums locaux et qu'une "mauvaise solution" est peut être le premier pas vers un minimum global (quand on cherche à résoudre le rubik's cube, on est bien obligé de parfois détruire ce qu'on avait arrangé pour pouvoir améliorer).
Et quand la solution ne change plus, on s'arrête.
On peut définir l'espace des solutions comme un terrain accidenté, et notre MH est un marcheur. Notre marcheur cherche à aller dans la vallée la plus profonde. Au début, il a la patate, il hésite pas à gravir des montagnes et collines pour sortir des vallées peu profondes... Mais à la fin de la journée il se fatigue et descend au fond de la vallée qu'il a finalement atteinte.
On peut améliorer la MH en lui faisant mémoriser les dix dernières solutions et en lui interdisant de revenir à l'une de ces solutions (recuit avec "queue": la MH refuse de se marcher sur la queue), on peut aussi faire travailler une MH sur 10 solutions de départ et choisir la meilleure ("les fourmis"), etc.
C'est un truc assez simple dans son idée de base, mais assez complexe à mettre en oeuvre. Par contre, les résultats sont incomparables. C'est très puissant.
Je ne sais pas si cela peut être appliqué à ASL, ou si du Branch&Bound ou autre théorie des graphes ne sera pas plus simple et efficace (les IA sont souvent des arbres/graphes).
Je te souhaite un très grand courage pour l'oeuvre titanesque (même sans MH) dans laquelle tu te lances.
Bravo!
greuh.
-
En gros, vous voyez bien ce qu'est un Rubik's Cube?
Sinon cliquez là: http://www.arrrr.com/photos/rubiks/3.jpg
Il est bizarre ton Rubik's cube...
-
Je te souhaite un très grand courage pour l'oeuvre titanesque (même sans MH) dans laquelle tu te lances.
Bravo!
Plutôt que de se perdre en conjectures, jetez déjà un coup d'oeil à JASL, après vous pourrez en débattre (http://www.thuring.com/asl/jasl/).
comme le dit Xavier :
JASL est loin d'être au point...
Le prorammeur semble travailler seul et être assez indépendant...
Dans la dernière version (nov 2004), on sent quand même que l'on est en train de faire de l'ASL, mais l'IA est assez déplorable... Pas mal de règles sont implémentées.
Enfin, faites une partie puis vous pourrez donner votre opinion et peut être proposé votre aide au programmeur (Lars Thuring).
-
Un autre problème à prendre en compte est que pour programmer un ASL avec IA il faut que le/les programmeur(s) soit déjà bien rompu au jeu afin de prendre en compte toutes les petites astuces du jeu qui sont fondamental dans une partie au-delà du stade débutant.
Sinon effectivement JASL est déjà en cours de programation et plutot avancé donc si vraiment vous voulez vous y coller (good luck, parce que MH ou pas....ca va être la fête) donner un coup de main avec ce qui existe déjà.
-
Salut,
Sur un plan pratique, la technologie ne permet pas encore d'envisager le traitement algorithmique d'une séquence de jeu d'ASL.
Les milliards de possibilités induites simplement par une phase de mouvement à 10 pions amis, sur 100 locations, face à 10 pions ennemis ne peuvent être traitées en un labs de temps suffisant.
Cela a été la réflexion faite par Rodney Kinney au moment de réaliser VASL. Il était parti pour faire un ASL informatique, et puis devant la puissance des algorithmes à développer, il avait reculé pour se limiter à une IHM. Rien que cette Interface Homme-Machine a été un boulot colossal pour aboutir à un résultat salué par la communauté ASLienne. Je reste pantois pour ma part devant la beauté du checklos. Les amateurs apprécieront.
Je trouve pour ma part que JASL est un excellent point de départ. On peut dire que l'ensemble des règles de base (chap A) sont modélisées dans l'application. C'est déjà beaucoup, croyez moi. Mais on peut voir que même sur un scénario simple (à priori) comme "The Guards counter-Attack", il n'y a pour ainsi dire pas d'AI, enfin rien de comparable même avec le plus débutant des newbies.
Comme toujours en informatique, tout part du besoin fonctionnel. C'est d'abord et avant tout cette partie qui doit être traitée en premier. Avant d'essayer de résoudre le moindre aspect technique.
Le RB est un bon point de départ, à priori, mais il n'est certainement pas suffisant.
On est encore loin d'un ASL informatique, mais je suis sûr qu'on en verra un un jour. Et un bon !
-
Je suis d'accord: filer un coup de paluche à l'auteur de JASL permettrait d'avoir un projet qui avance vite au lieu de 2 qui avancent lentement. De plus, JASL a déjà une IHM faite. Seul le travail sur l'IA reste à faire (enfin, j'ai pas vérifié, je me base sur ce que tous ont dit ici à ce sujet).
N'exagérons rien, sinon:
les possibilités de 10 pions amis sont effectivement nombreuses, mais elles sont traitables car unitairement simples (surtout avec les machines de guerre que chacun a pour PC aujourd'hui). Ce qui m'inquiète surtout, c'est le calcul de la LOS à chaque test. Elle doit couter cher en temps de calcul.
Le laps de temps de calcul est donc raisonnable si c'est bien codé et modélisé intelligemment. Et c'est là que le bât blesse: c'est très difficile à modéliser.
Après, le test de toutes les possibilités est faisable par MH.
greuh.
-
N'exagérons rien, sinon:
les possibilités de 10 pions amis sont effectivement nombreuses, mais elles sont traitables car unitairement simples (surtout avec les machines de guerre que chacun a pour PC aujourd'hui). Ce qui m'inquiète surtout, c'est le calcul de la LOS à chaque test. Elle doit couter cher en temps de calcul.
Le laps de temps de calcul est donc raisonnable si c'est bien codé et modélisé intelligemment. Et c'est là que le bât blesse: c'est très difficile à modéliser.
Après, le test de toutes les possibilités est faisable par MH.
greuh.
cf Close Combat proche d'ASL dans son layout (des squads et des vehicules) et avec une fonction checkloss.
-
C'est extrèmement instructif de vous lire et de connaitre les point de vue et expériences de chacun.
Je vous informerai de l'avancement de mon affaire.
Merci à tous pour tous ces conseils....Ils me seront surement très utiles.
Hervé
-
Un autre problème à prendre en compte est que pour programmer un ASL avec IA il faut que le/les programmeur(s) soit déjà bien rompu au jeu afin de prendre en compte toutes les petites astuces du jeu qui sont fondamental dans une partie au-delà du stade débutant.
Ceci ne me parait être le point le plus embêtant, je pense que l'on peut améliorer des points de décision, à partir du moment où ils existent dans le programme.
Choisir une solution A par rapport à une B, ne doit être qu'un pb de pondération (évaluation) de ladite solution (je ne connais pas cet aspect de la programmation, IA, etc, mais je ne pense pas me tromper).
Qu'en disent les experts ?
-
Tout n'est que problème d'évaluation et de décision, mais les critères de décisions sont générés par le programmeur, donc si le programmeur fait de mauvais choix, le logiciel les fera aussi...
-
N'exagérons rien, sinon:
les possibilités de 10 pions amis sont effectivement nombreuses, mais elles sont traitables car unitairement simples (surtout avec les machines de guerre que chacun a pour PC aujourd'hui). Ce qui m'inquiète surtout, c'est le calcul de la LOS à chaque test. Elle doit couter cher en temps de calcul.
Le laps de temps de calcul est donc raisonnable si c'est bien codé et modélisé intelligemment. Et c'est là que le bât blesse: c'est très difficile à modéliser.
Après, le test de toutes les possibilités est faisable par MH.
Je n'exagere pas.
Dans la mesure où tu cherches à créer une IA, tu dois prendre en compte une profondeur de jeu, c'est à dire tisser l'échelle du possible au delà du coup présent, sur lequel repose ton exemple. Et plus tu peux projeter l'IA loin du présent, meilleur il sera.
On est dans la même problématique que le jeu d'échec, dont les regles sont pourtant simplissimes, le perimètre spatial limité à 64 cases, avec 16 pions par camp dont 6 catégories.
Combien d'années a-t-il fallu pour modéliser le jeu ? Moins d'un an.
Combien de temps a-t-il fallu pour créer une IA qui donne du fil à retordre ne serait-ce qu'à un joueur moyen (je ne parle même pas d'un GMI) ? Vingt ans ? Y est-on vraiment arrivé ? Et ça ne tourne que sur de très gros calculateurs IBM (pour les GMI), car pour que l'IA devienne redoutable, elle doit calculer vingt coups d'avance.
Alors imaginez le travail pour ASL avec ses milliers de règles, ses espaces hypervariables et geomorphiques, sa multitude de pions, bref ses milliards de possibilités, on peut dire son infinie variance.
Close Combat est un bon exemple d'IA ratée, où même la modélisation des différents ensembles faisait défaut. Autant ça pouvait être interessant contre un adversaire humain, autant ça pouvait être horipilant et frustrant contre l'IA.
Par ailleurs, les concepteurs de Close combat n'on jamais pu résoudre le concept de level dans leur checklos, d'où des terrains plats et des buldings sans étages.
C'est compliqué ces petits détails qui n'ont l'ai de rien !
Encore une fois, c'est faisable. Je suis persuadé qu'on y arrivera un jour. Mais le mieux est de capitaliser sur un début de soft qui a le mérite d'exister, avant de réinventer la roue.
Prenez contact avec Lars Thuring. Je suis sûr qu'il verra d'un bon oeil l'aide que vous pourrez lui apporter.
-
Tout n'est que problème d'évaluation et de décision, mais les critères de décisions sont générés par le programmeur, donc si le programmeur fait de mauvais choix, le logiciel les fera aussi...
Oui bien sûr. Ce que je veux dire c'est que les pondérations que le programmeur met sur les actions ne sont que des paramètres (des variables) sur lesquels il peut intervenir après coup sans changer de fond en comble la totalité du programme.
-
Ok, PAT, j'avais oublié la vision à plusieurs tour...
Effectivement.
Sinon, perso, j'ai pas trop le temps de développer un IA, j'ai bien assez de problèmes sans ça...
Pour info: je vais peut être avoir un stage à Paris La Défense (entretien Lundi soir), donc je contacterai surement les joueurs Parisiens...
greuh.
-
Un autre problème à prendre en compte est que pour programmer un ASL avec IA il faut que le/les programmeur(s) soit déjà bien rompu au jeu afin de prendre en compte toutes les petites astuces du jeu qui sont fondamental dans une partie au-delà du stade débutant.
Ceci ne me parait être le point le plus embêtant, je pense que l'on peut améliorer des points de décision, à partir du moment où ils existent dans le programme.
Choisir une solution A par rapport à une B, ne doit être qu'un pb de pondération (évaluation) de ladite solution (je ne connais pas cet aspect de la programmation, IA, etc, mais je ne pense pas me tromper).
Qu'en disent les experts ?
Oui.
Par contre, pour bien pondérer, faut très bien connaître le jeu.
Mais cela reste toujours configurable (changer un chiffre dans un fichier de paramétrage).
greuh.
-
Oui.
Par contre, pour bien pondérer, faut très bien connaître le jeu.
Mais cela reste toujours configurable (changer un chiffre dans un fichier de paramétrage).
greuh.
C'est bien pour cela que pour avoir un système expert, il faut 2 experts :
- 1 informaticien programmeur de course
et
- 1 expert dans le domaine à expertiser
Ca tombe bien, sur le forum y en a plein d'experts ASL, par contre ils risquent de ne pas être tous d'accord entre eux... ben vi, ils sont français :lol: :lol: :lol:
-
Oui.
Par contre, pour bien pondérer, faut très bien connaître le jeu.
Mais cela reste toujours configurable (changer un chiffre dans un fichier de paramétrage).
greuh.
C'est bien pour cela que pour avoir un système expert, il faut 2 experts :
- 1 informaticien programmeur de course
et
- 1 expert dans le domaine à expertiser
Ca tombe bien, sur le forum y en a plein d'experts ASL, par contre ils risquent de ne pas être tous d'accord entre eux... ben vi, ils sont français :lol: :lol: :lol:
3, en fait. Il te faut un modéliseur/analyseur.
J'ose même pas imaginer le modèle UML d'une application ASL...
greuh. :shock:
-
A mon avis (qui est celui auquel je me réfère le plus souvent quand il s'agit pour moi de savoir ce que je pense), il serait probablement plus simple de d'abord faire une IA "ASLSK1", puis de la modifier lorsque sortira le ASLSK2, puis pour le ASLSK3 et enfin de la modifier encore pour implémenter le rulebook (chapitres A, B, C...). Après, peut être ajouter les autres chapitres.
Bref, comme mon apprentissage à moi du jeu ;)
Commencer petit et augmenter.
Le danger étant que la manière dont est modélisé le début empêche la modélisation des améliorations ultérieures...
greuh.
-
Cela suppose en fait que l'analyse initiale (fonctionnelle) prenne en compte l'intégralité du jeu (ASL plein pot soit un siècle/homme de boulot), mais que tu ne spécifies que la partie SK1 en phase 1 (un quart de siècle homme).
De ce fait, tu es capable d'emmancher le projet de manière modulaire en pur UML. Et aucun souci pour la suite .... Enfin mis à part la tonne de boulot necessaire ....
Je pense qu'il ya un tres gros travail fonctionnel à réaliser en amont, avant même de se pencher sur l'aspect technique. La réponse à de nombreuses questions, non abordées dans le RB mais necessaires à la comprehension du besoin, aboutira à la spécification de l'univers des variables d'environnemment. Elles sont la clef de la réussite de l'IA.
Par exemple, on voudra éviter que l'IA soit hyper omniscient. Déjà que certains joueurs ralent à propos de notre propre omniscience, imaginez de jouer contre un joueur qui la maîtrise totale de toutes les regles, de toutes les LOS de n'imorte quelle combinatoire de cartes, et de toutes les astuces de jeu !
Donc il faut commencer par limiter l'IA. Il commande quoi ? Il a quelle connaissance de son environnement ? Il a quel niveau de CII ? Etc. On peut multiplier ce genre de question et vous voyez que ca a peu de rapport avec l'informatique.
Franchement, autant je crois à une IHM de haut niveau, plus poussée que VASL, autant je ne crois pas à la faisabilité artisanale (sans péjoratisme) d'un IA sur ASL.
La tâche est tout simplement trop lourde.
-
Si quelqu'un ( ou plutôt plusieurs ) a assez de courage et de temps disponibles pour se lancer dans l'aventure d'une programmation ASL :twisted: :twisted: voici quelques infos qui pourront servir, au moins à donner une idée de l'ampleur de la tache :
En bouquins :
"Game scripting Mastery" de Varaneze chez Premier Press
"C++ for game programmers" de Llopis chez Charles River Media
"AI Game Engine Programming" de Scwab chez le même éditeur
"Strategy Game Programming" de Todd Baron
"
Pour un exemple pas mal voir sur le site de la bibliothèque d'Allegro ( Allegro.cc ) le jeu Empire et sa version Advanced . Avant de juger ( per exemple en comparant à Steel Panthers ) il faut aller lire le code source pour se rendre compte du boulot qu'un petit jeu comme Empire représente déjà. :roll:
Tiens pendant que je suis à parler de programmation. Est ce que l'un des informaticiens joueurs de ce forum connait comment appliquer automatiquement des skins dégradées sur des sprites comme ceux de Empire pour les rendre plus sympa ? J'ai pensé à appeler un script Python utilisant la biblio de Gimp. Est ce que quelqu'un connait comment c'est fait dans Steel Panthers ?
-
Ah, au fait, si tu veux modéliser ton appli en UML, un bon modeleur gratuit toutes plateformes (il est meilleur que les applis du commerce, mais par contre gourmand en RAM):
Poséidon (attention, lien Java Web Start, comme VASL):
http://www.gentleware.org/webstart2/Poseidon.jnlp
greuh.
-
UML est ce adapté pour une programmation de ce type ?
D'accord çà peut modéliser les dépendances entre objets mais est ce que çà peut modéliser les synchronisations entre les différents éléments ( boucle principale du jeu, machine à états finis de l'IA, sous ensemble de combat, sous ensemble de déplacement, moteur de sprite...) ?
J'ai comme un doute parce que UML me semble plus positionné comme outil d'analyse en informatique de gestion qu'en informatique temps réel.
-
UML est ce adapté pour une programmation de ce type ?
D'accord çà peut modéliser les dépendances entre objets mais est ce que çà peut modéliser les synchronisations entre les différents éléments ( boucle principale du jeu, machine à états finis de l'IA, sous ensemble de combat, sous ensemble de déplacement, moteur de sprite...) ?
J'ai comme un doute parce que UML me semble plus positionné comme outil d'analyse en informatique de gestion qu'en informatique temps réel.
Ben tu as les diagrammes statiques (diag de classes, diag de cas d'utilisation, de déploiement) et les diags dynamiques (diag de séquence, diag de machines à état, diag d'activité).
Ce que tu demande, ce sont donc les diagrammes dynamiques. Il faut toutefois aussi faire des statiques pour un modèle correct. Après, il te suffit de choisis ceux que tu veux faire parmi les 13 diagrammes différents d'UML2.x .
Si tu lis l'anglais, une liste des diagrammes est là:
http://www.agilemodeling.com/essays/umlDiagrams.htm
mais cette liste doit être trouvable en français...
NB: Poséidon (et son ancêtre ArgoUML) ne proposent que les 9 diagrammes de UML1.x mais c'est déjà pas mal!
greuh.