quelques questions après lecture de la bible de GM

Bonjour à tous,

je viens de découvrir Game Maker, dont je n'avais entendu parler que de nom jusque là, et j'avoue être assez séduit par le soft.
Surtout par sa façon d'être assez modulable et flexible grâce au GML.

Je précise en avant propos que je ne suis pas un total débutant en matière de création de jeu. J'ai déja fait quelque trucs sous UDK (je viens plus de la 3D au départ), et je maîtrise plusieurs langages (C, C++, C#, python, ActionScript, php, ...). De plus j'ai déjà pas mal fait de map making sous différents jeux, dont Legend of Grimrock que je commence à bien maîtriser au niveau langage de script.
Cependant, je suis plus un habitué de la 3D, et je découvre beaucoup d'aspect dont j'étais parfaitement ignorant en 2D.
De plus, même si j'ai fait plusieurs choses, je suis loin d'être un expert dans le domaine, et me considère toujours en phase d'apprentissage dans ce vaste domaine.

J'ai donc commencé par lire ce que beaucoup considèrent comme la bible de GM, c'est à dire : http://gamemaker.info/fr/manual
Je n'ai pas encore sérieusement entamé la partie GML, mais d'après ce que j'ai pu en voir jusque là, ça ressemble beaucoup, dans sa syntaxe en tous cas, à du C. Donc je pense que ça ira assez vite.

Quoi qu'il en soit, après lecture, il apparaît qu'il reste d'énormes zones de flous à éclaircir, voir de trous béants à combler. J'ai bien essayé de chercher un peu partout, mais fait complètement dingue, on dirait que GM ne bénéficie d'aucun support sur la toile au niveau doc.
A une époque où tout le monde veut faire son jeu, et où la scène indé a le vent en poupe, on pourrait penser que la documentation sur ce type de soft serait légion, mais bien au contraire...
Bien sûr, on trouve quelques ressources par-ci par-là sur des aspects très précis du monstres, mais rien sur les cas généraux ou l'apprentissage global.
On dirait presque que toutes les infos sont jalousement gardées par une petite communauté qui aurait peur qu'on leur vole leur bien.
Je ne dis pas que c'est le cas, mais c'est l'impression que ça donne.

Enfin bref, là n'est pas le sujet !  
Comme je le disais, plusieurs points sont complètement ignorés par la doc, et j'aimerai, si quelqu'un a la générosité de m'accorder un peu de son temps, qu'on me renseigne sur certaines choses.

Tout d'abord, comment faire une véritable GUI?
Chose complètement dingue, la GUI est une chose dont tout jeu à besoin (en tout cas la plupart), et c'est sujet complètement passé sous silence dans la doc. Aucune ligne là dessus (sauf vite fais dans la partie GML sur les splashscreen... yeah...).
Je suis tombé sur une vidéo youtube dans mes recherches, un truc sans sons d'un type qui bricole un truc en 4mn montre main sans rien expliquer (pas de sons... donc un peu compliqué), en agitant seulement sa souris dans tous les sens comme si ça rendait sa vidéo plus compréhensible.
Mais à part ça, rien de rien... le néant.
Je ne trouve aucun site, aucune source qui explique comment créer sa GUI pour son jeu.
On peu supposer que c'est possible à travers la gestion de background, mais on ne peut malheureusement que supposer...
Donc si quelqu'un avait des liens pour ça, ce serait le top du top!

Autre chose, les particules.
La doc officielle décrit bien chaque bouton, mais au delà de ça, c'est un peu dé***** toi en trifouillant comme tu peux...
Il faudrait apparemment créer un système avant, puis générer un émetteur, puis les particules...
Les effets sont pré-configurés et.... et...
Et puis rien, c'est un peu le soucis. Là c'est pareil, je ne trouve rien sur comment créer son propre système de particule proprement (dans bidouiller des trucs pas possible comme on peut le voir parfois).

L'inventaire, c'est pareil. On pourrait considérer que ça fait parti de la GUI (ce qui est un peu le cas d'ailleurs), sauf qu'il y a toute la partie interactive avec l'utilisateur à gérer. Et là c'est pareil, pas un mot dans la doc.
Il y a des choses préconçues pour accélérer les choses, ou c'est tout en GML?

Dernière petite chose, les shaders et les moteurs de rendu.
Alors de part mon expérience avec la 3D, je dirai que c'est réservé à cette partie là, et qu'en 2D on s'en tamponne.
En ouvrant le panneau des shaders, je trouve bien un algo pour la gestion des rebonds de particules lumineuses, donc je suppose que ce n'est pas la peine de détailler. Mais je demande tout de même en cas, on ne sait jamais^^

Voilou, j'espère que je ne vous ai pas trop soulé avec mes questions, et qu'une âme charitable sera à même de me guider
Je précise que j'accepte les sources Française, mais aussi Anglaises (bien que la première solution m'arrange évidemment, je vais plus vite à lire. Mais je ne suis pas difficile). Les autres langues je pense qu'il veut mieux laisser tomber. J'ai tenté parfois le google translate pour de l'allemand ou autre, et c'est jamais bien joyeux... 

Merci merci !!  

Bonjour,

pour la gui, si tu n'utilises pas de view mouvante alors il n'y a pas de problème. Si tu en utilises, pour que les objets de ta gui restent fixes par rapport à l'écran, utilises view_xview[numéro de ta view] et view_yview.
C'est vrai que ça semble un peu idiot, c'est pour cela que Game Maker Studio a été mis à jour pour avoir un nouvel event "Draw GUI" http://www.yoyogames.com/tech_blog/9. Mais tant que tu restes sur Game Maker standard, view_xview est la seule solution simple (tu peux sinon utiliser la méthode utilisée dans cette vidéo si tu veux te compliquer la vie ^^ : https://www.youtube.com/watch?v=MvuPNXiNrgQ).

