Sommaire
Présentation
Intitulé "X-Blaster Dominator", mon projet est un shoot'em up à scrolling-vertical en 2D développé pour Linux et Windows. Les premières versions se reposaient sur du C# avec le framework XNA de Microsoft, mais le code source a été complètement réécrit en C++ pour des raisons de portabilités, mais aussi de performances. Le but du jeu est très simple, puisqu'il faut détruire les ennemis dans la zone de combat. Le joueur dispose d'une arme principale pouvant évoluée sur trois niveaux en ramassant des power up. La seconde arme est plus puissante, mais plus lente et nécessite d'attendre avant d'être rechargée une fois le stock de balles épuisé.
Il ne s'agit pas d'un jeu pour puristes, bien que les premières versions étaient très nerveuses. Après plusieurs critiques dans mon entourage, j'ai préféré revoir complètement la copie et offrir quelque chose de plus facile à prendre en main. Même si le jeu pourra en frustrer plus d'un après avoir perdu la partie, le jeu offre se veut généreux lorsque le joueur se veut persévérant. Par exemple, lors de la première partie, si le premier niveau a été terminé, un crédit est offert. Dans le même esprit, après avoir perdu plusieurs fois, le jeu débloque plusieurs crédits sur le profil du joueur. Et puis si le jeu est vraiment trop pour dur, il est possible de régler le niveau de difficulté sur facile. Il faut savoir que chaque niveau de difficulté offre un game-play différent, puisque les vagues ennemies sont complètement différentes. De même lorsque vous commencez à connaître les niveaux, le jeu tentera de corser un peu les choses.
Scénario
L'histoire se situe dans le futur alors qu'un conflit entre le Japon et les États-Unis d'Amérique vient tout juste d'éclater après la conception d'une technologie par les scientifiques japonnais pouvant générer du carburant à partir de déchets ménagers. Après avoir espionné pendant plusieurs mois le laboratoire, l'armée américaine est en route pour s'approprier la technologie, mais le Japon dispose d'un avion redoutable, pouvant être piloté à distance par le cerveau humain. S'engage alors un combat aux quatre coins du monde où le joueur incarne l'un des pilotes japonais aux commandes du Dominator…
Pourquoi réécrire le code ?
La réécriture du code source était inévitable, du fait que j'avais choisi les mauvais outils et qu'ils ne correspondaient pas du tout a mes besoins. Le C# est un langage facile à prendre en main et il est très rapide de créer des jeux avec le framework propriétaire XNA. En contrepartie, il faut payer un abonnement auprès de Microsoft afin de bénéficier de toutes les fonctionnalités et on ne peut pas dire que les performances soient au rendez-vous. Impossible de faire tourner mon projet sur des machines trop anciennes, car XNA impose ses exigences côté hardware. Autre point très important : la portabilité. Souhaitant porter mon jeu sur Linux, j'ai dû me diriger vers Mono, mais force est de constater que tout marche à moitié. Plutôt que perdre du temps à adapter du code et passer du temps à reporter des bugs sur github, j'ai préféré partir de zéro et en même temps apprendre le C++. Au final, les ressources requises pour lancer le jeu sont ridicules et il peut même tourner sur de très vieilles machines. Ce qui est normal puisqu'il s'agit d'un jeu vidéo très pauvre graphiquement. Néanmoins, je me suis amusé à optimiser le code et les ressources, car il s'avère que le jeu ne se lançait pas sur les machines équipées d'une carte graphique S3. Le changement a été vraiment bénéfique pour le projet en plus m'apporter de précieuses connaissances en C++.
Vidéo de la version en C# : http://youtu.be/I_EnQXef3OQ
Vidéo de la version en C++ : https://www.youtube.com/watch?v=B1C-lSsWEDM
Un projet devenu open-source
Au départ, mon projet n'était pas open-source bien que gratuit. Étant un développeur débutant, c'était la première fois que je publiais un programme et j'étais un peu perdu dans ce monde de violence. Lorsque j'ai présenté le projet sur Linuxfr, j'étais très réticent à l'idée de partager le code source pour pas mal de raisons. La première était la peur du jugement. Ce n'est jamais évident de présenter son travail sans l'avoir évalué. D'autre part, j'ai été trop longtemps habitué à l’idéologie des programmes propriétaires et du coup, je ne voyais pas l'intérêt de distribuer mon code. Je commence tout juste à comprendre l'intérêt du libre, bien que cela fait plusieurs mois que j'ai décidé de libérer le code. À force d'utiliser Linux, de compiler des programmes et traîner sur github, pour moi le libre est devenu un réflexe, voir un mode de vie. Lorsque je cherche un logiciel ou autre chose, je me dirige toujours vers des solutions libres, du moins lorsqu'elles sont disponibles. Je pense que le libre apporte énormément et c'est pourquoi j'ai décidé de proposer la plupart des projets en open-source.
Je voudrais également en profiter pour remercier les membres de Linuxfr pour m'avoir ouvert les yeux et inciter à changer mon regard sur le libre. C'est vrai que je me suis senti au départ agressé, mais le plus important c'est d'être sur la bonne route.
À la recherche de contributions
Le temps passe et je n'ai toujours pas réussi à fournir une version stable de mon premier jeu, un petit shoot'em up sans prétention, et pourtant j'aimerais tant l'achever. Le fait est que j'ai besoin de quelques contributions pour faire avancer les choses, ne serait-ce qu’améliorer le code source ou bien proposer des ressources graphiques mieux élaborées. J'ai conscience que travailler tout seul dans mon coin fait ralentir son développement, c'est pourquoi je lance un appel aux personnes qui souhaiteraient apporter leur contribution afin de faire bouger un peu les choses.
Ça fait plusieurs mois que je n'avais pas touché au code ni tenté une compilation, mais j'ai décidé de régler quelques problèmes et de surtout proposer un code plus facile à compiler sur les différentes plateformes grâce à CMake. Je reconnais avoir pas mal de lacunes avec cet outil et il est possible que mon script ne soit pas d'une grande qualité, mais il fait son travail.
Ainsi, pour ceux qui souhaiteraient compiler le programme sous Linux, c'est vraiment très simple puisqu'il suffit de récupérer le code source via le git puis de laisser CMake faire son travail. Particularité pour les utilisateurs Windows, CMake télécharge automatiquement les bibliothèques externes nécessaires pour la compilation, c'est-à-dire SFML et Boost. Il est également possible de demander à CMake de télécharger les ressources graphiques et sonores en définissant la variable CONTENT_GET à TRUE. Pour plus de détails sur la compilation du projet, vous pouvez retrouver la procédure sur le git, mais ça reste vraiment très simple dans l'ensemble.
Actuellement, j'ai vraiment besoin de savoir si le code source tient la route ou pas et l'idéal serait d'avoir si possible quelques retours. J'ai écrit le code alors que je débutais complètement en C++, donc je suppose qu'il doit y avoir pas mal de choses à revoir. Par la suite, j'envisage de créer un éditeur de niveau, un tableau des scores en ligne et la possibilité d'ajouter des mods. Ce n'est pas un moteur très poussé, mais je pense qu'on peut faire de bonnes choses sans trop se prendre la tête.
Là où je suis très déçu du résultat, c'est au niveau de certaines ressources graphiques qui ne reflètent pas du tout la qualité j'avais souhaité. Le jeu manque cruellement d'animation et j'aimerais vraiment pouvoir offrir quelque chose d'un peu plus agréable à regarder. Avec ou sans contributeurs, je me dois de terminer et maintenir le projet. Avant d'en arriver là, le plus important est de développer l'éditeur de niveau afin de me simplifier le travail, car jusqu'à présent je dois définir chaque position et scénario des ennemis à la main.
Concernant les utilisateurs mécontents qui ne voulaient pas compiler ou installer SFML, j'ai décidé de ne plus proposer de binaire statique, car selon moi, cela n'a aucun sens sous Linux. J'ai aussi décidé de séparer les ressources du binaire, il faudra donc les récupérer manuellement, ça évite de de tout télécharger à chaque fois.
Pour le moment je bosse sur le nouveau site donc je n'ai pas de liens à vous fournir si ce n'est celui du git que j'auto-héberge via GitLab.
Liens
Attention, mon hébergement sur olympe.in est vraiment très mauvais, il arrive souvent que les archives ne soient pas téléchargées complètement. Si quelqu'un aurait un hébergement gratuit sous la main pour les archives du jeu (binaire, ressources, code source, etc.), se serait sympa de me donner un petit coup de pouce !
git : http://git.genku.net/shingosan/x-blaster-dominator.git
bibliothèques (extlibs) : http://shingosan.olympe.in/repo/x-blaster-dominator/extlibs.tar.gz
ressources : http://shingosan.olympe.in/repo/x-blaster-dominator/content.tar.gz
# Hébergement
Posté par Zenitram (site web personnel) . Évalué à 10. Dernière modification le 05 décembre 2014 à 18:28.
Tout logiciel étant passé sous licence libre, plus rien ne l'empèche d'être hébergé gratuitement par GitHub (par exemple).
TuxFamily si tu veux rester dans les francophones.
les hébergements de base et de qualité, ce n'est pas ce qui manque.
Sinon, heureux de voir que le libre a gagné un contributeur de manière pérènne.
# En tout cas.;
Posté par gaston . Évalué à 5.
Pour avoir regardé la démo et pas le code, ca en jette déja pas mal pour un premier développement… félicitations!
[^] # Re: En tout cas.;
Posté par maboiteaspam . Évalué à 2.
ayant joué au jeu, il est même vraiment sympa !
Par contre trop difficile pour moi, je ne l'ai pas fini…
[^] # Re: En tout cas.;
Posté par erdnaxeli (site web personnel) . Évalué à 4. Dernière modification le 06 décembre 2014 à 21:26.
Je confirme, jeu plutôt joli et sympa. Mais après avoir sué sang et eau pour passer le niveau 1, je me suis simplement vu gratifié d'un « peu mieux faire », on dirait mes profs de collège :p
Il existe deux catégories de gens : ceux qui divisent les gens en deux catégories et les autres.
# hebergement du site
Posté par maboiteaspam . Évalué à 3.
Si ton site est static tu peux l'héberger dans github.
Il suffit de mettre ces sources (du site) dans un branche spéciale dont le nom doit être gh-pages.
Après c'est dispo sous
http://[username].github.io/[project name]/
a+ et bon courage, moi j'ai particulièrement aimé le jeu, alors je suis content de voir qu'il pourrait être maintenu ! : )
# libs et cmake
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Pourquoi ne pas utiliser la macro find_package pour trouver les libs?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: libs et cmake
Posté par shingo (site web personnel) . Évalué à 2.
Le problème avec la macro find_package c'est qu'elle utilise à chaque fois une nouvelle variable alors que je voudrais tout mettre dans un tableau. De plus, elle reste en cache et ne peut pas être modifié. Je voulais l'utiliser dans un foreach histoire de me simplifier la vie, mais du coup je n'ai pas trop de solutions. Il faudrait définir à chaque fois une nouvelle variable, ce que j'ai réussie à faire, mais je ne connais pas la bonne syntaxe pour appeler l'une de ces variables…
[^] # Re: libs et cmake
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Je ne comprends pas trop, mais peut être que mon CMakeLists.txt pourra t'aider:
https://github.com/devnewton/superpaflaballe/blob/master/CMakeLists.txt
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: libs et cmake
Posté par shingo (site web personnel) . Évalué à 1.
Oui j'ai procédé comme cela au départ, mais ça fonctionne pas, CMake me retourne pleins d'erreurs en disant qu'il ne trouve pas les libs, du moins sous Windows…
[^] # Re: libs et cmake
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
Normal, find_package n'installe pas les libs, mais les cherche. Le but est d'utiliser les libs fournis par les bons OS avec un système de paquet.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: libs et cmake
Posté par shingo (site web personnel) . Évalué à 1.
Oui, oui je suis au courant. C'est la première macro que j'ai utilisée, mais ça ne fonctionne pas sous Windows. find_package trouve bien les libs, mais une fois que je fais appel target_link_libraries j'obtiens que des erreurs… d'après ce que j'ai lu, il y a une différence d'appel entre Windows et Linux. Je vais reproduire le code et te montrer là où ça plante.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: libs et cmake
Posté par shingo (site web personnel) . Évalué à 1.
Oui oui :) C'est CMake qui n'arrive pas à faire le lien, j'utilise uniquement le compilateur MinGW bien que j'ai une installation en parallèle de Cygwin, mais elle est isolée car exclue de la variable PATH.
# Camarade, fais ton autocritique !
Posté par fasthm . Évalué à 8.
Purée mais on est dans une secte ici ou quoi ? :p
C'est pas mon type de jeux mais à en juger par la video c'est impressionnant de qualité et de finition. Super projet !
La gent féminine, pas la "gente", pas de "e" ! La gent féminine ! Et ça se prononce comme "gens". Pas "jante".
# génération ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
Est-ce que tu as pensé à générer les graphismes ? Cela sera plus dynamique.
Par exemple, pour les missiles, tu peux imaginer des éclaires ou des rayons plus ou moins complexe. Tu peux aussi t'amuser à changer la couleur des sprites en fonction de la proximité de boule de feu.
"La première sécurité est la liberté"
# Pourquoi pas
Posté par Mais qui suis-je ? :) . Évalué à 2.
Ca tombe bien j'ai envie de progresser en C++, d'utiliser tous les nouveaux trucs de cpp11, et en ce moment je code quasi pas au bureau.
je promet rien, mais je retiens l'adresse de ton journal
# Mauvais outils
Posté par barmic . Évalué à 0.
Tu sais ce qu'on dit : "il n'y a pas de mauvais outils seulement de mauvais artisants/ouvriers". Tout ça pour dire que ça n'a pas de sens de dire qu'un outil est mauvais surtout quand on parle de langage de programmation. Par contre, il peut très bien ne pas être adapté à ton utilisation, ne pas te plaire, etc. Mais des langages fondamentalement mauvais à part le malboge et le whitespace, je n'en vois pas.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Mauvais outils
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Je ne sais pas si "mauvais" est le bon mot, mais XNA a été abandonné par Microsoft et d'après le journal Mono ne marche pas bien…
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Mauvais outils
Posté par fearan . Évalué à 2.
Non ils répondent à un besoin d’offuscation, tout comme le .Gertrude ;), par ailleurs tu pars à la défense de C# comme s'il avait été agressé, si je tente de visser une vis avec un marteau, j'ai clairement pris le mauvais outils, pas que le marteau soit de mauvaise qualité mais parce qu'il n'est pas adapté.
C'est comme si je voulais faire un jeu de plateforme en bash, j'aurai pris un mauvais outil.
Bon ensuite, il faut bien avouer que certains outils sont mauvais en toutes circonstances, le java par exemple… :D
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Mauvais outils
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
C# (XNA, Monogame, Unity…) et Java (lwjgl, libgdx, playn, l'api Android…) sont très utilisés pour les jeux.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Mauvais outils
Posté par fearan . Évalué à 2.
hé faut pas prendre la mouche, si tu veux que le bouzin tourne sur des antiquités, les outils comme c# ou java ne sont pas de bon outils, si en revanche tu as de la ram à plus savoir qu'en foutre, java est envisageable.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Mauvais outils
Posté par barmic . Évalué à 3.
Un paquet de jeux sont fait en python ou javascript qui sont pires à ce niveau là.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Mauvais outils
Posté par fearan . Évalué à 3.
J'en ai même fait en bash c'est pour dire ;)
On en est pas a déterminer quel est le pire langage pour faire des jeux, je réagissais juste à
Que je trouve complètement stupide. Que ce soit en informatique ou en bricolage, il y a des mauvais outils; dans le sens où ils ne sont pas adaptés; et cela n'a rien à voir avec la qualité intrinsèque le l'outil.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Mauvais outils
Posté par barmic . Évalué à 2.
Plus que de se contenter de lire les 2 premières phrases sur les 4 de mon commentaire initial ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Mauvais outils
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Il faut voir ce que tu appelles antiquité.
Newton Adventure tourne sur mon vieux PC (une machine bureautique de 2006 déjà pas foudroyante à l'époque) et mon netbook (Lenovo IdeaPad S10 de 2008) malgré son moteur physique lentissime et son code graphique très moyennement optimisé.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Mauvais outils
Posté par xcomcmdr . Évalué à 4.
Et perso je trouve que c'est des conneries.
Un plombier ne va pas se ramener avec une mauvaise boîte à outils. De même un développeur ne va pas essayer de compiler Linux avec MSVC : c'est juste le mauvais outil.
On va pas non plus faire du code qui est censé être multiplateforme avec Visual Basic 6 : ça ne marchera jamais.
On va aussi éviter de faire du code qui est censé tourner dans un Airbus en C : on lui préférera l'Ada qui donne plus de garanties.
On va pas non plus faire un jeu vidéo en PHP : on va devoir combattre constamment l'outil pour y arriver.
On va pas tester son site Web avec IE6 : le support des standards est à la ramasse.
Bref, oui, parfois c'est juste le mauvais outil.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Mauvais outils
Posté par devnewton 🍺 (site web personnel) . Évalué à 3. Dernière modification le 09 décembre 2014 à 14:51.
Le problème c'est qu'il n'y a pas de bon langage pour les jeux:
Les autres langages ne sont pas assez vivants pour ce secteur.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Mauvais outils
Posté par fearan . Évalué à 3.
Pas forcément pour cette raison, ça peut être fait pour simplifier la création de mods. Souvent tu vas avoir une séparation avec le moteur de jeu, et les ressources, les scripts étant inclus dans les ressources. Techniquement rien n'empêcherai d'avoir un système de plugin pour gérer les quêtes et autre éléments du jeu
(je pense même que si skyrim était fait comme ça ce serait un gros gain en perf, mais… les mods on un paquet d’interaction entre eux, doivent gérer la présence ou non d'autres mods, le fait que tous les mods ne se mettent pas à jour en même temps…
Bref faut aussi que lorsque qu'un mod tente d'en appeler un autre avec une fonction qui n'existe plus ne plante pas toute l'appli; c'est plus facile à faire avec un interpréteur maison.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Mauvais outils
Posté par shingo (site web personnel) . Évalué à 1.
De toute façon, les studios de développement ont leur propre moteur en C++, enfin avait puisque tout le monde se base désormais sur l'Unreal Engine 3 et bientôt le 4 ou Havok.
Il y a plus de dix ans, les développeurs créaient leur propre moteur de jeu afin de se simplifier la vie. Un moteur développé en C ou en C++ peut ensuite avoir son propre langage de script, ce qui est un gros gain de temps. De plus, il a toujours été dit que les développeurs de jeux utilisaient massivement le C++ pour ses performances, car c'est un langage de programmation bas niveau.
C'est que récemment qu'on préfère simplifier le développement au détriment des performances. Il suffit de regarder autour de nous pour s'en convaincre.
[^] # Re: Mauvais outils
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
On retombe sur ce que je dis: un système de mods peut être basé sur C++, mais on le fait avec d'autres langages, car c'est plus productif.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Mauvais outils
Posté par rewind (Mastodon) . Évalué à 4.
Je dirais plutôt que C/C++ ne sont pas productifs out of the box pour les jeux et qu'il faut développer plein de petits trucs génériques qui servent dans tous les jeux (et qu'on retrouve dans tous les moteurs de jeux).
[^] # Re: Mauvais outils
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Ce n'est pas trop lié au domaine du jeu: on réinvente plus souvent la roue en C++ qu'ailleurs à cause de l'absence de gestion des dépendances et du manque d'ABI.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Mauvais outils
Posté par rewind (Mastodon) . Évalué à 3.
Ok, je m'y mets après Akagoria :P
[^] # Re: Mauvais outils
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Je te donnerai un coup de main si j'ai le temps, je pense que beaucoup de gens serait ravi d'avoir un "maven pour C++" (même s'ils le savent pas encore!).
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Mauvais outils
Posté par shingo (site web personnel) . Évalué à 7.
Salut ! Quand je dis mauvais outil, je veux dire que XNA et le C# ne correspondait pas à mes besoins. Je l'ai pourtant bien expliqué, XNA est propriétaire et pas portable. De plus il faut un ordinateur plutôt récent pour faire tourner le framework même si c'est un fond d'écran et deux ou trois sprites tandis qu'avec le C++ et la lib SFML, ça tourne sur tout et n'importe quoi, ce qui est normal étant donné que ce n'est pas un jeu très gourmand de part ses graphismes très sommaires.
De plus, j'ai noté une grande réticence de mon entourage à l'idée d'installer le framework XNA, ou alors son installation rentrait en conflit avec le système. Du coup, si XNA ne fonctionne pas sur le système, le jeu non plus… Avec le C++, je n'ai pas ce genre de problème et je peux porter facilement le jeu sur d'autres systèmes.
Mis à part cela, il est très facile de faire un jeu en C# avec XNA, c'est vraiment simple et intuitif, je ne dis pas le contraire. Seulement que si demain un développeur décide d'utiliser le framework, il devra payer un abonnement au Xbox Live s'il souhaite profiter des fonctionnalités du Live (récupérer les données du profil, succès, etc.) et de toute façon le projet a été étrangement abandonné alors qu'il avait un avenir très prometteur sur la scène des jeux indépendants.
J'ai essayé de porter le projet avec Mono et MonoGame, c'est une horreur. Dans un premier j'ai dû effectuer quelques modifications sur le code, car en l'état ça ne marchait pas. Une fois compilé, j'avais un problème au niveau de la couleur des sprites, c'est violet fluo et impossible de changer la résolution qui est par défaut de 640x480. J'ai exposé le problème sur le github de MonoGame, bien que le problème est connu. Ce n'est que cette semaine que j'ai reçu des notifications sur ma boîte mail… soit plus d'un an…
Alors non, XNA était le mauvais outil pour mon développement et ne correspondait pas à mes attentes. Après si on est à fond dans les technologies Microsoft et qu'on supporte la Xbox, oui XNA est un bon choix, mais si demain tu voudrais ouvrir à ton projet et sortir des versions pour pas mal de plateforme, il faudrait forcément changer d'outil.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.