Plateforme un sens et pentes[Résolu]

Voila deux choses avec quoi je galère tout le temps, les plateformes à un sens ( si le personnage saute il passe à travers et si il tombe il est bloqué ), et les pentes.
J'ai déjà réussi à avoir quelques résultat plus ou moins fonctionnel mais c'est jamais parfait.
Je cherche surtout la solution pour les plateformes à un sens, les pentes au pire je pourrais m'en passer.

Merci d'avance en espérant que quelqu'un pourra m'apporter une solution

Pour les plateformes à un sens, si le personnage est plus bas que celle-ci (y du perso supérieur) la plateforme n'est pas solide et le perso passe à travers sinon elle est solide.

Il y a plusieurs objets donc si le joueur touche la plateforme les autres objets vont tomber, mais je vais faire avec collision_line finalement, j'aimerais juste savoir ce qui consomme le plus entre :

- Faire un bloc parent et tester les collisions sur ce bloc.

ou

- Tester les collisions sur chacun des blocs.

Parce que je crois pas que les fonctions "collision_" testent les collisions sur les bloc enfants.

Edit : Ah bah si enfaite ça marche x) désolé de vous avoir fais perdre votre temps ^^"

faut pas utiliser les fonctionnalités bouseuses "solid" de GM.

Pour du passe-bas, grosso-merdo ça donne ça :


if (vspeed>0 && place_meeting(x,y+vspeed,tonobjet))
{
vspeed=0;
// Et tout le reste pour atterrir
}

vspeed >= 0, sinon la condition n'est vérifiée qu'un step sur deux et tu t'enfonces petit à petit dans le sol.

Pourquoi elle ne serait exécutée qu'un step sur deux ?

Une fois que le perso a atterri, tu mets une variable genre "isOnGround" à true, et tu la repasse à false quand le perso saute/tombe, du coups tu prends en compte cette variable :

Code:

if (!isOnGround && vspeed>0 && place_meeting(x,y+vspeed,obj))
{
vspeed=0;
isOnGround=true;
}

Et c'est niquel

Au final j'ai fais ça :

Code:

vitesse_v += gravite*global.speed_game;
taille_w = sprite_get_width(mask_index);
if vitesse_v > 0
{
    repeat(vitesse_v)
    {
        if !collision_line(x-taille_w/2,y+1,x+taille_w/2,y+1,bloc,1,0) and !collision_line(x-taille_w/2,y+1,(x+taille_w/2)-1,y+1,bloc_plateforme,1,0)
        {
            y += 1 * global.speed_game;
            au_sol = 0;
        }
        else
        {
            vitesse_v  = 0;
            au_sol      = 1;
            break;
        }
    }
}
if vitesse_v < 0
{
    repeat(abs(vitesse_v))
    {
        if !instance_place(x,y-1,bloc)
        {
            y          -= 1 * global.speed_game;
            au_sol      = 0;
        }
        else
        {
            vitesse_v = 0
            break;
        }
    }
}

je test les collissions avec les bloc et les plateformes quand le joueur a une vitesse_h > 0 et dans l'autre cas seulement avec les bloc.

Le problème de place_meeting() c'est qu'il vérifie la collision de l'objet même quand il est a travers la plateforme donc il se bloque pas seulement lorsque la plateforme est juste en dessous,

Essaye de rendre plus lisible ton code, c'est une bonne habitude a prendre dans de grands projets.
Par exemple

if !collision_line(x-taille_w/2,y+1,x+taille_w/2,y+1,bloc,1,0) and !collision_line(x-taille_w/2,y+1,(x+taille_w/2)-1,y+1,bloc_plateforme,1,0)

Peut être remplacé par

var left, right;
left = x-taille_w/2
right = x+taille_w/2
if(!collision_line(left, y+1, right,y+1, bloc, 1, 0) and !collision_line(left,y+1,right-1,y+1,bloc_plateforme,1,0))

Et surtout pense a faire des fonctions (scripts)
Tu pourrais par exemple faire

Code:

if vitesse_v > 0
{
    repeat(vitesse_v)
    {
        playerUpdatePositionDown()
    }
}

De plus utiliser des fonctions permet de mieux éviter les conflits de variables.

Bref, même si GM ne facilite pas le fait d'avoir un bon code propre, il faut quand même se forcer

Ouais j'essaye d'utiliser de plus en plus avec des fonctions mais j'ai pas encore le réflexe.
C'est pareil j'utilise pas du tout les variables déclarés avec "var", c'est des variables qui sont utilisable que dans la fonction où elles sont appelées ?

En tout cas merci pour les conseils je vais essayer de les appliquer

Les noms des fonction s'écrivent sans "_" et avec des majuscules au début des mots ?

Alors le fait d'écrire une fonction nomDeTaFonction() c'est une habitude de programmeur C/C++
Je trouve ça plus rapide a écrire, et plus joli
De plus ça permet de voir que c'est tes fonctions, et non celles de GM.
En général on ne met pas de majuscule a la première lettre, par convention c'est réservé au classes/objets (en C++).

Pour var, c'est pour créer une variable 'temporaire', qui seras locale au bloc ou elle est déclarée.
L'intérêt, si tu l'utilise dans une fonction, c'est qu'il seras impossible que tes variables créent un conflit avec les variables de ton objet.

Imagine tu as la variable myVar de déclarée dans ton objet :
#create
myVar = 5

Si tu crée une fonction de cette façon, elle modifieras la variable de l'objet :
#script
myVar = argument0
return myVar * (myVar-10)

Mais si tu met le mot clé var, elle compteras comme une autre variable, et ne modifieras pas celle de ton objet :
#script
var myVar;
myVar = 12 // locale au script

