On ne m'arrête plus !

Yol (bis)

Bon bein ça m'aura pris beaucoup moins de temps que ce que je pensais... J'ai ajouté la navigation suivant les NPC et ... comme j'étais parti, la navigation suivant les animations du modèle.
Du coup, quand on appuie sur PgDown, on fait défiler les NPC ; quand on appuie sur PgUp, on fait défiler les animations du NPC. Simple, efficace.

Assez parlé, place aux screenshots de Steeve le marchand d'Halbor (d'ailleurs on sait pas ce qu'il vend, mais il vend!).

Là, Steeve il essaye de ratrapper Bob qui devrait courir moins vite... Bein ouais il a un marteau et un tablier, Bob...











Là, Steeve il te prévient que si tu lui achètes pas ses ..., enfin ses .... ses trucs qu'il a à vendre quoi, et bein il t'en met une. Pas fin le Steeve... :|

Steeve, dans sa posture classique du marchand.

Maintenant je mets en pause EaquentaNPCManager, pour préparer l'arrivée de Stardco sur EaquentaMapManager, notre futur éditeur de maps.

Bien à vous (bis).

Chose promise, ...

Yol

Comme promis dans le dernier message, voici des images de l'éditeur de NPC !

Bienvenue dans le dôme Eaquenta !

Je vous présente Bob, le forgeron d'Halbor. Vous remarquerez qu'il a sa position par défaut (c'était avant que mette les animations...) et que son tablier est pour le moins... sans dessus dessous !

Bob et son dragounet

Là, Bob il a remis son tablier à l'endroit et il part faire un footing, le marteau à la main. Il est ce fort ce Bob non ?

Voilà voilà !
Pour info, il ne me reste plus qu'à brancher le changement de perso (en appuyant sur une touche par exemple) et la première version de l'éditeur de NPC sera officialisée (avant vendredi je pense). Donc celà veut dire que vous aurez peut être la chance de rencontrer Steeve, le marchand d'Halbor ;)

Bien à vous.

PS: un intrus s'est glissé parmis les screenshots... Saurez-vous le retrouver ? :) Project Offset

Du neuf

Et oui, du neuf !

oups, pardon, j'oubliais l'éternel : Yol !

Guillaume aka Morsy s'est trouvée l'envie et la motivation pour redynamiser le site en l'améliorant ! Chapeau bas ;) Son frère va réaliser des maquettes d'ensemble du prochain site (plus communautaire, plus intéractif, plus... ) et si Zain le veut bien, il réalisera le design. Morsy s'occupera bien évidemment de la partie technique. Et moi, je supervise et j'approuve :p

Stardco m'a fait part de sa 9807ème installation de portable en moins de 6 mois ! Chapeau bas pour lui aussi ;) Un de ses nombreux ordinateurs portables (j'ai renoncé à les compter à partir du 386ème) sera désormais dédié à Eaquenta sur Linux et/ou Windows (je ne sais plus ce qu'il m'a dit...). Hâte toi, ami Stardco, ton aide nous sera précieuse à tous !

Lancer doit réaliser son stage de trois mois sur un projet de modélisation d'entrepôt en 3D. Nous avons conversé des éventualités s'offrant à lui et, (objectivement bien sûr...) je lui ai conseillé d'utiliser Ogre... :))) J'espère qu'il fera le stagiaire sérieux et commencera à travailler dessus avant son stage ;) Tu as plein de choses à découvrir, jeune Padawan ! Ne te laisse pas tenter par le côté obscur de l'Ogre...

