Aventura, le Royaume Poudingue... Un long projet !
Posté le 06/07/2016 23:44
Aventura, Le Royaume Poudingue est un RPG en Basic Casio (monochrome) entamé en 2016 et repris en 2018. Projet très ambitieux, ce dernier tend à s'emparer des meilleures techniques de Basic Casio pour offrir une expérience de jeu dépassant les attentes du joueur. Il aura fallu deux années complètes pour que la première version complète du jeu sorte enfin ! Ouf !
Le jeu est enfin disponible ! Cliquez ici !
Le projet en 2016
Cliquer pour enrouler
[...]
En réalité, je projette de concevoir un RPG en recommençant absolument tout de zéro. En errant sur ce forum, j'ai amassé une quantité satisfaisante de savoirs nouveaux en ce qui concerne le basic ! Toutes les techniques et les jeux que j'ai entraperçu ou étudié sur ce forum ont fait germer tout un tas de petites idées en moi !
Je vous expose le plan : l'idée n'est qu'à l'état embryonnaire, mais je compte la faire évoluer par débats et expositions d'idées. Pour l'histoire, le scénario, je n'ai pas de problème. J'ai l'imagination qu'il faut pour pondre des trucs farfelus. Ce dont j'ai besoin, c'est d'approfondir le système du jeu et tenter de construire un programme cohérent, très optimisé et performant. Procédons à tout cela par étape, je relèverai chacune de mes interrogations par la suite.
La map : Résolu
Cliquer pour enrouler
C'est ce qui me fait me poser le plus de questions. Voici ce que j'ai décidé : sur une picture sera enregistrée une sidebar qui sera visible pareillement sur le mapmonde et en combat. J'ai pour ambition d'adopter un système de tiles pour générer les maps (qui seront statiques, comme le fameux Zelda PC de Remiweb, et pas de map scrolling). Pour commencer, je projette de concevoir un système de sauvegarde provisoire des maps. Voici un schéma pourri fait à l'arrache :
Lorsque le joueur est sur la map 1, le décor de cette map est enregistrée en picture 1 (par exemple). Arrivé sur la map 2, celle-ci est enregistrée en picture 2. Sur la map 3, elle est enregistrée en picture 3. Lorsque le joueur veut retourner sur la map 2, la picture 2 est directement affichée plutôt que de la redessiner. En passant sur la map 4, la map 1 sur la picture 1 est effacée pour laisser place à la map 4. Ainsi, le personnage peut se ballader entre les map 2, 3 et 4 sans temps de chargement !
Résolu
Cliquer pour enrouler
je vais rencontrer de nombreuses problématiques concernant le dessin d'une map. Pour une map, je vais rentrer dans une matrice les ID de chaque case. Admettons que j'ai un programme "lecteur de matrice" qui dessine chaque case en fonction de l'ID. Il est évident que je vais essayer de dessiner d'une traite tous les tiles identiques avant de passer aux tiles suivants, plutôt que de faire :
For 1→A To 6
For 1→B To 11
Mat A[A;B]=1⇒{1,2,3→List 1
etc.
Next
Next
Drawstat
C'est-à-dire lire chaque case, une à une, même si elle est vide, pour dessiner une tile. après avoir entré dans la liste les coordonnées. Bref. C'est long, sale et un peu bulldozer.
Un génie de Naheulbeuk a écrit :
Baston !
J'avais prévu de faire entrer toutes les données chiffrées dans une chaîne (Str 1) plutôt que dans une matrice(qui est d'ailleurs lourde) pour pouvoir exploiter les fonctions StrSrch, StrMid, etc. Il est tout à fait possible de passer d'une chaîne à une expression numérique, donc ce point ne pose pas problème. Qu'en pensez-vous ? L'idée peut-elle être exploitée ou est-elle incohérente ?
Résolu
Cliquer pour enrouler
Je cherche le bonne taille de tiles à prendre. J'avais pensé à utiliser des tiles de 10*10. Chacune de mes maps feraient alors 6*11 cases. Y a-t-il une taille préférable à 10*10 ? Qu'en pensez-vous ? Je ne sais quoi en penser. Je vais rencontrer un autre problème : le stockage de données. Avec les listes, je me demandais si une seule liste avec des coordonnées complexes est plus légère que deux listes pour les abscisses et ordonnées séparées. La différence est-elle notable ? Si oui, ça m'arrangerait bien pour ce que je pensais faire :
Il serait possible que j'exploite la technique Augment( pour dessiner tout d'une traite avec le Graph(X ; Y)=. Cette technique étant très gourmande en mémoire sur l'instant, je pourrais effectuer l'opération plusieurs fois. Mais ça serait assez confortable de pouvoir mettre :
Dim List 1→Tθmax
Graph(X;Y)=(ReP List 1[T];ImP List 1[T
J'aimerais votre avis là-dessus !
Alors là, j'ai pas mal réfléchi. Sur le modèle de fonctionnement Poule/Renard/Épervier, ou Feu/Eau/Plante dans Pokémon, j'ai l'intention de créer trois types d'attaque :
Puissance ,
Dextérité et
Vitesse.
Le personnage aura trois attaques pour chacun de ces types. Donc une animation différente pour chacun d'entre elle. Il maîtrisera en plus une capacité de soin, et peut-être une capacité secrète.
Il n'y aura pas de niveau à proprement dire : Selon les attaques qu'on emploie, la maîtrise dans la branche correspondante augmente et améliore les capacités du personnage : Force, Défense, Nombre de coups, précision, Esquive, etc.
Bon. Le souci, c'est que je vais devoir à dessiner des monstres et risque d'être limité sur ce point là.
Le personnage est en fait personnalisable. Au début du jeu, vous pourrez choisir une arme et une coiffe (lunettes de soleil, chapeau en pointe...) La machine génère alors sur plusieurs listes trois positions du personnage : une statique, une en tenant l'arme en l'air, une troisième en donnant le coup. Pour cela, je fais tourner l'arme, comme je l'ai évoqué dans ce
topic. ce point précis est résolu. C'est grâce à ses trois dessins pré-enregistrés que je ferai les animations. Une question se pose : comment faire des animations pour les monstres potables et peu spacio-phages ?
Voici à quoi ils ressemblent !
(photos expirées)
Pour le menu :
Pas encore d'idée, si ce n'est un truc enregistré sur une autre picture qui sera beau graphiquement parlant. On y verra l'état du personnage et son niveau de maîtrise dans chaque branche.
Pour l'interaction avec des pnj :
Résolu
Cliquer pour enrouler
Je projette de concevoir un sous-programme "lecteur de texte", si je puis dire. Sur la map, le programme dessinera une boîte de dialogue dans laquelle s'écriront les paroles d personnage. Pour ce point, je compte beaucoup m'inspirer des travaux de Remiweb sur son Zelda PC. J'ai trouvé ce point absolument remarquable et incroyablement bien fait.
Voici la tronche du projet. J'aimerais vraiment avoir vos avis, savoir ce que vous en pensez, avoir de vos précieux conseils et surtout engager le débat pour progresser. Je vous remercie d'avance, et vous remercie aussi de m'avoir lu jusque là.
État des lieux du projet
modifié le 20 09 2018
À ce jour, voici ce qui est fait et ce qui reste à faire pour l'ensemble du programme de jeu.
Graphismes (personnages, monstres, background, carte du monde, title screen...)
Comme vous pouvez le voir, il reste beaucoup de travail.
Le plus difficile sera de faire tenir tout le jeu en ~ 60 000 octets. Seulement, je ne parle pas du programme seul : à présent, il ne fait que 6772 octets. Toutefois, les Pictures prennent déjà 11404 octets (avec y compris les 6072 octets des trois pictures du mon système de sauvegarde de map, et les list peuvent atteindre les 7000 octets. Actuellement, il me reste quelque chose comme 36 000 octets de libres pour faire TOUT LE RESTE.
Le jeu en quelques questions
modifié le 08 06 2018
Que sont les Poudingues ?
Les poudingues sont des petites créatures sans bras ni jambe, au corps semblable à un mélange entre une balle d'arme à feu et un pudding. Leur visage est expressif et ils déterminent généralement leur appartenance sociale par leur couvre-chef.
Quel est le but du jeu ?
Vous incarnez un de ces fameux Poudingues, vivant au sein d'un royaume dirigé par un monarque Poudingue. En tant qu'Explorateur, vous êtes convoqué par le roi lui-même pour vous confier une mission : localiser le repaire des poudingues anti-royalistes qui semblent préparer une révolte dans l'ombre...
Quel type de jeu ?
Aventura, le royaume poudingue est un RPG / jeu d'exploration. Vous devrez, pour une partie du jeu, explorer des terrains, trouver les pnj à qui parler pour faire avancer l'histoire, etc. Durant le jeu, vous devrez aussi affronter les monstres sauvages ou bien les opposants qui se dresseront sur votre chemin ! Au fil des luttes, vous affinerez votre style de combat, renforcerez vos spécialités et augmenterez votre niveau et vos caractéristiques.
Quelles caractéristiques et quel système de combat ?
Le système de combat est à priori un système au tour à tour, en un contre un de profil sur l'écran.
Un poudingue possède trois caractéristiques, avec un niveau de maîtrise pour chacune d'entre elle : Puissance, Technique, Vitesse. En fonction des attaques employées par le poudingue, ses niveaux de maîtrise correspondant augmentent. Lors d'une montée de niveau, chaque caractéristique augmente proportionnellement à son niveau de maîtrise. Utilisez beaucoup de fois l'attaque « Cogne » et votre puissance avancera davantage ! Votre type est ensuite déterminé par la valeur la plus élevée des trois caractéristiques : type Puissance, type Technique, type Vitesse, ou bien Neutre si vos caractéristiques sont équilibrées.
Ces trois types fonctionnent selon une règle similaire au jeu Pierre-Feuille-Ciseaux. Le type Puissance a l'avantage face au type Vitesse, le type Vitesse a l'ascendant sur le type Technique et le type Technique est plus efficace contre le type Puissance. Ce rapport de force se détermine dans le calcul des dégâts infligés, qui sont en pourcentage. Autrement dit, le joueur a 100% de vitalité et meurt s'il tombe à 0%. Le nombre maximal de vitalité ne change pas, il est de 100% pour tout le monde.
À priori, le niveau maximal atteignable serait de 100. Le système de calcul d'expérience n'est pas encore établi.
Les trois caractéristiques interviennent donc dans le calcul des dégâts en fonction du type de l'attaque. La caractéristique du lanceur correspondant au type de l'attaque et la caractéristique de la cible correspondant au type ayant l'ascendant sur celui de l'attaque sont pris en compte dans le calcul des dommages. Exemple : le joueur utilise une attaque Vitesse sur une cible de type Technique. La caractéristique Vitesse du joueur et la caractéristique Puissance de la cible seront pris en compte. Un facteur de dégâts accru s'appliquera sur les dommages totaux puisque le type Technique est faible face aux attaques Vitesse. Au final, si le lanceur a beaucoup de Vitesse et la cible peu de Puissance, l'attaque infligera de lourds dégâts.
Les niveaux de maîtrise augmentent aussi l'efficacité des attaques suivantes : Cogne, Estoc, Rafale. À partir de certains seuil, les niveaux de maîtrise donnent de nouveaux effets / bonus à ces attaques. Il peut donc sembler intéressant de se spécialiser dans un type pour améliorer ses attaques.
Les sorts, quant à eux, n'augmentent pas les niveaux de maîtrise lors de leur utilisation. Si un sort peut s'avérer plus efficace qu'une attaque classique, il ne permettra pas à son utilisateur de bien progresser sur le long terme.
Un aperçu du moteur de combat, le 09 07 2018 (V - 0.21)
Un aperçu du moteur de dialogue, le 21 07 2018 (V - 0.22)
L'Éditeur de mappemonde, 08/2018.
Un autre aperçu du moteur de combat, le 08 08 2018 (V - 0.24)
Phase 1 : Écriture. Cette étape consiste à coucher sur le papier ce que je projette de faire, le gameplay et les composants du jeu, dans un idéal. Je ne m'occupe pas tant de savoir si ça tiendra dans le code, ni de savoir si j'aurais le temps et/ou la motivation d'en faire autant. J'essaye d'en écrire le plus possible, dont le scénario avec le plus de détails possible, les personnages, etc.
Phase 2 : Architecture générale. Il s'agit de hiérarchiser les sous-programmes, menus, et les chemins qui s'opèrent entre chaque. Dans cette partie, on ne s'occupe pas du code dans les détails, mais plutôt de « blocs » en tant qu'ensembles de fonctions. Par exemple, j'aurai un bloc « Title screen », un bloc « dessin map », un bloc « dialogue », etc. Il s'agira de définir avec une certaine précision les blocs qui interviendront pour le fonctionnement du jeu, d'estimer si possible leur taille et de les positionner les uns par rapport aux autres, les cheminements de sous-programmes à sous-programmes – sachant qu'on ne peut pas avoir plus de 10 sous-programmes qui tournent à la fois.
Phase 3 : Code. Écriture du code à l'intérieur de chaque bloc, avec seulement quelques données à titre d'exemple. Il ne s'agira pas de faire du bô graphisme ou bien pleins de sprites et de pictures différentes. L'objectif ici est de fabriquer rapidement quelques éléments de dialogue et de graphisme pour pouvoir écrire tout le code qui fera fonctionner le jeu et qui agira comme un squelette. De beaux graphismes sont inutiles si le code sous-jacent n'est pas fonctionnel. J'ai eu tort de commencer à faire des maps et des pictures, mais elles sont là et je ne vais pas les gâcher.
Il me faudra alors écrire de façon individuelle et séparée chaque « bloc » ou « fonction » pour m'assurer que leur fonctionnement propre est opérationnel. C'est aussi l'occasion de revoir certaines ambitions à la baisse si elles demandent trop de place dans le code. Cette partie ne constitue pas l'intégralité de l'écriture du code, loin de là. La phase 4 y occupera une place importante aussi.
Phase 4 : Mise en relation et assemblage des blocs. Cette partie sera délicate, mais aura été largement anticipée avec la phase 2. Il s'agit non plus de faire fonctionner des pièces détachées, mais de les assembler et de penser avec ingéniosité leur articulation pour que le jeu devienne une seule entité. Cette phase comprendra vraisemblablement des modifications à l'intérieur même de chaque bloc pour d'éventuelles optimisations. Il y aura naturellement de nombreux tests et essais quant au bon fonctionnement de l'ensemble de la structure.
Phase 5 : Travail de « remplissage ». Si le squelette du jeu est tout à fait opérationnel et ne présente pas de bug, on passe à cette phase qui consiste à remplir le jeu de son contenu : les graphismes, les maps, les dialogues. C'est donc à ce moment que je m’attellerai activement à la conception des graphismes du jeu et à ses dialogues. Cette phase porte bien son nom puisqu'elle devra également être modulée en fonction de la place restante en mémoire dans la calculatrice.
Phase 6 : Optimisations, essais et tests du jeu intensifs. Cette phase vise à repérer les éventuels défauts dans le code du jeu, mais aussi dans le gameplay. C'est une phase très importante car elle vise à rendre le jeu jouable, appréciable et source de plaisir (oh yeah baby), mais aussi cohérent dans son ensemble. Elle contiendra donc beaucoup de recorrections et peut-être même de frustration chez le concepteur (moi) qui constatera que son jeu est tout pourri.
Phase 7 : Publication. Une fois que les corrections, tests, optimisations et finitions sont finis, il ne me reste plus qu'à publier une version 1.0 (ou Bêta) du jeu et attendre des retours de la communauté, qui sera sans doute enthousiaste de voir un jeu sortir après plus de deux années d'attente, lôl. En fonctions des retours, des finitions et des ajouts auront peut-être lieu pour donner suite à une version 1.1, 1.2, etc. L'objectif sera donc de corriger les éventuels bugs qui seraient passés inaperçus, et prendre en compte des suggestions pour améliorer l'expérience de jeu.
Phase 8 : Supplication. Demander à ce que le jeu jouisse du label de qualité Casio. C'est mon rêve. Je le veux. Au moins une fois dans ma vie !
Les suggestions de sorts par les membres de la communauté :
Lephenixnoir : « Pistole, Assaut, Regard perçant, Empalement, Illusion, Barrage, Retour de l'Hirondelle, Contournement, Vorpal, Survol, Coup ascendant, Berserk, Flèche ? »
Shadow15510 : « Boule de Feu (T) ». Woaw. Incroyable.
Membres ayant manifesté leur volonté d'apparaître dans le jeu :
Lightmare
Shadow15510
Cakeisalie5
Massena
Totoyo
Lephenixnoir
Math680
Git du projet : Soyez au plus près du code et des avancées des versions !
https://gitea.planet-casio.com/PlaneteCasio/Le_Royaume_Poudingue
Mis à jour le : 31/10/2018
Fichier joint
Citer : Posté le 31/07/2016 19:46 | #
Il est tout à fait vrai que j'ai décidé d'utiliser ta technique avec les coordonnées du type 4.04 au lieu de 4+4i, par exemple. Mais, le roi poudingue, je me demande si je vais vraiment l'attribuer. Je pensais juste mettre "Roi poudingue", mais j'y réfléchirai.
Tu veux m'aider ? Alors donne-moi des idées de monstres et de capacités utilisables en combat dont les animations ne prendraient que peu d'octets à faire !
Citer : Posté le 31/07/2016 21:14 | #
Alors le monstre le plus important du jeu : celui que tu croise au début, j'ai nommé le cake, avec seulement des attaques aux corps à corps.
Citer : Posté le 31/07/2016 21:15 | #
Et tu lui fais faire des bruits genre "hii... nuuux..."
Promotion ordinaire sur les inscriptions sur
Mon blog ⋅ Besoin d'utilitaires de transfert vers et depuis la calculatrice sous GNU/Linux ?
Citer : Posté le 31/07/2016 21:27 | #
Ok pour les monstre mais c'est du combat sous quelle forme ? De face ou en traviol à la Pokémon ?
Aussi pour les carac je suis d'accord avec PV mais les autres sont moins importante
Il faut metre attaque/défense mais aussi taux de critique (les chances en % de faire un crit) et les dégâts crit (de combien de % va augmenter l'attaque)
À à peut s'ajouter la luck qui définie les chances de loot un truc en cas de victoire
Citer : Posté le 31/07/2016 23:10 | #
Je n'ai pas envie de faire de carac d'attaque et de défense. En fait, j'ai pondu un truc plus spécial, plus unique, plus moi. Les caractéristiques qui découlent des niveaux de maitrise seront les suivantes :
Influencées par la puissance : Les PV, la force, et la parade
Influencées par la dextérité : La parade, la précision et la force
Influencées par la vitesse : Le nombre de coups, l'esquive et la précision.
Chaque branche de maitrise influence fortement deux caractéristiques et plus secondairement une troisième. Ainsi, on a : Les PV (évident), la force (influence directement les dégâts d'une attaque), la parade (plus cette valeur est élevée, plus le joueur a de chance de réduire de 50% les tous les dégâts d'une attaque subie. Prend en compte la précision ennemie), la précision (augmente les chance de toucher sur chaque coup donné et réduit la probabilité que l'attaque soit parée), le nombre de coup (indique le nombre de coups donnés par attaque), et enfin l'esquive (plus elle est élevée, plus le joueur a de chance d'éviter chaque coup qu'il subit.)
Lorsque le joueur lance une attaque sur le monstre, le calcul se fait ainsi : Facteur parade(vaut 1 ou 0.5)*Facteur maitrise(varie entre 1 et 2)*(0.8+0.1*(nombres de coups réussis-1))*(Puissance de la compétence+force+variable aléatoire(entre 1 et 3)).
Franchement, fuck la stat défense. Les coups critiques je verrai si j'en mets, m'enfin je ne pense pas. C'est original, c'est peu commun et ça me botte. J'ai pas envie de faire un RPG qui ressemble à tous les autres.
Bon, Cake : je vais vraiment faire un monstre à ton effigie. Rien qu'en regardant ton avatar, j'ai des idées. Tu auras l'attaque "Linux" ou "Gnunux", ça c'est sûr ! (Tu seras peut-être le troll du jeu, en fait). Je prends "GNU is not ta mère" (shout) ou "RTFM"
Suruq : C'est du combat en face à face. Le héros et le monstre sont de profil, et ce n'est qu'en un contre un.
Citer : Posté le 02/08/2016 21:42 | #
Le problème de retirer la stat de défense c'est qu'on retire avec un aspect stratégique qui va ajouter une dimension au combat contre un ours bien musclé. Contre un boss, éviter les dégâts c'est crucial. Si on doit se contenter de -50% (et rien d'autre) ou -100% (esquive), on se sent un peu négligé je trouve. On oublie les armures, visiblement la résistance élémentaire passe aussi à la trappe.
Trouves-tu vraiment que la parade et l'esquive sont indépendantes ? Que la dextérité permet de taper plus fort ? Que taper plus vite permet de taper plus précisément, mais pas de parer plus de coups en gérant mieux le déplacement du bouclier ? Qu'un hamster et qu'un scorpion se prennent en toute logique la même quantité de dégâts ? Que frapper les points vitaux empêche l'adversaire de parer ?
Bon, j'ai pas non plus de solution miracle. En essayant maladroitement de conserver tes statistiques originales j'ai abouti à quelque chose comme :
- Vie (résister à plus de coups)
- Force (infliger plus de dégâts)
- Résistance (subir moins de dégâts)
- Précision (faire plus de coups critiques)
- Esquive (parer, dévier, esquiver plus de coups)
- Vitesse (frapper plus tôt, toucher plus souvent, frapper plus de fois)
Je ne vois pas pourquoi la précision de l'attaquant influerait sur la probabilité de parade de la cible. Taper plus précisément signifie justement que le coup est plus localisé ; il ne serait donc pas plus difficile d'y placer un bouclier. Pourquoi fixer la parade à 50% ? Profiter de la stat de résistance ou d'esquive pour faire varier ce taux me semble tout aussi judicieux.
Citer : Posté le 02/08/2016 22:48 | #
Si on doit se contenter de -50% (et rien d'autre) ou -100% (esquive)
Tu sembles ne pas avoir compris le principe de l'esquive. As-tu déjà joué à Final Fantasy ? Lorsque tu lances une attaque basique sur ces jeux-là, le personnage répète son attaque très rapidement (jusqu'à 36 fois, voire 18 sur Bravely Default mais là encore on peut repousser la limite à 36 enfin bref, en réalité l'animation ne montre pas plus de 8 coups). Le calcul de l'esquive se fait sur chaque coup donné. Cela signifie que, même si le niveau de job et l'agilité (et d'autres paramètres moins connus) permettent au perso d'atteindre les fatidiques 36 coups, l'adversaire peut très bien en éviter de telle sorte à ne subir que 31, 27 ou 15 coups par exemple (là c'est que tu vises comme une b.. Ahum !)
Eh bien là ça sera pareil dans mon jeu. Le nombre de coups du héros peut être 15, alors qu'en réalité le monstre a réussi à éviter 4 coups sur l'attaque, donc il ne subira que 11 coups. Bref. Pour la parade, ça serait différent : soit tu pares TOUTE l'attaque (50%), soit tu pares rien du tout et tu manges les coups bien comme il faut. Bien sûr, l'esquive intervient toujours après. Il peut y avoir parade + esquives.
Ensuite, la dextérité permet de mieux viser, de mieux atteindre la zone vitale adverse. C'est pour ça qu'elle influençait, dans ma proposition, le taux de parade adverse. Ce que je voulais trouver, c'est surtout des caractéristiques (6 me parait bien) qui sont influencées différemment selon les niveaux de maitrise du héros. Mais il faut faire en sorte que ça reste équilibré, en terme d'efficacité générale. Si un mec vise bien mais qu'à côté il n'a pas de force, ni de pv, ni d'esquive, les monstres auront tôt fait de lui bouffer la trogne à ce p'tit gars.
Bon, soit, la défense, c'est vrai que ça a de l'importance, m'enfin certains jeux s'en passent quand même : Je peux citer Dofus (en tant que jeu, pas pour sa communauté de joueurs).
Citer : Posté le 02/08/2016 22:57 | #
Oh, je vois. L'esquive est une affaire plus subtile qu'en apparence. Mais si la parade se contente de diviser les dégâts par 2... outre que le coup critique (même si je ne sais pas si tu vas en implémenter) doit l'ignorer, la qualité de l'équipement au moins devrait jouer...
Ensuite, la dextérité permet de mieux viser, de mieux atteindre la zone vitale adverse.
Perso j'ai une armure plus épaisse au niveau du coeur, et je surveille particulièrement ces attaques. Je suis donc plus susceptible... de les parer. x)
Bon après c'est toujours discutable, mais je suis pas convaincu pour le coup de la défense (avis personnel).
Edit : Si les monstres plus résistants (scorpion) avaient une meilleur réduction de dégâts lorsqu'ils parent ?
Citer : Posté le 03/08/2016 10:49 | #
Edit : Si les monstres plus résistants (scorpion) avaient une meilleur réduction de dégâts lorsqu'ils parent ?
Merveilleuse idée. Tu es génial.
Et, pour ce qui est des équipements, je doute que je vais en implémenter. Le truc, c'est que je ne sais même pas si tout ce que je voulais faire à priori va tenir. C'est de la place à investir et je pense que je ne le ferai pas. Pour les coups critiques j'en sais rien !
Bon après c'est toujours discutable, mais je suis pas convaincu pour le coup de la défense (avis personnel).
En réalité la défense m'a toujours enquiquiné pour une raison simple, c'est que je ne sais pas comment la prendre en compte dans les dégâts. Sur Eon, je me suis contenté, schématiquement, de faire :
Mais tu y as déjà joué, à ce jeu, et t'as bien vu comment on peut se faire avoiner facilement ? Ce calcul est trop classique, et si jamais t'as le malheur de tomber sur un adversaire qui a un peu plus de défense que toi, POUF tu tapes pu' rien. Dans Pokémon, si tu tapes un steelix avec 400 de défense avec (je sais pas, moi) un grotichon qui a 250 d'attaque et qui utilise nitrocharge, steelix ne va pas se prendre 1 seul point de dégâts ni deux, mais un petit peu plus. Tu vois ce que je veux dire ?
Citer : Posté le 03/08/2016 11:02 | #
Pour la défense, il suffit d'implémenter une loi sur le rapport et non la différence.
Ainsi si la défense de la cible est du même niveau que l'attaque de l'agresseur, aucun ne l'emporte et les dégâts de base sont infligés. Si l'attaque de l'agresseur est nulle, aucun dégât n'est infligé, et si la défense de la cible est nulle (genre 0 quoi, aucune défense du tout), elle est morte d'office (c'est le plus discutable mais ça ne doit jamais arriver : aucune stat n'est nulle en pratique).
Sur un Steelix qui a 400 de défense ce facteur ne permettrait que de réduire les dégâts en proportion du rapport. Ça rend plus difficile d'avoir des personnages boostés à fond en attaque ou en défense, après on peut ajuster le modèle et passer sur des puissances plus élevées pour accentuer les effets :
Citer : Posté le 03/08/2016 12:18 | #
Hmmm, c'est pas mal, ça.
Un seul problème : lorsque les stats ne sont pas très élevées. Mettons que l'attaquant aie 50 points d'attaque, et le défenseur aie X points de défense. Si on calcule le rapport 50/X, on a quelque chose de très déséquilibré... :
Soit f la fonction définie sur ]0;100] par : f(x) = 50/x (calcule notre fameux rapport) (que de bons vieux souvenirs)
Alors :
f(2) = 25 //défense = 2
f(5) = 10 //pour 4 points de défense supplémentaires, le facteur est réduit de 80%...
f(9) = 5.56 //pour 4 points de défense encore la réduction est bien moindre
f(20) = 2.5 //un facteur 2.5 reste quand même énorme
f(50) = 1 //naturellement
f(60) = 0.833 //bref.
Voici un joli petit graph tout mignon :
Bref. Ce qui me gène, c'est d'avoir des facteurs bien trop énormes dès que la défense est bien inférieure à l'attaque (franchement, entre 50 et 20, il y a seulement une différence de 30 points). Le problème, c'est que sur des petites stats (donc au début du jeu), ces facteurs, en quelques points, passeront de 1.2 à 2.7 !
Mais l'idée n'est pas idiote du tout. On pourrait tenter de la perfectionner pour équilibrer la courbe.
Et si on prenait en compte les niveaux ? Enfin, il n'y aura pas de véritable niveau à proprement parler, mais c'est tout comme. Admettons :
ça peut être bien, non ?
Citer : Posté le 03/08/2016 12:34 | #
Alors oui, une mauvaise défense c'est beaucoup de dégâts subis. Mais à l'inverse, une mauvaise attaque c'est très peu de dégâts infligés. On a deux effets antagonistes :
- Difficile d'avoir des personnages très pétés parce que le rapport augmente lentement vers l'infini
- Facile d'avoir des personnages médiocres parce que le rapport évolue très vite vers zéro
Tu peux tenter de modifier la formule avec les niveaux, mais ça semble factice : le niveau n'a généralement pas d'influence directe, parce que l'influence qu'il pourrait avoir est déjà représentée dans les statistiques proprement dites. Et puis, je te dis pas ce qu'il se passe si le niveau de l'attaquant est très inférieur au niveau du défenseur, notamment dès que la différence dépasse 10 (des dégâts négatifs, you-hou), ce qui pourrait se produire entre un joueur de niveau 135 et un monstre de niveau 147. Tu vois l'idée. Encore une fois le rapport des niveaux a des propriétés plus intéressantes que la différence.
Pour tenter de modifier ce comportement asymptotique gênant, on peut bien sûr opter pour des exposants plus doux : du 1/√x serait déjà plus acceptable. Cela dit, le défaut avec les polynômes et affiliés c'est que leur comportement asymptotique finit toujours par être gênant peu importe l'exposant exotique que tu peux choisir. Histoire de modifier un peu ça, je t'invite à considérer 1/ln(x+1). D'autres ajustements pourraient améliorer ce modèle.
Citer : Posté le 03/08/2016 15:15 | #
Personnellement, pour un RPG, le truc c'est de n'avoir ni HP, ni attaque, ni défense, ni level up. Un coup et tu es mort, sans aucune possibilité de sauvegarde dans tout le jeu.
Mais plus sérieusement :P il m'arrive de ne pas utiliser de défense du tout, sauf pour les protections élémentales (comme feu, glace, foudre, où les dommages sont diminués de moitié ou doublés). Car ça peut faire un peu redondant quand on sait que nos points de vie augmentent au fil du jeu anyway.
Citer : Posté le 03/08/2016 15:29 | #
Alors oui, une mauvaise défense c'est beaucoup de dégâts subis. Mais à l'inverse, une mauvaise attaque c'est très peu de dégâts infligés. On a deux effets antagonistes :
- Difficile d'avoir des personnages très pétés parce que le rapport augmente lentement vers l'infini
- Facile d'avoir des personnages médiocres parce que le rapport évolue très vite vers zéro
Voila, c'est tout à fait cela !
J'ai sous les yeux le précieux Guide de stratégie officiel de Final Fantasy III. Voici comment fonctionne le calcul des dégâts ... Enfin, en fait, c'est hyper compliqué. Cela implique une tonne de facteurs que je n'utiliserai pas. Grosso merdo et schématiquement, ça fonctionne comme ça : (admettons que ce soit une arme dans une seule main, pas de harpe ni d'arc/flèches car les calculs diffèrent)
Rien que ça. Je remplace quelques éléments, au final, je vais avoir ceci :
Ensuite, on a le calcul de la fréquence d'attaques (=le nombre de coups max). On va dire qu'on a une carac qui nous donne ça a priori | à priori, on a ensuite le calcul des chances de toucher pour chaque coup.
Bon. On va faire un peu plus simple. Mettons quelque chose comme ceci :
Et enfin, total de dégâts :
Je retouche :
Bon, je trouve que Final Fantasy est quand même LA référence pour le modèle Nombre de coups/attaque, donc autant reprendre ce modèle pour faire un truc potable. En fait, le calcul reprend à la fois une différence et un rapport attaque/défense. C'est pour ça aussi qu'il est intéressant. À moi de le réadapter en fonction des stats et des PV.
Citer : Posté le 05/08/2016 09:56 | #
Ah ouais, la combinaison rapport/différence. Pas mal. Cependant ta formule de dégâts ne te sauve pas de la situation où un ennemi de trop grande défense ne subit plus aucun dégât (ou alors ça demande démonstration, parce que ce n'est pas évident).
Et euh... rien ne me garantit que ta formule de probabilité de hit ne va pas passer au-dessus de 100%... s'il y a des limites pour certaines stats ça pourrait être intéressant de le préciser.
Pour le total de dégâts, je serais d'avis d'appliquer un facteur aléatoire différent à chaque coup, plutôt qu'au total. Certes, ça amortit l'aléatoire donc on pourrait faire varier son échelle (style entre 0.4 et 0.9).
Citer : Posté le 05/08/2016 11:47 | #
Cependant ta formule de dégâts ne te sauve pas de la situation où un ennemi de trop grande défense ne subit plus aucun dégât
Je vais vérifier de ce pas !
Et euh... rien ne me garantit que ta formule de probabilité de hit ne va pas passer au-dessus de 100%...
Dans Final Fantasy, le fréquence d'attaques ne dépasse jamais les 95% : c'est le seuil maximal. Je ne sais pas si je vais mettre ça ou bien 100%, on verra. Donc même si, théoriquement, la fréquence atteint 126%, elle sera considérée comme égale à 95%.
Bon, j'ai fait quelques essais, pour un perso avec une force de 5 contre un monstre d'une défense de 25, les dégâts sont biens positifs, ça a l'air de bien aller.
Je pense que pour réduire le problème qu'on a rencontré plus haut, il faut faire en sorte d'éviter d'avoir de toutes mini stats du genre force = 2 ou défense = 3. Pour tester la solidité de mon calcul, il faut que je définisse comment sont calculées les stats parce que là, ce que j'ai fait ne va plus trop bien.
Donc, je refais : allez, que nous évoque la PUISSANCE ? La force bien sûr, mais aussi la vigueur, la vitalité, l'endurance. L'esquive ? C'est pour les mauviettes, 'faut taper fort !
La DEXTERITE : Il faut manier son arme avec précision, savoir viser, mais aussi donner de la force à ses coups, anticiper les attaques adverses. Précision, esquive et parade sont de la partie, mais peut-être la force ? J'en sais rien. Finalement, c'est une catégorie complète.
La VITESSE : La rapidité, l'initiative en combat bien sûr, mais aussi le nombre de coups, le taux d'esquive... Tout ce qui nécessite d'être réactif.
bon... J'tourne en rond.
Ajouté le 25/09/2016 à 17:44 :
Hey les potos ! Ceci n'est pas un déterrage, non, il ne faut pas exagérer ! J'annonce seulement l'arrivée trèèèèèsssss imminente de la version Démo de mon jeu, j'ai intitulé...
Aventura, Le royaume Poudingue
Bref, je posterai cette version démo dans la rubrique "Projets en cours de création". Une fois la version démo sortie, je donnerai le lien ici, sur ma signature, un peu partout.
Il était trop tard pour mettre ça dans la rdp, et puis en semaine je suis absent, anyway... Dans cette version démo, vous pourrez seulement explorer et discuter avec des personnages. La map est construite à 45%, le scénario à 68% (dans ma tête, lôl) et le moteur de combat à 1%... Bref, c'est pas non plus pour demain la sortie de ce jeu.
Ajouté le 25/09/2016 à 18:21 :
C'est fait ! vous n'avez plus qu'à fouiller ma signature !
Ajouté le 20/11/2016 à 12:53 :
Mes amis ! J'ai, avec le temps et le recul, complètement changé d'avis. En fait, j'vais pas faire quelque chose qui a déjà été fait. Je me suis rendu compte que j'allais faire un moteur de combat semblable à celui d'un Final Fantasy (genre I ou III). Entre temps, j'ai découvert l'existence d'un jeu qui a fait fureur sur internet, j'ai nommé Undertale. Pour ceux qui ne connaissent pas, je vais simplement parler du moteur de combat qui est unique en son genre : l'âme de votre personnage est symbolisée par un petit cœur, et vous devez éviter les attaques adverses en vous déplaçant de haut en bas et droite à gauche. Après, ce système a été si poussé et développé de diverses façons selon les boss qu'il en devient carrément incroyable. Tout ça pour dire que je souhaitais repenser mon moteur de combat complètement autrement. Faire du neuf. Parce que moi, j'suis un artiste, yolo, et que j'suis là pour être créatif et innovateur.
Donc voici comment je vais organiser mon moteur de combat : Le personnage n'aura que deux caractéristiques primaires (pour l'instant, on verra si on complexifie après). Les Pdv et les dégâts. Peut-être rajouterai-je, en deuxième plan, les niveaux de maîtrise. En clair, le joueur pourra employer les actions suivantes lors de son tour :
- Cogne : type puissance. Une jauge de puissance s'active, et le joueur doit arrêter la jauge en appuyant sur une touche le plus proche possible du point culminant. Plus la jauge est arrêtée proche du point culminant, plus le coup sera puissant.
- Rafale : type vitesse. Le joueur doit marteler une touche le plus de fois possibles sur un temps court. Le nombre de coups, et donc la puissance de l'attaque découlera du nombre de fois où le joueur a pressé la touche.
- Précision : type dextérité. Un carré de 3 * 3 cases apparaît. Le joueur doit appuyer sur les touches numériques correspondant aux cases noires le plus vite possible. S'il se trompe, c'est l'échec critique. Les dégâts de l'attaque découlent de sa rapidité d'exécution.
- Sort-code : Une capacité qui devrait plaire. Un pavé de 9 chiffres apparaît, à l'instar de l'attaque précision. Les chiffres ne sont pas dans le même ordre que sur les touches numériques de la calto. Le joueur doit rentrer un code à 3 chiffres. S'il tarde trop ou s'il rentre un code faux, c'est l'échec critique (ou un sort-troll est lancé). Cette attaque lui permet d'utiliser certains sorts employés par les monstres, ou d'autres confiés par des pnj. Par exemple, mettons que le code "000" donne le sort "soin". Si le joueur tape "000" au sort-code, il lancera le sort soin !
- (éventuellement) Objet : permet l'utilisation d'un objet. À voir.
- Fuite (si vous êtes un lâche) : permet de fuir un combat. Si l'adversaire est un boss, cette commande ne fonctionnera pas.
Pour les actions adverses, je ne sais pas encore bien précisément comment je vais organiser cela. Je suis preneur d'éventuelles idées, sachant qu'on est en basic.
Nota bene : Toutes les commandes comme Cogne ou Rafale s'effectuent sur l'interface Texte dans un souci de réactivité.
Ainsi, sur l'interface de combat, ça ressemblerait plutôt à ça :
L'adversaire est affiché au milieu de l'écran, de face. Tout en haut figure la barre de tâches enregistrée dans une picture compressée. La boite de dialogue s'affiche en bas de l'écran. Je peux faire un background spécial pour les combats avec les boss. En haut à droite figurent les Pdv (points de vie).
Qu'en pensez-vous ? Des suggestions ?
Citer : Posté le 20/11/2016 13:56 | #
Le concept est sympa, mais j'ai un peu peur qu'au bout de quelques combats, devoir faire ces mini QTE devienne agaçant.
Est-ce que ça apporte vraiment quelque chose au gameplay ?
Citer : Posté le 20/11/2016 15:01 | # |
Fichier joint
Oui. Le principe est de rendre le joueur actif, il ne se contente pas d'appuyer sur un bouton pour faire attaquer son personnage, mais se doit de rester éveillé, sur le qui-vive !
Citer : Posté le 04/06/2018 14:24 | # |
Fichier joint
Bien, les amis : je reprends ce projet, comme indiqué dans la RDP 107. Sans plus attendre, je poste quelques images. Les deux images suivantes sont des background pour l'écran de combat. je pense en mettre 3 voire 4 au total.
Je ne tarderai pas, à partir de ce soir, à réactualiser la page du topic.
Citer : Posté le 04/06/2018 15:16 | #
Tes dessins sont sublimes : on sent le dessinateur derrière
Tu les as fait on calc ?
Citer : Posté le 04/06/2018 18:34 | #
Waouh, et dire que je trouvais mes fonds pour Arena jolis xD