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

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.

Eaquenta Day

Yol !
Hier s'est déroulée une Eaquenta Day (une journée où l'on se regroupe pour faire avancer les choses ensemble...) avec au menu du jour :

• Recensement des entités à modéliser pour la première map.


• Activation et mise en route du CVS


• Installation d'Ogre pour Dev-Cpp

Finalement, peu de choses ont avancées, car seul TomCat a complété le cahier des charges que j'avais commencé, Kut et Lancer galèrant sur des problèmes (parfois) incompréhensibles, Stardco et moi peinant à comprendre comment marche le CVS...

Enfin bref, il va falloir en refaire ! ;)

Roadmap d'Eaquenta

Je viens d'ajouter la Roadmap (la ligne de progression que nous nous engageons à tenir pour chaque différente version sortie) d'Eaquenta.
Allez y jeter un coup d'oeil et dites moi ce que vous en pensez... (les traductions en et es ne devraient pas tarder)

Ouverture du blog !

Bonjour à tous !

Grande première pour moi que d'ouvrir un web journal...
Je ne pense pas le remplir de pensées journalières, mais plutot de faits concernant Eaquenta (le projet de jeu vidéo que je dirige actuellement), ou de mon stage (quand j'en aurais trouvé un !).