Pour les particules, je ne m'y connais pas trop, mais je peux te dire que http://gmc.yoyogames.com/index.php?showtopic=461092 m'a un peu aidé. Et il doit y avoir aussi des tutoriels sur ce forum.

Pour l'inventaire, il n'y a rien de pré-configuré. Et je te conseille fortement d'utiliser le gml, car tu vas avoir besoin ici de tableaux... Mais de toute façon, comme tu l'as dit, le gml est effectivement un copié-collé du C au niveau de la syntaxe (en moins bien, bien sûr ) donc tu ne devrait pas avoir trop de mal. Et il y a de très bon tutos sur ce forum (regarde ceux de Onilink). Maintenant, si tu veux des scripts tout fait pour créer rapidement un inventaire, il y a en a un peu partout (mais bon c'est toujours mieux d'en faire un soit même une bonne fois pour toute, et de le garder pour tous tes futurs projets).

Pour ta dernière question, je ne sais pas.

Voilà, j'espère que ça t'a aidé.

Idem au niveau de particules, je ne suis pas vraiment bon. Dans tous les cas sa gestion ne m'a jamais servi x)

L’événement Draw GUI a été implanté dans GM:S et il permet une gestion plus simple de la GUI. En gros si tu as une view à 400, 400, au lieu de faire draw_text(view_xview[0]+16,view_yview[0]+16,"Bonjour"); , tu peux très simplement faire draw_text(16,16,"Bonjour"); ce qui permet de se retrouver bien plus facilement dans son code.

La gestion de la 3D sous GM ( Même GM:S ) reste assez minable. Du coup je te conseille Ultimate3D qui supporte également les shaders. Cependant c'est seulement du Windows ( Je crois, en tout cas c'est prévu à la base pour GM simple ).

En tout cas si tu as besoin de conseils, tu es au bon endroit!

@GrandeLangue
Ok, merci pour les "view_xview et view_yview. Il m'avait semblé avoir aperçu ça dans un poste je ne sais plus où, mais je ne savais pas trop à quoi ça correspondait.
De but en blanc, ça doit permettre le positionnement d'un objet à l'écran sur certaines coordonnées.
Reste à voir sur quelle couche ça se pose, mais ça je le verrais bien en testant

En ce qui concerne le "DrawGUI", j'avoue que je ne comprends pas trop la logique au premier abord.
En fait, j'ai du mal à comprendre comment l'affichage de la GUI peut être un événement...
J'aurai plutôt tendance à penser qu'au contraire, c'est une action traitée au lancement au jeu (ou de la room).
Je vais regarder ça, mais comme ça, je trouve ça assez déroutant.

Pour la vidéo, je vais regarder. Il doit y avoir dans tous les cas beaucoup de bonnes choses à prendre

Merci pour le lien vers les particules, ça va me faire de la lecture instructive !

Pour l'inventaire, je me doutais un peu qu'il n'y avait rien en interface. En même temps c'est tellement intrinsèque au type de jeu que ce serait compliqué de traiter tous les cas en drag&drop...
Mais bon, ce n'est pas plus mal pour bien voir les choses en profondeur. De toute façon, à terme, je pense qu'on passe plus de temps en GML que dans l'interface (hors création de sprites, etc...). Donc ça ne fait qu'accélérer les choses au final  
Je vais d'ailleurs me faire un plaisir de chercher les tutos d'Onilink sur le sujet comme tu me l'as indiqué.
Et en effet, comme tu le dis, je préfère faire ça moi même. Bidouiller des scripts trouvé sur le net, ça peut dépanner en cas de grosse bourre ou sur des sujets totalement inabordable autrement, mais globalement on apprends quand même beaucoup mieux en se cassant quelques dents en faisant les choses soit-même.
Surtout qu'en règle générale on a envie que l'inventaire soit comme l'imagine, et pas un mélange de différentes choses imaginé par d'autres

@Soundii
Merci pour tes précisions sur l'Event DrawGUI. Dis comme ça, c'est sûr que ça à l'air intéressant !

Pour la 3D, je ne compte pas m'y mettre. En fait j'en ai bouffé pendant un peu trop longtemps entre UDK et Unity. J'ai envie de faire de la bonne 2D pure souche des familles histoire d'aborder un nouveau domaine où j'ai encore beaucoup à apprendre! (j'ai encore beaucoup à apprendre en 3D aussi bien sûr, mais la 2D m'attire de plus en plus, je ne sais pas trop pourquoi... un charme que la 3D n'aura jamais^^).


Sinon, j'ai déja des petites questions...  
En fait une petite qui va vous faire rire, mais qui pose à vrai problème à mon niveau.
J'aurai bien tenté de trouver la réponse par moi même, mais à dire vrai, je ne sais pas trop comment expliquer ça, et du coup j'ai pas les mots pour une recherche (le truc con quoi...).
Je vais tenter de m'expliquer le plus simplement possible :

j'ai 8 sprites pour mon personnage :

1. immobile face vers l'avant
   
2. immobile face vers la gauche
   
3. immobile face vers la droite
   
4. immobile face vers l'arrière
   
5. cycle de marche vers le bas
   
6. cycle de marche vers la gauche
   
7. cycle de marche vers la droite
   
8. cycle de marche vers le haut
   

Jusque là c'est assez banal (je pense).
Au niveau des événements/actions, j'ai fait les choses comme suit :

si le joueur appuie sur haut -> le sprite devient le cycle de marche vers le haut.
si le joueur relâche la touche haut -> le sprite devient le personnage immobile vers l'arrière.

