Star-Killer

Rules of Optimisation (from M.A. Jackson):

Rule 1: Don't do it.

Rule 2 (for experts only): Don't do it yet.

Ce tutoriel est plutôt une révision du tutoriel précédent qu'on peut trouver ici.

Ce qui va suivre va vous permettre de compiler Raknet sur n'importe qu'elle plateforme UNIX (et sur Windows aussi mais c'est un peu inutile). Pour ce faire on va utiliser cmake. Cette commande à ne pas confondre avec make va justement nous permettre de générer un makefile propre à notre machine. C'est bien pratique notamment pour moi qui travail sur une machine amd64.

La première chose à faire est donc de se procurer cmake. Pour les utilisateurs de Debian (-like), un :

apt-get install cmake

devrait suffire.

Ensuite on se rend dans le répertoire de RakNet grâce à cd et l'on tape :

cmake .

Veuillez noter le "." après, ce n'est pas une faute de frappe.

On enchaîne ensuite sur les grands classiques make et make install. Le .a produit devrait se trouver dans /usr/local/lib. Voilà, vous êtes enfin armé pour vaincre RakNet. Avouons tout de même une chose, la documentation de cette bibliothèque est bien pourri. C'est dit (ce qui n'enlève en rien au fait qu'elle est extrêmement puissante et simple à utiliser).

Le premier est un éditeur graphique de diagramme de classe en UML, le second est son complément indispensable. AutoDia est entièrement en ligne de commande et permet de réaliser des fichiers XML compatible avec Dia. Vous indiquez à AutoDia le répertoire où sont vos sources, le langages de programmation que vous utilisez (l'ajout du support de nouveaux langages se fait par plugin) et ce dernier génère un diagramme de classe lisible avec Dia. Je m'en sers actuellement pour réaliser l'article qui vous présentera le fonctionnement du serveur de AMO.

Les commandes pour l'utiliser sont :

autodia.pl -d Emplacementdessources -l Langage

Par exemple pour AMO je tape :

autodia.pl -d ./AllMonstersObliterated/src -l C++

L'exécution est très rapide. Vous remarquerez que Autodia est écrit en Perl d'où le .pl. Normalement le diagramme de classe se fait avant de commencer le dev pour permettre à tout un chacun de se répartir les tâches et d'avoir une vision clair de ce qu'il va falloir implémenter. Ici, je l'utilise en sens inverse. J'ai codé la majorité des fonctions et au fur et à mesure que le projet se complexifie, je peux ensuite m'aider d'une aide visuelle pour ne pas m'y perdre. C'est également beaucoup plus simple de faire un exposé sur ce genre de schéma standardisé que sur ses propres graph.

Petite note pour les utilisateurs d'Ubuntu. Autodia va générer un .xml. Dia ne pourra pas l'ouvrir. Renommez donc ce .xml en .dia et ça marchera.

C'est pour moi et Benji une grosse émotion, nous sortons la première release jouable de AMO. Alors la démo ne vous laisse jouer que sur une map de quake 3 nommé Berserk. C'est juste un carré délimité par de hauts murs. Au centre, un zombie spawn à l'infini sur une sorte de stèle pour venir vous dévorer.

ICI POUR TELECHARGER.

La démo est multijoueur. Vous pouvez voir les autres joueurs se déplacer et tirer. Cependant chaque zombie appartient au client, ce qui veut dire en gros que vous ne voyez pas sur quoi tir les autres. Ce n'est pas une feature très compliqué à rajouter mais nous avons eu tendance à tomber dans le syndrome : "Et si on rajoutait ça avant de faire une release ?". On devait sortir la démo initialement dans mes plus folles estimations hier soir à 22h. Une série de bug sur le réseau nous a empêché de le faire. Nous avons fixé et réparé le tout vers une heure du matin. En nous levant nous avons rajouté la possibilité de voir les projectiles tirés par les autres. Cela m'a fait ajouter au moins 150 nouvelles lignes dans le code du serveur. Ce n'était pas un petit ajout. Donc là c'est décidé on stop tout.

Vous aurez donc droit à des personnages qui bougent sans interpolation, c'est à dire qui vont flotter, des tirs lumineux dans tout les sens, à du hard rock néo métal et enfin à des bruitages dignes de la Guerre des Etoiles.

Mais ne nous excitons pas. Ce n'est que la première pierre de quelque chose de plus gros. Les fondations sont posées, reste à bâtir une maison ou peut être une grosse merde sait-on jamais. Nous sommes tout de même assez fier de notre moteur, que ce soit le réseau, la 3D tout nous semble vraiment apte pour faire quelque chose de solide.

Après bien sûr, manque des graphismes et des maps digne de ce nom. Je suis actuellement en train de poser des annonces pour recruter des personnes dont c'est le domaine de compétence.

Nous cherchons donc : Des mappeur, des modeleurs, des graphistes en général. On aime bien les animations par keyframe et les maps en bsp du genre de Quake 3. Après il n'y pas de style ni de limite de polygone a proprement parlé. Il suffit d'avoir du talennnnttttttt ma brave dame.

Juste par pur plaisir je vous copie colle le readme écrit avec amour par mes soins. Attention c'est écrit en mauvais Anglais.

#########################################

1. AMO : All Monsters Obliterated #

########################################

#############################################

1. Pre-Alpha Version : Revision number 100 + 1 #

###########################################

Welcome to the firt public playable Version.

There are no goal, no special action to do.

Enjoy your game. We are waiting your feedbacks !

Contact : nobunaga.duc@gmail.com

See you on : http://www.star-killer.net for Dev Diary.

######################################

1. How To : #

####################################

-Windows : Just run AMO.exe .

-Linux : No buildable executable yet.

-MacOs : Don't play on Mac. Seriously.

Move with : z, q, s, d and fire with left mouse.

######################################

1. Features : #

####################################

-Connect to the master server

-Move on a single map with others players.

-Shot fireball.

-Simple movement (up, down, etc..) included.

######################################

1. Requirements : #

####################################

-A pc. Not a Mac.

-An internet connection.

-OpenGl Acceleration Enable.

-Skill.

##################################

1. Team : #

#################################

-Caled : Core designer & first C++ Guru.

-Deckard : Network Engine Designer & Spokesman (Guru skills of course).

##################################

1. Support us : #

#################################

We are seeking help. If you are able to draw low poly on your favorite software like blender, 3DSMAX or Maya join us. You can make Map with the BSP format.

If you can make a build for MacOs, sorry. But you can still send me an email, the engine if fully cross-platform.

Give me money to buy some porn. Oups, to buy some servers. It's cool. You know, we can do web hosting and another stuff like porn server.

The entire source code will be released under GPL when the project will be nicer.

######################################

1. Thanks to : #

####################################

-Irrlicht (3d Engine): Free software are cool.

-IrrKlang (Sound Engine) : It's better with stereo.

-RakNet (Network API) : Fast & Furious. Not free but it's better when it's complicated.

-Our family to feed us.

######################################

1. The last but not the least : #

####################################

We are still single, send me an email with a picture of you. Big boobs will be rewarded. Thanks you.

Sous ce titre un poil racoleur, ce cache une vérité que connaîtrons un jour tout les développeurs. Un projet mal pensé au début nécessitera si le projet veut aboutir, une refonte totale de son architecture. Si un programme est bien pensé on pourra changer allègrement de technologie et ajouter de nouvelles fonctionnalités.

Mais que veut donc dire ce "bien pensé" qui je suis sûr vous a fait soulever la moustache. Je parlerai uniquement de l'expérience AMO. Il est nécessaire de clarifier certains points avant.

AMO est devenu un shoot massivement multijoueurs. Nous gardons le principe des zombies et de la ville qui sera une zone neutre. Pour l'instant notre seule prétention est de fournir un shoot vue de dessus avec un environnement persistant et un système de stats. Le tout multijoueurs bien sûr et en coopératif dans un premier temps. Les contraintes sont donc multiples. Offrir un jeu fluide propulsé en 3D par Illricht (qui est GPL je crois), et en multijoueurs par Raknet.

Pour permettre cela il faut bien organiser son code. Nous sommes en C++, donc nous devons organiser les objets qui composent le jeu entre eux (les joueurs, la physique, le moteur 3D). La première étape est de bien spécifier ses objets. Qu'est ce que je vais mettre dedans, que vont-ils faire, pourront-il modifier des variables d'autres objets. Toutes ces questions doivent être posées. Ensuite on doit construire le schéma du déroulement type de son jeu. Est ce que je calcul la position des balles avant de faire un render, dois-je prendre en compte tel événement à ce moment de la boucle. Les réponses à ces questions sont relativement simple. Le fait de se les poser nous oblige à structurer déjà notre code avant de partir à l'aventure dans le vide. Pour AMO nous avons opté pour une structure pyramidale. Les objets communiquent entre eux par un système de message qui suit cette logique. Un module (un objet) est au sommet de la pyramide et connaît les modules juste en dessous de lui. Ces modules connaissent également les modules qui leur sont inférieurs, etc. Cette architecture a pour avantage de permettre d'ajouter n'importe quel module à n'importe quelle étape du développement. En effet, seul le module du dessus connaîtra son existence. Ainsi, on a pas besoin d'aller retoucher un code obscure codé il y a 6 mois par tata Jeannine. La facilité d'implémentation de nouvelles fonctionnalité est un premier point. On peut ajouter que cela hiérarchise totalement la construction du programme. Généralement, le module au sommet fait juste transiter les messages entre différent types de modules. On retrouve juste en dessous, la couche chargé du moteur de rendu et des events (les deux sont intrinsèquement liés), le moteur sonore, le réseau et la logique de jeu. Cela me semble être la meilleur façon de procéder. Tout ces objets hériterons d'une même classe qui implémentera le système de communication entre module.

Tout cela est implémenté dans le tout nouveau moteur de AMO. Nous avons fait table rase du passé. Benji avait pourtant bien avancé. Nous disposions de notre parser XML, d'un niveau avec un avatar jouable qui tirait des balles (détection des collisions inclus). Alors pourquoi avoir changé ? Car l'implémentation du réseau semblait hasardeuse ainsi que la boucle principal du programme. Cela se passait tout au même endroit et rendait le programme incompréhensible. Cela marchait maintenant mais on allait vite se retrouver bloqué par notre propre manière de faire. Alors autant tout recommencer sur des bases solide et en 3D s'il vous plaît. Nous pourrons ainsi implémenter le scrolling et les collisions de manière beaucoup plus évidente qu'en 2D.

Histoire de rigoler, je vous laisse les exécutables compilé par Benji de notre ancienne version. On vous livre une version Windows qui tournera sûrement avec Wine sous Linux ICI. Je ne vous livre pas les sources car je n'ai pas vraiment la motivation de faire un readme pour compiler la bête étant donné l'étendu de mon lectorat qui visite ce blog sous Linux (deux voir trois personnes). Je vous laisse admirer au passage le XML de tout beauté et ma skin de chasseur de zombie. Si Benji veut libérer les sources on peut y trouver un exemple de l'utilisation de la classe Singleton qui pourrait se traduire par : "Singleton rime avec branlette élitiste mais sa a été fait par l'inventeur du C++ donc c'est indispensable". Il est comme ça Benji. Toujours à la pointe de la branlette. C'est plutôt un compliment. Je suis resté coder le serveur de AMO en utilisant des char* et strcpy. C'est dire.

Nous disons au revoir à Wxwidget qui est une bonne bibliothèque mais le passage à la 3D lui aura été fatal. On vous tient au courant bientôt, je dois dire que le projet avance assez vite.

PS : Si Benji met un troll sur JAVA dans cette article je lui rajoute le tag.

PPS: Si des fan des manchots se réveillent je ferai bien sûr un readme et même un makefile pour compiler la bête sous linux.

Après plusieurs péripétie, le svn est crée et nous avons notre première base de travail. Nous avons choisis de faire un render avec SDL dans une fenêtre de WxWidget. Nous serons cross-platform. C'est d'ailleurs ce qui nous a usé toute la journée. Créer les environnements de développement pour chaque os, linker les bibliothèques et enfin compiler sur les deux plate formes nous aura pris du temps. Benj attaque aujourd'hui l'écriture de toute la partie qui s'occupe du parse. Je commence quand à moi la spécification de tout les éléments de jeu dont nous aurons besoin pour sortir une première release jouable.

Le Villageois :

Cet individu à l'air malsain est caractérisé par :

• Force : Régis les dégâts qu'il inflige, le nombre de denrées qu'il peut porter.
• Endurance : Régis sa capacité en encaisser les coups et à survivre en environnement hostile.
• Vie: Régis l'état de santé actuel du personnage. Cet état est basé sur l'endurance.
• Sexe: No comment
• Age: Défini l'âge du personnage et ainsi sa capacité à se reproduire et son utilité dans la société.
• Soif: Défini si le personnage à soif.
• Classe : Défini la spécialité d'un personnage. Un personnage peut être sans classe.

L'action de base du villageois est de creuser le sol pour trouver des objets.

Classe :

On pense à mettre des chasseurs, des bagarreurs mais ce sera pour une prochaine release. Ces capacités permettront une action spéciale et augmenteront les capacités du porteur.

Le Zombie :

Le Zombie est soumis aux même règles que le villageois. Son âge, son sexe et l'eau n'ont seulement aucune importance. Nous sommes également conscient que l'attribut peut être mal interprété pour le Zombie, on passera outre !

Le Secteur :

Zone de carte de taille variable. Un secteur est défini par un style d'environnement. Le seul prévu pour l'instant est le désert. L'on pourra ajouter après d'autres environnements tel que la ville, la forêt. Suivant cet environnement la carte est généré avec les textures correspondant à l'environnement. Le chargement graphique du secteur s'effectue en trois phases. Tout d'abord le sol, puis les bâtiments et enfin les personnages (zombies, villageois, animaux).

La Carte :

Elle est prévu à l'origine pour être d'une taille de 9*9, le secteur de ville étant placé aléatoirement sur l'une de ces cases.

La Ville:

Le personnage représentant votre avatar est situé au milieu du campement de base. Un feu indique l'endroit ou les villageois oisif se retrouvent. La ville est constitué de deux parties. Celle derrière les murailles, et celle située en dehors. Les bâtiments ont des restrictions de construction lié au fait qu'ils soient en dehors ou à l'intérieur. En début de partie vous aurez, un puit et une muraille sommaire construite.

Les Bâtiments :

• Le puit : C'est le lieux où vous pouvez demander à des citoyens d'extraire de l'eau. Les quantité que vous pouvez en extraire ne sont pas illimité.
• La muraille : C'est la défense de base contre les zombies.

Les ressources :

• Eau : Nécessaire pour nourrir vos villageois et quelques bâtiments. Elle sert également à faire voyager vos villageois d'une case à une autre.
• Nourriture : Nécessaire à l'entraînement des villageois et à quelques bâtiments.
• Tôle froissé -> Tôle redressé -> Tôle neuve : nécessaire à la construction de bâtiments.
• Tronc (bois)-> Planche.
• Pierre-> Pierre taillé.

Tout ceci constitue une première ébauche de ce que nous intégrerons. Toutes ces fonctionnalités devraient se retrouver dans la première release. En attendant nous nous attachons à coder la génération et le rendu des terrains. Nous nous attaquons également à l'animation et au pathfinding des premiers modèles que nous avons.

J'ai décidé d'exhumer un vieux projet que j'avais commencé à coder avant la fin des cours. C'est un remake de l'excellentissime Pang ! Pour ceux qui n'avaient pas d'Amiga à l'époque je vais rappeler le concept. Vous êtes un petit personnage qui peut tirer verticalement (c'est de la 2D façon RICK dangerous). Son but est de dégommer des boules qui rebondissent sur le terrain de jeu sans se faire toucher. Lorsqu'une boule est touchée, elle se subdivise en deux, et ainsi de suite. Donc plus vous tirez sur une boule, plus les boules résultantes seront petites et donc dures à toucher. Un gameplay simple mais terriblement addictif. Comme je le disais donc, je pars déjà d'une vieille base pour coder le jeu. J'ai choisis de faire un jeu entièrement moddable avec la possibilité de faire ses maps, d'importer ses textures, etc. J'avais donc écris beaucoup de code pour parser des fichiers de configuration. A l'époque je n'utilisais que des librairies standards. Puis j'ai rajouté une couche de SDL en me basant sur mes anciens travaux que je partagerai sûrement bientôt ici. Seulement entre temps j'ai découvert le remake de civilization 2 version GPL, FreeCiv. Lui est construit sur le combo SDL/GTK et c'est diablement efficace. Ca l'est tellement que je vais le porte sur Wxwidget / SDL. Je vais donc devoir me dérouiller un peu sur Wx mais ca ne devrait pas poser trop de problèmes. J'espère sortir un visuel la semaine prochaine. D'ici là je me contenterai de parler de hordes je pense :).