De mon côté, je continue tranquillement et efficacement mon avancée dans le monde implacable de l'architecture multi-plateforme (je crois que j'ai perdu quelques lecteurs en route...). En bref, je travaille actuellement sur l'éditeur/visualiseur de Personnages Non Joueurs, ce qui me permet de tester le nouvel agencement des données sur Mac, ainsi que l'architecture logicielle, et je dois dire que je suis plutôt content de moi pour le moment (bein quoi ? faut bien que je me jette des fleurs, personne d'autre ne le fait...). Je pense que j'aurais fait une première version du visualiseur pour la fin de la semaine, et j'espère donc agrémenter mon prochain post de screenshots furtifs, pour récompenser de leur patience mes chers lecteurs si assidus.

Bien à vous !

SVN, enfin !

Ca y est,
j'ai branché le repository SVN de SourceForge.net avec le projet.

Je n'ai pas mis les anciennes sources car je compte reprendre un peu l'architecture physique et celle du code également. Je vais faire ou modifier certaines classes pour des fonctions de bas niveau utilisables par tous les projets (Log amélioré, fonctions mathématiques, chemins généralisés, ...). Celà constituera donc un noyau commun pour toutes les applications.
J'utilise également un autre formalisme d'écriture que celui précisé dans le document concerné. Je le modifierais donc pour que tout soit bien homogène, et que tout le monde utilise bien les bonnes normes.

Bientôt d'autres news ;)

Art Work : Tour Elfe

Hello !

Voici mon dernier gribouillage :

d'autre a suivre ....

Zain

Ouf...

Yol

Après un petit week end Eaquenta avec TomCat, nous avons finalement trouvé la source de notre problème de textures : la résolution doit être au maximum de 1024*1024. Très étrange, car le logo d'intro fait 1280*1024... :/
Enfin, au moins nous savons à quoi nous en tenir pour Nidhogg.

Les modèles ont été re-exportés avec Blender 2.40, le sapin est tout neuf et moins complexe (à mon avis celà devait bien plomber le FPS auparavant...) et il ne reste plus que le Narbre à faire (hein Roboss !? ;-) ).

Niveau développement : j'ai besoin d'aide ! :-D
En effet, je dois m'occuper de la gestion des lumières/ombres, la collision ne marche pas et le son n'est pas implémenté...
De plus j'aimerais séparer TinyXML du code compilé et le lier simplement en librairie. Si cela est fait, je pourrais modifier le gameplay avec CEGUI (gestion de la souris pour le déplacement).

A suivre... ;)

∞

Yol

After a little 'Eaquenta weekend' with TomCat, we found out what was our textures problem: the max resolution is 1024*1024. Very strange because the intro logo is 1280*1024... :/
Well, at least we know what to do with Nidhogg.

Models have been re-exported with Blender 2.40, the pine is all new and less complex (to my mind that dropped the Framerate before...) and there is just the 'Narbre' left.

Regarding the programming tasks : I need help! :D
Actually, I have to manage the lights/shadows, collision doesn't work et sound is not implemented yet...
Moreover, I would like to use TinyXML as a library to modify the gameplay thanks to CEGUI (mouse management for moving).

To be continued... ;)

Réunion du 11/01/06 ~ Meeting.

Yol !

Voici l'ordre du jour discuté lors de la réunion de ce jour :

1. Web
1. Réorganiser l'affichage des fichiers publics : le rendre plus intuitif, ergonomique et lisible
2. Activer le RSS pour les news et les fichiers privés
   
2. Design
1. Le Nain de Gildas...
2. Blender 2.40
1. Convertir les meshs à la nouvelle version
2. Refaire le "Narbre" central (moins de polygones)
3. Refaire les sapins (un mesh, une texture)
4. Essayer les rendus Blender
3. Nouveaux modèles
1. Améliorer la map existante (Halbor)
1. Végétations : arbres, buissons, ...
2. Décors : tonneaux, paille, ...
3. Divers : armes, boucliers, ...
   
2. Nouvel Humain(e)
4. Concept Art : continuer ainsi en définissant des thèmes/scènes se rapprochant plus d'Halbor et du contenu de Nidhogg (discution entre le PJ et le Forgeron, arrivée devant la maison du chef, ...)
5. Etablir la charte graphique de l'interface utilisateur (à travers des exemples) : l'UI doit donner une identité unique à Eaquenta
   
3. Musique : continuer ainsi
   
4. Développement
   
1. Finaliser le port Windows et Linux
2. Implémenter les fonctionnalités de lecture du son
3. Réaliser le Gestionnaire de Langues
4. Réaliser le Gestionnaire de NPC
5. Réaliser l'étude du Gestionnaire de maps
6. Réaliser l'étude du Gestionnaire de Base de Données Statique
7. Réfléchir à une architecture plus ou moins commune pour tous les logiciels du projets :
1. Physique (emplacement des données, répertoires, ...)
2. Logicielle (Classes communes, architecture souple pour QT, ...)

