GameMaker - FAQ

[back]

J'ai hésité à poser mes questions directement dans le topic d'Alec, mais autant prendre de bonnes résolutions tout de suite.

Je propose donc un topic pour poser les problèmes ou de simples questions méthodologiques rencontrés dans gamemaker.

Ce topic ne servira d’ailleurs pas à présenter le projet dans lequel je me lance, j'en parlerais ailleurs quand tout ça aura un peu évolué/émergé/commencé.

***

Bref, toujours est-il que j'ai attaqué une maquette de shoot histoire de poser quelques bases de mon game design et je suis confronté au problème suivant :

Je réalise un shoot vertical et la progression du vaisseau se fait donc sur l'axe des Y. Malheureusement l'origine de Y se trouve en haut de ma Room et du coup je dois décrémenter la position de mon vaisseau au lieu de l'incrémenter. Ca ne pose pas de gros problème si on reste sur un format fixe mais j'imagine bien que ça ne sera pas le cas et que la taille de ma Room sera susceptible de s’agrandir ou diminuer, décalant ainsi tout le contenu du jeu.

Du coup ma question est simple : est-il possible de placer l'orgine de Y en bas de la Room ? Sinon quelle est la méthode la plus simple ? Définir un Ygame en jouant avec la hauteur de la Room ou travailler le jeu "à l'envers" et tourner l'ensemble de la Room sur le rendu final ?

Merci d'avance
Je préfère poser ces questions toutes bêtes histoire d'éviter de garder des "problèmes" assez longtemps qui me pourriront bien la vie.

[Alec]

Utilises les "view" tu fais ta room et tu place la view à l'endroit que tu veux (en haut, ou en bas !

Bien sur il faut que cette même view se déplace vers le haut !
Et à la même vitesse que ton vaisseau !

Hein Gunny, j'ai bon ?



Je crois même que tu peux faire suivre la view (sur le sprite joueur par exemple) ce qui peut te permettre de faire un léger scrolling horizontal à la raiden !

Après comment faire ça......
Je peux pas t'aider plus !

[back]

Pour le scrolling horizontal c'est déjà fait . Etant (comme tu t'en doute) très influencé par Cave, c'est un des premiers trucs que j'ai implémenté. Je scroll ma view de 1 ou 2 quand je déplace mon vaisseau de 5 ou 10 (shot / laser).

Mais en fait tu as esquivé la question, j'ai en effet placé ma view en bas et elle monte (normal).

Le soucis c'est le suivant : le Y=0 est en haut de la room.

Du coup tu poses ta view à Y=5000 (par exemple).

Le soucis étant que si je veux en cours de route allonger ma room à 6000, les 1000 de hauteur supplémentaire vont apparaître en bas, et donc sous ma view et je serais bon pour tout décaler !

Du coup mon but c'est d'avoir le Y=0 (de la room) en bas et non en haut.

[Radigo]

En Flash l'origine est aussi en haut à gauche. Il me semble que c'est un placement généralisé pour bien des moteurs. Le plus sage est de t'adapter à ce placement sur ta scène pour prendre de bonnes habitudes.

C'est perturbant de dire "va vers l'avant = diminue la coordonnée Y", mais on s'y fait à la longue. Si tu commences à inverser l'axe des Y tu cours au devant d'emmerdes assez énormes (genre les calculs de visée automatisés de GM, etc...), et si tu baisses ta view il faudra tout initialiser en négatif.

Sans compter le temps de calcul supplémentaire. Bref, très mauvaise idée...

[back]

Du coup tu me conseilles de déterminer une taille fixe de niveau et de m'y tenir ?

Du genre : 2mn de scroling classique + un loop sur le boss ?

En flash j'avais pas eu ce problème pour la bonne raison que je n'avais pas de view, mais un background qui défilait et un tableau générateur d'ennemis.

[Gunny]

Plutot que de se prendre la tête avec une room gigantesque et un scrolling de view :

1) Faire une room de la taille d'une view. par exemple si ta résolution est 1024*768 tu fais une room légèrement plus haute ( de la taille du plus gros ennemi )

2) faire scroller le BG plutot que la view.

3) utiliser une timeline pour créer les ennemis ( sur une petite room, tu ne peux pas placer tes ennemis à l'avance )

Dans le cas d'un scrolling de view avec une grande room :

1) utiliser les coordonnées de view plutot que les coord globales. ( type : view_xview, view_yview )

2) faire scroller la view

