[help] Comment créer un ennemi et le tuer (mario-like) ?

Bonjour,

Après des essaies infructueux, et une recherche de tutos étrangement toute aussi infructueuse (ou alors je ne sais pas mis prendre, lol), j'appelle à l'aide
J'ai pour l'instant un personnage qui se déplace et sautille sans problème sur ma room. Je veux maintenant y ajouter un ennemi tout ce qu'il y a de plus classique : déplacement horizontale, inflige des dégâts au héros par contact.

Dans un premier temps je cherche simplement à le faire se déplacer de gauche à droite en continu (jusqu'à un mur et/ou jusqu'au bord du vide).

Mais je galère grave
(Je précise que je débute)

Pour le déplacement dans Create :

Code:

wait_dir=0
dir=4
movespeed=X

( Remplace X par la valeur de ta vitesse )

Dans step :

Code:

if dir==4 and place_free(x-movespeed,y){
x-=movespeed
}

if dir==6 and place_free(x+movespeed,y){
x+=movespeed
}

wait_dir+=1
if wait_dir>=25{ // Changes 25 par le nombre de step où il marchera dans la même direction.
if dir==4
dir=6
else
dir=4
wait_dir=0
}

Ça te fera déplacer ton perso pendent un certain nombre de frame d'un côté, puis de l'autre.

Pour l'arrêter près d'un précipice, je pense qu'il suffit de changer les conditions en :
if dir==6 and place_free(x+movespeed,y) and not place_free(x+movespeed,y+1)
et
if dir==4 and place_free(x+movespeed,y) and not place_free(x-movespeed,y+1)

Je pense que ça devrait marcher ^^.

Ton code m'a l'air juste mais

Citation :

Pour l'arrêter près d'un précipice, je pense qu'il suffit de changer les conditions en :
if dir==6 and place_free(x+movespeed,y) and not place_free(x+movespeed,y+1)
et
if dir==4 and place_free(x+movespeed,y) and not place_free(x-movespeed,y+1)

m'a l'air bizarre : tu vérifie si la place est libre à l'endroit ou il se trouve ; mais c'est inutile non ? Puisque si il est à cette position, c'est que la place est libre !