Voilà !

∞

1. Web
1. Manage the display for public files: make it become more intuitive
2. Activate the RSS feed for news and private files
2. Design
1. Gildas's dwarf
   
2. Blender 2.40
1. Convert every mesh to new version
2. Make a new "Narbre" of the center (less polygons)
3. Make new pines (one mesh, one texture)
4. Try Blender renders
   
3. New models
   
1. Enhance the current map (Halbor)
1. Vegetation: trees, bushs, ...
2. Decorations: barrels, straw, ...
3. Divers: armes, boucliers, ...
   
2. New Human (Male or Female)
   
4. Concept Art : keep up that way while defining themes closer to Halbor and the content of Nidhogg (chat between a player and the Blacksmith, arrival in front of the Chief's House, ...)
5. Establish the Graphical Charter for the User Interface (with examples): the UI must a unique identity to Eaquenta
   
3. Music : keep up the good work ;)
   
4. Programming
   
1. Finish the port to Windows & Linux
2. Make the sound reading functionnality
3. Realise the Languages Manager
   
4. Realise the NPC Manager
   
5. Realise the study of the Maps Manager
   
6. Realise the study of the Static DataBase manager
   
7. Think about a commmon architecture for any software of the project:
1. Hard (locations of data, folders, ...)
2. Soft (Common config classes, flexible architecture for QT, ...)

Here it is!

Bonne Année 2006 ∞ Happy New Year 2006

Bonne année à tous !
L'équipe d'Eaquenta vous adresse ses meilleurs voeux pour la nouvelle année !

∞

Happy New Year Everyone!
The Eaquenta team gives its best wishes for the new year!


J'espère que la production d'Eaquenta continuera d'avancer comme elle l'a fait cet été !

∞

I hope the Eaquenta production will continue as well as it was during the 2005 summer!


Grandes nouvelles : Blender est désormais disponible en version 2.40 et apporte un grand nombre de nouveautés ; allez vite la télécharger !!! L'exporteur pour Ogre est déjà prêt.
A cette occasion, je demande à tous les modeleurs de porter leurs créations sur la nouvelle version de Blender puis de les exporter à nouveau (et évidemment me redonner les meshs...). Merci ! J'espère que celà reglera le problème de textures...

∞

Great news: Blender 2.40 is now available (with a lot of new features) ; go downloading it now!!! And the Ogre exporter is already ready.
I would like to ask every modeler to "port" their creations onto the new version of Blender then export them again (and obviously give me back the meshs...). I really hope we will get rid of this texture problem...


Les recommandations personnelles du dernier message restent valables puisque personne n'a réalisé ses objectifs, sauf Be||e qui nous a terminé sa maison du chef, et Zain qui a fait de beaux Artworks sur les Nains (voici d'ailleurs un portrait).

∞

Personnal goals from last message are still active because noone has done what he was supposed to do excepted Be||e who has finished his 'chief's House', and Zain who have done cute Artworks on Dwarves (here is one portrait).

Mais ils sont où ? Mais ils font quoi ?

Nous ne sommes pas morts... :)

Ne cherchez pas non plus Nidhogg, il n'est toujours pas sorti... Les raisons sont multiples diverses et complexes, malheureusement...

Tout d'abord, nous avons un problème de rendu tel que vous pouvez le voir sur cette image :

Ceci résulte de ... bein en fait on sait pas, d'où le problème... :p Nous sommes actuellement en train d'essayer d'autres choses pour déterminer la cause du soucis.

Autre problème : l'application n'est toujours pas portée sur Windows et Linux, or nous voulons sortir les trois versions en même temps...

Autre problème (bis) : j'ai passé trois semaines à chercher des stages (infructueusement pour le moment) et je me suis pas trop occupé d'Eaquenta...

Bref, le problème de rendu semble aléatoire donc nous avons tout de même réussi à avoir quelques screenshots, disponibles sur le site. Je vous en mets un inédit ici :