Ok, merci d'avoir pris le temps de m'expliquer, je vais essayer de prendre l'habitude d'utiliser tous ça.
T'aurais pas d'autres conseils de programmeur super expérimenté xD ?

Ben, sous GM, disons que c'est pas facile de tout bien faire comme il faut, mais essaye de faire les choses de cette manière :

Range bien tes ressources, essaye de bien les nommer, d'une façon compréhensible pour tous, mais avant tout pour toi x)
Par exemple je procède ainsi :
Sprites : sNomSprite
Scripts : nomDuScript
Objects : MonObject

Si tu y arrive, favorise les sprite sheets au sprites composé de sous images.
L'intérêt :
-plus léger en mémoire
-très pratique, pour faire des skins ou changer les couleurs de ton perso, il te suffiras d'ajouter une sous image supplémentaire avec une autre sprite sheet
-prend beaucoup moins de ressources sprite (tu n'as besoin que d'un seul sprite pour toutes les actions)
Le désavantage :
Un peu plus dur a coder, vu que tu doit faire un système d'animation custom.

Essaye de coder de façon modulable. Trouve un moyen d'organiser les actions de tes personnage afin qu'en ajouter, ou en enlever une soit simple.

Favorise l'utilisation d'un objet de contrôle dans une room plutôt que pleins d'objets qui agissent de manière similaire.

Par exemple dans un zelda, inutile de créer 50 interrupteurs différents qui vont chacun ouvrir une porte différente.
Tu peut contrôler tout ça soit via un objet unique, ou utiliser la fameux 'Set Code' dans une room quand tu fait Ctrl+Clic Droit sur une instance.

Imaginons que je veux créer un objet panneau, et bien dans son create je vais mettre :
#create
if(!variable_local_exists("message")) message = ""
pour éviter les erreurs, et maintenant pour afficher un message différent suivant les instances, tu peut utiliser le Set Code :
message = "Voici un super panneau"

Pour l'exemple de l'interrupteur qui agis sur une porte, il te suffit de passer l'id de la porte dans le Set Code de ton instance interrupteur.

Optimise ton code tout en codant, ne remet pas ça a plus tard.
Pas la peine de faire des optis de malade cependant, essaye surtout de le rendre modulable et bien lisible.
Ne fait surtout pas se cumuler les bugs, sinon tu seras bon pour tout recommencer.

Et dès que j'ai d'autres trucs qui me viennent a l'esprit, je te tient au courant :p
Mais ça fait un bon moment que je n'ai pas touché a GM, donc faut le temps que ça remonte au cerveau x)

Tu peux m'en dire plus sur les sprite sheet ? ou si t'as un tuto ou autre dessus, ça à l'air super pratique mais j'ai aucune idée de comment faire ça.

Sinon pour le code modulable j'essaye mais en général je suis obliger de me planter une première fois avant de comprendre comment j'aurais dû le coder, mais je comprend le principe je pense qu'a force ça finiras par rentrer x)

Je me demandais si il y avait pas mieux que" Ctrl+Clic Droit sur une instance" pour faire plusieurs portes avec interrupteur par exemple, parce que c'est pas très pratiques à gérer dans la room mais je suppose ça fais partie des défauts de game maker ?

je connaissais pas "variable_local_exists()" mais je sens que ça vas beaucoup de me servir xD

Je pense que mon plus gros problème c'est que je veux toujours ajouter un tas de choses que j'avais pas prévu au début du coup je les ajoutent en mode bricolage et je suis obligé de tout recommencer depuis le début parce que ça devient n'importe quoi, j'imagine que ça veux dire que mon code n'est pas assez modulable x)

Comme je disais, pour le coup de ctrl+clic t'est pas obligé.
Tu peut soit créer un objet de contrôle, et depuis cet objet en utilisant les id des instances tout contrôler, ou carrément tout mettre dans le code de création de la room.
M'enfin je suis d'accord que c'est pas ce qu'il y a de plus pratique quand même x)


Pour les sprite sheets, j'avais fait il y a longtemps un tuto, donc a mon avis c'est pas le top mais je pense que ça vaux le coup que tu regarde :
https://cbna.forumactif.com/t10140-tutoriel-utilisation-de-spritesheets

Je vais voir pour faire un moteur plus modulable et propre de mon coté :p

Cool le tuto je pense que ça vas être un bon point de départ.
J'te remercie pour tout et si t'as d'autres conseils je suis toujours preneur

Moi je go m'entrainer à utiliser les sprites sheet

Je viens de te faire une série de scripts pour gérer facilement les sprite sheets, mais y a de l'orage donc je déco.
Je te passe ça dès qu'ils se seras calmé

Ok cool Merci moi de mon côté j'ai commencé un peu à tester avec l'aide de ton tuto, c'est pas encore parfait mais ya un début xD

Pour les pentes : https://cbna.forumactif.com/t10498-pour-ceux-qui-veulent-creer-un-jeu-de-plateforme?highlight=plateforme

Merci mobi

Et voila, j'espère que t'aimeras : http://www.host-a.net/u/onilink_/spriteSheet_Anim.gm6

Merci c'est top, j'ai pas encore tout compris xD mais ça m'a l'air parfait

Si t'as une question sur une quelconque fonction, ou autre n'hésite pas hein :p

Pour l'utilisation, une fois que t'as crée tes anim, c'est exactement pareil qu'avec des sprites normaux.
Tu modifie ton anim courante avec la variable que t'as crée pour, dans l'exemple animIndex, tu change l'image en cours avec
image_index et la vitesse d'animation avec image_speed