(Ou alors j'ai mal compris ton raisonnement )

Non, je vérifie la place qu'il devrair avoir après le déplacement. ( x+movespeed )

Oui mais ce code suffirait non ?

Code:

if dir==6 and not place_free(x+movespeed,y+1)

EDIT : non tu as raison autant pour moi ; j'avais mal lu ton post

Béh ... Non, puisqu'on veut que ça soit passable en bas ( place_free(x+movespeed,y) ), mais pas passable en dessous de cette position ( not place_free(x+movespeed,y+1) );

Oui je sais désolé je croyais que que tu vérifiait place_free(x,y) ; j'avais pas capté que t'additionnais la vitesse

Merci je vais tester ça et vous en direz plus après

Par contre, où puis-je aller pour me former au langage de programmation de GM8 et connaitre les différentes fonctionnalités.

L'aide ( qui est en Anglais, mais ça passe sans trop de soucis ), ou internet.

La doc est disponible en fr (téléchargeable sur le cbna) mais y a aussi le fabuleux tuto d'onilink_ :
https://cbna.forumactif.com/t10918-apprendre-le-gml-1-initiation

Le premier code fonctionne, mais remplacer les 2 lignes pour que le personnage ne lévite pas dans le vide en allant trop loin ne sert à rien (et en plus le personnage bloque si il rencontre un mur).

Pour mon perso joueur j'ai dû ajouter une notion de gravité et de collision avec le sol. Est-ce qu'on ne doit pas faire quelque chose de similaire pour un ennemi ?

Je cherche également comment faire en sorte que le personnage se retourne en bout de course.

Tu veux qu'il se retourne quand il rencontre un mur ?
Si oui, essaie ce code :
Event collision mur
[code]

if other.y<=y
{
// tu modifie ton code pour qu'il change de sens, change la direction ou inverse la vitesse
}

Je retiens le code de collision mais j'ai décidé de faire "plus simple pour le moment (en tout cas sur cet ennemi).
Par contre j'ai trouvé la solution du "retournement" j'ai tout simplement ajouter sprite_index aux 2 premières conditions.

Avant d'aller plus loin, je me rends compte qu'il me faut peut-être avant réfléchir aux notions de barre de vie, game-over, etc. pour mon perso. Ai-je tort ? Ou alors est-ce que je peux déjà voir pour que cet ennemi tue mon heros et sois lui-même tué par lui ?

Bah ca dépend si tu veux que le héros meure directement dès qu'il touche un ennemi ou juste qu'il perde de la vie.

Mais tu devais lire un peu la doc avant de te lancer dans un vrai projet ; c'est vraiment pas compliqué et tu pourra faire des trucs vraiment évolué. Il y a aussi les tutos d'onilink_ qui te permettrons de maitriser les notions de base comme les variables, boucles, tableaux,etc...

Le problème si tu te lance dans un grand projet sans prendre le temps de lire la doc et/ou des tutos c'est que tu va te retrouver avec un jeu ou la qualité du code est inégale.

Je me rappele un jeu que de course que j'avais fait à mes débuts ; je connaissais ni les boucles ini les tableaux, et je voulais faire qu'on puisse customiser le design de sa voiture (à la NFS) : résultat je me suis retrouvé avec 20 000 lignes de code toutes identiques à 2/3 trucs près et un chargement de près d'une minute....
Bref j'ai bousillé un jeu qui aurait pu être pas mal ; donc si tu veux pas faire comme moi....

Il me semble qu'il y a un exemple sur le site Yoyogame : http://sandbox.yoyogames.com/make/tutorials

Le mieux c'est de développer en premier les éléments prépondérants du gameplay : le moteur physique complet (qui va être le cœur du système, et doit être fait minutieusement pour un bon gameplay), la barre de vie s'il y a, un ennemi générique pour tes tests... Sans rentrer dans les détails des évènements particuliers (un petit show_message() pour notifier que le joueur meurt à ce moment-là est simple et rapide pour débugger).
Ensuite tu rajoutes les différents éléments secondaires du jeu : les différentes sortes d'ennemis, les IA, les obstacles et pièges, tu commences le mapping.
Puis, tu fignoles : tu fais les graphismes, effets de particules, l'écran de Game Over qui vient remplacer ton message de débug, tu continues le mapping.
Ensuite les éléments d'interface, les menus. Tu auras pris soin d'utiliser des variables pour les contrôles du perso, la densité des particules, etc, que tu déclarais en tant que constantes pour les tests. Il ne reste plus qu'à les lier à l'interface pour faire le menu de configuration !

Une chose dont j'ai pas parlé, c'est les sons : parce que je n'ai jamais vraiment fait gaffe à eux (pas bien !), mais une chose sûre : ne PAS commencer par rechercher des sons ! Ils doivent intervenir plus tard, catégorie "fignolage". Sinon on se retrouve rapidement à passer des heures de recherche pour une seule musique, sans avoir posé un seul bout de code sur lequel l'appliquer. De plus, chercher sans avoir sous les yeux le matériel concret censé recevoir la musique nuit à l'objectivité (on se retrouve à comparer les musiques entre elles plutôt qu'avec le jeu dont on veut créer l'ambiance...). Pire encore, si un tournant drastique advient dans le développement, ce sont des heures de recherche perdues !

+1 D-z

t'en fait pas tu va y arriver moi aussi j'ai galéré la 1er fois.

D-z a écrit:

Le mieux c'est de développer en premier les éléments prépondérants du gameplay : le moteur physique complet (qui va être le cœur du système, et doit être fait minutieusement pour un bon gameplay), la barre de vie s'il y a, un ennemi générique pour tes tests... Sans rentrer dans les détails des évènements particuliers (un petit show_message() pour notifier que le joueur meurt à ce moment-là est simple et rapide pour débugger).
Ensuite tu rajoutes les différents éléments secondaires du jeu : les différentes sortes d'ennemis, les IA, les obstacles et pièges, tu commences le mapping.
Puis, tu fignoles : tu fais les graphismes, effets de particules, l'écran de Game Over qui vient remplacer ton message de débug, tu continues le mapping.
Ensuite les éléments d'interface, les menus. Tu auras pris soin d'utiliser des variables pour les contrôles du perso, la densité des particules, etc, que tu déclarais en tant que constantes pour les tests. Il ne reste plus qu'à les lier à l'interface pour faire le menu de configuration !

Une chose dont j'ai pas parlé, c'est les sons : parce que je n'ai jamais vraiment fait gaffe à eux (pas bien !), mais une chose sûre : ne PAS commencer par rechercher des sons ! Ils doivent intervenir plus tard, catégorie "fignolage". Sinon on se retrouve rapidement à passer des heures de recherche pour une seule musique, sans avoir posé un seul bout de code sur lequel l'appliquer. De plus, chercher sans avoir sous les yeux le matériel concret censé recevoir la musique nuit à l'objectivité (on se retrouve à comparer les musiques entre elles plutôt qu'avec le jeu dont on veut créer l'ambiance...). Pire encore, si un tournant drastique advient dans le développement, ce sont des heures de recherche perdues !

Merci des conseils
J'essaie d'avancer dans ce sens. Mais j'ai besoin de me rassurer dans ce genre de projet, par exemple si je réfléchis à un ennemi avec une capacité particulière j'ai besoin de savoir de suite (ou presque, lol) si c'est faisable ou pas (et de mon niveau aussi).
J'ai trouvé un PDF de l'aide de GM6. Ça m'aide, mais je trouve ça trop sommaire dans les explications, notamment concernant la syntaxe du GML. C'est un peu frustrant parce par exemple sur un ennemi que j'essaie de créer, je vois ce qu'il faut faudrait faire (une solution plausible en tout cas) mais je galère à mettre correctement et à régler les bouts de codes :/
Mais c'est déjà un bon point de trouver une communauté aussi réactive et prête à aider ^^ (ça devient rare sur le web...)

une conseil télécharge plusieurs exemples et tu verras

En réalité, tu pourras toujours coder ton jeu selon ce que tu veux, il n'y a pas de limite à ce que tu peux faire (hors limites machine, mais ça devrait aller pour n'importe quel ennemi ou boss de jeu de plates-formes...). Bien sûr ça sera plus ou moins difficile à coder, mais c'est de là que vient la p-p-p-puissance

