Ami d'un monde plus juste

"Baune" travaille sur son jeu de boxe depuis 5 ans maintenant. Je souhaitais vous montrer brièvement où il en est. Il utilise Java, JMonkeyEngine 2.0, JGN et PhysX et LWJGL. Pour en savoir plus, allez sur http://onlineboxing.net

Je dois reconnaître que j'ai eu quelques gros soucis dans le développement de TUER cette année. J'avais entrepris d'utiliser le moteur 3D JMonkeyEngine. J'ai passé plus de temps à le réparer qu'à développer mon propre jeu. J'ai beaucoup appris mais je suis très déçu. TUER n'est pas fondamentalement meilleur en 2009 qu'en 2008. JMonkeyEngine 2.0 a grandement profité de mes corrections, son système de rendu basé sur JOGL est suffisamment stable pour être utilisé en production si on met de côté le problème que j'ai eu sur certaines machines au niveau de la gestion de la souris.

Cependant, j'ai décidé de me tourner vers un autre moteur à la fois plus jeune, plus prometteur et beaucoup plus stable, il s'appelle Ardor3D. Je vais essayer d'améliorer l'interface graphique dans un premier temps. La nouvelle introduction est plus dynamique et plus convaincante. J'affiche d'abord l'écran comportement les indications PEGI. Alors, j'affiche le logo de la FGF qui tourne sur lui-même. Ensuite, j'affiche une carte de l'Europe qui se rapproche progressivement du joueur tout en se recouvrant de rouge. Je trouve que l'ensemble est plus esthétique que les menus textuels et les affichages un peu ternes auxquels je m'étais habitué dans la version précédente.

JFPSM va me permettre de gagner un temps fou dans l'ajout de nouveaux éléments. J'espère vraiment que TUER méritera son nom en 2010. Je souhaite faire vivre aux joueurs une expérience plus frénétique tout en gardant les pieds sur Terre, TUER est très très loin des standards actuels et je doute fort que cela change. Les développeurs d'Ardor3D doivent encore régler quelques détails pour me permettre d'utiliser Java Webstart pour déployer la nouvelle maquette. Si vous aussi vous voulez vous défouler sur la police nationale, suivez le développement de TUER. J'annoncerai la mise en ligne de la prochaine version d'ici quelques semaines.

Mercredi, j'ai mangé au comptoir nippon près de la gare montparnasse et c'était assez bon. J'ai terminé par le tempura cheesecake et glace vanille comme vous pouvez le voir.

Depuis mon arrivée à Paris en septembre 2006, j'étais resté en contact plus ou moins étroit avec Valérie, la femme qui a le plus compté dans ma vie, une de mes anciennes petites amies. Nous avons passé de bons moments ensemble, nous nous sommes aussi faits beaucoup de mal. De mon côté, j'ai assumé ma part de responsabilité, j'ai reconnu mes torts, j'ai essayé de réparer ce qui pouvait l'être.

Au fil du temps, j'ai réalisé que je ne voudrai plus jamais faire machine arrière, plus jamais je ne redeviendrai son petit ami. Je pense qu'elle a réussi à devenir indépendante de moi et à se construire un semblant de vie sociale depuis notre dernière rupture, je trouve cela assez positif. Cependant, ses problèmes de santé ne se sont pas évaporés dans la nature et elle a privilégié son entourage amical. Les choses qui causaient des problèmes en 2006 et encore en 2008 ont très peu évolué (pas seulement dans le bon sens) et ses orientations l'ont rendue encore plus incompatibles avec moi. A partir de la fin du mois de janvier 2009, après avoir mûrement réfléchi, j'ai tiré un trait sur toute perspective de construction amoureuse avec elle.

Malgré cela, j'étais resté assez attaché à elle, j'avais besoin de son affection ce qui m'avait parfois poussé à revenir vers elle comme un drogué irait voir son dealer de cocaïne. Elle avait fait le même genre de chose à une époque... sauf que cette année, elle avait décidé que ça ne marcherait que dans un sens, le sien. C'était l'une des rares personnes à laquelle je pouvais me confier en me sentant compris et c'était en partie réciproque. C'était un peu ma seul bouée de sauvetage. Elle attendait au mieux de l'amitié de ma part, rien de plus. J'attendais un minimum d'affection et de tendresse. Nos intérêts étaient contradictoires. Je n'ai pas un coeur d'artichaut. Comme disait mon amie Nicoleta : "de beaux amoureux qui deviennent de bons amis n'étaient pas de vrais amoureux". Non je ne pouvais pas m'adresser à elle en oubliant même un seul instant les langoureux baisers, les câlins, les bisous, les mots doux, tout ce qui fait un couple. Bon sang, même quand je faisais mes courses à LIDL, je pensais très fort à elle, ça me donnait le cafard. Je ne supportais plus d'être uniquement là pour l'écouter parler de ses problèmes sans l'agréable compensation de la serrer dans mes bras. Je ne suis pas un monstre. J'ai du coeur. Je veux bien aider les gens mais cela faisait longtemps que je ne lui faisais plus confiance. Valérie s'acharnait à me faire part de ses peines et de ses tourments sans vraiment se soucier de ce que j'attendais. C'était la fin du soutien mutuel, elle m'imposait un cadre qui ne permettait pas mon épanouissement.

J'ai fini par fermer les vannes, pour de bon cette fois. Après l'avoir bloquée sur MSN et ajoutée à ma liste noire sur mes comptes email, j'ai installé l'application "aFirewall" sur mon téléphone HTC Dream équipé de Linux Android 1.5 afin de bloquer ses appels et ses SMS. C'est lamentable de devoir en arriver là. Je ne reste pas sur elle, ce temps est déjà loin. Je n'ai pas de problème psychologique. Il n'y a pas de bonheur sans malheur. Je suis heureux de savoir aimer quitte à ce que cela m'expose parfois à la souffrance. De ce point de vue, je préfère mille fois ma situation à la sienne, je n'ai pas égaré la clé du bonheur. Je terminerai cet article par cette citation :
"De toutes les prudences, la prudence en amour est la plus nocive au bonheur".