3) utiliser la timeline pour créer les ennemis ( dans un soucis d'économie de RAM ) ou activer les objets hors view au bon moment ( ce qui sous-entend que tes objets hors view sont désactivés dans la room par défaut )

[back]

Merci pour les réponses
A vrai dire je pensais monter mon background à base de tiles du coup (sauf si la première méthode à un véritable intérêt pour le jeu) je m'orienterais tout de même sur la 2ème méthode.

Et nickel pour les timeline, ça anticipe une question.

[back]

Question bonus pour Gunny !

Toi qui à l'air de t'y connaitre un peu en mémoire.

Est-ce que le fait de placer directement tous les monstres sur la Room avec un joli
"instance_deactivate_region" / "instance_activate_region" qui les empêche de bouger/tirer avant d'arriver dans la zone visible serait tout de même trop lourd en ressources ?

Ça me simplifiait grandement la tâche au niveau de l’intégration de toutes ces petites bébêtes

[Gunny]

Le must :

Utiliser une timeline.

Marche à suivre pour ton level design :

1)Avoir la room comme il faut.
2)Régler ton scrolling.
3) créer un objet de contrôle qui va avoir une variable nommée "etape" initialisée à 0
4) Dans le step event de ton objet de controle, un script avec

Code : Tout sélectionner

etape+=1;

5) Placer ton ennemi visible et activé dans ta room ( sans les mouvement ).
6) Lancer en debug et afficher les variable locale de ton objet de controle
7) Quand ton ennemi apparait, tu mets en pause, et tu regarde la valeur de ta variable.
Dans ta timeline, au step que tu as noté, tu actives ton objet avec un script ( ou un peu avant pour pas qu'il apparaisse subitement à l'écran, c'est juste une question de réglage fin )

C'est propre, malléable, et réutilisable

[back]

Super, j'essayerais ça en temps voulu.

J'suis bien content de ma soirée j'ai réussi à mettre au point un système de comptage de boulettes à l'écran (+scoring qui va avec) et un moyen de ralentir les boulettes qui passent dans une zone définie par le joueur.

+smartbomb
+pas de bugs
+ennemis/tirs détruis hors de la zone.

Tout marche, j'aime gamemaker.

[Gunny]

Le comptage de boulette, c'est pas difficile si tu t'y prend comme il faut
En mode crade et brutal, ca prendrai un script pour chaque type de boulette d'une ligne et une variable globale...

En mode propre : 1 script, une option a définir sur les boulettes, un objet de controle.
( les variables globales, c'est moche, c'est modifiable par "tout le monde", éviter autant que possible )

[back]

Bin j'ai un oBoulettesEnnemis (en gros) qui est parent de toutes les boulettes ennemies.
Du coup ouai j'ai une variable globale NBboulettes qui s’incrémente chaque fois qu'une boulette est créée. Et qui décrémente chaque fois qu'une boulette est détruite hors de la zone ou que je pète toutes les boulettes à l'écran via une bombe ou le système de score que j'ai mis au point.

J'imagine donc que j'ai fais en crade.

[Gunny]

Un mix crade/propre
Sachant que tu as un truc qui s'appelle instance_count() ou qqc dans le genre.

Et avec des connaissances de la programmation orientée objets, tu peux bénéficier de l'héritage type "est-un"

Ce qui fait que... Tu peux bénéficier d'une sorte de polymorphisme, de surcharge de fonctions ( pas aussi puissant et souple qu'en C++ ).

Non, ta variable ne s'incrémente pas, elle est incrémentée par d'autres objets Et ca, en orienté objet, c'est mal quand c'est direct
Tous les autres objets ont directement accès aux variables globales.

Il vaut mieux utilisée un objet de controle pour la sécurité des données.
Car on ne peut pas accéder directement à la variable d'un autre objet.
Et au moins, le jeu te sortira une erreur si jamais tu merde quelque part

Il faut utiliser la méthode :

Code : Tout sélectionner

with (objet) {instructions;} // syntaxe complete pas forcément évidente avec la doc

( pour les codeur, ca fait le boulot d'une méthode d'accès publique meme si c'est délicat à utiliser )

Pareil pour le score, c'est une variable globale, c'est mal ( surtout pour un système de scoring pour un shoot, faut que le truc soit carré )

En terme d'instruction, je suis pas sûr que l'incrémentation et la décrémentation soient les plus efficaces...
Tu as l'instruction instance_count( objet) ( de mémoire, jamais utilisée, donc peut-etre erroné sur l'orthographe ). Tu la lance chaque step.

Imagine, ton joueur est soudain en train de péter le TLB qui arose magistralement à 1000 bullets/s. En cas de smart, t'as 1000 instructions à exécuter de décrémentation.
Bon, c'est pas forcément dramatique, mais t'as toutes les opérations de destructions des objets qui vont venir s'ajouter

Si tu peux éviter de lancer une instruction sur un objet meme léger en grand nombre, faut pas s'en priver Ca fait des ressources pour autre chose ( et gamemaker est relativement gourmand en RAM/CPU si on ne fait pas attention )

MAIS on rentre dans les subtilités, donc tant que ca marche, je taperais pas sur les doigts sauf si c'est vraiment crade

