Je manage les Game States

Pour ceux qui vont faire comme Morsy : "les quoi ??", je vais tout d'abord expliquer le principe des Game States...
Un état dans le jeu correspond à une phase du jeu, typiquement : l'intro, le menu, le jeu, la pause, ...
Pour gérer ces états successifs, on définit une classe mère GameState (pour pas faire trop compliqué...) de toutes les classes états : IntroState, MenuState, PlayState, PauseState, ... Jusque là ça va... ;) Le but de ces classes est de pouvoir gérer les évènements souris et clavier (input) pour pouvoir passer d'un état à un autre (par exemple, on appuie sur Echap pendant l'état "Intro" pour passer en état "Menu"). Cette gestions des Input se fait dans les méthodes standarts des FrameListener et KeyListener : frameStarted, frameEnded, keyPressed, ... Pour gérer la succession de ces états, on utilise un gestionnaire d'états, le GameManager (qui est un peu la classe principale du jeu puisqu'elle va charger les ressources au départ) qui va démarrer avec un premier état (ici l'Intro). Là c'est déjà un peu plus compliqué... L'état d'intro étant créé (avec allocation des caméras, windows nécessaires), il gère tout seul les futurs évènements d'input dont sa propre succession : lorsque l'on presse Echap pour aller en état de Menu, il appelle la méthode changeState (héritée de GameState et non redéfinie) qui se charge d'appeler le GameManager pour le prévenir de changer d'état (=>détruire l'ancien état et créer le nouveau).

Voilà voilà... C'est pas très très compliqué mais ça demande un peu d'implication cérébrale quand même :)
J'ai fait la modélisation UML d'une telle archi :

J'ai proposé sur le forum officiel d'Ogre d'ajouter cette représentation UML sur le wiki.
Mon post | Le tuto sur le Wiki

Note : cette modélisation est tirée du State Pattern utilisé pour divers logiciels (autres que des jeux vidéos).

Maintenant que vous savez tout sur les Game States (si vous voulez en savoir plus, suivez le lien du wiki), je peux dire que je les manage ces Games States ! :D
En effet, le pattern est implémenté (sans douleur) dans Nidhogg avec toutes les améliorations que j'ai pu y apporter : gestion des ressources et des configurations personnalisées (notamment pour Mac). J'ai également pris soin de faire en sorte que les fichiers soient compilables pour Mac/Win/Linux, en ajoutant les macros d'Ogre pour la détection d'OS...

Hier, j'avais également recréé un GUI de Debug (sur la base de celui d'Ogre) personnalisé :

Bon ok, c'est pas super fashion mais bon ça sert qu'au debug :)

Je suis content, j'ai fait tout ce que je voulais faire en une soirée, je vais pouvoir affiner les GameStates demain et me remettre sur la SmartCam après...

Certains diront que je m'acharne, que je ne dois plus avoir de vie sociale, que j'ai un cerveau fonctionnant en binaire désormais, ... Et bien c'est vrai ! Nan j'déconne... C'est juste que je peux me permettre en ce moment de mettre un grand coup de fouet sur le projet pour pouvoir sortir Nidhogg pour septembre, c'est à dire juste avant d'envoyer mes propositions de stage pour l'année prochaine (une démo à présenter me parait indispensable). Donc comme je peux, j'en profite, et je fais tout pour faire avancer le projet le plus possible. Voilà voilà :)

Je l'ai eu...

Hummm...
Soit je ne dis rien et on va me demander si j'ai finalement réussi ce que je voulais faire, soit je le dis et je risque de me faire chambrer...
Bon je suis joueur et je vous annonce que l'appli marche très bien et est très rapide ! Normal en fait puisqu'elle ne charge quasiment rien... Mon seul problème était (le premier qui rigole a perdu...) d'avoir *oublié* un delete... Je sais c'est pas très glorieux comme problème surtout quand on sait que j'y ai passé quelques heures...

Bref, voyons de l'avant désormais !
NeXtSteP :

• faire un projet compilable ss Mac (done) / Win / linux (j'aurais besoin de ton aide Stardco...)
• réaliser la modélisation UML du tuto sur les GameStates
• réaliser le tuto sur les GameStates
• l'intégrer dans Nidhogg
• me remettre sur la SmartCam

Je l'aurais...

J'ai mis de côté ma caméra pour le moment pour me créer une application vraiment indépendante (avant j'utilisais l'ExampleApplication et l'ExampleFrameListener).
Déjà je me rends compte qu'il faudra faire des versions différentes pour Mac/Win/Linux. En effet, sous Mac les logiciels fonctionnent sous forme de bundles (dossiers contenant le nécessaire applicatif) contrairement à Windows ou Linux. Faudra-t-il faire 3 main et 3 classes de chargement ? à voir... ou sinon n'en faire qu'une qui charge les bonnes ressources suivant l'OS. Enfin ça, ça ne devrait pas poser trop de problèmes... Enfin j'espère.

