quelques questions après lecture de la bible de GM

image_angle = direction

Merci pour ta réponse onilink_.
Malheureusement ça je l'ai déja fait, et ça ne correspond pas à ce que je cherche à faire.

Le soucis de cette fonction, c'est qu'elle change l'angle du sprite d'un certain degré lorsque le path change de direction.
Dans mon cas, le sprite doit pouvoir changer de direction au milieu d'une ligne droite.
Par exemple un long mur avec une fenêtre au milieu. L'ennemi longe le mur en regardant vers le haut ou le bas, mais arrivé à la fenêtre il regarde vers celle-ci.

Ou alors je n'ai pas compris comment marchait la fonction.
Mais à priori, ce n'est pas possible de faire ça avec celle-ci.

J'en suis vraiment pas sûr, mais je crois qu'il y a une checkbox dans l'éditeur de path pour que l'angle suive la direction, essaie de la décocher...
Comme dit je suis pas sûr, je confonds peut être....

Nop, je vois pas.
Il y a une check box pour fermer ou non le chemin automatiquement, et un list blox à deux boutons pour savoir si on veut que ce soit des angles droits ou des courbes qui constitue le chemin.
Ensuite ce sont les options classiques de vitesse, etc... mais rien sur l'orientation du sprite.

La seule solutions que je vois pour le moment, c'est de faire le chemin à la main en GML. Là ça règle le soucis. Par contre si je dois créer le chemin en GML pour chaque ennemi, c'est juste du délire total^^
Vu que c'est exactement le comportement des ennemis dans "hotline miami" et qu'il a été sous GMS, je doute très sincèrement que ce soit la solution qu'ils ont adopté...
Il y a forcément une solution simple, mais là j'ai le cerveau qui fond... je trouve vraiment pas... :/