Bien, maintenant que tout le monde a eu des petites vacances (je parle des membres du groupe et pour Eaquenta uniquement ;) ), passons aux futures tâches (dans l'ordre prioritaire) :

• Stardco, Lancer : rendre compatible le logiciel pour Linux et Windows,
• Roboss : refaire un nouvel arbre central (ou modifier l'existant) moins polygoné (l'arbre actuel est overkill, il fait perdre plus de 10 FPS :( ),
• Be||erophon : il nous manque une maison du chef ! ;)
  
• Zain : faire des artworks (Noir & Blanc) de ce que t'inspirent les screenshots,
• Nirnaeth : continue sur ta lancée ;)
• Poupi : faire le gestionnaire de NPC (déjà entamé),
• Wallace : faire l'éditeur de langues
• Morsy : voir avec Sam pour l'éditeur de contenu (te presse pas, masterise le C++ d'abord :p ),
• TomCat : un nouveau perso ?
  
• MadProf & son pote : un nain :D

Encore une fois désolé pour ceux qui attendaient la sortie d'Eaquenta le mois dernier, on va tout faire pour le sortir rapidement désormais...

Nidhogg approche...

Yol

Nous avons décidé (totalement arbitrairement) de sortir la première version d'Eaquenta le 17 octobre 2005 (oui, dans 10 jours !). Celà nous permet de nous fixer un objectif concret pour tous. A cet effet, les tâches essentielles ont été recensées et assignées aux personnes concernées.

Be||erophon a fini la maison standard et s'occupe de finir la maison du chef.
TomCat travaille sur la map puis sur les persos.
Stardco et Lancer s'occupent du port vers Linux et Windows.
Wallace a terminé le gestionnaire de langues qu'il me reste à intégrer.
Kut galère sur le gestionnaire de musiques. :p
Roboss rebosse (!) sur le web pour permettre d'intégrer l'encart de téléchargement (fait par TomCat), et réalise encore des objets pour compléter la map.
Pour ma part, j'ai fini la gestion des déplacements avec le clavier (la souris sera ma dernière étape), je m'attaque à la collision... Je dois également faire des documentations et des modèles pour Blender (un gros arbre au centre du village :p).


Autre news très importante : le site a changé d'adresse !!! Maintenant, dirigez vous vers : www.eaquenta.net ;)

Nouveau format de fichier

Yol

J'ai pensé à un nouveau format de fichier pour gérer les Personnages Non Joueurs (PNJ ou NPC en anglais). Un fichier sera renseigné et contiendra la définition des NPC utilisables dans les cartes (via le .map déjà présenté précédemment). Le dotMap référencera un type de NPC (par ex: "blacksmith") et lors du chargement de celui-ci via un fichier XML, le mesh est créé avec la texture précisée, et des meshs sont éventuellement ajoutés aux os (bones) du squelette. Ceci permet de définir simplement tous les NPC dans un fichier, mais aussi des animaux par exemple qui reposent sur le même principe.

L'idée finale serait de faire un petit éditeur de fichier dotNPC qui pourrait créer, modifier ou charger un dotMap. Cette application se présenterait un peu sous la forme de l'éditeur de personnages de LastCity. Je ne pense pas réaliser cet éditeur avant Nidhogg, mais pourquoi pas avant que Stardco ne finisse l'éditeur de dotMap (prévu pour décembre environ).

Concernant les autres parties :

• Le logo avance et Zain devrait porter un coup de boost pour le sortir avant Nidhogg ;)
• TomCat masterise Blender et a terminé la première animation de personnage : un forgeron qui tape sur un enclume avec un marteau. Il a également conçu un système pour optimiser l'utilisation des textures de cartes (notamment pour le chemin sur la carte).
  
• Roboss continue son apprentissage et fait différents objets à intégrer dans la map (étalage, chaise, ...)
• J'ai moi-même réalisé une enclume, un marteau et un sapin. Niveau développement, je galère un peu à intégrer CEGUI sur Mac mais ça devrait être résolu rapidement. Sinon, depuis la dernière fois, j'ai préparé tous les Game States pour Nidhogg et j'ai légèrement optimisé le chargement des données.

J'estime que dans 3 semaines, Nidhogg pourra être laché... Possible ou pas ? :)

Ogre Mac Community

Ce week end, j'ai fait du communautaire... J'ai lancé une partie spéciale Mac sur le wiki d'Ogre et j'ai réalisé 2 tutoriaux (XMLConverter et dotSceneOctree). C'est vrai que j'y ai passé pas mal de temps, alors autant que les autres après moi ne se prennent pas la tête autant... :)
J'espère que d'autres viendront enrichir cette section.

