Novos

Comme je l’évoquais ici, je me suis mis en tête de créer un jeu vidéo avec Blender ; je veux dire un vrai jeu, pas un remake d’Asteroid ou un Shoot’em’Up pas terminé comme j’ai l’habitude de le faire. Alors j’ai choisi un genre complètement simple et qui parlera à tout le monde, à savoir un base-builder-survival-permadeath dans un univers hard-science. Ouep.

Un base builder c’est un jeu ou tu construit une base (non ?) ou une ville ou ce que tu veux, dans la tradition SimCity, Dungeon Keeper ou Theme Hospital. Survival parce que le monde est hostile et que si tu te sors pas les doigts, tes persos vont probablement mourir. Et permadeath parce que si tes persos meurent, bien ils sont morts et ils n’ont pas trois vie, ils n’en ont qu’une, ils ne peuvent pas recharger une sauvegarde, bref la mort c’est comme dans la vraie vie (enfin je me comprends). Ah, et dans un univers hard science donc comme de la science fiction, mais en version « réaliste » donc sans artifices genre télépathie, télékinésie, voyage dans le temps, vitesse lumière ou ce genre de trucs : juste des robots, des vaisseaux spatiaux et des humains désabusés par leur vacuité face à l’infinité de l’univers.

Vous allez me demander, avec raison, « mais quelle être sain d’esprit voudrait s’imposer de jouer à ce genre de jeu ? ». Mine de rien ça a son petit public (mais alors c’est très « niche » hein comme public), à commencer par moi. Pardon, vous vouliez quelqu’un de sain d’esprit ? Hé bien figurez vous que j’ai choisi de faire ça avec le Blender Game Engine, histoire de rendre l’expérience plus intéressante.

Je vous avoue que l’idée de base, c’était d’utiliser Unity. C’est LE moteur de jeu du moment pour les indés, ça fonctionne très bien et surtout ça s’exporte facilement sur plein de plate-formes (Linux, Windows, MacOS, iOS, Android par exemple). Mais ça me bloquait d’investir beaucoup de temps à me former sur un truc non libre : si demain Unity changeait complètement de politique et décidait par exemple de n’exporter que sous iOS, bin les développeurs de jeux n’auraient guère le choix que de suivre le mouvement ; très peu pour moi. Ensuite, avec Unity on développe soit en C#, soit en Java ; et honnêtement quand tu commence à prendre tes aises avec Python, la dernière chose que tu as envie de faire c’est de te lancer corps et âme dans son exact opposé : des langages compilés, fortement typés et objectivement illisibles.

Donc ce sera le BGE et Python. En un sens c’est audacieux parce que si le BGE est totalement capable d’encaisser sans broncher ce genre de jeu (on parle d’un truc qui ressemblera au mieux à du Warcraft 3), Python n’est pas forcément taillé pour gérer en temps réel un monde complexe (et hostile !) et une foultitude de personnages ayant chacun leur IA, quand bien même celle ci serait basique. Mais c’est pas grave, on va se débrouiller.

Après deux semaines de dev, voici la liste de ce qui est fait et qui fonctionne (ça ira plus vite que de faire la liste de ce qui ne fonctionne pas ou qui reste à faire).

  • la map est générée de manière procédurale
  • le joueur peut donner quelques ordres (creuser ici, construire un mur là, ce genre de chose)
  • les personnages exécutent les ordres s’il y en a et s’ils en sont capables ; sinon, ils glandouillent en se promenant sur la map.

Mine de rien ça m’a demandé pas mal de boulot.

Générer la map j’en parle ici, les scripts ont pas mal évolué mais la logique reste la même. Le plus galère a été d’associer les données de la map (basiquement un tableau de 0 et de1) avec un tileset (des murs, des angles internes et externes, des T, etc, le tout dans 4 orientations). Je n’ai pas trouvé de manière intelligente de le faire, donc j’ai opté pour une méthode de bourrin où je compare des morceaux de 3×3 cases de la map, avec des pattern prédéfinis. C’est moche mais ça fonctionne.

Ensuite j’ai intégré des menus avec bGUI, c’est très bien mais la doc est, disons, minimaliste. Les quelques exemples fournis ne fonctionnaient pas chez moi. Bref il faut un peu bricoler, mais une fois qu’on a pigé le truc ça va tout seul.

J’ai codé plusieurs AIs (c’est prétentieux de parler d’intelligence artificielle pour dire « des scripts qui exécutent des ordres » – mais c’est plus ou moins le terme consacré), pour cela j’ai eu besoin d’un bon pathfinding, un A* par exemple ; celui que j’avais codé avec les pieds il y a quelques années n’étant pas du tout performant (il fonctionne hein, mais il prend son temps…), j’ai utilisé celui-ci qui est beaucoup mieux ; ça m’a donné l’occasion d’apprendre un peu à utiliser numpy.

Le plus gros du boulot, qui n’est pas facile à décrire, c’est de coller tout ça ensemble et de faire que ça fonctionne dans le BGE. Par exemple mes personnages se trouvent constamment, du point de vue du programme, dans des cases comme aux échec (ils se déplacent de A1 à A2, puis de A2 à B2, etc). Mais il faut que l’objet 3D qui les représente, se déplace de manière fluide entre chaque cases, sinon c’est moche ; j’ai un peu galéré. Je ne parle même pas de la gestion de la caméra (je voulais qu’on puisse la déplacer à peu près librement avec la souris, sauf qu’en l’état c’est complètement incontrôlable).

Bref, mon objectif est de sortir une démo jouable fin octobre ; ça me laisse assez peu de temps pour fignoler tout ça, corriger les bugs et surtout rendre le jeu un minimum intéressant. Au départ j’avais prévu de travailler un peu l’aspect graphique, mais ça me semble compromis : on va devoir se contenter de modèles assez moches pour le moment…

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *


Time limit is exhausted. Please reload CAPTCHA.