Et je procède du coup de la même façon pour toutes les directions.
Alors ça marche plutôt bien, sauf à un niveau: si le joueur appuie sur deux touches en même temps (par exemple lors d'un changement de direction, il appuie sur la seconde touche avant de relâcher la première, ce qui arrive très très fréquemment), alors là c'est le drame, et le perso s’arrête net. Il faut donc appuyer de nouveau sur la touche pour le relancer. Mais c'est parfaitement normal puisque le jeu capte une touche qui se relâche et charge donc un nouveau sprit sur un autre en cours. Bref, ça fait conflit, et le jeu n'aime pas.

Pour remédier à ce soucis, il suffit, au niveau des Events de ne pas réagir lorsque le joueur relâche une touche, mais de capter un <NO KEY>, et de placer la réaction en immobilité (vitesse 0). A ce moment là, il n'y a plus de soucis puisque plus de conflit. Donc on peut appuyer sur toutes les touches en même temps, le perso ne s’arrête jamais de marche sauf quand on relâche tout, ce qui est parfait.
Par contre gros soucis, on ne peut pas contrôler la position du personnage lorsqu'il s’arrête. L'astuce du fennec c'est que lorsqu'il n'y a aucune touche appuyée, alors le sprite devient celui de face immobile.
Sauf que visuellement, bah c'est pas top...
Quelque soit la direction dans laquelle on s’arrête, le perso revient de face, ce qui n'est pas tout naturel...

Alors je pense sincèrement que la question a du être posée mille fois, et qu'elle a autant de réponses, mais très franchement, je ne sais pas du tout comment chercher ça ni avec quels mots clés... :/

J'espère que je me serai montré clair, car c'est loin d'être évident  

Merci beaucoup pour votre patiente!

EDIT : en fait plus j'y pense, et plus je me dit que ce n'est pas trop possible de faire ça en interface...
L'idéal serait que lorsque le soft capte qu'une touche de direction est relâché, un script est lancé.
Les script en question testerai les touches enfoncées, et si des touches directionnelles sont enfoncé, alors il ne fait rien. Par contre si aucune touche n'est enfoncé, le mouvement du personnage stop, et il charge le bon sprite.
Je pense que c'est sûrement ce que je vais finir par faire...

T'aime bien expliquer en profondeur toi Faut du courage pour lire tout tes messages, mais au moins tu sais écrire, ce qui est loin d'être le cas pour tout le monde sur internet Donc bienvenue sur le cbna, ca fait plaisir de voir des gens motivés !
Pour ton problème, c'est assez simple, suffit de comparer la position courante et celle du step précédent (le step est l'unité de temps de GM, par défaut 30steps=1s). Pour ca ia les variables x,y,xprevious et yprevious ; donc par exemple si x>xprevious, bah c'est qu'on s'est déplacé vers la droite
Pour ce qui est de la GUI, bah c'est le gros problème de GM je trouve, pas moyen de mettre des vrais boutons, checkbox,etc... C'est pas indispensable pour un jeu mais c'est quand même pratique si tu veux utiliser GM pour autre chose... Donc, ouais, tu fous tout dans le draw, puis pour ce qui est de la visibilité, tu déclare X et Y pour view_xvview[0] et l'équivalent en y, comme ca suffit d'écrire draw_text(X+16,Y+16,"Bonjour"), pour reprendre l'exemple de Soundii.
Au niveau des particules, perso j'ai compris comment ca marchait grâce à l'exemple de feu d'artifice fourni dans la doc, mais ca reste chaud si tu veux faire quelque chose de réaliste sans trop bouffer (genre un feu ><)...
Puis l'inventaire, bah ouais, c'est des data structures, mais bon avec GM c'est un peu de la ***** donc ca aide pas... Puis pour gérer l'interaction avec l'utilisateur, bah ca dépend vraiment du genre de jeu que tu veux, mais faire un système de sélection/drag'n drop, bah c'est assez basique, une fois que t'as pris le soft en main

C'est quoi ton niveau en C++ par exemple ? Parce que si t'arrivais déjà à faire des trucs évolués, bah tu va plutôt te retrouver limité par GM ; par contre si tu ramais, bah GM c'est le meilleur moyen de comprendre les bases de tout langages, genre boucles, tableaux, héritage (****** avec GM) et surtout tout ce qui est fonctionnement d'un jeu : diviser les events step/draw, faire des events, etc...

Oui, désolé...  
J'aime beaucoup écrire, c'est vrai. Ça peut être une qualité, mais c'est aussi un gros défaut dans le sens où je suis très mauvais pour expliquer quelque chose de façon concise. J'ai toujours peur de ne pas me faire comprendre, et j'en fait des tartines...
Mais promis, je vais tenter de synthétiser un peu mes posts^^

Merci pour l'explication sur les previous qui est très intéressante.
Le gros soucis d'utiliser ça dans ce cas de figure (je pense), c'est que si je script ça sur un Event No Key, le perso ne s’arrête pas si j'ai une autre touche appuyé. Si par exemple j'ai une touche pour courir et que le joueur la maintient alors qu'il a lâché les touches directionnelles, le perso continue de courir. C'est donc un soucis. Il ne faut, par conséquent, pas vérifier si une touche est appuyé, mais bien si une touche directionnelle est appuyé.
Enfin bref, il faut en effet mettre les mains dans le GML. Chouette, ça va être mon baptême^^

Ok pour la GUI, il va vraiment falloir que je me penche rapidement là dessus.

Moi pour le coup le coup du feu d'artifice, il m'a un peu laissé de marbre... :/
J'aurai aimé qu'ils mettent un exemple, même basic, pour comprendre l'ordre des actions à traiter.