Sinon pour Nidhogg, j'ai terminé ce que je devais faire : gestion des effets pour les temps (pluie, neige, ...), ajout des lumières.

Voilà, c'est tout pour ce dimanche.

Next step, mardi chez Stardco :

• Finition des arbres de Merlu (je veux, pardon, j'exige, une forêt !)
• Essai du script d'animation pour TomCat
• UV Mapping du village pour Be||erophon et Roboss (choix des textures !)
• Install & config d'Ogre sous Linux pour Stardco ; idem pour les plugins que j'utilise déjà
• Essai de ce que j'ai de Nidhogg sous Linux
  

Bilan de l'équipe graphisme

Salut à tous, nous avons fait un bilan d'avancement cette semaine. Nous sommes désormais capable de vous informer de l'avancement de l'équipe vis-à-vis de version Nidhogg.

Dans un premier temps voici les choses faites de :

- Merlu : il finiole la modélisation de son pin, qu'il devrait avoir terminé pour aujourd'hui.

- Zain : il a terminé le logo noir des LdPA (voir blog précédent), et estime avoir terminé le logo du jeu à 60%.

- Bellé : son écurie est quasiment terminée, on peut espérer qu'elle sera exploitable avant la fin août.

- Roboss : Il maitrise la modélisation classique ainsi que l'uv-mapping pour les objets simples. Il prépare ectuellement un épée à une main.

- Madprof : Son nain en 3D est en avancement mais c'est assez flou pour le moment.

- TomCat : La modélisation, le texturage, et le squelette du perso sont terminés. L'animation est prête à commencer.


En bref, voici les choses qu'il restent à faire avant la sortie prochaine de Nidhogg :

- L'animation marcher/courir de mon perso.
- Un beau logo du jeu.
- Les arbres et éléments environnementaux.
- Des maisons communes.
- La map du village.

Nous pourrons de plus nous attaquer prochainement à l'élaboration :
- De la maison du chef.
- D'objets et flores variés avec les textures associées.

Halbor underground

Wow, ça faisait quelques temps que je n'avais pas bloggé !
La raison ? Une erreur de gestion de mémoire qui m'empêchait de charger correctement un dotScene... Cela a l'air d'être dû à TinyXml (sûrement à cause de gcc4 en plus, mais j'en sais pas plus...) placé dans le framework de CEGUI (que j'ai donc enlevé pour l'instant).

La map s'affiche donc bien (à vérifier que la tour renversée est bien une erreur d'ailleurs...) et assez rapidement. La perte de FPS n'est pas trop importante, du moins pas assez pour cela soit injouable. Tant mieux, parce qu'il reste des choses à mettre dessus ! :D

J'ai ensuite implémenté ma SmartCam (tiens ça fait longtemps qu'on en avait pas entendu parlé de celle-là :p) pour pouvoir me ballader sur la (très) petite map...

Je suis désormais sur le chargement de la carte en fonction du fichier dotMap. Tout se passe bien pour l'instant (chargement du dotScene, choix du temps suivant l'heure avec son skyDome associé et lumière ambiante), à part l'écran de chargement qui ne veut pas s'afficher :| J'avance plutôt tranquillement, tant que je ne rencontre pas de problème critique. D'ici à ce week-end, je pense que les temps seront totalement chargés (effets de particules, lumières, ...). Dès que TomCat aura terminé une animation de perso, je m'attaquerais au chargement des Personnages Non Joueurs (PNJ) animés.

Sinon, Zain m'a fait une version spéciale du logo de Légendes du Premier Age avec un fond noir (en gardant les halos gris). Je la trouve vraiment très très bien. Et je ne me lasse pas de regarder encore et encore le fondu pour l'écran d'intro...

Chargement d'un .scene

J'ai fini de parser le .map, il ne reste donc plus qu'à créer la scene...

Blender exporte un .scene contenant les entités, les lumières et les caméras. Si nous voulons créer un temps *dynamique*, les lumières ne doivent pas être en fonction de la scène car suivant le temps, il faudra en rajouter (ou en enlever). A la rigueur, on peut garder dans le .scene les lumières qui resteront quelque soit le temps... En revanche pour la caméra, il ne faut pas l'inclure car on utilisera la (les) notre(s).

