Salut à tous,
avant de commencer, il s'agit de programmer quoi?
Un programme forcément.
Comme tout cliqueur vous devez savoir, qu'un programme possède une structure.
Mais il n'y a pas de programme avec MMF!
Il y a déjà un programme, ce programme gère l'éditeur d'événements, de scènes, etc.
Afin de ne pas contrarier ce programme susceptible, le mieux est donc de mettre en place une structure similaire.
La lecture se fera logiquement de haut en bas.
1) Déclarer les variables.
2) Évaluations d'expressions, instructions (tester les conditions, actions).
3) Le débogage.
Surtout prenez cette similitude pour argent comptant, à cause de ma susceptibilité.
Rajouter où vous le sentez, séquence, sélection, répétition.
MMF a des variables initialisées à zéro, elles existent, mais vous ne les voyez pas encore.
Un objet actif, mouvement huit directions, possède au moins une variable vitesse, réglée sur zéro.
De même qu'une variable n'existe pas déjà par hasard dans MMF, on n'invente pas une variable.
On déclare (utilise) une variable afin d'atteindre un objectif.
Mais au fait c'est quoi une variable?
Une valeur modifiable, l'objet MMF s'en rapprochant le plus, le compteur.
Avant de trouver la bonne combinaison de conditions sur une ligne, dans l'éditeur d'événements, un cliqueur se doit d'effectuer des tests.
Donc d'empiler sur son disque dur, des tonnes de scènes tests, tel sera le résultat d'un premier "débogage".
Le pas à pas avec TGF1, était un gadget, à l'époque j'ai vite compris que désactiver et activer un groupe d'événements était le "debuggeur".
De nos jours avec CTF 2.5 on peut le faire ligne par ligne, plus besoin de mettre les conditions dans un groupe d'événements.
Quelle révolution extraordinaire, c'est fabuleux, merveilleux, gigantesque, impossible de trouver les mots pour décrire cette avancée technologique majeure.
Un testeur d'activité du joueur, avec "key wait" intégré, serait sans doute plus utile, heureusement il reste le "skinage" comme lot de consolation.
L'un de mes aïeux devait être un grognard?
Néanmoins si Clickteam devait intégrer toutes mes astuces...
La sélection se fait soit par activation ou désactivation d'un groupe d'événements, soit par présence ou absence d'un actif, etc...
Les cliqueurs et cliqueuses s'adonnent à la programmation structurée, la méthodologie peut prendre forme à force d'entraînement (pratique).
Contrairement à ce que j'ai déclaré quelque part, avec ironie, MMF possède un langage de programmation.
Ce langage en "bon" français est le Klik and Play code, ou Klik coding en anglais.
Klik and play étant l'ancêtre de CTF 2.5.
Ma méthode, toujours copiée, jamais égalée (humour), anticipation, Klik coding sur layers, optimisation.
Objectif, faciliter le développement, pour les septiques, il y a donc un "semblant" d'approche méthodologique.
On vient d'appréhender l'aire de jeu, l'endroit où tout le monde s'éclate, au sens propre et au sens figuré, ma culture "prototypaire" est à prendre avec des pincettes, puisque je ne suis pas un programmeur professionnel.
A vous de dessiner les contours de la piste de danse, afin d'effectuer vos figures, pourvu qu'elles deviennent un jour acrobatiques...
Désolé si par moment, je suis sincèrement dans l'erreur, mais n'est ce pas cela, le charme de l'amateur éclairé.
S'il y a ineptie, n'hésitez pas à la souligner, on en débattra pendant des heures et des heures.
La culture "prototypaire", c'est quoi?
Un prototype passe par des phases schématiques, puis un niveau jouable complet, soit un programme forcément.
L'objectif principal du klik codeur, quoi qu'il arrive, est la mise au point du moteur de déplacement, puis du "Training Mode".
Voici les trois rengaines à savoir sur le bout des doigts.
1) La base d'un jeu vidéo 2D est la tuile.
2) L'élément premier d'un jeu vidéo est le moteur de déplacement.
3) La matière première d'une intelligence artificielle est la ligne comparative.
Coucou "programme forcément" tu as besoin de quoi?
Pour commencer de ressources graphiques visibles et invisibles.
MMF a des variables initialisées à zéro et surtout des couches, elles existent, mais vous ne les voyez pas encore.
Hé! Mais il n'y a pas de couches.
La scène MMF est une couche non obstacle, un obstacle est placé dans la scène, une couche obstacle est réalisée, un décor pour faire joli est réalisée, une couche décor pour faire joli est réalisée, et ainsi de suite.
Si vous n'avez pas conscience de ce fait indéniable, votre "programme forcément" sera comme un oiseau sans aile.
Une fois n'est pas coutume, je vais me soumettre à un exercice indispensable pour le novice.
Le pas à pas, afin de mettre en pratique la théorie vue ci-dessus.
Autant le souligner, un codeur travaille avec des notions, des abstractions, des trucs invisibles, il met en "mouvement" des acquisitions (connaissances).
Le pas à pas est évidemment "débile", le skate park est là (merci Clickteam), il n'y a pas de régles à suivre à la lettre afin d'effectuer un trick.
L'aire de jeu où scène MMF a besoin de couches à définir autant que faire se peut, et de sprite afin d’exécuter les interactions.
Notre pas à pas, concerne un classique, le moteur de déplacement du personnage joueur case par case.
1) Ouvrir MMF, cliquer sur nouveau, une scène MMF apparaît comme par enchantement.
2) Insérer un nouvel objet dans la scène, un décor taille 32x32, réaliser un carré blanc avec un contour.
3) A partir du carré blanc au contour noir, créez un objet décor rapide, vous obtenez...
Oh! Merveille, une grille qui vous permettra de visualiser des cases non obstacle (tuile 32x32 pixels).
4) A partir du carré blanc au contour noir, créez un objet décor, à la place du blanc colorisez en gris, vous obtenez...
Oh! Sublime parmi les sublimes, une case obtacle, à condition de le préciser dans les propriétés (option du runtime, type d'obstacle, obstacle).
5) A partir du carré blanc au contour noir, créez un objet actif, mouvement statique, à la place du blanc colorisez en vert fluo, vous obtenez...
Oh! Extase suprême, un sprite invisible (visible pendant la phase schématique).
6) A partir du sprite, créez un objet actif, mouvement huit directions, limité à quatre directions (haut, bas, droite, gauche), à la place du vert fluo colorisez en bleu foncé, vous obtenez...
Oh! Félicité, un testeur d'activité du joueur, un sprite invisible (visible pendant la phase schématique).
Vous n'êtes pas infographiste, vous vous rebutez à réaliser une tuile, pas de panique, je vous offre les ressources graphiques.
Infographiste à ce niveau n'est pas donné à tous.
Attention, les tuiles sont sous copyright, © à vendre 1000 euros, parce que bientôt collector.
La phase schématique décomposée, à tel point qu'elle reste figée (zzzzz).
Attention c'est parti pour une ligne (n°2 sur la capture d'écran) de conditions, actions, dans l'éditeur d'événements, à droite, droite!
- Valeur modifiable A du sprite vert fluo = 0.
- Lors de l'appui sur la touche "Flèche Droite".
- Direction du testeur de l'activité à droite soit direction = 0.
Alors (action)
- Fixer la valeur modifiable A du sprite vert fluo à 1.
Condition restrictive?
Valeur modifiable A du sprite vert fluo = 0.
Confirmation de la condition, appui sur la touche "Flèche Droite"?
Direction du testeur de l'activité à droite soit direction = 0.
Le joueur tape comme un forcené sur la touche "Flèche Droite", rien ne se passe puique la variable A du sprite vert fluo, est différente de zéro.
C'était définir la direction et la variable ou déclarer les variables.
La valeur modifiable A du sprite vert fluo est réglée sur 1, que va t'il se passer?
Un déplacement forcément.
Notre sprite va se déplacer de pixel en pixel.
Attention c'est parti pour une ligne (7) avec une condition.
- Valeur modifiable A du sprite vert fluo = 1.
Alors (actions).
- Fixer la position X, du sprite vert fluo à position X, du sprite vert fluo + 1.
1 représente précisément un pixel, un pixel étant indivisible.
Néanmoins, vous pouvez toujours essayer de couper un pixel en quatre (mdr).
- Ajouter 1 à la valeur modifiable B du sprite vert fluo.
Tant que la valeur modifiable A sera égale à 1, le sprite vert fluo, se déplacera de + 1 pixel sur l'axe X.
Taille de la scène 640x480, axe X 640 pixels, axe Y 480 pixel.
En gros une ligne horizontale de 0 à 640, (0 à gauche) et une ligne verticale de 0 à 480 (0 en haut).
Je vous laisse devinez où se trouve sur la scène le point X =0 et Y = 0.
Hé! Il y a un bug, que fait la Clickteam, impossible d'arrêter le sprite vert fluo, de changer de direction.
Calmos, rien de plus normal, je saute les trois autres directions (gauche X-1, haut Y-1, bas Y+1), puisque c'est à chaque fois, le même principe.
Attention c'est parti pour une autre ligne avec une condition.
- Valeur modifiable B du sprite vert fluo > 31 (= 32).
Alors (actions).
- Fixer la valeur modifiable A du sprite vert fluo à 0.
- Fixer la valeur modifiable B du sprite vert fluo à 0.
Tant que la valeur modifiable B ne sera pas plus grande que 31, le sprite vert fluo, se déplacera de + 1 pixel sur l'axe X.
C'était le déplacement de + 32 pixels, d'un sprite joueur, sur l'axe X.
Ce sprite joueur se trouve au dessus de la couche non obstacle, MMF mémorise la position X et Y du sprite vert fluo, à l'aide de deux variables modifiables, X et Y (ligne 14).
Le sprite vert fluo se trouve au dessus de la couche obstacle, MMF fixe la position du sprite vert fluo à la position précédente X et Y du sprite vert fluo, mémorisée via les deux variables modifiables, X et Y (ligne 15).
Ce moteur de déplacement n'est pas optimisé, afin de rester lisible par un débutant.
Néanmoins la gestion du sprite PJ, est présente, direction, animation, collision.
Exemple "Pixel par pixel" (mfa):
https://www.dropbox.com/s/nsw6r18pk4sonhj/Pixel%20par%20pixel.mfa
En espérant que ces quelques bases, se révèlent utiles.
Cordialement.
Klougy.