P.S : Il est temps de faire le ménage dans mon entourage féminin. Je me suis accroché à Valérie aussi parce que certaines personnes n'ont pas répondu à mes appels au secours quand je me sentais vraiment mal. Si j'avais été un peu plus soutenu, j'aurais pu prendre mes distances plus tôt.

Dans le cadre du projet TUER et dans le contexte actuel (mon infographiste m'a rapidement lâché), j'ai besoin d'un outil RAD (Rapid Application Development) appliqué au domaine des First Person Shooters (jeux de tir en vue subjective). Cet outil doit être suffisamment simple pour pouvoir être utilisé aussi bien par un game designer qu'un développeur. Il doit également être interopérable afin de s'intégrer dans l'environnement logiciel d'un infographiste. Cependant, mon logiciel ne s'adresse pas spécifiquement à des artistes car ils disposent déjà d'outils bien plus poussés. J'ai choisi d'exporter à terme les cartes dans les formats DAE (Collada) et OBJ (WaveFront) pour qu'ils puissent les améliorer avec leurs modeleurs favoris (Blender, Art Of Illusion, Maya, Milkshape, 3DSMax, Virtools, Cinema4D, Bryce4D...). Ainsi, JFPSM se concentre sur la conception rapide de maquettes de FPS.

L'outil est rudimentaire pour le moment. Il se situe à mi-chemin entre FPSCreator (mais sans les bogues) et Duke Nukem Build (dont un collègue m'a parlé). Cependant, JFPSM sera à ma connaissance le seul outil du genre compatible avec 4 familles de système d'exploitation (vous me direz que ce n'est pas bien difficile avec Java). JFPSM n'est pas seulement un éditeur de cartes, il contiendra une sorte de méta-moteur. Concrètement, vous pourrez générer un jeu facilement déployable et exécutable. Je proposerai 2 modes d'installation :
- Java Webstart
- IzPack
Pour les applets, je préfère attendre qu'elles gagnent en stabilité. Java Webstart s'avère adapté pour de petites maquettes, pour des projets pas encore finalisés à destination de non joueurs (bêta-testeurs pour l'essentiel) alors qu'IzPack permet un déploiement beaucoup plus propre et plus professionnel afin que le jeu soit bien intégré pour que le joueur final dispose clairement d'un raccourci pour (re)lancer le jeu et d'un autre pour le désinstaller (on peut aussi rajouter un raccourci vers la notice, etc...).
Le méta-moteur s'interfacera avec un moteur 3D existant. Pour le moment, je ne supporterai qu'Ardor3D. Les développeurs de Xith3D, 3DzzD et JMonkeyEngine sont invités à implémenter les interfaces nécessaires si le projet les intéresse surtout qu'une bonne partie du boulot est déjà faite pour JMonkeyEngine 2.

JFPSM est organisé de manière arborescente. Un projet contient un ensemble d'étages (floor set) et un ensemble de tuiles (tile set). Une tuile gère un motif à appliquer à un voxel. Chaque tuile se voit associer des textures, des ensembles de coordonnées, des caractérisques de matériel (en rapport avec la lumière) et un code couleur qui l'identifie dans la visualisation 2D. Dans cette visualisation, un étage comporte plusieurs couches :
- la container map qui gère les éléments de délimitation (murs, portes, téléporteurs ...)
- la light map qui gère l'éclairage
- la content map qui gère les objets, la faune et la flore
- les path maps qui gère les chemins notamment pour les patrouilles d'ennemis
Toujours dans cette visualisation, les codes couleur des tuiles apparaissent dans les cartes énumérées ci-dessus. Je prévois aussi une visualisation 3D, je me demande si je vais implémenter la modification de la géométrie directement dans cette visualisation, ce serait intuitif à utiliser, souvenez-vous de Duke Nukem Build.

Les projets JFPSM sont au format ZIP (je voulais utiliser GZIP mais j'ai eu un souci d'implémentation qui était déjà réglé avec ZIP). Le ZIP contient un fichier "project.xml" qui contient l'essentiel des informations et un répertoire "floorset" avec l'ensemble des cartes. L'implémentation n'étant pas terminée, il me reste plein de choses à ajouter.
Les jeux sont composés de plusieurs JAR et soit d'un fichier JNLP (pour Java Webstart) soit d'un fichier XML (pour IzPack).

J'ai débuté la programmation de ce logiciel il y a environ deux semaines. Il est sous licence GNU GPL. Le code source sera mis sur mon dépôt SVN dans la branche pré-bêta de TUER avec la maquette d'Ardor3D dans les prochains jours. Je rappelle une chose importante : j'ai évoqué FPS Creator mais je ne cherche en aucun cas à concurrencer des logiciels professionnels maintenus par une équipe de programmeurs à plein temps; c'est encore une fois un modeste sous-projet avec des objectifs réalisables. Une bonne partie des traitements les plus complexes nécessitera seulement un petit refactoring du code source des systèmes de pré-calcul des géométries des cartes de TUER. Je n'ai utilisé ni Eclipse RCP ni Netbeans RCP car j'estime que le projet est trop petit pour vraiment en tirer partie. Toutefois, je changerai peut-être d'avis pour éviter de réimplémenter certaines fonctionnalités qui sont déjà présentes dans ces frameworks.

P.S : Je remercie Etoile-Blog pour la publicité.