Projet - jeu de combat avec personnages et maps scriptables

Bonsoir les gens.

Je sais pas si certains s'en souviennent, mais sur IRC y'a 2 ou 3 semaines, on a parlé vite fait de faire un jeu de combat Touhou, mais dans le style des Super Smash Bros. Je me suis proposé pour voir si développer un moteur de jeu peut se faire convenablement, puis laisser le soin à des membres du forum de "scripter" les attaques et les comportements des personnages, de même que leur attribuer une apparence, etc. Bref. Il se trouve que c'est potentiellement faisable à condition de fournir un langage de script pas trop dur à comprendre et à utiliser, puis pas trop dur non plus à interpréter voire compiler. Je pencherais plus pour la 2ème option (bien qu'elle soit un chouïa plus difficile) vu que ca pourra être plus rapide (Danmakufu se contente d'interpréter les scripts je crois, et il rame comme un porc dès qu'il y a plus de 500 bullets à l'écran, parfois beaucoup moins), et que de toutes façons on apprend en ce moment dans mon école comment construire un compilateur beaucoup plus complexe que ce que je prévois de faire pour ce projet. Entre autres je vais utiliser le C++ comme langage intermédiaire plutôt que de faire vers de l'assembleur ou pire du code machine, ce sera moins risqué et ça ne prendra pas 5 ans juste pour faire ça.

Bon voilà. Donc le but, dit autrement, c'est de permettre de créer un jeu de combat SSB-like à la sauce Touhou, sauf que ce sera assez flexible pour ressembler à des trucs comme MUGEN. Sauf que MUGEN c'est fait pour les jeux de combat du style classique "un terrain plat, une combinaison de directions + un bouton pour taper ou faire des trucs au mec en face ... qui est déjà en face et rarement derrière, on peut pas se retourner ... et une barre de vie, ainsi que quelques trucs exotiques" alors que SSB c'est "un terrain qui pourrait sortir d'un jeu de plateforme, pour attaquer on utilise une seule direction avec un certain timing plus le bouton, le placement et l'orientation du personnage sont totalement libres, un compteur de dégâts et il faut éjecter l'adversaire". Donc en gros on peut pas faire de SSB-like avec MUGEN (ou alors c'est probablement chiant et difficile à faire), c'est pas fait pour, et c'est aussi pour ça que quiconque voit ici une tentative de concurrencer MUGEN peut tout de suite oublier de me troller en balançant des "ouais mais MUGEN c'est plus élaboré, les mecs ce sont des pros et ils maintiennent ça depuis des années, tu tiens pas la comparaison". C'est vrai, mais ça ne vise pas le même genre de jeu de combat. De plus, si je suis à EPITA, c'est aussi pour ne pas être un amateur dans le domaine. Bref. Donc, à moins qu'un moteur de jeu SSB-like n'ait vu le jour avant, celui que je prévois de créer est un truc tout neuf, tout beau, tout frais. [/marketing]

Arrivé là, si quelqu'un n'a pas compris ce que je voulais faire, j'en ai rien à foutre et je continue.

Donc en gros, ce que je vous demande *insert I NEED YOU pic here* :

- M'aider à élaborer deux langages de script faciles à utiliser (pour vous) et à traduire (pour moi). Un pour les maps, un pour les personnages. Le but c'est surtout de se mettre d'accord sur quelque chose qu'on va traîner jusqu'à la fin et même après, si on se mange des fails à ce stade ça va pourrir la suite et certains changements peuvent ralentir énormément l'avancement de tout ce que l'on fait. J'ai pas envie que 500 kevins me gueulent dessus si c'est trop dur à faire, s'il faut réécrire leur super pack de Ninjas from Naruto ou si le jeu de leur rêve ne sort pas à cause d'une mauvaise décision alors que c'est un projet faisable.

- Une fois que c'est fait, me laisser le temps de coder un compilateur et un moteur de jeu potable. S'il y a des gens qui sont prêts à toucher à la fois au C++, à OpenGL, à Bison, à Flex et à Git (surtout Git et C++ en fait, ce sont les deux seuls trucs vitaux), je veux bien de l'aide de ce côté. Pour information, Bison est un générateur de parser, Flex est un générateur de scanner, Git est un outil de versionning décentralisé, et le C++ je pense que tous ceux qui sont susceptibles de m'aider savent au moins ce que c'est.
Je suis pas contre toute autre technologie si elle est intéressante. Notamment, mais on s'en occupera plus tard, je sais pas trop si on devrait passer par SFML, passer par SDL, ou passer par autre chose pour se lancer sur OpenGL.
Au passage, les débutants en programmation sont acceptés en tant que "spectateurs", s'ils font pas de conneries et s'ils veulent apprendre des trucs. Je pourrais même leur laisser des trucs à faire s'ils sont sages et qu'ils comprennent ce que je fais. ::

- Si je (on ?) arrive au bout de ce compilateur/moteur de jeu, il sera possible de commencer à tester les premiers scripts de maps ou de personnages que les plus casse-cous auront écrit depuis pas mal de temps (des compétences basiques de programmation sont suffisantes pour faire un truc qui marche, les plus aguerris peuvent faire des trucs qui roxxent du poney - au pire quelqu'un fera un tuto, y'aura une doc et tout), et de faire en parallèle le moteur graphique. A ce stade, tout le monde peut faire ce qu'il veut, juste une chose : ne pas faire de personnage surpuissant qui démonte tout avec des attaques instantanées utilisant des hitbox monstrueuses. Ou des maps injouables.

- Enfin, si tout se passe bien (ça pourrait être dans 1 an, 2 ans, 10 ans, jamais ...), on aura un MUGEN-for-SSB-like avec un paquet de personnages et de maps en relation avec Touhou (parce qu'on est des touhoufags) qu'on pourra aller vendre au Comiket ou au Reitaisai qu'il faudra de préférence équilibrer. Aussi, il restera probablement des bugs et autres qu'il faudra corriger. Une fois que c'est assez stable, y'a moyen d'en faire un jeu jouable en réseau, mais j'ai pas l'intention de me spécialiser dans ce pan de l'informatique. Cependant j'ai assez de notions pour bidouiller un truc qui fonctionne plus ou moins, et puis on a le temps de trouver un gars qui s'y connaisse mieux, encore faut-il en arriver là.

*drool*

Ahem.
Bon je crois que c'est tout. J'en profite quand même pour dire quelques mots à propos du prototype sur lequel j'ai bossé pendant mon temps libre depuis qu'on en a parlé sur IRC, histoire de dire que c'est faisable en 1 an si on passe pas son temps à jouer à fap fap et que j'ai assez de temps libre :
Le langage de script pour les maps était moche et incomplet mais marchait plus ou moins (surtout moins), sachant que j'utilisais pas Bison/Flex, je faisais tout le parseur à la main (c'est pour ça qu'il vaut mieux les utiliser, ça permet à la fois de faciliter plein de choses et de faire plein de trucs, ce sont des outils monstrueusement efficaces).
Les personnages n'étaient pas scriptables, j'en ai fait qu'un seul qui pouvait seulement bouger, et encore le code était dégueulasse juste pour gérer les transitions d'état. Y'avait des switch partout, immonde, fallait penser à tout et c'est super chaud à débugguer. D'où l'idée de séparer le moteur de jeu et les scripts, chacun de leur côté est plus facile à maintenir, des gens quasiment non initiés à la programmation peuvent donner un coup de main. Je sais pas si vous avez déjà vu des scripts de personnages pour MUGEN, mais pour un personnage de base il y a des centaines d'états et de transitions différents, hors de question de les coder à la main en C++ sans faire de la merde. Pareil, pour ceux qui ont touché à Danmakufu, la plupart du temps vous avez juste à vous demander à quel moment on balance tel ou tel pattern, et quelle est la trajectoire des bullets. Y'a plein de trucs qui sont faits automatiquement et proprement à votre place sans que vous ne le sachiez. Bon après certes, le code auto-généré derrière est aussi immonde que si c'était fait à la main, sauf que y'a pas besoin d'y toucher
Le moteur de jeu, il était ultra basique (pas de gestion des dégats par exemple, vu que j'avais pas fait d'attaques, c'était pas la peine), il marchait pas trop mal sur certains points, mais il n'était vraiment pas assez travaillé pour un truc fait en 1 semaine. De toutes façons tel quel, il est injouable.
Le moteur graphique j'en parle pas, j'avais juste fait des collages de carrés pour voir à peu près ce qui se passait.

M'enfin bon voilà quoi, si je peux bidouiller tout seul un machin qui ressemble à quelque chose en 1 mois, on peut bien faire à plusieurs un truc potable d'ici 1 ou 2 ans.


Si certains sont partants pour la première étape, j'expose les notions que j'ai déjà intégrées au langage de script pour les maps. Entre autres le système d'ancres qui est assez puissant et qui fait à lui seul tout l'intérêt de pouvoir scripter les maps, justement. Pour les personnages je pense que s'inspirer de MUGEN serait pas mal, je suis allé voir comment ils font mais on peut faire des trucs plus jolis je pense.

Pavay Caysar, désolé pour le texte brut mais je suis pas ergonome.
Des questions ?

En voilà un projet intéressant ! Bon étant débutant en programmation je pense que je me contenterais d'être spectateur, mais je me pose une question, qui est peut-être idiote mais bon, comment est-ce qu'on va suivre le projet ?

.

Ca a l'air sympa le côté SSB mais malheureusement, je ne vois pas comment je pourrais me rendre utile si je connais rien en informatique...
Par contre, si tu cherches des testeurs, je suis là
*part rejoindre Vink et Trinity dans le rang des spectateurs*

PS: Miam, un pavé

L'idée est fort bien sympathique. J'aimerai bien t'aider mais je débute en programmation (un an d'IUT Informatique et un semestre en L1 Informatique) donc j'irai avec les autres au rang spectateur. Bonne chance !

Merci pour le soutien.

Vink => pour suivre le projet, soit tu as accès au dépôt Git et tu as tout ce qui est fait sous tes yeux, soit je posterai des news, on verra. Ca dépend de qui fait quoi et qui a besoin de savoir quoi on va dire.

Trinity => Pour élaborer un langage de script, le minimum de connaissances dont tu parles c'est surtout de savoir comment il peut être traduit derrière et si c'est faisable par un ordinateur (y'a des langages qui ne le peuvent pas mais on va pas rentrer dans les détails). Ca je le sais, vous n'avez pas à vous en soucier. Si vraiment vous avez des doutes sur ce que vous pouvez apporter, contentez-vous de balancer des idées, comme tu le suggères.

Kero => Y'aura besoin de testeur oui. Si tu rapportes bien tous les bugs et trucs louches trouvés.

Ryu => C'est déjà pas mal, perso j'ai seulement appris sur le tas pendant 3 ans avant mon 1er semestre à EPITA donc bon ... après j'avoue qu'à EPITA on mange du C et du C++ tous les jours, le genre de projet qu'on a c'est recoder malloc/realloc/free (1 semaine), faire un shell (1 mois), un shmup (36h sans cours et sans dormir) et plein d'autres trucs, mais si tu t'y mets tu devrais pouvoir faire des choses assez bien.

Cela dépasse de loin mes propres compétences qui restent cantonné à GameMaker, RPGMaker et danmakufu ^^

Je te souhaites bonne chance et bon courage (t'auras besoin des deux :/)

Bien qu'ayant les compétences pour, je n'aurai jamais le temps pour t'aider à ça hélas x(

Well, je dis pas non pour aider un peu pendant des vacances, mais en dehors de ça, j'ai très peu de temps.
De plus, j'ai touché au C, Ptyhon, Java (j'aime pas le java ><), mais jamais au C++.
Je m'y mettrai quand j'aurai du temps et en restant en spectateur.
Si je comprends tout, que je m'en sors, j'aiderai au projet.

Nasty => t'as quand même le profil pour faire des scripts de bonne qualité, du coup. =D

Zef & Vivaldi => dommage, mais vous pouvez toujours changer d'avis.


Bon, demain je vous fait un pavé pour voir cette histoire de langage de script.

Perso j'aurais bien aimé tenter de faire quelque chose pour ce projet, surtout qu'apprendre à utiliser OpenGL est quelque chose qui m'intéresse grandement. Malheureusement j'ai déjà un projet en cours donc prendre celui-là en plus signifierait la mort de l'un des deux... Au pire si je trouve du temps après l'autre (qui risque de m'en prendre pas mal) et bien je me porterai volontaire pour filer un petit coup de main sachant que je suis très à l'aise en programmation de manière générale (surtout java) et que je connais les principe de base du C et suis très familier avec la POO, donc j'imagine que le C++, avec un petit tutoriel peut s'apprendre assez facilement.

Tu pourras toujours rejoindre plus tard quand il faudra toucher à OpenGL. Pour le moment c'est pas la priorité.


Bon, petit topo sur le système d'ancres pour les maps :

L'idée c'est de définir des points d'appuis (que j'appellerai "ancres") pour les les divers obstacles et plateformes, et de rattacher ces derniers sur plusieurs ancres selon l'endroit où on veut les mettre (par exemple un bloc se rattachera à 4 ancres). Les intérêts d'avoir ça au lieu de donner la position de chacun des obstacles sont les suivants :
On peut définir facilement quelles plateformes se rattachent entre elles, genre pour pouvoir marcher de l'une à l'autre, il suffit par exemple de rattacher le coin de droite de la plateforme de gauche sur une ancre, et le coin de gauche d'une autre plateforme sur cette même ancre. Si on ne le fait pas, ça veut dire qu'on peut soit tomber quand on passe entre les deux, soit avoir un glitch et "tomber" sur la plateforme d'en face depuis une hauteur nulle. Sans les ancres on aurait dû préciser quelle plateforme se trouve à côté, mais un oubli est si vite arrivé.
On peut faire bouger une ancre (avec des fonctions qui peuvent dépendre de plein de trucs), ça fera bouger toutes les plateformes associées. On peut même aller plus loin, pour ceux qui ont un peu de notions de physique, une ancre peut servir d'origine de repère pour les déplacements d'une autre. Ca permet de composer facilement certains mouvements, ou d'empaqueter plusieurs ancres sur une ancre maîtresse pour toutes les faire bouger de la même manière (utile pour faire bouger un ensemble entier de plateformes ou d'obstacles).
On peut aussi rattacher les décors. L'idée ici, c'est que si vous placez un obstacle, vous vous en foutez de son apparence, il peut tout aussi bien être invisible. Après il suffit de faire ce qu'on veut niveau apparence, sachant que le moteur de jeu est en 2D alors que les graphismes sont en 3D (oui oui).

Voilà. Pour faire bouger les ancres j'ai parlé de fonctions : il suffit d'en définir quelques unes (certaines seront prédéfinies bien sûr), elles prendront principalement en arguments des coordonnées, des flottants, des entiers, seules celles qui renvoient des coordonnées peuvent être affectées sur des ancres (qui donnent aussi leurs propres arguments à la fonction). Il y aura aussi des variables prédéfinies comme le nombre de frames passées, le nombre de personnages marchant sur certaines plateformes, l'ancienne position de certaines ancres, etc. Si besoin on verra pour stocker des variables internes à une ancre utilisables dans les fonctions, mais c'est plus chiant à faire pour peut-être pas grand chose.


Ensuite, au niveau des plateformes :
Outre le fait de pouvoir les rattacher à des ancres et de ne plus se soucier de comment elles bougent ni à quelles autres plateformes elles sont connectées, on peut définir certaines propriétés comme : "est-ce qu'on peut traverser d'un côté, de l'autre, d'aucun ou des deux ?", "est-ce qu'on peut marcher dessus ?", "est-ce qu'on peut s'accrocher sur un des bords ?"
Quoique pour le fait de pouvoir s'accrocher, je pencherais plutôt pour le mettre sur les ancres, à voir. C'est ce que j'ai fait sur mon prototype d'ailleurs.
Il faudrait aussi rajouter un moyen de créer ses propres obstacles (en particulier pour ceux qui peuvent faire des dégâts et qui ne le font pas de la même manière : dans les SSB y'a de l'acide, des pics, des Starwings, des crocos, des plantes carnivores ... sans faire des dégâts y'a aussi les tonneaux, les souffleries, les tuyaux, les tapis roulants ... bien qu'on puisse faire les deux derniers avec juste des plateformes classiques) j'ai pas trop d'idées là dessus, faudrait pouvoir interagir plus en profondeur avec les personnages. En tout cas tous ces trucs peuvent toujours se rattacher à des ancres et ça c'est cool.

Je crois qu'il n'y a pas grand chose d'autre au niveau des maps. Reste à savoir comment on écrit tout ça dans un script, y'a la partie "définitions" (fonctions, modèles d'obstacles, textures, couleurs), et la partie "déclarations" (ancres, attachements de plateforme, attachement de décor). On peut s'inspirer d'un langage existant s'il est adaptable. Mais avant faut se mettre d'accord sur les fonctionnalités, ce qu'on peut faire avec.

Vous pouvez dès à présent balancer vos suggestions.

Salut,

J'ai pas tout lu, mea culpa.

Mais juste à propos de certaines choses, étant étudiant en game design, et développeur de jeu, me retrouvant toujours à programmer, le C++ c'est sympa, ça te fera bosser tes cours. Mais ça te fera surtout galérer pour pas grand chose. Si tu veux rester dans du code pur et tout calibrer par toi même, pense plutôt à :

- C#, c'est vraiment axé pour les applications graphiques et jeux.

- Ajoute les librairies XNA pour que ce soit plus accessible et tranquille en C#, là pour le coup c'est vraiment fait pour le jeu, les boucles d'update / draw sont déjà implantées. Et tu pourras compiler pour xBox / PC / (Windows Phone même !§) directement.

- Dernière possibilité et sûrement la plus aisée, utiliser un moteur de jeu comme UDK / Cry Engine, ou le plus simple qui en plus est gratuit si tu ne prends pas la version pro (pas vraiment utile pour commencer), Unity 3D. Avec ça tu pourras faire travailler tout ceux qui ont des bases d'algo sur ton projet, et leur faire faire du tweaking facilement.

Juste quelques choses qui me sont venues à l'esprit en voyant ce post. Et si t'as besoin d'info supplémentaires, hésite pas à me contacter par MP.

See ya ~

ah ce genre de truc me tente bien...

sauf que voilà j'ai juste toucher a lunar magic, alors je suis débutant ou débutant

C# over .NET, tu as de grande chances de produire quelque chose de qualité.

Par contre il va te falloir BEAUCOUP de connaissances en génie logiciel. Si tu attends un peu (pour mes vacances en Février), je pourrai t'aider la dessus.

A propos de C# :
C'est un langage dont la philosophie est trop éloignée de l'environnement sur lequel je me suis posé. Outre le fait que ce soit orienté vers Microsoft (ce n'est pas mon but), je n'y ai jamais touché, et le C++ reste mon préféré (c'est pas une question de bosser les cours, j'étais déjà dessus avant). S'il fallait aller voir un autre langage, j'irais voir du côté de Haskell.
Ensuite, dire que C# est adapté pour tout ce qui est graphisme/jeux, j'y crois pas trop, même avec XNA. Tout dépend des capacités de chacun, de ce que l'on saît faire. D'un autre côté, si trop de monde se pointe en voulant faire du C# il faudra que je reconsidère la proposition, mais ça risque de me gêner fortement.

A propos des moteurs de jeu (ou de XNA) :
Je sais faire des jeux vidéos en C en partant de rien (juste une lib graphique bas niveau comme SDL ou SFML), pas besoin qu'on me colle un moteur de FPS déjà prêt sous le nez ou des boucles de jeu/draw que l'on peut de toutes façons écrire à la main en 5 minutes et sans perdre une miette de ce qui est réellement fait. Sans galérer.
Après j'dis pas que je peux faire mieux que ce que fait un moteur de jeu existant, mais c'est de l'artillerie lourde pour pas grand chose. Et puis, ce projet c'est un peu comme un moteur de jeu de combat, de quoi j'aurais l'air en faisant un wrapper vers un autre moteur de jeu ?

edit : Par contre pour les moteurs graphiques j'dis pas non, si on n'arrive à rien seuls. Mais là aussi c'est de l'artillerie lourde. De toutes façons c'est pas pour maintenant.

Je comprends ton ressenti vis à vis des frameworks de moteur de jeu. Je préfère en général partir from scratch lorsque le temps n'est pas limité, là il ne l'est pas tu peux donc te permettre de faire ce que tu veux. C'était surtout pour t'ouvrir des pistes "au cas où".

Développer un jeu c'est beaucoup de temps de travail, et on peut être démotivé face à la tâche au bout d'un certain, il est toujours bon de savoir se tourner vers les choses déjà existantes plutôt que de kill un projet.

Je te souhaite dans tous les cas bon courage.

Le projet me tente beaucoup, mais j'ai peur d'être loin du niveau requis pour suivre.
Mais quelque part, ça me motive vachement de participer a un Touhou-fangame, et si en plus c'est SSB tu peux compter sur mon aide, même si faible...

Je suis tout particulièrement intéressé par ton idée de script simple a interpréter et simple a écrire =)

En tout cas, ça m’intéresse comme projet, au moins l'option "être spectateur" annoncée dans ton premier post =)

(Au fait, tu es à EPITA... Promo? :D Je suis un petit 2016 moi)

J'aimerais bien participer mais... je serais d'aucune utilité

Neige => Je retiens quand meme l'idee d'un moteur graphique, vu que c'est assez adapte, mais je tiens vraiment a faire le moteur de jeu from scratch sachant qu'il n'est pas si difficile que ca et qu'il faut que je puisse bidouiller dedans en profondeur pour s'accorder avec les scripts.

Goombi => Je suis en promo 2014 (Ing1 donc). En ce moment je suis au KB, a l'under, en SM2. En train de bosser sur Corewar.
Sinon je te donne mon login, si un jour tu veux me trouver : thomas_z.
Mais en promo 2016, tu es toujours a villejuif non ?