Pour en revenir à ce que je fais, j'arrive désormais à charger nos médias (enfin pour l'instant il n'y a que la tour...) et lancer la fenêtre. Les évènements clavier sont au moins détectés (j'ai essayé d'afficher la tour suite à une pression de touche et ça marche) et mon seule problème est la fermeture de l'appli... Lorsque je retourne false à mon FrameListener, il semble ne pas s'arrêter et donc l'appli ne s'arrête pas... Je viens de poster sur le forum d'Ogre donc on verra ça demain... :-)

Etude du format .map

Yol !

La plage, ça fait réfléchir... Et quand on a pas de portable, on griffonne sur des bouts de papier (et c'est pas plus mal...). Résultat, plein de gribouillis sur du sopalin, des post it, et j'en passe :D

En recomposant ces bouts de papiers, on peut trouver (dans l'orde quelconque) :

• une pré-analyse des classes en jeu dans le déplacement des entités 3D,
• une pré-conception des cas d'utilisation du jeu en général,
• une étude du format .map.

Je parlerais des 2 premières parties lorsque j'aurais quelque chose de plus fondé. Le format .map (du XML intrinsèquement) nous servira à stocker les informations sur les cartes que nous allons charger dans le jeu. Une première étude m'amène à un format de ce style.
N'ayant pas une grande expérience du XML (je n'ai manipulé que du GPX, et une seule fois en récupération, jamais en création), j'aimerais que les spécialistes me disent ce qu'ils en pensent d'un point de vue structural. Du point de vue du contenu, il faudra surement ajouter d'autres choses (je pense d'ailleurs déjà aux lumières...).

Bref, laissez moi un commentaire sur ce que vous en pensez...
++

Soirée apprentissage Blender

Bonjour, bon je n'ai pas beaucoup dormi, à cause de la soirée passée en compagnie des membres Eaquenta. Vincent nous a montré sa motivation certaine pour l'apprentissage de Blender, bravo pour le vaisseau soit dit en passant ;)
De plus nous avons pu commencer l'architecture d'un pont de pierre avec Bellérophon, très prometteur. Nous avons aussi intégré l'écurie de Bellé dans Ogre, mais un problème s'est posé : pourquoi, lorsqu'on ne passe pas par l'UV-Mapping, les textures ne s'exportent-elles pas ? Cela-dit : bravo pour ta belle écurie :D
Il va falloir regarder si la taille des objets est paramétrable directement sous Blender afin d'éviter de modifier leur taille sous Ogre.
De mon côté j'ai commencé un personnage (masculin pour l'instant héhé), la modélisation est terminée, mais cette étape est sans doute la plus intéressante quand on voit que l'UV-Mapping est très contraignant.
Bref, on avance on avance. On se retrouve ce soir de nouveau chez notre cher gourou Fp12 ;)

SmartCam step #1.1 & more

Bon j'ai pas réussi à faire grand chose finalement ce soir, même en m'y mettant plus tôt. Enfin c'est normal, c'est toujours les petits trucs qui prennent le plus de temps...

Je me suis aperçu aujourd'hui qu'il y avait une fonction déjà inclue dans l'Ogre pour cibler automatiquement un noeud lors du mouvement de la caméra (autoTrack). Peu importe... Ma classe est beacoup plus custom et intègre plus de souplesse, donc pas de regrets... :)
L'angle minimum de vue de dessus est désormais fixé. Il ne reste plus qu'à limiter le zoom.
J'ai fait des tests avec des touches pour bouger la cam, et d'autres pour bouger le perso (+ une sur la souris, il faut donc avoir 3 mains :D) et ça marche plutôt bien (enfin j'ai pas vu de bugs pour l'instant) depuis que j'ai attaché la caméra à un noeud fils du noeud ciblé (logique mais c'était pas implémenté avant). Au final on arrive à mieux se modéliser l'intérêt d'une telle caméra : on a complètement l'impression d'être libre (on bouge comme on veut en fixant quand même le noeud) tout en se laissant guider par le mouvement du noeud. J'ai hâte de modéliser la partie intelligente de la SmartCam pour la voir bouger vraiment toute seule face aux obstacles :D.

Côté musique, j'ai discuté avec Nirnaeth (notre talentueux compositeur) et il se chargera de créer 5 thèmes différents (passés en boucle sur les maps) à décliner sous 3 formes : Elfique, Humaine et Naine, soit pour chaque type de village rencontré. Une question me vient maintenant : et pour les maps neutres (en forêt, dans le désert, ...) ? Sinon le thème du jeu sera présent dans les menus et une musique plus stressante sera présente pendant les combats.
Le format de fichiers utilisé sera l'ogg (plus "libre" que le mp3...).

