Journal PlanetWars2dRT 0.2.0, début d'un jeu libre 2D de bataille spatiale

20
29
déc.
2016

Sommaire

En parcourant le Firefox Marketplace (le store avant tout pour B2G / Firefox OS), j'ai découvert Auralux. C'est un jeu de bataille spatiale temps réel en 2D, simple mais prenant. Il y a une version web (qui ne marche plus à cause d'un TLS mal configuré) et des versions natives mais pas pour GNU/Linux. Beaucoup plus embêtant pour moi, c'est un logiciel privateur.
Des planètes qui produisent des vaisseaux, des vaisseaux et des planètes qui s'affrontent en se rentrant dedans, une interface graphique simple, bref ça ne parait pas trop compliqué. Mais il faut tout de même du temps. Cette année scolaire là (2015-2016), je devais faire un projet sur toute l'année, aucun des sujets proposés ne m'emballait particulièrement. Je n'avais qu'à proposer le mien, et espérer que ça intéresse au moins un autre camarade puisqu'un des buts étaient de nous faire travailler ensemble. En voila le résultat, sous licences libres (surtout de l'AGPLv3+ et de la LGPLv3+) et fonctionnant sous GNU/Linux ! D'une manière très original, le projet se nomme PlanetWars2dRT (RT étant pour Real-Time).

Le cahier des charges

Le but était de faire un jeu similaire à Auralux, sans pour autant le copier, juste sans servir comme base pour les concepts. Le plus simple techniquement est de faire un jeu natif, surtout que mon école (l'ENSICAEN) apporte très peu d'importance au Web, ce qui aurait été contraignant pour les camarades qui m'ont rejoint et qui ne connaissaient presque rien au JavaScript. Cependant, j'avais dans la tête de faire en sorte que je le jeu soit facilement portable sur le Web, avec un outil comme emscripten. Il devait aussi fonctionner sous GNU/Linux et être entièrement libre (y compris ses dépendances et les outils nécessaires pour le faire tourner et compiler).

Le C se convertit apparemment bien en JavaScript, c'est solide (pas de cassage de compatibilité, typage statique, etc) et mes camarades connaissent aussi, c'est donc le langage qui a été choisi. C'est rustique (par exemple comparé à du C++ ou Java, notamment pour ce qui est de la librairie standard), mais le projet est de faible ampleur et ne nécessite pas de structures de données compliquées.
Il fallait ensuite choisir un toolkit graphique. Qt allait être appris en cours dans la seconde partie de l'année, très puissant mais pas sur que ça soit facilement convertissable pour le Web. SDL2 lui est en C et géré à coup sur par emscripten, de plus il est utilisé par de nombreux jeux, il a donc été choisi.

Si vous voulez en savoir plus sur le cahier des charges, il y a dépôt git dédié pour les idées autour du projet (majoritairement en LaTeX, et avec un peu de Markdown).

Ok, mais il y a quoi qui a été fait ?

Le moteur du jeu marche. Il est composé en 2 grandes parties : le modèle (comme sont stockés les données, etc) et le contrôleur (les collisions, des intelligences artificielles, etc). Il est dans un dépôt git dédié, séparé de la vue, nommé core.
SDL2 n'a pas vraiment enthousiasmé mes camarades. De toute façon, la vue en SDL2 était peu avancé, donc une autre en Qt a été lancé. Il y a des boutons, de belles images pour les planètes, et d'autres trucs, mais ça avance lentement, et il manque le plus important : l'affichage d'une partie ! Au moins la version SDL2 affiche une partie, et il ne reste plus qu'une ou deux semaines avant la fin du projet (pour l'école), mais un joueur humain ne peut toujours pas déplacer ses vaisseaux ! Mes camarades sont moins dégourdis que moins en programmation (mais ça se comprend étant donné qu'ils n'ont pas fait d'études en informatique avant alors que j'ai fait un DUT informatique), et il faut faire vite, la vue en SDL2 est donc reprise pour y ajouter le contrôle des vaisseaux du joueur humain. Ouf, "fini" pour l'école à temps.

Dépôts git avec du code source et modèle MVC

C'est un début, mais loin d'être "user-friendly" et pas beaucoup testé. Je souhaite donc continuer pour en faire une version stable avec plein de tests avant d'ajouter de nouvelles fonctionnalités. Beaucoup de tests (unitaires avec check, via des outils en ligne de commande comme cppcheck et vera++, des options des compilateurs, etc) ont été ajoutés, et il y a eu beaucoup de refactorisation. La version 0.2.0 est enfin là (presque 1 an après le gel des fonctionnalités utilisateurs, hormis des options en ligne de commande) et stable.

L'interface rustique avec SDL2

Comment tester ?

La partie core nécessite uniquement un compilateur C99 (comme GCC ou Clang), une bibliothèque standard C99, make, CMake et la bibliothèque check. Si vous n'avez pas cette dernière, installer la (au moins Trisquel, Debian et Ubuntu la proposent dans leurs dépôts) ou compiler la statiquement avec make static-libs. Un simple make exécutera CMake, make tests fera les nombreux tests (mais vous aurez besoin de logiciels non cités ici). Les sources peuvent se récupérer avec git : git clone https://gitlab.com/RyDroid/PlanetWars2dRT-core.git. Pour plus d'informations : https://gitlab.com/RyDroid/PlanetWars2dRT-core/blob/master/BUILDING.md

La partie SDL2 nécessite en plus la bibliothèque SDL2 et 2 extensions (image et gfx), que vous pouvez probablement récupérer via le gestionnaire de paquets de votre distribution favorite ou via make static-libs. Bien entendu, il faut la partie core, si vous ne l'avez pas installé au niveau système, utilisez make externals/core. Pour finir, un simple make suffit. Le chemin du binaire est ./release/bin/planet-wars-2d-rt-sdl2-gui. Il y a des options pour la fenêtre (notamment sa taille) que je vous laisse découvrir avec --help. Encore une fois, les sources sont disponibles via git : git clone https://gitlab.com/RyDroid/PlanetWars2dRT-SDL2.git. Pour plus d'informations : https://gitlab.com/RyDroid/PlanetWars2dRT-SDL2/blob/master/BUILDING.md

Il ne devrait pas y avoir de problème sous GNU/Linux. Ça devrait fonctionner sous macOS (mais le dernier test sur cet OS remonte à loin). En l'état, ça ne compile probablement pas sous Windows, mais ça ne devrait pas être compliqué de faire le nécessaire au vu de ce qui est utilisé.

Ce n'est pas fini

Il reste de nombreuses choses à faire. Je n'aurais pas le temps avant au moins mars, et c'est mieux à plusieurs tout en allant plus vite, n'hésitez donc pas à vous joindre à cette odyssée spatiale libre.

La plus évidente est l'interface graphique, qui est bien trop rudimentaire. Je prévois personnellement de continuer celle en SDL2. Mais la partie core est une librairie indépendante qui fait fortement abstraction du fonctionnement interne du moteur du jeu, donc il devrait être facile de faire une interface avec GTK, Qt, wxWidgets ou que sais je si ça vous tente.

Il n'y a toujours pas de version web, mais ce n'est plus une priorité pour moi. Si un tiers ne la fait pas, il est probable qu'elle n'existe jamais.

Il pourrait être intéressant de pouvoir créer, enregistrer et charger son propre univers. Ça étendrait la "durée de vie" du jeu, et permettrait aux non programmeurs de contribuer indirectement. J'envisage personnellement de faire avec du XML avec libxml2 du projet GNOME.

Quelques intelligentes artificielles ont été faites. Elles ne sont pas très malignes et surtout très bourrins. Il y a probablement beaucoup de choses intéressantes à faire, et il y a la contrainte du temps réel. J'ai peu d'idées sur le sujet, ça n'est pas à court terme ma priorité, mais avec un peu de temps il n'est pas dur d'en créer une au moins pour qu'il y en ait plus (pour diversifier les adversaires). Si vous voulez en faire au moins une, vous pourriez être intéressé par les cartes statiques (c'est-à-dire codés en dur) qui permettent de comparer différentes IA et le générateur aléatoire qui vous offre une infinité de cas différents pour voir comment se comporte une IA.

J'aimerais qu'il soit packagé pour des distributions. Pas juste qu'il soit possible de faire des paquets (c'est déjà fait automatiquement en deb et rpm via CPack), mais qu'ils soient dans les dépôts officiels. Je voulais au moins le faire pour Debian, mais la complexité pour faire des paquets propres m'a découragé pour l'instant (malgré le très bon tutoriel de Vincent Bernat, mais trop simple pour mon cas). Au moins, si quelqu'un veut s'y coller, il y a de bonnes grosses bases (hardening, fichiers nécessaires pour la partie core, etc), et les outils utilisés sont standards et déjà packagés.

Bon jeu (et contributions ?) !

  • # Terme employé

    Posté par (page perso) . Évalué à 4 (+2/-0).

    Au niveau du premier schéma, j'utiliserais plutôt le terme de système planétaire :)

    • [^] # Re: Terme employé

      Posté par (page perso) . Évalué à 1 (+0/-0).

      Effectivement, un de mes camarades me l'avait fait remarquer. J'ai commencé avec le termes planète dans le code, et je n'ai pas changé (ça impliquerait un paquet de changements), du coup je fais souvent l'erreur.

  • # Galcon

    Posté par . Évalué à 2 (+1/-0).

    Le but était de faire un jeu similaire à Auralux, sans pour autant le copier

    De ce que j'en vois, j'ai l'impression qu'Auralux est déjà un jeu très similaire à Galcon (que je trouvais excellent lorsque j'y jouais encore), pour ce qui est des scrupules à s'en inspirer. :)

    • [^] # Re: Galcon

      Posté par (page perso) . Évalué à 1 (+0/-0).

      Je ne connaissais pas Galcon. De toute façon, les concepts d'Auralux sont simplistes, il n'y a pas grande originalité, donc je n'avais pas de scrupules, mais je n'avais pas pour autant d'en faire une copie exacte.

  • # Ça me fait penser un peu à...

    Posté par . Évalué à 1 (+0/-0).

    Ça me fait penser un peu à Mars - a ridiculous shooter, que je trouve vraiment bien fait. Le jeu est fluide, fun, et même plutôt joli. Petite mention d'ailleurs pour la musique, vraiment bien choisi, ce qui est assez rare pour le souligner.

    Hop, un petit lien pour faire découvrir ça.

    Enjoy !

    • [^] # Re: Ça me fait penser un peu à...

      Posté par (page perso) . Évalué à 1 (+0/-0).

      MARS est graphiquement un très beau jeu, avec effectivement de belles musiques que je pourrais prendre pour mon jeu. Néanmoins, il est très différent en terme de gameplay, MARS donne le contrôle d'un vaisseau pour se battre contre d'autres vaisseaux, tandis que mon jeu donne le contrôle d'un "empire galactique" pour imposer sa tyrannie au reste de l'univers avec des vaisseaux qui sont de simples pions.

  • # Oubli d'un "le"

    Posté par (page perso) . Évalué à 1 (+0/-0).

    Je n'aurais pas temps avant

    Si un modérateur passe par là.

  • # IA

    Posté par . Évalué à 3 (+2/-0).

    Si je comprends bien il s'agit du même type de jeu qu'un défi d'IA de 2010 (Planet war).

    Le vainqueur a publié le code source de son bot et un article pour commenter sa méthode. Apparemment le lien vers le code dans l'article ne marche plus mais le code semble se retrouver sur github :
    Article du vainqueur (en anglais)
    Code sur github, en Common Lisp

    Le code d'autres IA se trouve sans doute sur github ou ailleurs, ça peut être intéressant de fouiller si quelqu'un s'intéresse au sujet.

    • [^] # Re: IA

      Posté par (page perso) . Évalué à 1 (+0/-0).

      Merci du filon, ça pourrait être utile (dans mon cas reste à apprendre le Lisp…).

  • # konquest

    Posté par (page perso) . Évalué à 2 (+0/-0).

    C’est proche de konquest non?
    https://games.kde.org/game.php?game=konquest

    • [^] # Re: konquest

      Posté par (page perso) . Évalué à 2 (+1/-0).

      Pas vraiment, ou qu'en partie. Konquest est un jeu de bataille spatiale en tour par tour. Mon jeu est en temps réel (en fait il y a aussi des tours mais au moins 1 par frame). De plus, dans mon jeu, on voit les vaisseaux qui peuvent être n'importe où (pas nécessairement près d'une planète) et ils peuvent se détruire en se rentrant dedans, alors que les vaisseaux dans Konquest sont invisibles et ne peuvent attaquer que les planètes.

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.