Tiens justement je sais pas comment aborder une situation.

Je cherche à créer un ennemi un peu particulier. Il est toujours statique, il titre un laser (vers la gauche exclusivement) sur une certaine distance (on va dire 150 pxl) mais uniquement si le joueur passe devant lui (dans un rectangle qui fait 30x150pxl).

Je galère avec le système de collision (dont je ne comprends pas les réglages en fait), et je ne sais pas si je procède bien. En effet, je me suis dit qu'il me faudrait mettre des bloc invisibles devant l'ennemi pour que dès que le joueur passe dessus il soit touché. Je suis donc parti sur un Event collision avec ce fameux bloc invisible, sur l'objet Joueur.

Est-ce une démarche qui vous parait cohérente ou est-ce que je suis à côté de la plaque ?

T'est a coté de la plaque x)

Utilise une collision par bounding box, donc soit avec quelques conditions, soit avec une fonction adaptée (ici collision_rectangle).
Puis vu que c'est un laser tu peut même utiliser collision_line

lol, je m'en doutais un peu.

Mais qu'entends-tu par "bounding box" ?

Ben 'boite de collision' :p
http://www.siteduzero.com/tutoriel-3-254500-formes-simples.html#ss_part_2

Mais dans GM la fonction collision_rectangle te permet d'éviter de le faire a la main.

Ok.

Je créer donc un Event collision avec l'obj joueur dans l'obj ennemi, puis un code. Après je n'arrive pas à saisir (malgré ton lien) comment paramétrer "collision_line(x1,y1,x2,y2,obj,prec,notme)".

Désolé de faire mon noob de service, mais x1, y1 etc.... j'arrive pas à en saisir la logique. J'me doute que c'est des variables, mais ça s'arrête là :/

X1 : position sur l'axe horizontal (axe x) du début de ton rectangle
Y1 : pareil mais sur l'axe vertical (axe y)
X2 : position x de la fin de ton rectangle
Y2 : pareil mais en y
Obj : l'objet qui doit être détecté dans le rectangle ; tu peut mettre all mais tu devrais mettre ton objet heros
Precise : si tu veux que la collision soit au pixel perfect ou un simple carré de la taille de ton heros ; en général on met 1
Notme : l'instance dans laquelle est exécutée le code ne sera pas prise en compte, met a 1 aussi

Ok merci, mais ce que j'ai du mal à comprendre c'est le repère des axes x,y : est-ce la room ou le sprite de l'obj ? Et si c'est l'obj, où commence x et y, au coin bas-droit du sprite, ou autre part ?
Je m'explique en dessin :


J'ai testé ça, sans résultat : if collision_line(x,y+17,x-150,y+17,heros,1,1) { sprite_index=ennemi-tir }

Dans l'éditeur de room, la position de la souris est indiquée en bas.
La position 0,0 est en haut à gauche de la room ; si tu veux avoir la position d'un objet, utilise les variables x et y.
La position d'un objet est déterminé par l'origine du sprite : par défault elle est de 0,0 donc si tu créer un objet en 32,32, le coin haut-gauche sera à la position 32,32 ; si l'origine est a 16,16, le coin haut-gauche sera dessiné en 32-16 ; donc 16,16.
Je me suis peut-être mal expliqué mais il est indispensable de bien comprendre l'origine et les positions ; par exemple, la rotation d'un sprite se fait autour de son origine.

Ok, par rapport à ton explication, dans l'objet Ennemi j'ai créé un Event Create, puis le code "if collision_line(x,y-17,x+150,y-17,JDG,1,1) {object_delete(JDG)}"

Donc en passant devant l’ennemi il devrait se passer quelque chose ? et bien là rien :'(
C'est assez frustrant parce que je comprends le principe de collision_line et du coup je n'arrive pas à saisir pourquoi ça ne marche pas.