Comme certains le savent je travaille sur un projet de "platformer" sur RM2k3. Les collisions et tout le tralala avancent plutôt bien, mais je souhaiterais avoir un système de saut plus réaliste ou du moins plus proche d'un "Mario like" que celui que j'utilise actuellement (Actuellement, la fonction saut ne modifie que la composante Y, ce qui permet au joueur d'avoir un contrôle total sur le saut. Intuitif mais pas vraiment réaliste).
J'aimerais connaître les formules employées pour un saut de ce type afin de pouvoir l'adapter au langage event de RM2k3.
Merci par avance.
EDIT : Pour illustrer, voici la manière dont le personnage saute (Maintenant si vous me dites que c'est bien, je laisse tomber ) :
(Oui je sais, j'ai mis de coté le problème du scrolling horizontal pour l'instant).
Mac-AB -
posté le 07/02/2015 à 20:58:06 (82 messages postés)
❤ 0
Franchement... pareil !
C'est nickel comme ça touche à rien !
Tout le monde souhaite être riche... Moi je souhaite que tout le monde soit pauvre...
Mack -
posté le 07/02/2015 à 21:09:24 (2288 messages postés)
❤ 0
Bah, perso au contraire je suis vraiment pas fan :/.
Le plus gros problème, c'est la vitesse de chute / saut.
On dirait que c'est la même, à l'exception du signe.
Mais le plus gênant, c'est le fait qu'elle soit "fixe", alors qu'elle devrait changer plus ou moins progressivement.
M'enfin, déjà qu'en prog c'est pas forcement la joie de faire un système de saut jolie à voir, alors sur RM 2k3 ...^^".
J'avais trouver un dossier ( en anglais ), qui expliquer plein de trucs sur les systèmes d'un jeu de plateforme.
J'vais essayer de le retrouver.
Après, moi j'vais fais un système de vecteur, en gros, quand tu appuyé sur Gauche/Droite, une variable simulant la vitesse en X augmenter/descendais, et selon cette variable je déplacer le joueur.
La valeur changer progressivement, et revenait lentement à 0 si aucune touche n'était pressé, et si le joueur sauté, elle diminué plus vite.
Et je faisait changer cette valeur progressivement, ce qui faisait que si le joueur courait à gauche, sautait, puis essayer d'allez à droite, bah il changer lentement de trajectoire, et pas d'un coup sec.
( Je prend note de tout les commentaires, même si je n'y répond pas )
Qb!k -
posté le 07/02/2015 à 22:03:13 (918 messages postés)
-
❤ 0
Loading ||||...... Please Wait
@MACK
Tu as un bon oeil : la vitesse de chute / saut c'est la même, à l'exception du signe.
C'est vrai : en pratique la vitesse d'un saut est progressive, puisque la vitesse dépend de la gravité (9,81 m.s-²) qui est une accélération.
J'ai bien trouvé quelques formules sur internet pour le saut mais qui privent le joueur d'un contrôle total ce qui est certes plus réaliste mais moins agréable pour le joueur.
Trouver un équilibre entre les deux est difficile mais ce que je veux surtout c'est éviter une "usine à gaz" en guise de code.
Cependant tu me fais penser à ce qu'à dit ROTS sur ton projet lors du choix de la position des portes :
Dans un choix comme ça, il faut toujours préférer la visibilité maniabilité par rapport à la logique !
Je te remercie de ton aide, encore une fois, comme pour le principe des collisions, tu m'offres une piste intéressante.
Merci les autres pour vos remarques et vos encouragements !
Joke -
posté le 07/02/2015 à 22:06:39 (5089 messages postés)
❤ 0
Bilouteux fou
Sinon tu regarde cette vidéo qui explique assez clairement le moyen le plus simple d'arriver à ce que tu veux faire :
En adaptant/améliorant un peu ce qu'il propose, on peut obtenir ça sous RM2k3 (je viens de le coder en même temps que je regardais la vidéo) :
Attention, RM2k3 tourne à 60FPS. Si tu veux que les calculs soient fait toutes les 1 frames (0.0sec), je te conseille fortement de simuler deux décimales à tes valeurs de paramètre.
Pour simuler un paramètre qui vaut 0.65 (la gravité que j'ai choisi)... ben tu rends le paramètre égal à 65, et au moment de faire le calcul de coordonnées pour l'image, tu rends une variable secondaire égal à la valeur de ton paramètre, et tu divise simplement par 100.
Je ne vais pas te gâcher le plaisir de découvrir par toi-même, donc je ne vais pas donner le code... mais si tu veux un bon point de départ :
Les variables que j'ai nommé en MAJUSCULE sont des constantes, elles ne varient pas :
GRAVITY = 65 correspond à une vitesse de 0.65 pixels par frames pour la gravité.
SPEED_H = 400 correspond à une vitesse de déplacement horizontal de 4 pixels par frames pour les déplacements horizontaux.
SPEED_JUMP = 800 correspond à une vitesse initiale de 8 pixels par frames pour les sauts.
BOUNCE_LIMIT = 600 méthode différente de la vidéo qui limite le rebond à un nombre de rebonds, ici je dis que le rebond se fait seulement si la vitesse est supérieure à 6 pixels par frames.
%AMORTIZATION = 60 ici, c'est le pourcentage d'amortissement par rebonds, chaque rebond sera 60% moins rapide que la retombée.
%SKID_H = 93 ici c'est la valeur de dérapage en pourcentage. plus la valeur est grande, plus le héros dérape.
( Je prend note de tout les commentaires, même si je n'y répond pas )
Qb!k -
posté le 07/02/2015 à 22:12:52 (918 messages postés)
-
❤ 0
Loading ||||...... Please Wait
Merci Joke et Mack, je vais essayer de bidouiller tout ça !
Edit : je viens de voir que l'objet rebondi, faut voir si on peut virer la séquence qui fait ça. Tu as une façon de coder Intéressante Joke, moi qui m’em... à appeler des common event... Ta méthode fait beaucoup plus propre.
Joke -
posté le 07/02/2015 à 22:27:03 (5089 messages postés)
❤ 0
Bilouteux fou
En fait ce que j'ai fait est parfaitement reproductible en 100% common event, si tu ne veux pas copier/coller le moteur physique sur toutes les maps.
Je suis habitué à coder comme ça parce que je fais plus des mini-jeux que des jeux. ^^ Donc il n'y a rien de mieux qu'un événement stand-alone pour ça.
Mais pour faire un jeu entier comme ça, je te conseille de faire en événement commun. La page 7 serait donc le seul événement commun qui tourne en processus parallèle, les autres pages seraient d'autres événements communs en mode appel.
Joke -
posté le 07/02/2015 à 22:56:49 (5089 messages postés)
❤ 0
Bilouteux fou
Je n'ai jamais touché à scratch, non plus. x)
C'est une boucle, oui.
Fais gaffe par contre, sur scratch apparemment le y est positif vers le haut, alors que dans RPG Maker le y est positif vers le bas ! Donc quand il fait "rendre égal" à une valeur négative en y, en fait c'est positif, et vice versa.
Je suis allé un peu plus loin que la vidéo dans l'adaptation et le paramétrage, mais si tu reproduis déjà exactement ce que dit la vidéo, en changeant un peu les valeurs, ça fait déjà l'essentiel.
nathaniel-japon -
posté le 08/02/2015 à 00:03:52 (143 messages postés)
❤ 0
Forever est bien une boucle.
Je te conseille d'aller directement sur le site de Scratch. Tu y trouveras des tas de clones de Mario, peut-être même trop (en même temps, c'est pour les écoliers à la base, donc beaucoup de projets sont très brouillons...).
Mais l'avantage, c'est que tu peux regarder TOUTE la programmation de TOUS les projets, et qu'il te suffit de changer la langue pour que tout soit modifié automatiquement en français.
Les sauts, les scrollings, les collisions...bref tout. Après, bien sur il faudra adapter pour RM.
Apprenez la programmation à vos enfants avec SCRATCH (PC)
Tassle -
posté le 08/02/2015 à 00:16:50 (5234 messages postés)
❤ 0
Disciple de Pythagolf
Juste en complément de ce qui a déjà été dit : je sais pas à quel point ça t'est familier mais tu peux t'inspirer des formules physiques de la dynamique.
Si tu négliges la résistance de l'air (sinon t'as des équadiffs et des solutions exponentielles c'est chiant) dans la vraie vie t'auras ta position y qui variera comme ça au cours du temps :
y = (1/2)g*t² - (v0)*t + y0
Où g désigne l'accélération de la pesanteur, v0 la vitesse verticale au début du saut, et y0 la position verticale au début du saut. Tu fixes g et v0 comme tu veux pour que les sauts te plaisent.
Ensuite en x t'as simplement :
x = w0*t + x0
Où w0 désigne la vitesse horizontale en début de saut et x0 la position x en début de saut.
Le problème c'est que là le personnage n'est pas du tout contrôlable en saut. Tu peux rajouter une accélération du genre :
x = w0*t +x0 + a
Où a est une valeur que tu fais augmenter lorsque la touche droite est enfoncée, diminuer lorsque la touche gauche est enfoncée et que tu rends nulle quand rien n'est appuyé. Dans ce cas il faudra peut-être contrôler la valeur de a histoire qu'elle ne devienne pas trop grande lors de longs sauts.
~~
Joke -
posté le 08/02/2015 à 01:16:35 (5089 messages postés)
❤ 0
Bilouteux fou
Par contre, il y avait un manque, dans la vidéo et mon premier essai : c'est de la simulation d'inertie (sauf la solution de freinage proposé qui n'est pas des plus joyeuses).
J'ai donc potassé une petite accélération/décélération horizontale, c'est plus précis et dynamique comme ça :
Anton_ -
posté le 08/02/2015 à 10:25:18 (1522 messages postés)
❤ 0
Pour le saut, j'avais utilisé une astuce pour sauter plus haut quand on maintient la touche saut.
Une variable "gravité en saut" qui était trois fois plus faible que la gravité normale.
Une variable "Delay max de saut" qui permet de reprendre la gravité normale au bout d'un certain temps même si la touche saut est encore enfoncée.
Et aussi, pour éviter des chutes trop rapides, on peut penser à capper la vitesse verticale à un minimum fixe. avec une variable "vitesse de chute maximale"
Joke -
posté le 08/02/2015 à 14:57:09 (5089 messages postés)
❤ 0
Bilouteux fou
Pour ma part, dans ma dernière version j'ai préféré ajouter (pour tester) un quart de la différence entre la vitesse horizontale et la vitesse horizontale minimale à la vitesse initiale du saut, ce qui fait que plus il prend de l'élan et plus il saute haut. Pour ne pas embrouiller le joueur j'ai retiré le principe de "si on maintient la touche il va un peu plus haut" pour qu'il n'ait plus à se soucier du temps d'appui, mais en gros pour le "si on maintient la touche", j'avais fait que :
Pendant les dix premières frames où on n'est plus sur le sol, la touche d'appui du saut pouvait continuer de fixer la vitesse verticale initiale. Ce qui faisait qu'on pouvait sauter plus haut en ne subissant pas tout de suite la force de gravité seulement pendant le temps (restreint à 10 frames, donc) qu'on laisse appuyé la touche de saut.
Anton_ -
posté le 09/02/2015 à 13:06:18 (1522 messages postés)
❤ 0
On part bien du principe des sauts à la mario hein ?
Bon d'accord, il est vrai que la vitesse de saut est plus grande quand on atteint une vitesse horizontale conséquente.
Mais je maintiens mon idée de rester enfoncé le bouton saut pour baisser momentanément la gravité (jusqu'à un certain point dans la parabole) pour allonger la durée de saut et donc donner une notion de contrôle aérien.
Ave ça, on pourra faire de tout petits sauts même en courant à fond.
Enfin bon, je compare ça avec ma façon de jouer à SMW, SMB3, et compagnie.
Joke -
posté le 09/02/2015 à 18:55:09 (5089 messages postés)
❤ 0
Bilouteux fou
Joke a dit:
mais en gros pour le "si on maintient la touche", j'avais fait que :
Pendant les dix premières frames où on n'est plus sur le sol, la touche d'appui du saut pouvait continuer de fixer la vitesse verticale initiale. Ce qui faisait qu'on pouvait sauter plus haut en ne subissant pas tout de suite la force de gravité seulement pendant le temps (restreint à 10 frames, donc) qu'on laisse appuyé la touche de saut.
Ce que j'ai expliqué ici c'est une alternative au fait de baisser la gravité, au lieu de faire un saut plus léger donc plus haut, le début du saut garde sa vitesse constante le temps qu'on laisse appuyé la touche au départ du saut, la vitesse commence à décroître dès qu'on lâche la touche, sinon au bout d'une limite de temps de pression (que j'ai fixé à 10 frames dans mon test, ce qui fait 0.16 sec). Le saut garde le même dynamisme, il est juste plus élancé (ce qui est tout aussi impossible à faire physiquement qu'une décharge pondérale/gravitationnelle, certes, mais tous les moyens sont bons pour donner l'illusion qu'on saute plus fort. x) )
Je dis ça pour dire qu'il y a deux façons possible de faire la même chose plutôt qu'une.
Après le coup de retirer la possibilité de sauter plus haut si on laisse appuyé et pouvoir sauter plus haut selon l'élan que l'on prend, je ne crois pas qu'il y ait ça dans mario bros, c'est plus une mécanique façon super meat boy si je me souviens bien. Comme quoi on peut faire ce qu'on veut, ajouter des double sauts, etc. (ou encore faire comme mario64 où le second saut consécutif est plus fort que le premier, le troisième est un super saut.)
Nemau -
posté le 10/02/2015 à 01:42:29 (52207 messages postés)
- -
❤ 0
The Inconstant Gardener
Mettez Joke Qb!k et Anton dans une pièce avec dedans juste un ordi et RM 2003 (sans patchs) et deux heures plus tard ils ressortent avec un moteur de jeu en 3D.
nathaniel-japon -
posté le 10/02/2015 à 05:46:33 (143 messages postés)
❤ 0
Ça mérite un bon petit "Joke's Tuts", non ?
Comme ça, après les MMO des vacances on aura les MARIO LIKE des vacances Ça changera un peu.
Apprenez la programmation à vos enfants avec SCRATCH (PC)
Qb!k -
posté le 10/02/2015 à 20:30:28 (918 messages postés)
-
❤ 0
Loading ||||...... Please Wait
Bon ça me gonfle j'arrive pas à rajouter la vélocité à mon code de départ sans me planter dans les boucles et les appel.
J'ai déjà intégré trop d'éléments (Genre bruitage et effet de poussière lorsque le personnage atterrit) et je m'y perds un peu (Trop de switch).
Je vais reprendre le codage du mouvement à zéro a partir de la structure proposée par Joke.
Et plus je regarde le saut actuel plus je trouve ça moche (En gros au lieu d'avoir une colline j'ai une montagne). Si j'ai pas dès le départ un moteur clean, ça fera un jeu de merde, donc je préfère encore perdre 3 mois sur le moteur...
Et puis quand on a compris le principe des collisions, coder des maps de platformer ça va assez vite.
Par contre j'ai rejoué à Megamike du coup.
EDIT :
VOILA ! c'est mieux maintenant non ?
J'ai rajouté le principe de l'élan :
Si vous sautez sur place ou avec peu d'élan, la portée du saut est moins importante.
Danzaiver -
posté le 12/02/2015 à 02:08:48 (364 messages postés)
❤ 0
Largement !
Joke -
posté le 12/02/2015 à 20:30:31 (5089 messages postés)
❤ 0
Bilouteux fou
Yes, GG ! C'est bien mieux.
Ça peut venir du gif (mets le Max FPS à 60 pour montrer des trucs dynamiques ! ), mais ça me semble un peu mou par contre.
Tu simules des décimales à tes paramètres, pour plus de précision dans la configuration ? Sans ça on est vite restreint à "trop rapide VS trop lent si +- 1", alors qu'en utilisant des valeurs en centièmes de pixels la configuration devient royale.
Chat
- 
Ça changera un peu.