Pour l'inventaire, on verra par la suite je pense. Je vais passer par une phase de petits projets sans inventaire histoire de m'habituer au soft et au langage. Je verrai ensuite pour intégrer ça proprement

Niveau C++ difficile de m'auto-évaluer. Disons que je n'ai aucun problème en algorithmie et que la POO est assimilé. La syntaxe je la connais par coeur...
A partir de là, disons qu'avec une bonne doc sous la main, je peux à peu prêt faire n'importe quoi en théorie.
Après dans la pratique c'est autre chose. J'ai déjà fait de projets, mais je petite ampleur. Rien qui nécessite des centaines de fichiers avec une hiérarchie complexe.
GM me permet donc de passer rapidement sur des choses qui prendraient beaucoup de temps en code pure, et il organise tout comme un grand pour moi. Donc c'est plutôt chouette.
Rien que le fait d'importer une spritesheet, et d'indiquer le découpage par ligne et colonne, de pouvoir voir l'animation en temps réel, et de dupliquer certaines frames pour ralentir certains mouvements... c'est juste énormissime... en C++ ça m'aurait prit des plombes rien que pour coder la fonction qui permet de le faire...
Donc je ne vais pas cracher sur GM, limitations ou non! :p

Désolé par avance du double post, mais si quelqu'un qui recherche une aide au niveau des directions et tombe sur ce post, ce sera plus simple pour lui d'avoir les codes dans un post séparé au lieu que ce soit au milieu du reste.
Voici donc la solution que j'ai appliqué à mon soucis :

Pour mes press<Up><Down><Left><Right>, rien de bien sorcier, ça reste classique. On a une action de direction dans celle qui convient avec un vitesse qui convient, puis une seconde action de chargement de sprite.

J'ai ensuite créé mes release<Up><Down><Left><Right>, et ceux-ci sont reliés à un script chacun dont voici le contenu:

ReleaseUp

Code:

if (keyboard_check(vk_left) = 1 || keyboard_check(vk_right) = 1 || keyboard_check(vk_down) = 1)
{

}
else
{
    self.speed = 0;
    sprite_index = <nom de votre sprit dirigé vers l'arrière>;
}

ReleaseDown

Code:

if (keyboard_check(vk_left) = 1 || keyboard_check(vk_right) = 1 || keyboard_check(vk_up) = 1)
{

}
else
{
    self.speed = 0;
    sprite_index = <nom de votre sprit dirigé vers l'avant>;
}

ReleaseRight

Code:

if (keyboard_check(vk_left) = 1 || keyboard_check(vk_up) = 1 || keyboard_check(vk_down) = 1)
{

}
else
{
    self.speed = 0;
    sprite_index = <nom de votre sprit dirigé vers la droite>;
}

ReleaseLeft

Code:

if (keyboard_check(vk_right) = 1 || keyboard_check(vk_up) = 1 || keyboard_check(vk_down) = 1)
{

}
else
{
    self.speed = 0;
    sprite_index = <nom de votre sprit dirigé vers la gauche>;
}

Et voilà, plus de soucis.

Pour la petite explication, ces scripts sont très simples. Lorsque le joueur relâche une touche directionnelle, le script vérifie si une des trois autres touches est enfoncée ou non.
Si c'est le cas, il ne stoppe pas le mouvement du personnage à l'écran pour ne par interférer avec le mouvement en cours.
Par contre si aucune autre touche directionnelle n'est enfoncée, il met le speed à 0 (donc arrêt du personnage), et il change le sprit en cours par celui qui va bien.

En fait, c'est clair que si on connait le C, le GML c'est galette...
Ce qui est terrible, c'est que la doc côté code est fait comme une doc normale pour un langage informatique. Donc tout est classé en fonctions... c'est juste le top!

Effectivement, le GML ca te permet de faire des ptits trucs plus rapidement qu'en C++ ou autre ^^
Petite précision, t'es pas obligé de mettre le self devant speed, ca sert surtout pour faire des conditions avec des objets
Au niveau de la doc, bah tu trouve ce que tu veux, mais c'est pas comparable à une doc comme celle de php, ou absolument tout est expliqué, alors qu'avec GM, bah t'as une ligne et tu te dé*****... Surtout au niveau des trucs un peu hard genre particules/3D (déjà que c'est limité, si en plus c'est incompréhensible ><)...
En fait le principal inconvénient de GM face aux autres langages, bah c'est la pauvreté du langage : ils mettent en avant le fait qu'il y a plus de 1000 fonctions, mais niveau algorithmique pure, bah c'est vraiment misérable.... Les tableaux, les datastructures, etc... Tu peux toujours reprogrammer les fonctions orienté game-making de GM depuis un autre langage, mais c'est quasi-impossible de refaire les fonctions de base en GML... Avec n'importe quel autre langage, bah un tableau c'est usuel, bah avec GM tu peux être sûr que ca va foutre la ***** si tu veux un truc un minimum organisé... :/ A partir du moment ou tu peux pas retourner un array depuis un script... ><
C'est pour ca que je voulais savoir ton niveau en C++, si t'y connais rien, GM c'est le top, mais si t'as déjà un minimum d'expérience... Enfin bref, je vais pas cracher dessus, c'est quand même bien GM ^^

Ces dernier temps, ils semblent faire des efforts pour améliorer grandement Game Maker Studio (tu peux retourner des arrays par exemple ). Le problème, c'est que j'aurais préférer qu'ils améliorent Game Maker 8 et qu'ils sortent le 9 (vu la différence de prix). M'enfin...

Pour ton code, tu fais

Code:

if expression
{}
else
{ /*ton code*/ }

Mais ceci serait mieux :

Code:

if !(expression) // le ! signifie NOT
{ /*ton code*/ }

Et les keyboard_check() renvoient des booléens (en réalité, des réels qui valent soit 1 soit 0) donc pas besoin d'écrire dans keyboard_check() = 1

Donc par exemple :
ReleaseUp

Code:

if !(keyboard_check(vk_left) || keyboard_check(vk_right) || keyboard_check(vk_down))
{
    speed = 0;
    sprite_index = <nom de votre sprite dirigé vers l'arrière>;
}

@Térence68
Ok pour le self. J'ai plus l'habitude de désigner l'instannce en cours à cause de l'ActionScript qui est un peu tatillon à ce niveau, mais il semblerait que le GML soit un peu plus permissif^^

Pour la doc, c'est sûr que ce n'est pas non plus digne d'une doc genre php (plutôt exemplaire pour le coup...), mais elle est bien organisé.
Ils auraient pu faire un détail d'algorithmie et balancer des fonctions en vrac dans un chapitre dédié; mais là ils ont prit le parti de faire une passe très rapide sur l'algorithmie et la syntaxe en supposant que ce n'est pas notre premier langage (ce qui est logique car on n'aborde pas GM sérieusement comme outil de création sans aucune connaissance dans aucun langage d'après moi), et ont logiquement organisé leurs fonctions par type, ce qui est franchement sympa.
En fait j'apprécie d'autant plus qu'il n'y a pas longtemps, je scriptait sur le jeu "Legend of Grimrock" avec un dérivé du LUA (au secours niveau syntaxe... TT), et niveau doc, tout était jeté pèle-mêle dans une page où tout était en vrac, et demmerdes-toi avec ça...
Donc là, je salue tout de même l'effort

Après niveau limitations, j'y serai sûrement confronté un jour, mais pour le moment, c'est loin d'être le cas vu mes ambitions :p
Mais comme tu dis, c'est difficile de cracher dessus vu le temps que ça fait gagner sur un paquet d'autres trucs^^

@GrandeLangue
Il y a une différence entre GM et GM: studio??
En fait j'ai téléchargé GMStudio parce qu'il n'y avait que ça sur le site de YoYo, mais j'étais aussi étonné de voir de versions 8 partout, alors que ma version est 1.2.xxx.
C'est pas la même chose??

Pour ton code, c'est en effet plus élégant. Généralement, je ne fais pas trop gaffe avec le booléens... c'est un tort je sais. Du coup ça peut être optimisé^^

Là je suis en train de créer une réplique de Bomberman, en simplifié bien sûr.
J'ai déja bien avancé.
Ma salle est crée, mes persos aussi, j'ai mes blocs solides et ceux qui sont destructibles, le perso se déplace bien, il lâche des bombes qui bloquent les mouvement, et font des déflagrations de 3x64 dans chaque direction à l'explosion (3s après la pose de la bombe). Les murs se détruisent bien etc...
Bref, j'en suis à coder l'IA du joueur adverse, mais j'en **** sérieusement^^

Citation :

on n'aborde pas GM sérieusement comme outil de création sans aucune connaissance dans aucun langage d'après moi

Là je suis pas d'accord, 95% des utilisateurs de GM commencent par le D&D puis passent progressivement au GML.
J'ai jamais codé en LUA, mais je reconnais que la doc de GM est largement convenable.
Pour GM8.1 et GM:S, bah GMS c'est la m^me chose que GM8.1 mais avec plus de formats d'exports et un prix multiplié par 10... >< Ils ont récemment abandonnés GM8.1, mais ia au moins la moitié des membres habitués qui ont encore GM8.1, justement à cause du prix et parce qu'ils sont tous plus ou moins passé à d'autres langages ^^

Pour l'IA, ia un certain nombre de fonctions assez pratique, en plus avec un système comme bomberman en case, c'est rapide. Puis sinon tu peux toujours le faire toi même à partir de rien, c'est pas très compliqué, tu compare lex positions x et y des ennemis et du joueur, puis si le chemin est libre ou pas, tu le fais bouger en fonction

J'ai commencer GM en D&D et maintenant je fait 90% des choses en GML T'apprend sur la tas

Quand a l'IA, je suis d'accord avec Terence, si tu a de la logique, ce n'est pas vraiment dure a faire, mais cela reste ch*ant et long

Bon courage !

@Térence68
Disons que pour moi, ça ne me conviendrai pas en premier langage alors
J'estime (peut-être à tort), que pour maîtriser un langage, quel qu'il soit, il faut avoir de bonnes bases en algorithmie - c'est ce qui forme le cerveau à la réflexion procédurale - et en POO - c'est ce qui forme le cerveau à réfléchir en encapsulation et en terme d'héritage.
Et quand je vois la doc disponible, je me dis qu'il est absolument impossible d'avoir de bons réflexes avec un sujet à ce point survolé. Je ne parle même pas de la philosophie de la POO qui est parfaitement jeté à la poubelle.
Quand j'ai été jeté un coup d'oeil à l'introduction de la doc, j'ai failli avaler ma langue en constatant qu'on incitait presque les gens à utiliser des globales comme on gobe des carrés de chocolat...
Ce n'est pas pour faire mon gros con élitiste, mais je pense sincèrement que commencer avec GML et la doc officielle, c'est le meilleur moyen de prendre de très mauvaises habitude.
Après il est certain que de pouvoir raccorder le code au drag&drop plus visuel possède un certain avantage non négligeable qui peu pas mal aider.
Mais il y a autant de bon que de mauvais dans ce type d'apprentissage.
Je pense sincèrement qu'il vaut mieux en baver un peu en apprenant le C++ avant, puis passer au GML pour être sûr de savoir réellement ce qu'on fait niveau code.
Après, ça ne reste que mon opinion bien évidemment