[back]

justement j'utilise le with au moment de lacher ma smartbomb et dès que je dois détruire des objets en masse et du coup j'en profite pour mettre un NBboulette = 0.

Après voilà, je n'ai que de vagues connaissances de l'action script / processing, du coup je fais ce que je peux. Mais continue à tapper sur les doigts, c'est formateur.

[Gunny]

Si tu as d'autres questions, hésites pas.
J'essaierai de pas rentrer dans les détails d'optimisations dans un premier temps...
Il faut d'abord que ca fonctionne avant de se poser la question de l'optimisation

[back]

C'est sympa de ta part.

Pour l'instant tout fonctionne, y'a quelques bidouilles mais ça va. J'essaye de mettre en place tout mon système de jeu avant d'attaquer autre chose, mais c'est finalement assez léger pour un shoot donc je m'en sors. (du moins ça marche comme tu dis.)

[Gunny]

MOuhaha je fais du hors topic mais je suis content

J'ai une piste sérieuse pour créer une IA pour un jeu de voiture qui ne fasse pas que suivre le rail pré établi !

C'est pas très compliqué, mais faut y penser...

Faut surtout faire pas mal de test en mode debug pour comprendre comment fonctionne certains mécanismes xD et là, je me suis penché sur les path.

Au début, je voulais utiliser un path... Mais c'est trop rigide... Je veux que l'ordi puisse se planter ou dépasser un adversaire/joueur.

Après, je voulais prendre un système de waypoint...

Problème, si je fais pas un système complexe et permissif, l'origine de mon objet DOIT passer pile aux bonnes coordonnées pendant un step ( 1pixel a coté et la condition ne sera pas remplie. ) sinon mon objet tourne en rond autour du waypoint.

Mon truc :

1) Je prend le path du circuit.
2) Si rien n'empeche la voiture, elle accélère. Sinon, je calcul un chemin pour dépasser, éviter un objstacle.
3)Je prend cette accélération, et je me déplace sur le path pour récupérer les coord x et y sur le path pour dire à la voiture de se diriger dans cette direction.
4) j'effectue les mise à jour des coord x et y.

Et hop on boucle comme ca

J'ai passé des jours à me demander comment faire... Pffffff
Reste plus qu'à coder maintenant

[niluge]

Qu'est ce que tu entend par rien n'empêche ?
Parceque si ton "concurrent" se deplace en suivant la même physique que ton vehicule joueur, il y a pleinnnn de chose dont il faut se mefier, et particulierment les points d'entrés dans les virages ainsi que la vitesse a l'entré de ceux ci. en oublient certainement encore deux trois truc et en omettant la gestion des virages (qui n'est pas le plus simple):

si route vide devant moi :
est ce que j'ai le temps de decelerer pour atteindre la vitesse conseillé a l'entré du prochain virage ?
oui :
j'accélère en direction du point d'entré du prochain virage
non :
je ralenti en direction du point d'entré du prochain virage
sinon c'est que je doit doubler
calcul du delta de vitesse entre moi et le véhicule concurrent
estimation de la position a la fin du doublage (en prenant en compte les décélération nécessaire)
estimation du risque de se planter en fonction de cette position et de la vitesse estimé a ce moment là
est ce que je prend le risque ? (dépend des carac du concurrent)
oui :
je double
non : j'attends une prochaine occasion
fin

et là je ne cherche même pas a définir la meilleure solution entre doublé par la droite ou la gauche, doublé dans les virages etc...

après tout dépend du niveau d'IA qu'on souhaite. ta solution selon les ressources nécessaire peut être satisfaisante, mais il faudrait peut être mieux détaillé certaine chose et pensé aussi a faire décélérer la voiture de temps en temps ^^ (Attention particulièrement au "si rien n'empêche" qui est un peu vague et ne vas pas t'aider des masses au moment de l'implémentation. ça peut cacher beaucoup de choses)

[back]

Ca marche comment en fait la concatenation dans gamemaker ?

Je voudrais stocker 10 nombres en random dans r0 r2 r3 ... r9

Mon "rand" sort d'un script qui marche (je l'utilise ailleurs sans problèmes).
Visiblement c'est dans le 'r_'+string(i) et j'arrive pas à trouver la bonne manière de l'écrire...

Code : Tout sélectionner

for( i = 0; i < 10; i += 1 )
{
    'r_'+string(i) = rand(-25,+25);
}

Un petit coup de pouce ?

[Gunny]

Je comprend pas trop ce que tu veux faire...
Si tu veux des 10 variables contenant chacune un nombre aléatoire, la méthode la plus simple est celle-ci en utilisant un tableau :

Code : Tout sélectionner

{
for ( i = 0 ; i < 10 ; i += 1 )
    {
     r_[i]=rand(-25,25);
    }
}

