La tanière du blaireau

Par magenico Blog créé le 08/04/10 Mis à jour le 02/05/10 à 15h35

Tribulations d'un noob dans l'univers du développement amateur.

Ajouter aux favoris
Signaler

     Bonjour à tous, trop nombreux lecteurs. J'ai essayé d'avancer un peu le projet GFG. Même si ça ne va pas aussi vite que ce que je voudrais, ça prend forme. Je me permet donc de poster une petite vidéo pour illustrer l'état actuel du projet.

     J'ai continué le développement du moteur graphique, l'architecture de base a été complétement remaniée pour permettre la gestion des Nodes avec une structure d'arbre (Noeud fils, Noeud père ...). J'ai aussi codé un petit système de particule pour l'instant basé sur les Points sprites d'openGL. Je m'en suis servi pour générer la fumée qui sort des canons lors de chaque tir. Le tout est encore très moche, bien bugguée et pas du tout jouable, mais ça prend forme.

     Vous aurez aussi remarqué la présence de HitBoxs rouges autour des différentes entités. Elles préfigurent les prochains développements du moteur : gestion des collisions, dégats, mais je vous en reparlerais plus tard.

bonne continuation à tous.

Ajouter à mes favoris Commenter (0)

Signaler

    Cette fois-ci je vais vous proposer un petit billet "technique", rien de novateur ou de très compliqué, je vais vous parler des bases de la programmation 3D.

     Commençons par énoncer une stupidité : vous vous en doutez le grand apport de la 3D par rapport à la 2D c'est  l'insertion d'une troisième dimension. On passe d'un plan à un espace en 3 dimensions. Il est alors possible de rendre des volumes à l'écran, et c'est là tout son intérêt. Mais il faut passer outre le fait que l'écran ne soit qu'en 2D. En effet le rendu 3D doit passer par une image 2D, sauf pour les lunettes 3D où c'est encore un peu plus complexe. Il faut donc rendre un effet de volume autrement.

     Rappelons d'abord qu'une bibliothèque "3D" (openGL, directX / direct3D) permet de déclarer des formes géométriques en 3 dimensions (ou 2 ou 1 d'ailleurs). Ces formes seront ensuite projetées sur un plan correspondant à l'écran. Les formes 2D ainsi obtenues subiront ensuite une étape de rastérisation qui consiste en une transformation en pixel. Et c'est finalement ces pixels qui seront affichés à l'écran. Bon évidemment, il y a plein de raccourcis et de détails manquants dans l'explication ci-dessus, mais elle est largement suffisabte pour ce que je veux vous expliquer par la suite.

     Intéressons nous maintenant au rendu des volumes. Si vous dessinez une sphère bleue en 3D, celle-ci sera projetée comme un disque et c'est un disque bleu uniforme qui apparaîtra à l'écran. Si vous tournez autour de cette sphère, c'est toujours un disque qui apparaîtra à l'écran. Il n'y aura aucune illusion de volume étant donné que le disque sera a priori d'une seule couleur unie. Un des façons les plus simple de rendre un volume est d'éclairer la scène 3D. En effet notre sphère si elle est éclairée ne sera plus d'une couleur uniforme, les surfaces élémentaires de la sphère faisant face à la lumière seront plus éclairées que celles qui ne font pas face à la lumière.

      La deuxième sphère et la troisième sont éclairées : la couleur rendue à l'écran est calculée en fonction de la direction de la lumière incidente sur une face et de la normale de cette face. On remarque tout de suite que l'effet de volume est présent contrairement au disque bleu. On a vraiment l'impression d'avoir affaire à deux sphères. La troisième image paraît cependant nettement plus "sphérique" que la seconde. On pourrait croire que c'est parce qu'elle contient plus de polygones, c'est à dire plus de faces de tailles plus petites donc qu'étant plus détaillées, son rendu est moins grossier. Il n'en est rien, elle a strictement les mêmes faces / points que la sphère de la seconde image. Et je laisse pour un futur billet l'explication de cette différence !

 

 

 

 

Ajouter à mes favoris Commenter (0)

Signaler

Ma première tâche dans le développement du projet GallionFightGame (GFG) a été de m'interroger sur les techniques de simulation d'étendue d'eau. Cela posait déjà de nombreux défis techniques et il fallait faire des choix. D'abord quelques explications sur la manière dont je souhaite faire avancer ce projet.

      Pour éviter d'être trop vite découragé par l'ampleur de la tâche, j'ai choisi de travailler par itération. Je commence par réaliser de la manière la plus stupide possible une partie du jeu et ensuite j'itère pour améliorer le rendu, optimiser le code ... Knuth disait "premature optimization is the root of all evil" (source wikipedia), et j'essaie d'avoir cette phrase en tête à chaque fois que je programme quelque chose. Il faut d'abord obtenir quelque chose qui fonctionne, avant de vouloir optimiser. Il est en effet dangereux de vouloir dès le début implémenter une super optimisation/fonctionnalité (de la mort qui tue) sous peine de pondre un code incompréhensible, difficile à débugguer et impossible à mettre à jour. Il faut bien évidemment se poser les bonnes questions avant de coder quelques choses, avoir déjà en tête les optimisations que l'on voudrait faire et la manière de les implémenter, mais il faut d'abord se borner à le coder simplement et s'attaquer aux optimisations par la suite. Ce n'est pas un principe général (chacun sa méthode), mais c'est le mien.

      Revenons à notre simulation de mer. Plutôt que de tenter le photoréalisme que j'aurais été incapable d'atteindre, il me fallait obtenir une simulation assez proche de la réalité la mer tout en utilisant un rendu un peu stylisé pour éviter d'avoir à y passer 10 ans. La première itération consiste donc à utiliser une fonction sinus ainsi qu'un tableau de décalage aléatoire à deux dimensions. La mer est découpé en case carrée. Chaque point voit sa hauteur changer au cours du temps à l'aide de la fonction sinus et du décalage (aléatoire). J'utilise des shaders maisons pour l'éclairage.

 

 

 

la page d'où la citation de Knuth est tirée :

http://en.wikipedia.org/wiki/Program_optimization

Ajouter à mes favoris Commenter (1)

Signaler

     Bonjour à toi lecteur (comme je suis sûr de relire ne serait-ce qu'une fois cet article, je peux présupposer avoir au moins un lecteur). Je vais te présenter mon blog en quelques phrases.
     Je suis un développeur amateur depuis quelques années déjà, à un niveau qui tient plus du noobisme que du développeur d'ailleurs. Récemment j'ai décidé de me lancer dans une nouvelle aventure: créer un prototype de jeu en 3D. Je tiens tout de suite à fixer un certain nombre de choses.
     Premièrement je fais cela sur mon temps libre et donc il y a peu de chance que ce projet avance rapidement. Secondement, je suis beaucoup plus intéressé par l'aspect technique de la chose que par le fun du joueur devant le prototype final. Cela veut dire qu'il y a peu de chance pour que j'obtienne quelque chose de beau ou de sympathique à jouer.  On me rétorquera alors que mon entreprise est (en plus d'être vouée à l'échec) complètement inutile.
     C'est pas faux !  Mais le seul but que je me fixe est d'apprendre des choses, de manipuler de nouvelles techniques et de m'amuser en créant cet embryon de jeu.
     Maintenant que mes motivations sont clairement établies, je peux te décrire ce que je compte faire.

     Mon but est de développer un moteur 3D minimaliste à base d'openGL et de l'utiliser pour faire un jeu de bataille navale dynamique dont l'époque se situerait entre le 15ème et le 18ème siècle (c'est plutôt large). Pour l'instant le projet s'intitule GallionFightGame et sous-entend donc qu'il s'agira d'un jeu mettant en scène des combats entre différents gallions pour une suprématie maritime aussi futile qu'exagérée.

     J'essaierai de mettre ce blog à jour le plus régulièrement possible.

 

Ajouter à mes favoris Commenter (0)

Édito

Ce n'est sûrement ni le lieu, ni l'endroit mais j'ai envie au fil des semaines de vous faire partager une petite aventure que je viens d'entrependre, programmer un prototype de jeu.

Archives