Le .scene n'est qu'un format XML pseudo-normalisé par des mecs utilisant Ogre. Le parser ne poserait pas trop de problèmes a priori. Le problème, c'est que je me suis dit que l'on pouvait en profiter pour faire quelque chose de plus intéressant avec : le découpage en octree. Je ne saurais vous l'expliquer clairement, mais en gros ça découpe les meshs en plus petits pour permettre un meilleur affichage suivant la distance.

Il existe un addon pour Ogre (dotSceneOctree) qui fait cela. Un tutoriel explique bien comment faire pour le compiler sous Windows ou Linux, mais pas sous Mac évidemment... J'ai donc passé une bonne journée à essayer de compiler le bundle (et ça a l'air d'être bon...) pour finalement ne pas arriver à le faire marcher le soir... :'( Le support étant mince pour l'addon, je ne sais plus quoi faire... Je vais tenter un post sur le forum fr et le forum officiel au cas où...

Sinon il reste la possibilité de le parser nous même (pfffiiiuuuu la flemme !) puis l'afficher ensuite. Seulement j'aime bien l'octree parceque ça optimise la map et on peut y intégrer directement des infos de collision, ce qui n'est pas négligeable...

Enfin là je crois que j'ai besoin d'un bon week end pour me rafraichir les idées ! :o

Halbor !

Ce sera le nom de la première map d'Eaquenta !
En langage Humain de l'époque, cela signifie (à peu près) : Pierre de Garde. Libre à moi ensuite de justifier ce nom dans les quêtes avec la proximité d'un village Druadan (dans la forêt), la localisation du village par rapport à l'Ennemi, ...
En parlant de localisation, ce village sera placé en lisière de la forêt de Brethil (côté Ouest) au bord du Teiglin (qui devra mesurer une trentaine de mètres de large...). On peut donc imaginer que ce village est juste un point de surveillance des troupes obscures et que peu de villageois y habitent donc... ce qui nous arrange ! :D

Merci au "Tolkiendili" pour les infos ;) http://tolkiendil.com

Niveau programmation, le parsage est presque terminé, il ne me reste plus que la gestion des lumières pour les différents temps. Le format .map a légèrement évolué pour être plus complet et plus souple. Après avoir réfléchi aux différentes manières d'instancier et charger les objets, caméras et autres, je pense que je vais retenir la solution mixte :

• Instancier toutes les choses instanciables sans SceneManager (lumières). Il suffira ensuite d'ajouter les lumières crées au SceneManager.
  
• Précréer les instances de Caméra (nom et position), d'entités (mesh, position et animations) et d'effets (particules). Tout cela sera ensuite chargé avec le SceneManager par défaut.

Une autre solution aurait été de tout charger dès le départ, ce qui ne me plaisait pas (juste pour l'organisation et la clarté du code).
L'autre solution aurait été de tout précréer (donc aussi les lumières), mais ça fait encore du boulot en plus pendant le chargement... :p
La solution idéale aurait été de tout instancier au départ, puis de charger simplement dans le SceneManager ensuite en temps voulu, mais Ogre ne le gère pas : la plupart des choses doivent être fabriquées avec le Scene Manager...

Release mode...

hum non, je n'ai pas fait la release de Nidhogg cette nuit... (les graphistes ne me donnent pas assez de contenu à afficher ! hum... désolé, j'ai pas pu m'en empêcher :D).

J'ai essayé de builder en mode release (donc comme il faudra faire pour Nidhogg et les futures versions d'Eaquenta) un projet d'une personne voulant tester son projet Ogre sous Mac... Après avoir modifié le code pour le rendre cross-platform, est venu ensuite l'étape d'ajout des frameworks et leur linkage statique (de telle façon à ce qu'ils soient livrés avec le bundle au cas où l'utilisateur n'a pas la librairie...). Avec le SDK X11 ça marche sans problème après avoir réglé le problème du framework IL... Pour un utilisateur final sans SDK X11, faire une appli d'install pour l'installer (à voir pour Nidhogg donc).

Un grand merci à Loïc pour leS bêtaS testS qu'il a subi, ses conseils et enseignements avisés, ainsi que sa patience... ;)

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... :-)