Et tu utilises r_[0], r_[1] ... r[9].

[Alec]

Et j'ai vu les sources de son jeu (à Gunny) ça a l'air très prometteur !

Et toi backwash, le theme que tu traites dans ton jeu ?
-Big trip space+vaisseau+terre en péril ?
-Fée qui tire des nuées de cartes magiques sur des ours en peluches maléfique ?
-ou autre ?

Hein dis nous !

[back]

j'étais pas clair, mais toi tu l'as été, ça marche.

[back]

Question 1 : Vaut-il mieux utiliser un background de 6000x600 ou le découper en plusieurs bouts ?

Question 2 : Vaut-il mieux faire tourner le jeu en 30 ou 60 fps ?

Merci d'avance

[Gunny]

Pour de futures optimisations, il vaut mieux faire ce qu'on appelle un tileset.
C'est à dire une grosse image contenant un tas de petites images de tailles identiques ( ca simplifie la gestion avant et après optimisation ).

30 FPS, tu vas manquer de fluidité. Pour un shoot, vaut mieux tourner à 60 fps. Ce qui permettra d'avoir une plus grande précision aussi car tes cycles étant plus courts, tu peux contrôler plus finement les réglages, notamment ceux en step.

[Radigo]

Je pense que Back imagine une image de 6000px de long entièrement dessinée avec que des trucs différents pour faire un décor qui scrolle. Si c'est ça il vaut mieux le découper, dans tous les cas charger un gros bitmap de bourrin c'est pas top.

Le mieux est vraiment de se prendre la tête avec des tilesets mais c'est juste inabordable pour un débutant, il faut déjà maîtriser un peu.

Sinon pour la question du 30/60 FPS, demande à ceux qui ont acheté Gigawing Generations sur PS2 ce qu'ils pensent d'un shmup à 30 FPS...

[Guts]

Sinon pour la question du 30/60 FPS, demande à ceux qui ont acheté Gigawing Generations sur PS2 ce qu'ils pensent d'un shmup à 30 FPS...

C'est claire comme réponse ?

[back]

Merci pour les réponses. Mais du coup on peut faire des déplacements d'un demi pixel ? Car j'ai des trucs qui bougent à 1pix/frame

[Gunny]

Bizarrement, oui...

J'ai déjà constaté des déplacements avec des coordonnées du genre 0.911px en x et 0.122 en coord Y

C'est bizarre, mais ca passe

[back]

Je bug vraiment sur la logique d'un truc là.

J'ai un objet bestiole disons oBestiole
Je créer une ombre à ce oBestiole qu'on va appeller oBestioleOmbre

Jusque là pas de soucis.

Mais comment dire à GM que si oBestiole meurt, alors son oBestioleOmbre associé sera également détruit, sachant que pour le moment l'action qui tue les ennemis est contenu dans la collision entre un oEnemy (parent de tous les ennemis dont oBestiole) et un oShot (parent de tous les tirs de mon vaisseau).

Merci d'avance

[Gunny]

Rend ton objet oBestioleOmbre enfant de oBestiole.
De cette manière, ton objet ombre aura le meme comportement que ton objet bestiole ( et ce sans avoir à réécrire tout le code )

C'est le concept d'héritage qu'il faut appréhender sur la programmation orientée objet.
Un objet hérite de toutes les propriété de tous ces parents ( pour faire simple ) ce qui pose certains problèmes quand on commence à avoir quelque chose d'un peu complexe

C'est là qu'interviennent la surcharge et le polymorphisme.
La surcharge dans gamemaker est faite en réécrivant l'event que l'on veut modifier.
Si l'on veut ajouter une fonctionnalité à un enfant sans écraser ce qui a déjà été fait... C'est plus complexe.

Dans ton cas...
oEnemy est ton objet de base.
oBestiole un enfant de oEnemy.
oOmbrebestiole est-il plus proche de oEnemy ou de oBestiole dans son comportement ?
C'est là que tu choisis qui est parent de ton oOmbreBestiole

Mais moi, au vu du nom de ton objet, je serai plutot d'avis d'ajouter un sprite à l'affichage plutot que d'utiliser un nouvel objet...
Car j'en déduis que ton ombre n'a rien à voir dans un quelconque mécanisme de jeu, c'est juste un élément décoratif.

Il serait donc plus avantageux d'utiliser ton event draw pour afficher le sprite de ton objet, puis sur un layer inférieur afficher le sprite de l'ombre.

Mais là, je me pose aussi la question de... N'aurait-il pas été plus simple d'éditer ton sprite, inclure ton ombre, régler le canal alpha sur ton ombre et enregistre ton image au format PNG ?
Maintenant que GM gère le PNG et le canal alpha en natif... Ce qui n'était pas le cas jusqu'à la version 7 de GM