Ok pour le GMS. Je comprenais pas aussi pourquoi certains annonçaient un prix à ce point différent pour l'achat... :p
Bon après ça reste 50$, soit un peu plus de 35€...
Comparativement à ce qu'on peut gagner en créant un jeu qu'on peu distribuer en licence payante en bossant un peu, c'est franchement dérisoire. Pas de quoi s'étouffer avec sa soupe^^
De plus, la version gratuite est super complète je trouve, et niveau ajout de la version payante, c'est assez symbolique et négligeable. Peut-être certaines choses à faire en GML au lieu de l'interface graphique, mais rien de bien méchant. C'est donc à ce niveau cadeau.

Pour l'IA, je la fait moi même à partir de rien. Je préfère dans le cadre de mon apprentissage. Non seulement je trouve ça assez amusant (même si parfois prise de tête^^), mais ça aura le mérite de me faire découvrir pas mal de fonctions de déplacements et de vérifications.

@Kujaff
Je sais que certains apprennent sur le tas, et c'est une chance que je n'ai pas... :/
Personnellement, j'en suis incapable. J'ai besoin d'avoir une phase de théorie pour assimiler le résonnement avant de me lancer dans l'applicatif.
Ma vision de l'apprentissage à traver GM est donc basé là dessus.
Mais si certains arrivent à apprendre via ce procédé sans prendre de mauvaises habitudes, c'est vraiment top, car ça offre tout de suite un terrain de jeu génial pour des tas d’expérimentations plus ludiques que les éternelles : "créez moi une fonction qui permet de savoir si une année est ou non bissextile!" (l'exo super sexy quoi... -__

Pour l'IA, c'est plus le nombre de possibilités qui fait mal...
Il faut penser aux réactions lorsque le personnage se trouve devant un mur solide, lorsqu'il se trouve devant un mur destructible, quand il est bloqué, à quel moment poser une bombe, etc...
C'est pas évidement d'envisager toutes les réactions et surtout que ça ai l'air assez naturel (donc avec une part d'aléatoire) pour avoir l'impression de jouer contre un vrai joueur en face

Bon par contre j'ai un gros soucis...
Ça fait deux heures que je bloque sur un truc débile au possible, et je ne comprends pas du tout pourquoi ça merdouille... Oo

Je veux obtenir un nombre aléatoire entre 1 et 4 pour déterminer une direction aléatoire.
Rien de bien délirant...
Je fais donc un :

Code:

i = ceil(random(4));

Le truc, c'est que mon perso part toujours dans la même direction à chaque cycle...
J'ai donc fait un :

Code:

show_message(i);