Tu veux définir toi même les angles pour chaque point de ton path?
T'as forcément besoin d'utiliser des smooth curves? (ça complique le moyen que j'ai en tête mais y a surement moyen avec)

Exact, ce serait l'idéal.
Pour le path, je n'ai aucune curves, uniquement des straight.

Je crois avoir trouvé un moyen de faire ça de manière pas trop compliqué (et en fait ça marche aussi sur les smooth curves).
Je teste et je poste si ça fonctionne.

OMG, tu risques de me sauver la vie!!  

Je suis aussi en train de me battre avec les collision_circle/line aussi... c'est un vrai casse-tête...
Décidément, je n'ai pas fini d'en baver... XD

Pour les collisions normalement GM intègre tout ce qu'il faut: collision_xxx

Pour ce qui est de ton problème j'ai trouvé une solution:
Il te faut créer un tableau d'angles voulus en fonction du pourcentage du parcours du path.
Par ex tu veux qu'au début ton perso regarde a droite, au milieu du path a gauche, puis a la fin en haut:

Code:

tabAngles[0] = 0
tabAngles[1] = 180
tabAngles[2] = 90
nbAngles = 3

Tu lances ton path avec un path_start(path0, 3, true, true)

Pour récupérer l'angle en fonction du pourcentage du parcours du path:

Code:

t = path_position * (nbAngles-1)
ind = floor(t)
a1 = tabAngles[ind]
a2 = tabAngles[ min(ind+1, nbAngles-1) ]
angle = interpolationLineaire(a1, a2, t - ind)

interpolationLinaire (script a ajouter):

Code:

return argument0 * (1 - argument2) + argument1 * argument2

Tu peux d'ailleurs utiliser une interpolation cosinus pour un rendu plus doux.

Je suis vraiment désolé onilink_, mais je n'arrive pas à faire marcher ta solution...

j'ai crée un event "create" avec un fichier code contenant l'initialisation du tableau et du path:

Code:

tabAngles[0] = 0
tabAngles[1] = 180
tabAngles[2] = 90
nbAngles = 3

path_start(pth_ennemi,2,1,1);

Puis j'ai créé un event "step" avec les vérifs à effectuer:

Code:

t = path_position * (nbAngles-1)
ind = floor(t)
a1 = tabAngles[ind]
a2 = tabAngles[ min(ind+1, nbAngles-1) ]
angle = interpolationLineaire(a1, a2, t - ind)

J'ai enfin créé un script "interpolationLineaire" avec la ligne dedans pour le retour.
Et rien... je n'ai pas de changement d'angle.

J'ai fait comme ça supposant que c'était la bonne méthode, mais je pense que je me plante lamentablement...
Désolé

En fait la 'valeur de retour' est dans la variable angle.
Du coup si tu veux visualiser ça, il serait judicieux de faire a la suite un image_angle = angle
(ou remplacer angle par image_angle directement)

c'est image_angle, pas angle

Edit : mince, trop tard ^^

Oh purée oui en effet...
Merci Onilink_ et GrandeLangue d'avoir mit le doigt sur ce qui n'allait pas. Je n'avais même pas capté... TT

Du coup ça marche super bien, c'est le top.
Merci beaucoup beaucoup, c'est vraiment génial Onilink_.
Chapeau pour cette solution!

Content que ce soit bien ce que tu voulais

Sinon si tu as plusieurs objets qui utilisent ce système, n'hésites pas a en faire des scripts.

Par ex:
addAngle(angle) pour l'initialisation du tableau
updateAngle() pour l'update de l'image_angle

Ou sinon tu peux toujours faire un objet parent, dont tu feras dériver les objets qui auront besoin de ce système.
En fait sous GM, ça reviens exactement au même. A toi de voir ce que tu préfères.

Oui, c'est ce que je pensais justement. Faire un archétype et le décliner ensuite en héritage pour me faciliter la vie

Alors juste une dernière question (promis, après mon cerveau ne tiendra pas le choc de toute façon^^).

Je suis en train de tester les collision_line, et ça marche très bien dans un sens.
Je viens d'ailleurs de découvrir qu'on ne pouvait tester cette fonction qu'avec "noone" et non pas des booléens comme je tentais de le faire. C'est pourquoi ça ne marchait pas jusque là...
Encore un truc qu'ils ont oublié de préciser dans la doc :p

Alors la vérif se fait parfaitement, dès qu'il y a un objet dans la ligne de collision, j'obtient ma réaction.
Le soucis, c'est que ça détecte quand le garde est de côté, de dos, etc...
Logique puisque la détection c'est juste une ligne tirée entre deux objets.
Mais ce que je voudrai, c'est que le garde ne me voit que lorsqu'il est plus ou moins face à moi (angle de vision à déterminer).
Je pense du coup que cette fonction n'est pas la bonne.

La solution pourrait être du coup de réellement créer un cône de détection en invisible qui servirait de point de contact avec le joueur. Comme ça on aurait aussi bien l'angle d'ouverture que la distance de visibilité.
Mais niveau collision c'est un peu le bordel... il faudrait que le cône rétrécisse lorsqu'il rencontre un mur pour ne pas passer à travers. Mais selon la distance du garde avec le mur, comment gérer ça?...

Bref, peut-être qu'en fait c'est possible de faire tout ça avec un collision_line, mais j'ai un doute.
Sinon la seconde solution est-elle envisageable?
Mais la encore, je pense qu'il n'y a pas vraiment de solution simple clé en main :p

En gros, ce que tu veux c'est que chaque garde ai un cône de vision, et puisse détecter le joueur?

Ce que je ferait, pour chaque garde:
1. Calcul de la distance avec le joueur, si joueur assez proche passer a 2.
2. Un produit vectoriel pour savoir si le joueur est dans le cône de vision. Si le joueur est bien dans le cône de vision, passer a 3.
3. On fait en sorte de savoir s'il y a des obstacles entre le garde et le joueur. Surement la partie la plus chiante pour que ce soit bien réussi.
Pour cela une idée possible:
Tu utilises cette fonction pour connaitre le premier obstacle dans la direction du joueur, tu compares avec la distance réelle qui sépare le garde du joueur. Si la distance trouvée est plus petite que la distance réelle, alors y a un obstacle, sinon le joueur est bien visible.
Par contre lancer un seul rayon ne suffira peut être pas (dépend de la taille du joueur et des obstacles), et dans ce cas tu peux en envoyer plusieurs et faire les même tests. Si un des rayons atteint le joueur, alors c'est gagné.

Bon après y a peut être des solutions plus simple/efficaces, mais a vrai dire je me suis jamais penché sur le sujet auparavant

moi j'utilise collision_circle, et je me sers des fonctions lengthdir_x et lengthdir_y pour orienter le cercle en fonction de la direction exemple:
if collision_circle(x+lengthdir_x(300,direction),y+lengthdir_y(300,direction),250,object,1,1)
{}

fais la même chose mais avec un draw pour voir ce que ça donne genre:

draw_circle(x+lengthdir_x(300,direction),y+lengthdir_y(300,direction),250,1)

C'est pas un conne de vision mais bon un cercle c'est ce que j'ai trouvé de plus ressemblant.

Pour l'étape 3. de Onilink, ce serait beaucoup plus simple d'utiliser le collision_line entre ta position et celle du garde pour savoir s'il y a intersection avec un objet mur.

Ha oui et tu peux combiner ce que j'ai écris avec un collision_line orienté entre le garde et le perso pour détecter si il y a un mur entre les deux. Ca donnerait un truc comme ça:

if collision_circle(x+lengthdir_x(300,direction),y+lengthdir_y(300,direction),250,perso,1,1)
{
if not collision_line(x,y,perso.x,perso.y,obj_mur,1,1)
{
// tous ce que tu veux  
}
}

Classe, tout plein de réponses!

Je vais tenter un peu tout ça et voir ce que ça donne. Je vais fais un bon mix pour tenter de trouver quelque chose d'optimal.

Merci beaucoup pour votre aide, c'est chouette!

Rebonjour à tous,

alors me voilà avec un nouveau soucis que j'ai bien du mal à comprendre.

J'ai un personnage, et je gère mes déplacements avec des motions_add.

Voici le code en question qui se trouve dans un event "step" de mon objet personnage:

Code:

if keyboard_check(90)
{
    motion_add(90, vitesse);
}

if keyboard_check(83)
{
    motion_add(270, vitesse);
}

if keyboard_check(68)
{
    motion_add(0, vitesse);
}

if keyboard_check(81)
{
    motion_add(180, vitesse);
}

Ca marche très bien (normal, il n'y a rien de bien dingo là dedans...), sauf pile poile au lancement de la room.
Le truc que je ne m'explique pas, c'est que si j'attends une petite seconde après le lancement et que je déplace le personnage, tout est nickel... aucun soucis.
Par contre si j'ai le malheur d'appuyer sur les touches de déplacement au moment du lancement de la room, mon perso part comme une fusée dans la direction, et traverse une distance hallucinante en un step... Oo

Là je demande votre avis expert, parce que c'est très très étrange... :/

Essaie de mettre un motion_set(0,0) dans le create, à tout hasard...

Et non malheureusement, ça ne marche pas. J'avais déjà tenté cette solution en fait (oublié de le préciser :p).
J'ai tenté d'initialiser la vitesse, la position etc... en début de room puis de laisser le step fait son boulot ensuite, mais ça n'a rien changé.
C'est un peu comme si durant une seconde à la créa de la room, l'objet possédait des attribue incohérents... :/

Moi sinon ce que je fais:

dans create:

Code:

vg=0 //vitesse gauche
vb=0 //vitesse bas
vd=0 //vitesse droite
vh=0 //vitesse haute
vm=5 //vitesse max
acc=0.4 //acceleration
dec=0.5 //deceleration

dans step:

Code:

if keyboard_check(ord("Q"))
{vg+=acc}
else
{vg-=dec}
if keyboard_check(ord("S"))
{vb+=acc}
else
{vb-=dec}
if keyboard_check(ord("D"))
{vd+=acc}
else
{vd-=dec}
if keyboard_check(ord("Z"))
{vh+=acc}
else
{vh-=dec}

if vg>vm{vg=vm}
if vg<0{vg=0}
if vb>vm{vb=vm}
if vb<0{vb=0}
if vd>vm{vd=vm}
if vd<0{vd=0}
if vh>vm{vh=vm}
if vh<0{vh=0}

for (i=0;i<vm;i+=1)
{
if place_free(x-1,y)
{x-=vg/vm}
if place_free(x,y+1)
{y+=vb/vm}
if place_free(x+1,y)
{x+=vd/vm}
if place_free(x,y-1)
{y-=vh/vm}
}

Black_cat a écrit:

C'est un peu comme si durant une seconde à la créa de la room, l'objet possédait des attribue incohérents... :/

Ah bah tiens, ils ont peut être oubliés d'initialiser des variables  

Étrange comme bug, a croire qu'ils te poursuivent :b
En tout cas sur mes versions < GMS ça ne le fait pas.

Histoire de pas poster pour rien, au lieu de faire un keyboard_check(81), fait un keyboard_check(ord('Q')), c'est plus lisible.

Sinon vu que GMS est gratos depuis peu je l'installerais peut être voir si on peut faire quelque chose dans avoir a ajouter des conditions a la con.
(genre une variable qui attend que le premier step soit écoulé avant de laisser le joueur bouger l'objet).

onilink_ a écrit:

Ah bah tiens, ils ont peut être oubliés d'initialiser des variables  

Bah tiens, ça me fait penser que j'ai eu une réponse à ce propos. Là voici :

Citation :

Hi there,

Please use this function to set the seed to a random value:

randomize();

Should you need to keep a consistent value over a number of runs of a game, you should be using random_set_seed().
Please note, that when using the random number functions in GameMaker:Studio the initial seed is always the same, as this makes tracing errors and debugging far easier. Should you wish to test with true random, you should call this function at the start of your game.

Hope this helps.

Il semblerait donc que ce soit fait exprès pour des histoires de traçage au niveau debug...
Il faut le savoir quoi.

onilink_ a écrit:

Histoire de pas poster pour rien, au lieu de faire un keyboard_check(81), fait un keyboard_check(ord('Q')), c'est plus lisible.

En effet, je n'avais pas encore regardé comment on remplaçait le ascii dans GML, et j'avais un peu fait ça à l'arrache^^
Maintenant je sais comment on fait !

onilink_ a écrit:

genre une variable qui attend que le premier step soit écoulé avant de laisser le joueur bouger l'objet

C'est ce que je me suis dit à un moment, mais ça me soule de faire une bricolage cracra pour un truc complètement incohérent...
Qui a dit que j'étais psychorigide?!!?  

@chopsuey
Merci pour ta réponse.
C'est clair que ça marche tout aussi bien comme ça, et si vraiment je ne trouve aucun moyen "normal" de régler ça, je passerai par ce type de solution.
Ceci-dit, ça m’énerve un peu d'avoir un code parfaitement fonctionnel, et d'obtenir une réaction incohérente à un instant T. J'aimerai vraiment comprendre d'où ça vient... :/

Au cas ou tu te servirais de mon code je l'ai réédité, j'avais fais n'importe quoi dans la boucle.

J'ai en effet résolu mon soucis en changeant carrément de code.
Bon bah je saurai pas pourquoi ça marchait pas, mais au moins maintenant ça marche^^

Merci chopsuey pour la mise à jour de ton code!
(Je suis méga ultra fan de ton gif... !!)

Sinon petite question du jour.
Oh que oui vous en avez marre de moi... oh que oui :p

Est-il possible de faire des conteneurs dans GMS?

En fait, j'ai par exemple un garde. A lui est attaché une zone de détection, deux lignes de collisions (une courte et une longue), ainsi qu'un faisceau lumineux.
C'est un peu la configuration de base de tous mes gardes.
Tout est initialisé à la création de chaque objet pour coller aux coordonnées et à l'angle du garde, et roulez jeunesse.

Sauf que...
Si je veux faire plusieurs gardes, il faut à chaque fois que je place un garde dans la room, tous les objets de détections, et que je replace mon code...
Bon, c'est pas non plus la mer à boire, on est d'accord, mais en code pure, c'est quand même plus simple que ça.
Je fais un objet qui contient tous mes objets, et bim, je le place où je veux comme conteneur, et on en parle plus.

Sauf que dans GMS, je ne vois pas du tout comment faire...^^
Des objets dans des objets...
Comme quoi, une interface graphique c'est bien pour certains trucs, mais il y en a d'autre, je trouve ça moins parlant.
Il y a évidemment une possibilité simple de faire ça, je n'imagine même pas le contraire. Mais là... je vois pas...

Je suis pas sûr de bien comprendre ce qui te pose problème.
qu'est ce que tu veux dire par  " et que je replace mon code..."

Tu peux faire un objet obj_creation_garde, dans le create de cette objet tu mets des instance_create(x,y,obj) de tous tes gardes avec les coordonnés qui correspondent.

Mais je vois pas bien l’intérêt, si ton problème c'est de devoir replacer des objets de détections de chaque gardes, pourquoi ne pas mettre un instance_create des objets de détections dans le create de l'objet garde.
Comme ça tu pose ton garde la ou tu veux et c'est tout.

Bah pour faire un objet qui en contiens d'autres, rien de sorcier.
Il faut juste savoir qu'une instance est toujours allouée dynamiquement, du coup tu dois faire:

#Create (allocation)

Code:

nb = 10
for(i=0; i<nb; i+=1) ins[i] = instance_create(x + lengthdir_x(80, i*360/nb), y + lengthdir_y(80, i*360/nb), Guard)

#Destroy (desallocation)

Code:

for(i=0; i<nb; i+=1)
{
  if(instance_exists(ins[i]))
    with(ins[i]) instance_destroy()
}