J'ai délégué la tâche d'afficher les tours de TomCat texturées à Kut (qui semble avoir quelques problèmes avec Code::Blocks :p) pour bien me concentrer sur la caméra.

MerluBreizh semble avoir des difficultés à se mettre à Blender à cause des différences entre la v2.37 actuelle et la version du tuto de TomCat (en v2.36).

SmartCam step #1

Bon bein finalement ça ne m'aura pas demandé tant de temps que ça... Les mouvements de la caméra sont entièrement recréés :

• mode attaché dans lequel la caméra regarde toujours le personnage. La caméra a tout de même une grande liberté de mouvement (souris) : strafe G/D, mouvement H/B et zoom in/out (molette!).
• mode libre dans lequel l'utilisateur manipule la caméra comme bon lui semble à la manière d'un FPS sans perso attaché.

Il reste à fixer des limites :

• l'angle vertical avec le personnage pour ne pas "passer par dessus" lui en bougeant vers le haut (pas trop d'angle quand même pour avoir une vue presque de dessus).
• la distance minimale entre le perso et la caméra.

Puis implémenter la partie "intelligente" :

• afficher le curseur de la souris (exit OSX :( Code::Blocks powa :D )
• détecter les différents éléments sur le Ray de la SmartCam et la bouger de façon auto si le premier élément n'est pas le node attaché.

C'est tout pour ce soir !
Ah non, j'ai failli commencer à regarder OpenAL pour le son, mais il est trop tard alors je regarderais ça demain ou je dirais à quelqu'un de s'en occuper...

Screenshots de cette demie tour...

Sous Blender :














Rendu avec Ogre :

Eaquenta National Day :)

Yol !

Et bien on peut dire qu'on est des acharnés quand même... Pour s'y remettre efficacement, il a fallu qu'on choisisse le 14 juillet !!! De toute façon, c'est un des rares jours où on peut se réunir (à cause du stage...).

Bref, je pense que cette journée Eaquenta a été la plus rentable et la plus intéressante... Tout d'abord, les designers nous ont prouvé leur rapidité et leur savoir faire en faisant une tour fort sympathique (je posterais des sreenshots plus tard) et exploitable par les développeurs sur le champ... Le seul problème au rendu est que l'on ne voit qu'une moitié de cette tour (d'après le forum officiel d'Ogre, c'est quelque chose à gérer dans Blender pour que ce soit plus propre...)
Niveau développement, la journée a montré qu'on pouvait tout à fait laisser tomber DevCpp pour adopter Code::Blocks qui a l'air plus sympa a utiliser. Kut a fait ses mimines sur l'Ogre et a placé 4 murs pour enfermer un pauvre ninja (si si...).

Moi depuis ce temps là (ça m'a filé un coup de boost je vous raconte pas !), j'arrive à faire se déplacer notre récurrent ninja grâce aux touches de direction, et à faire que la caméra le suive. J'ai même implémenter ce matin une petite fonctionnalité sympatique : l'attachement de la caméra au personnage, ainsi que sa libération (donc passage en caméra libre). Ceci sera implémenté dans le jeu pour permettre au joueur de laisser ses persos et se ballader librement dans la map (enfin c'est une idée). Je vous avouerais que l'intuitivité de la caméra m'intrigue beaucoup et que j'ai pas mal d'idées quand à son futur comportemnt car c'est pour moi une des clés du gameplay (jouablilité & plaisir de jouer) d'Eaquenta et de tout autre jeu.

Next Step : faire déplacer un perso en cliquant quelque part sur la map et réimplémenter la caméra libre (il doit juste manquer un ou deux paramètres)... Ensuite, je devrais implémenter un petit algorithme de caméra intelligente pour qu'elle bouge (plus ou moins) toute seule si un obstacle se trouve entre la caméra et le personnage.

Pour les autres :
* Kut : continuer à se faire la main avec les tutos,
* TomCat : continuer et finir son perso pour le rendre plus "humain",
* Belle : terminer l'écurie, refaire sa maison et commencer la maison du chef,
* Stardco : finir ton déménagement et installer CVS ou SubVersion (le choix de CVS est dû à l'inscription SourceForge, même si je préfererais SVN personnellement...),
* Morsy : finir le schéma de la base,
* Zain : terminer le logo pour septembre absolument,
* Vince : te faire la main sur Blender et pourquoi pas commencer à faire des petis objets (v. TomCat),
* Nirnaeth : faire d'autres samples,
* Wallace, revenir d'Ecosse (te presse pas man, profites-en bien ;))
* les autres : donner de vos nouvelles !!!!!!!!!

prochaine ED : chez moi vendredi 22/07 à 20h26.