Histoire de voir un peu pourquoi j'avais cette anomalie.
(d’ailleurs en passant, ce n'est pas possible d'avoir une console et de faire des affichages console à l’exécution d'un code durant le déroulement du jeu ?)
Et là c'est le drame, en fait, j'obtient toujours le nombre 1 !

Très honnêtement, je ne comprends pas du tout...
Ça fait des heures que je suis sur la doc, et random(x) renvoi bien un nombre réel entre 0 et x.
Et ceil(x) renvoi bien un arrondi au supérieur de x.
Donc What the ****??? Oo

Désolé si ma question est débile, mais là je vois plus du tout... c'est juste complètement dingue... :/

EDIT: pour un peu plus d'infos:
un random(4) me donne toujours: 0.34
un random(5) me donne toujours: 0.42
un random(6) me donne toujours: 0.51

Si ça peut vous aider à comprendre... parce que moi là perso... une fonction aléatoire qui renvoie toujours le même nombre... j'avoue que je suis totalement largué.

oO Jamais vu ca... Essaie de faire un random_set_seed() avec une valeur au hasard....

arf, tu as vu pile poile dans le mille... chapeau bas!  
Si je fais un :

Code:

random_set_seed(current_second * current_minute * current_hour);

juste avant de lancer mon aléatoire, tout rentre dans l'ordre, et mes résultats redeviennent cohérents.

Alors ta réponse m'a également permis de me renseigner un peu sur les forums Yoyo du coup, et il s'avère qu'il s'agit d'un bug connu de GMS qui date de...
Accrochez vous bien à vos slips...
2012!

J'ai retrouvé des posts de 2012 sur le forum officiel qui soulève le bug, et apparemment ça traîne depuis là.
D'après ce que j'ai compris, le seed du soft reste bloqué sur 0, et du coup vu que le random en tient compte, on a le même chiffre à chaque fois...
Vu qu'on est fin 2013, je ne sais pas si il faut compter sur le fait que ce soit corrigé un jour...
Enfin bon, vu qu'il est possible de reset le seed soit même ce n'est pas un gros soucis.
Mais c'est quand même dingue qu'un bug pareille se traîne depuis 2012... le random(x), c'est quand même un truc ultra méga utilisé dans les jeux... :/

En tout cas merci de ta super réponse, je commençais à me demander si ce n'était pas moi qui devenait dingue à force :p

EDIT: j'ai fait un ticket d'erreur pour remonter le bug.
On verras bien.

Si ils connaissent déjà le bug ça ne sert à rien de refaire un ticket. Au contraire, il perdent du temps dont ils ont besoin pour régler les bugs.

Je ne sais pas si ils connaissent le bug...
J'ai dit que le bug était connu. Je sous-entendait par les utilisateurs, non par l'équipe de dev.
Je n'ai aucune idée de si ce bug a été ou non remonté.
Tout ce que je sais, c'est qu'un utilisateur sur leur forum officiel avait demandé de l'aide rencontrant le même bug, et un autre utilisateur lui donnait la solution en disant que c'était un bug connu de GMS. A savoir si l'équipe lit ou non le forum et si les gens prennent les peine de faire remonter des tickets... je n'ai malheureusement pas de boule de cristal pour ça
J'ai donc prit la peine de vérifier dans les tickets prioritaires et dans les derniers tickets affichés, et il n'y avait aucune trace concernant ce bug. Je me suis donc permis d'en faire un moi même dans le doute.
J'espère ne pas leur faire perdre trop de temps...

Que la seed soit initialisée sur 0, je ne pense pas que ce soit un bug.
Dans de nombreux langage la seed est sur 0, pour justement obliger l'utilisateur a en choisir une.
C'est plus un choix a mon avis, et le modifier risque de justement perturber les gens qui en ont l'habitude :b

Ah, je ne savais pas du tout ça...
C'est même plutôt bon à savoir.

Je dois dire que je n'avais jamais été confronté au problème avant.
Dans n'importe quel langage, lorsqu'on fait un random(), ça sort un nombre basé sur l'horloge et puis voilà.

Là comme ça ne réagissait pas pareil et que sur le post sur lequel je suis tombé la personne disait qu'il s'agissait d'un bug, j'ai pas cherché plus loin :p
Enfin bon, c'est pas franchement un gros soucis non plus... il suffit de le savoir.

Merci pour la précision onilink_

D'ailleurs j'imagine que ce choix a été fait puisque GM est accès jeux vidéo, et que dans ce domaine c'est important de savoir ce qu'est une seed.
Par exemple pour un jeu qui utilise de la génération procédurale, la seed peut être utile pour que les joueurs puissent se la partager et ainsi avoir les même mondes générés (minecraft, starbound).
Mais je suis d'accord qu'une seed directement réglée sur l'horloge c'est quand même plus pratique.
Ça a d'ailleurs été introduit dans C++2011.

Je comprends. Du moins je comprends l'importance d'une seed.
Par contre ce que j'ai du mal à comprendre c'est pourquoi un random() prend en compte la seed?

En fait, si on a besoin d'une génération aléatoire (procédurale ou autre), on lance un algo prenant en compte les infos de l'horloge qu'on passe à la moulinette pour obtenir notre aléatoire.
Que la seed soit par défaut réglé sur 0 dan le soft, je peux comprendre.
Par contre quand on fait un random dans un script, pourquoi celui-ci se fie au seed et ne passe pas directement par l'horloge? C'est ça que j'ai beaucoup de mal à comprendre...

Mais je pense que mon incompréhension provient de ma totale méconnaissance de la façon dont marchent les seed.

J'ai tenté de trouver des infos sur le net, mais je ne trouve pas grand chose. Il faudrait que je voit un peu ça, ça peut être très intéressant !

Bah justement, plutôt que de passer par l'horloge, tu passe par la seed. Ca te permet d'enregistrer tout un niveau généré avec du random avec une seule valeur, c'est super pratique puisque ca t'economise énormément de mémoire au niveau du fichier de sauvegarde. Comme le disait oni, c'est grâce à ca que tu peux partager les maps de Minecraft juste avec un mot, sans télécharger de fichiers
Donc si tu veux que ton random utilise l'horloge, suffit d'initialiser la seed avec ce genre de fonctions.
Bon après perso j'ai jamais eu recours a ca, mais ca peut être utile Par contre je trouve complètement con qu'on soit obligé de définir la seed si t'en a pas besoin... Surtout pour GM, qui est censé te simplifier la vie, si à chaque fois que t'utilise des fonctions, faut initialiser des trucs et que c'est écrit clairement nulle part.... ><

C'est vrai qu'une ligne dans la doc à ce sujet n'aurait pas été de trop^^
C'est le genre de truc à noter dans un coin pour s'en rappeler lorsqu'on utilise ce genre de fonctions.

En fait random est juste une fonction mathématique, qui essaye de trouver des valeurs assez 'chaotiques' en fonction de 'x' (la seed).

C'est souvent de cette forme:

Code:

ret = g(seed)
seed = f(seed)
return ret

Par ex: http://www.christianpinder.com/articles/pseudo-random-number-generation/

La génération de la suite de nombres dépend donc complètement de la seed.
D'ailleurs, un mauvais algorithme de pseudo aléatoire est un algo qui a des cycles trop courts, ou des valeurs prévisibles.
Par ex y a le xorshift 8 bits qui a des cycles très courts (256 je crois):

Code:

static byte seed = 1;
byte xorshift8(void) {
    seed ^= (seed << 7);
    seed ^= (seed >> 5);
    return seed ^= (seed << 3);
}

Dans le cas de valeurs prévisible, ça permettrait au joueur de savoir sur quoi va tomber un event aléatoire dans un jeu...
Pas super super
Et le pire c'est en cryptographie, étant donné que certains masques jetables sont crées a partir de nombres pseudo aléatoire, il deviens très simple de décoder le message (surtout si on connais l'algo pseudo random utilisé).

