Posté le 04/04/2021 20:53
Le jeu serait développé sur Graph 90+E pour plus de facilités, et avec gint, pour avoir un jeu fluide. Le gameplay consisterait à se bourrer de coups pour augmenter la jauge de dégâts de ses adversaires. Une jauge de dégâts élevée propulse les adversaires plus loin. Pour gagner, vous éjectez tous vos adversaires en dehors de l'écran. Le casting serait composé de personnages issus de jeux plus ou moins emblématiques de Planète Casio, idem pour les arènes. Multijoueur local ? Si oui, comment on le gère ? Câble 3-pin ou bien deux joueurs sur le même clavier ? Combien de touches, quels types d'attaques ? Shift > Attaque normale, Alpha > Attaque spéciale. La touche de saut intégrée au pavé directionnel ou sur une touche à part ? Comment on gère les attaques spéciales spécifiques aux personnages ? Comment on programme tout ce bordel ? Les difficultés techniques ?
). Comment éviter de tomber dans un projet-type Odyssée et de sombrer petit à petit ?
Planète Casio v4.3 © créé par Neuronix et Muelsaco 2004 - 2024 | Il y a 88 connectés | Nous contacter | Qui sommes-nous ? | Licences et remerciements
Planète Casio est un site communautaire non affilié à Casio. Toute reproduction de Planète Casio, même partielle, est interdite.
Les programmes et autres publications présentes sur Planète Casio restent la propriété de leurs auteurs et peuvent être soumis à des licences ou copyrights.
CASIO est une marque déposée par CASIO Computer Co., Ltd
Citer : Posté le 04/04/2021 22:44 | #
Pour ce qui est du technique, voilà une première analyse.
• Le multi sur un seul clavier c'est vaguement jouable, la contrainte étant (mais c'est aussi valable pour un seul joueur) qu'il ne faut pas utiliser quatres touches en rectangle (ie. deux paires se partageant chacune une ligne, et les deux autres combinaisons de paires sur partageant chacune une colonne). Ça limite un peu les options. C'est à cause de problèmes de ghosting (par exemple 2 touches de REPLAY + SHIFT activent ALPHA donc on ne peut pas donner un rôle aux 4 touches à la fois). Notez par exemple que si on utilise tout REPLAY alors on n'a droit qu'à 4 touches parmi les 8 qui sont à côté, et il ne faut surtout pas toucher aux touches non utilisées (puisque 2 touches de REPLAY + ALPHA activent SHIFT).
• Le multijoueur sur 2 caltos c'est faisable via la liaison série, ce n'est pas encore implémenté dans gint mais ce n'est pas trop un problème. Le plus dur c'est d'avoir 2 Graph 90+E pour tester...
• Pas de difficultés techniques particulières à prévoir, la latence ne posera pas de problème, les perfs graphiques ne devraient pas gêner non plus pourvu que ça soit pas codé avec les pieds.
Honnêtement ce jeu pourrait être une super collab' de la communauté, l'idée est tellement parfaite !
Citer : Posté le 04/04/2021 23:04 | #
hype hype hype
Multijoueur local ? Si oui, comment on le gère ? Câble 3-pin ou bien deux joueurs sur le même clavier ?
Je dirais les deux, si le multijoueur est bien pensé c'est faisable.
Combien de touches, quels types d'attaques ? Shift > Attaque normale, Alpha > Attaque spéciale. La touche de saut intégrée au pavé directionnel ou sur une touche à part ?
Je pense que trois ou quatres attaques est le grand maximum, mais pour la santé mentale des développeurs et l'ampleur du projet je pense qu'il serait mieux de commencer avec seulement deux types d'attaques et développer vers trois ou quatre dans le futur si ce n'est pas suffisant. Quand à la disposition, je pense qu'il serait important de proposer de remapper les touches et donner des options par joueur.
Les difficultés techniques ?
Comme l'a dit Lephé, trouver plusieurs caltos pour tester le multi.
Comment on gère les attaques spéciales spécifiques aux personnages ? Comment on programme tout ce bordel ?
J'ai pensé à une structure, et vous pourrez me corriger je suis un peu paumé en C !
Les données de chaque personnage seraient gardées dans une structure. Celle-ci serait commune entre tous, pour optimiser la réutilisation du code. Cette structure serait composée de plusieurs valeurs communes (pourcentage, position, vélocité, etc.) et d'une union : cette union tiendrait plusieurs structures, appartenant au personnage. Les personnages seront identifiés avec un enum et les logiques sélectionnées avec des switch (c'est plus propre que ça en a l'air). Je ne pense pas avoir été très clair, mais quelqu'un répondra sûrement avec une meilleur solution de toute manière
L'idéal serait aussi d'avoir un support du modding à la fin.
Ça risque d'être chaud, mais pourquoi pas en ajouter un après la sortie. Il faudra que tu définisses « modding », si ça touche les stages par exemple ce sera plus simple que les personnages (éditeur de niveau on-calc, mmm).
Le plus dur c'est d'avoir 2 Graph 90+E pour tester...
Je n'ai pas tant d'argent que ça, mais si besoin je peux en acheter une ou deux et vous les prêter en siphonant mes fonds.
J'ai plein de trucs à ajouter, mais je pense que ça irait plus vite avec une réunion audio. À la manière de celle faite pour Odyssée, mais avec moins de monde et un plan plus strict.
hype hype hype
Citer : Posté le 04/04/2021 23:11 | #
Les données de chaque personnage seraient gardées dans une structure. Celle-ci serait commune entre tous, pour optimiser la réutilisation du code. Cette structure serait composée de plusieurs valeurs communes (pourcentage, position, vélocité, etc.) et d'une union : cette union tiendrait plusieurs structures, appartenant au personnage. Les personnages seront identifiés avec un enum et les logiques sélectionnées avec des switch (c'est plus propre que ça en a l'air).
C'est une option, mais à mon humble avis le plus propre serait d'avoir à la place de l'union un ensemble de fonctions qui implémentent le mouvement et les attaques du personnage. Vu l'énorme variété dans Smash je pense qu'il y aurait pas mal de code pour gérer la physique et tout le bordel autour donc je serais tenté de séparer les personnages avec différentes fonctions plutôt que d'avoir un if/else massif qui traite les cas de l'union.
Pour les données à proprement parler, il suffit de mettre un pointeur et chaque personnage pourra allouer la mémoire qu'il lui faut. Globalement on s'en fout parce qu'il n'y a que 2 personnages dans la partie, on a donc la latitude d'implémenter ce qu'on veut même si ça coûte un malloc() ou un autre petit coût du genre.
Les réunions audio ont le défaut de laisser peu de traces, moi j'aimerais bien avoir plus d'avis sur ce topic x3
Ajouté le 04/04/2021 à 23:19 :
Autre idée en vrac, pour tester le multijoueur client/serveur sans avoir deux calculatrices, on peut essayer d'utiliser un PC comme second clavier, ce qui devrait pas être trop compliqué, ou carrément de lancer une copie du jeu sur le PC (mais ça c'est carrément expérimental).
Citer : Posté le 04/04/2021 23:25 | #
C'est une option, mais à mon humble avis le plus propre serait d'avoir à la place de l'union un ensemble de fonctions qui implémentent le mouvement et les attaques du personnage. Vu l'énorme variété dans Smash je pense qu'il y aurait pas mal de code pour gérer la physique et tout le bordel autour donc je serais tenté de séparer les personnages avec différentes fonctions plutôt que d'avoir un if/else massif qui traite les cas de l'union.
Pour les données à proprement parler, il suffit de mettre un pointeur et chaque personnage pourra allouer la mémoire qu'il lui faut. Globalement on s'en fout parce qu'il n'y a que 2 personnages dans la partie, on a donc la latitude d'implémenter ce qu'on veut même si ça coûte un malloc() ou un autre petit coût du genre.
C'est à peu près ce que j'avais pensé, mais tu l'as mieux pensé et expliqué.
Je ne vois pas le rapport entre l'union et les fonctions cela dit, dans mon idée l'union ne serait utilisé que pour les variables spécifiques au personnage. Je pensais qu'il n'y aura sûrement qu'une dizaine de valeurs max et que ça ne coûterait rien à le mettre sur le stack.
Le code des joueurs serait évidement découpé en fonctions, avec des parties réutilisées. Comme je l'ai dit, la partie de l'union serait spécifique aux personnage. Je ne suis pas très précis, surtout pour formuler ce genre d'idées désolé x(
Les réunions audio ont le défaut de laisser peu de traces, moi j'aimerais bien avoir plus d'avis sur ce topic x3
Les réunions trimestrielles sont pourtant productives, faudrait prendre des notes mais je pense que ça aiderait
Citer : Posté le 05/04/2021 00:02 | #
Sympa comme idée, si ça peut voir le jour ce serait vraiment chouette
Quelques commentaires en vrac :
+1 pour le ghosting. Faut *vraiment* faire attention à ça, typiquement sur le proto de Touhou, j'avais justement choisi Replay + Shift + F1 + F2 pour ne pas être sujet à ça. C'est pas forcément le plus pratique pour jouer, mais c'est définitivement mieux que déclencher l'attaque 2 parce qu'on a lancé l'attaque 1 pendant un déplacement sur deux axes.
Pour ce qui est du multi sur une même calto, faut s'accrocher. L'écran est déjà pas grand, le clavier encore moins, et avec les problèmes de ghosting trouver des touches qui ne provoqueraient pas de bugs relève du miracle. Pour ma part, je pense que c'est beaucoup d'efforts pour quelque chose d'inutilisable en pratique.
Les difficultés techniques que je vois : aucune.
La principale difficulté : faire une gestion de projet qui remplit au moins ces critères :
– correctement organiser les tâches (ne pas mettre la charrue avant les bœufs)
– arriver à ce que chacun⋅e se sente à l'aise pour contribuer
– poser des objectifs SMART, et les tenir
En ce qui concerne les problèmes techniques, je ne me fais aucun soucis. Si les briques techniques sont correctement définies et découpées, le reste roulera tout seul. Je pense que le SRP est particulièrement adapté dans ce cas, puisque chaque brique développée par quelqu'un d'autre pourra être faite de manière assez indépendante du reste.
Typiquement le cas du test des communications 3-pins peut être fait entre une G90+E et ce qu'on veut (autre G90, une G35+EII, une Arduino, whatever). Ensuite c'est par dessus qu'on ajoute un niveau d’abstraction, qui permet de gérer une session de jeu, et par dessus une autre couche gère les données de jeu. Reste finalement que l'intégration de tous les composants qui nécessite éventuellement deux G90+E, mais toutes les étapes d'avant peuvent être faites individuellement, via de la dummy data.
Ce qui me permet de faire la transition avec des bonnes pratiques dans ce genre de projets, ie tests unitaires et tests d'intégration. C'est pas forcément évident à mettre en place, mais ça peut permettre de ne pas tout casser dès que les choses se complexifieront. À voir…
Dans tous les cas, voir simple puis si tout va bien complexifier est définitivement la meilleure des options.
Citer : Posté le 05/04/2021 00:03 | #
Bon, je ne peux pas donner un avis très technique sur le problème. Je vais me contenter de donner mon point de vue à l'approche des fonctionnalités.
Le multijoueur local est un nécessaire pour tout jeu smash. N'y aurait-il pas une trop grosse latence entre les deux calculatrice ? Le problème d'un jeu de combat est sa vitesse. Il faut qu'il soit très fluide et surtout très réactif. Si le câble 3-pin rend le jeu lent, ça risque d'être vite problématique.
Sur le même clavier ça risque d'être compliqué. D'autant plus sur le plan technique (cf lephenixnoir plus haut) que sur le plan physique
Les smashs sont réputés pour être compliqués à prendre en main à cause des touches. Pour avoir un peu de stratégie dans le jeu, 2 actions sont nécessaires. (bouclier + attaque en fonction des déplacements). Rajouter une action spéciale propre à chaque personnage permettrait de rajouter du fun dans le jeu mais n'est pas nécessaire à son fonctionnement.
Alors ça, je laisse lephenixnoir faire de la magie noire en C.
La nécessité de faire un code propre afin de ne pas se prendre la tête pour rajouter des actions. Un mode solo avec """IA""" avec plusieurs niveaux serait incroyable.
Vu la motivation de lephé et son niveau en C, je ne vois pas de problème auxquels il ne pourra pas faire face.
Honnêtement, après y avoir réfléchi avec mon moi intérieur, je pense que ce projet est largement faisable. Permettant de réunir une équipe motivée et surtout communautaire. Ne laissons pas ce projet tomber dans l'oubli ! Nous en avons besoin !
Les réunions audio ont le défaut de laisser peu de traces, moi j'aimerais bien avoir plus d'avis sur ce topic x3
Les réunions audio permettent de mettre au point rapidement et sans effort l'état du projet. La prise de note ce n'est pas un problème, ça fait un an qu'on fait des visios (un mal pour un bien...)
En tout cas, les screens donnent envie ! Maintenant il faut le jeu derrière
(Et de toute façon, vous pouvez pas dire le contraire)
MultipliCasio
RDM Calculs
Back Mirror
A Switch To The Top C
Citer : Posté le 05/04/2021 00:17 | #
J'en profite pour vous rappeler l'existence de cet excellent topic de Louloux, sur comment faire un bon prototypage par itération.
C'est tiré de son expérience dans un studio de jeu vidéo, je recommande particulièrement
Citer : Posté le 05/04/2021 00:54 | #
Les smashs sont réputés pour être compliqués à prendre en main à cause des touches. Pour avoir un peu de stratégie dans le jeu, 2 actions sont nécessaires. (bouclier + attaque en fonction des déplacements). Rajouter une action spéciale propre à chaque personnage permettrait de rajouter du fun dans le jeu mais n'est pas nécessaire à son fonctionnement.
Les Smash sont connus pour être très accessibles et complexes à la fois. J'ai déjà joué à Ultimate avec des enfants, pour que le jeu soit intéressant pour le public cible (qui a probablement entre 13 et 18 ans) et qui a probablement déjà joué à Smash, je ne pense pas qu'il soit nécessaire de réduire les contrôles.
Niveau game design, je trouve que Rivals of Aether est une meilleure source d'inspiration que Smash, surtout au niveau du gameplay. Je préfère très largement le système de contre et d'esquive de RoA au bouclier des Smash par exemple. Je pourrais donner plein d'arguments, mais je suis crevé et vais résumer comme cela : contre/esquive crée un gameplay rapide et dynamique, le bouclier est statique et lent. Bref, ça vaudrait peut-être le coup pour les designers de jouer à Rivals of Aether, Super Smash Flash 2 et autres jeux indés.
Si on commence à se partager des liens, voici une collection de tweets sur le game design de Dan Fornace, le concepteur de RoA.
https://twitter.com/i/events/1354550890946940929
J'ai pas grand chose d'autre à ajouter pour le moment, bonne soir- matinée.
Citer : Posté le 05/04/2021 08:33 | #
Le multijoueur local est un nécessaire pour tout jeu smash. N'y aurait-il pas une trop grosse latence entre les deux calculatrice ? Le problème d'un jeu de combat est sa vitesse. Il faut qu'il soit très fluide et surtout très réactif. Si le câble 3-pin rend le jeu lent, ça risque d'être vite problématique.
Une latence entre deux calculatrices connectées par un câble de 20 centimètres, entre lesquelles on envoie 4 octets quand le client presse ou relâche une touche ? Tu plaisantes, c'est l'affaire de moins d'1 ms. Envoyer les données dans l'autre sens demanderait un peu plus de finesse mais au pire cas on peut simplement filer les touches de l'hôte au client et le client fait le calcul du jeu aussi de son côté.
Non dans la boucle de feedback entre le signal électrique dans ton cerveau pour appuyer sur une touche, et le signal que tu as quand tu perçois à l'écran le résultat de cette action, le problème c'est plus l'envoi à l'écran. Pour l'instant l'ordre d'idée minimal pour afficher un frame c'est 11 ms, donc c'est là que se situeraient les problèmes les plus limitants a priori.
Citer : Posté le 05/04/2021 08:34 | #
> Multijoueur local ? Si oui, comment on le gère ? Câble 3-pin ou bien deux joueurs sur le même clavier ?
Vu que ya la feature USB qui arrive sur GINT, on peut faire un mode "semi local", qui utiliserait le PC comme serveur, et cela permetterait a faire un smash avec ses amis en local, et avec d'autres amis en ligne.
Citer : Posté le 05/04/2021 08:35 | #
... malin ! C'est vrai en principe, mais par contre là tu as droit pour de vrai à la latence du réseau.
Citer : Posté le 05/04/2021 08:42 | #
Et puis avec mes connaisances en Java, la partie serveur local(sans le réseau) sera facilement possible(si j'arrive a communiquer par USB aux calculatrices)
Citer : Posté le 05/04/2021 10:04 | #
Je suis chaud pour participer au développement du jeu.
Il n’y a pas 40 solutions pour le multi, le câble 3-pins me semble primordial et le multi sur une seule calto me semblent complexes, non pas techniquement, mais pour la gestion des contrôles avec le ghosting.
À moins de faire une version monochrome au passage, comme ça on peut tester sans trop de problèmes, car pas mal de personnes disposent d'une calto monochrome et une calto couleur. Mais il nous faut une sprite sheet mono du coup.
J'ai récemment fait un prototype de loader de libraires dynamiques sur calto. Je pense qu'on pourra aller investiguer à ce niveau-là pour la gestion des mods, je ne pense pas que ce sois trop complexe à implémenter (mais assez technique cela dit). Par contre, qu'est-ce que tu entends par "modding" ? tu penses à quoi ?
Il nous faut une sprites sheet.
À part ça aucune, mais sans vouloir être pessimiste, le projet ne verra probablement jamais le jour, car la hype du projet va se dissiper d'ici deux semaines et on aura tout juste fini de poser les objectifs SMART ou tout autre technique d'organisation marketing théorique qui mette 60000 ans à être appliqué et qui décourage 90% des effectifs, donc bon, dommage quoi.
Le seul pseudo-moyen de garder la flamme du projet serait de commencer, dans la minute suivant mon post, à pondre un proto aussi vide soit-il pour poser le début de l'architecture. Mais du coup, ça mettra implicitement en place une organisation de ce style: une personne qui fait tout (archi + dev), un assistant dev, un graphiste, quelqu'un qui s'occupe d'écrire la documentation....bref [url= https://en.wikipedia.org/wiki/Chief_programmer_team]l'organisation de Harlan Mills[/url] en sommes. Après ça, si la hype est toujours présente, on commencera à poser sur papier les spécifications, les objectifs, etc, etc, ... Mais si on part sur des débats qui n'en finiront pas comme on est en train de faire, on n'aura pas l'ombre d'un proto avant longtemps.
Citer : Posté le 05/04/2021 10:11 | #
Ou on pourrait faire un interpreteur, mais au cout de la vitesse.
Citer : Posté le 05/04/2021 10:14 | #
Je suis d'accord avec Yatis, juste pas aussi pessimiste. Je pense pas qu'il s'agisse de modder du code à la façon lib dynamique ; en tous cas un plan raisonnable évitera toujours les trucs trop expérimentaux.
Citer : Posté le 05/04/2021 13:00 | #
Que c’est beau !
Plus sérieusement, ça me hiperait pas mal de faire partie de ce projet.
Masséna, as tu les sprites utilisés pour les artworks ?
Sinon je peux essayer de les recréer (?)
Je peux essayer de commencer avec cela ...
Citer : Posté le 05/04/2021 13:32 | # |
Fichier joint
À l'heure actuelle, je ne pense pas que les graphismes soient la principale préoccupation.
En pièce jointe, une archive contenant les calques des screens 2 et 3 exportés en PNG, et les fichiers aseprite des trois images.
Citer : Posté le 05/04/2021 14:46 | #
Merci, je vais essayer de faire un truc...
Citer : Posté le 05/04/2021 16:07 | #
À voir, ça ne me derange pas d'etre le lead dev mais il me faut les sprites pour avoir un proto un minimum "visuel".
À l'heure actuelle, je ne pense pas que les graphismes soient la principale préoccupation.
Quitte à radoter, je vous conseille vivement d'aller lire l'article de Louloux sur le prototypage : Prototyper : la qualité par l'itération.
Alors mettons tout de suite les choses au point : je ne suis pas là pour critiquer, ou imposer une méthode, mais pour donner des conseils pour faire des meilleurs jeux en moins de temps. Cette méthodologie devient absolument nécessaire lorsqu'on travaille en équipe, puisqu'à ce moment un développement linéaire mené par la vision d'une seule personne devient impossible.
Citer : Posté le 01/04/2023 10:37 | #
J'ai décidé de reprendre le développement du jeu en intégrant des personnages plus récents comme Link de Zelda TOTK.
Rien de special à montrer pour l'instant, juste faites moi confiance pour mener à bien ce projet
On l'aura un jour ce PC Brawl !
(Et de toute façon, vous pouvez pas dire le contraire)
MultipliCasio
RDM Calculs
Back Mirror
A Switch To The Top C