Bref, le pseudo aléatoire on pourrais en faire un bouquin tellement y a a dire dessus (et je suis sur qu'y en a plein)  

Merci beaucoup pour tes explications onilink_ !
Et merci pour le lien qui est, en effet, très intéressant.

Du coup, je pense que mon incompréhension venait du fait que je pensais que la seed était fixe durant toute la longueur de l’exécution du programme.
Si je ne me trompe pas :

lors de la création d'une map Minecraft (exemple bateau^^), au moment de la génération, un algo basé sur la seed chopée à la volée s'exécute et permet d'avoir une map originale.
L'instant d'après la seed change.
Mais la seed utilisée pour la génération est stockée en mémoire, et affiché ensuite comme une référence.
Si un autre joueur (ou le même), génère une nouvelle map en indiquant cette seed, Minecraft au lieu de prendre la seed en cours va utiliser celle-ci pour avoir les mêmes paramètres de création.

J'ai bon?

Ce qui m'embrouillait, c'est que je croyais que la seed ne bougeait jamais en cours d'éecution.
Apparemment, là dans GM, elle est initialisé à 0 au départ, et en effet ne bouge pas.
Et il faut lui préciser qu'il faut s'actualiser constamment.
D'où le fait que mes nombres n'étais pas aléatoire (algo effectué sur 0 constamment), et le sont devenu une fois la seed initialisé.

Pour minecraft oui ça fonctionne comme ça. Par contre il faut garder a l'esprit qu'a chaque appel de la fonction random, la seed est modifiée.
Pour une seed qui vaux 0 par contre, certains algos (comme le xorshift) ne fonctionnent pas, et laissent la seed toujours a 0.

Pour ce qui est de GM, non il ne faut pas update la seed plusieurs fois, mais juste au lancement du jeu et la mettre sur une valeur en rapport avec l'horloge interne de l'ordi. Car une fois que t'appellera random, la seed passera automatiquement a sa valeur suivante, assignée par le générateur de nombres aléatoires. Modifier la seed a chaque fois avec l'horloge ne donnera pas des nombres pseudo aléatoires, mais n'importe quoi.

Par contre c'est étrange, dans le cas de GMS donc si tu utilises plusieurs fois random sans avoir initialisé la seed tu obtiens toujours la même valeur? (bug)
Ou plutôt toujours la même suite de valeurs? (normal)

Ok, merci pour toutes ces précisions. Je comprends beaucoup mieux comment la génération pseudo-aléatoire fonctionne !

Pour le cas de GMS, sans initialiser la seed, j'obtient bien toujours la même valeur pour la même fourchette.
Comme je le donnais en exemple un peu plus haut :

Citation :

un random(4) me donne toujours: 0.34
un random(5) me donne toujours: 0.42
un random(6) me donne toujours: 0.51

Donc le résultat changeait en fonction de la fourchette puisque l'algo changeait pour s'adapter à la nouvelle limite, mais sur une même fourchette, c'est toujours le même nombre qui sort quoi qu'il arrive.

Ok je vois, donc depuis GMS ils ont du changer d'algo pour le pseudo aléatoire, et il ne doit pas être adapté pour une seed a 0 (que l'ancien algo supportait vu que sous les versions que j'ai tout fonctionne).
C'est bien un bug du coup, ou plutôt une connerie

Ça me rassure un peu quant-à-l'utilité de mon ticket alors !  

Par contre encore un petit soucis (j'espère ne pas vous soûler à force...) de débutant.
Je fait des tests de path en ce moment.
A ce niveau, aucun soucis, mon sprite parcours bien mon path sans aucun soucis.
Par contre ce que j'aimerai, c'est que mon sprite change d'angle lorsqu'il change de direction. Et c'est là que ça se gâte...

je me suis dit que j'allais simplement détecter à chaque step la position du sprite, et au moment où il arrive à une certaine position, on change l'angle. En théorie c'était plutôt simple. Sauf que bien évidemment, ça marche pas... ^^
Voici mon code:

Code:

if (x==448 && y==64)
{
    image_angle = 180;
}

Rien de bien fou. Un bout de code placé dans un event "step". Il vérifie la position, et lorsqu'il arrive à une certaine position, il change l'angle du sprite.
Sauf que le soucis, c'est qu'il réinitialise tout de suite après l’exécution du code l'angle du sprite en question.
C'est à dire qu'à cette position précise, le sprite change d'angle, puis rechange immédiatement au step suivant. C'est tellement rapide que c'est invisible à l’œil nu.
Sauf que je ne trouve pas ça logique du tout...
J'attribue à un instant T un nouvel angle. Une fois la variable initialisée avec un nouvel angle, il devrait la garder en mémoire, pas en changer tout de suite après.

En fait, c'est un peu comme si le soft par défaut vérifiait à chaque step l'angle du sprite pour le remettre dans sa valeur par défaut si le contraire n'est pas indiqué...
Vous avez une technique de ninja pour qu'il garde en mémoire qu'à partir de ce point, c'est l'angle qu'il doit garder?

Autre question au passage, je trouve que cette technique n'est pas forcément très... propre on va dire...
J'entends par là que lorsqu'on crée un path, on définit un certain nombre de points de passage qui sont stockés.
Ce qui serait carrément plus propre, ce serait de récupérer ces point de passage et de changer l'angle à ce moment là.
Il suffirait alors de faire un script qui donnerait un angle pour chaque point de passage, et ça pourrait se dupliquer simplement.
Parce qu'avec ma technique, je dois pour chaque itération regarder la liste des points de passage avec les coordonnées, et faire mon if avec les coordonnée, ce qui n'est pas forcément pratique.
Ce qui serait beaucoup mieux, c'est que les points de passage possèdent des ID à la création et qu'il suffise de jouer avec ces ID dans son code.

J'ai parcouru la doc pour voir si ça existait, mais apparemment pas. Les contrôler sur les path sont plus que réduits apparemment...

EDIT: En fait je vais tenter d'être plus clair, parce que j'ai conscience que je m'exprime comme un pied.
Ce que je voudrai faire, c'est contrôler l'orientation de mon sprite entre deux points de passage le long d'un chemin. Entre le point 1 et le 2, le sprite est à un angle de 90°; entre les points 2 et 3, le sprite est à un angle de 180°; et ainsi de suite.
J'ai beau éplucher la doc et parcourir les forums, je ne vois rien qui corresponde à ce que je veux faire