Messagerie
-
Salut, oui tu peux trouver Mario Sorb ici: https://lecomptoirduclickeur.fr/game/2019-10-08-22-06-super-mario-sorbXenon3K - 20/09/2024 14:15:26 -
Quelques jeux ici également: http://sscompf.free.fr/Xenon3K - 20/09/2024 14:16:54
-
Merci Xenon j'espère que ça va bien depuis le temps ^^burnedsoul - 20/09/2024 20:49:04 -
Le premier lien est down sur le comptoir mais je vais voir sur ssc ;)burnedsoul - 20/09/2024 20:49:30
Programmation Klik (niveau débutant).
Salut à tous,
Afin de suivre les explications proposées, vous devez posséder la notion variable.
Comment programmer avec CTF?
Avec méthode...
_________________________________________________________________________________________________
Un click soft possède un langage de programmation Klik. >> Le Klik coding.
Ce langage passe principalement par des éditeurs, un inconvénient à haut niveau de programmation.
L' idéal pour un proto de jeu vidéo. >> Gros gain de temps, quand on a de l'expérience.
1) L'éditeur de scènes, l'espace de travail graphique.
Un projet réclame de mettre au point des sprites (lutins) invisibles, donc des trucs et astuces. >> Klik spriting.
Lors d'un projet on étudie et on prépare les ressources graphiques à l'avance, on essaye de les "simplifier" via des layers.
Un layer est une capture d'écran de plusieurs objets, ou une "décomposition" d'un objet.
2) L'éditeur d'événements, un tableau cases à cocher.
Ce tableau est plein de subtilités, un bouquin pour les expliquer est nécessaire.
Les choses à bien comprendre sont...
a) La variable.
b) La boucle rapide.
c) L'objet tableau.
Remarque à la base une scène, le tableau cases à cocher, sont des espaces "limités", bien sûr il existe des astuces afin de réduire le nombre d'objets.
A déconseiller les gadgets, groupes d'événements globaux, comportements#1, #2, #3, etc, sauf pour un petit projet.
3) L'éditeur de storyboard.
Copier coller une scène, le gros plus comparé à TGF 1.
_____________________________________________________
Il est besoin d'une méthodologie, on part du plus simple, et ensuite on complique, on ne part pas du plus compliqué afin de simplifier, logique.
Un jeu basique se compose généralement d'une tuile de base, d'un moteur de déplacement, d'une I.A si besoin.
La base d'un solver est la ligne comparative.
© Un projet réclame de mettre au point des sprites (lutins) invisibles, donc des trucs et astuces.©
Klik spriting. >> Mise au point de sprites, de layers.
Exemple de mise au point d'un layer "décomposé", en gris la couleur transparente.
Layer de base.
Layer 1
Layer 2
Ce layer "décomposé" sert à mettre au point une astuce pour un slider, via un jeu de variables, on déplace les pièces du slider.
Un slider puzzle, pour ceux qui ont oublié.
Super pour les enfants!
Le but étant de progresser et non de régresser avec un logiciel click, la mise en pratique, le moteur de déplacement avec une tuile de base 80x80 pixels, fait 2 lignes difficiles à comprendre.
Vous devez la décortiquer afin de cerner le principe, le layer n°1, interdit le déplacement d'une pièce en diagonale.
Le layer n°2 permet le déplacement d'une pièce sur quatre direction, haut, bas, droite, gauche.
Un curseur (carré vert) mémorise la position courante X et Y, via une variable A et B, à condition de cliquer sur l'emplacement libre.
Par abus de langage, le clikeur dit moteur, pour tout et n'importe quoi, une habitude à prendre si vous maîtrisez déjà un langage de programmation.
Lors d'un "gros" projet, savoir réduire les lignes (conditions) est indispensable, une habitude à prendre.
Mise en pratique, confirmant qu'avec CTF, tout ne se règle pas à grands coups de programmation, un logiciel click possède une "philosophie" klik (and play).
https://mega.nz/#!mdAViY4Q!ZGbGmU5gaXg8WoQ5B7K24lYI06YZvG__p1sJMZt3L-0
En espérant que ces quelques bases, se révèlent utiles.
Cordialement.
Klougy.
Afin de suivre les explications proposées, vous devez posséder la notion variable.
Comment programmer avec CTF?
Avec méthode...
_________________________________________________________________________________________________
Un click soft possède un langage de programmation Klik. >> Le Klik coding.
Ce langage passe principalement par des éditeurs, un inconvénient à haut niveau de programmation.
L' idéal pour un proto de jeu vidéo. >> Gros gain de temps, quand on a de l'expérience.
1) L'éditeur de scènes, l'espace de travail graphique.
Un projet réclame de mettre au point des sprites (lutins) invisibles, donc des trucs et astuces. >> Klik spriting.
Lors d'un projet on étudie et on prépare les ressources graphiques à l'avance, on essaye de les "simplifier" via des layers.
Un layer est une capture d'écran de plusieurs objets, ou une "décomposition" d'un objet.
2) L'éditeur d'événements, un tableau cases à cocher.
Ce tableau est plein de subtilités, un bouquin pour les expliquer est nécessaire.
Les choses à bien comprendre sont...
a) La variable.
b) La boucle rapide.
c) L'objet tableau.
Remarque à la base une scène, le tableau cases à cocher, sont des espaces "limités", bien sûr il existe des astuces afin de réduire le nombre d'objets.
A déconseiller les gadgets, groupes d'événements globaux, comportements#1, #2, #3, etc, sauf pour un petit projet.
3) L'éditeur de storyboard.
Copier coller une scène, le gros plus comparé à TGF 1.
_____________________________________________________
Il est besoin d'une méthodologie, on part du plus simple, et ensuite on complique, on ne part pas du plus compliqué afin de simplifier, logique.
Un jeu basique se compose généralement d'une tuile de base, d'un moteur de déplacement, d'une I.A si besoin.
La base d'un solver est la ligne comparative.
© Un projet réclame de mettre au point des sprites (lutins) invisibles, donc des trucs et astuces.©
Klik spriting. >> Mise au point de sprites, de layers.
Exemple de mise au point d'un layer "décomposé", en gris la couleur transparente.
Layer de base.
Layer 1
Layer 2
Ce layer "décomposé" sert à mettre au point une astuce pour un slider, via un jeu de variables, on déplace les pièces du slider.
Un slider puzzle, pour ceux qui ont oublié.
Super pour les enfants!
Le but étant de progresser et non de régresser avec un logiciel click, la mise en pratique, le moteur de déplacement avec une tuile de base 80x80 pixels, fait 2 lignes difficiles à comprendre.
Vous devez la décortiquer afin de cerner le principe, le layer n°1, interdit le déplacement d'une pièce en diagonale.
Le layer n°2 permet le déplacement d'une pièce sur quatre direction, haut, bas, droite, gauche.
Un curseur (carré vert) mémorise la position courante X et Y, via une variable A et B, à condition de cliquer sur l'emplacement libre.
Par abus de langage, le clikeur dit moteur, pour tout et n'importe quoi, une habitude à prendre si vous maîtrisez déjà un langage de programmation.
Lors d'un "gros" projet, savoir réduire les lignes (conditions) est indispensable, une habitude à prendre.
Mise en pratique, confirmant qu'avec CTF, tout ne se règle pas à grands coups de programmation, un logiciel click possède une "philosophie" klik (and play).
https://mega.nz/#!mdAViY4Q!ZGbGmU5gaXg8WoQ5B7K24lYI06YZvG__p1sJMZt3L-0
En espérant que ces quelques bases, se révèlent utiles.
Cordialement.
Klougy.
Salut à tous!
© Lors d'un "gros" projet, savoir réduire les lignes (conditions) est indispensable, une habitude à prendre.©
Un forum apporte des solutions au coup par coup, pas des notions de programmation.
En plus clair tôt ou tard vous serez seul à klik coder, et seul face à des choix cornéliens, des compromis selon le projet.
Sans notion de programmation, il sera difficile de finaliser un projet un tantinet sérieux.
Un projet de jeu vidéo, débute par un prototype, CTF propose un kit un peu déroutant, une page blanche à remplir.
Pour un jeu basique, la procédure est simple, la phase schématique, afin de parvenir à un training mode, une base valable donc fiable et sans bug.
Le niveau de base sera ensuite copié, collé, modifié, afin d'obtenir un autre niveau et ainsi de suite.
Autant dire que si la base est mauvaise, le projet sera mauvais, au début sans expérience, on perd du temps pour ensuite en gagner.
Il y a un effet kiss cool, plus la méthodologie est au point, plus on peut l'affiner, plus on finalise rapidement.
Pour ma part, je mets au point des groupes d'événements, sur lesquels on peut ajouter sans prise de tête d'autres groupes, mais ceci est une autre histoire.
Le sujet du jour, savoir réduire les conditions.
En matière de klik coding, on ne part pas du travail des autres, mais de son travail.
© Le meilleur moteur est celui que l'on comprend de A à Z.©
Réduire les conditions, consiste à trouver des trucs et astuces, afin d'alléger les "commandes", le travail de CTF.
Avec des conditions moins nombreuses, il est plus facile par la suite d'ajouter d'autres conditions.
Cela réclame de la méthode, de la discipline, de la rigueur, de la persévérance, de l'obstination.
Si le klik coding n'est pas ordonné, commenté, inutile de dire que réaliser un jeu vidéo peut vite devenir un cauchemar.
Une phase schématique permet de résoudre peu à peu, les problématiques liées au projet, en effectuant des tests.
Ne travaillez pas dans le vide, constituez une base de données "moteurs" relatifs à une problématique, un cahier des charges.
Au départ on peut gribouiller un schéma de programmation, en partant de la fameuse question "how to play".
____________________________________________________________________________________
La phase schématique pour un remake du jeu Atomix, une phase non optimisée d'environ 40 lignes.
https://mega.nz/#!6cQwSSaZ!U1I9FPfk5BOvqJVQmTvvXljvcPhYzDas6MkO8WvF3uY
Déjà pour en arriver là, il y a du boulot, beaucoup de scènes tests, etc...
La phase schématique optimisée de 14 lignes, on peut encore la réduire mais trop optimiser une phase schématique peut devenir contre productif.
Quand on reprend le prototype, on ne sait plus ce qui a été fait, le code klik doit rester lisible et accessible.
https://mega.nz/#!vZA3UZBT!Aue_96GFhDU1DgmxQ4XlDAlFnnu8jg9vUjs8VRGdeuA
A vous de décortiquer les phases afin de capter les subtilités.
____________________________________________________________________________________
Les difficultés rencontrées.
1) Pas d'exemple, de modèle klik concernant le jeu Atomix.
***
2) La gestion des collisions ("bug" CTF à contrer, "contre" moteur de déplacement).
https://mega.nz/#!yERlyQrQ!5PG0zxm1z1kNrhvj4fTD-L98ESjjwuV50eMHJV_PL5k
La gestion des collisions, étant la principale problématique, je vous propose de la résoudre pas à pas.
Dans ce cas particulier, le mieux est de gérer l'axe X et l'axe Y, séparément lors d'un déplacement, ne pas confondre un déplacement avec un drag and drop.
L'astuce utilisée pour gérer les collisions est fort simple.
a) Arrêt d'un atome.
Actif est en collision avec un décor (un obstacle). >> Actif stop.
Là, rien de compliqué.
b) Atome stoppé, position au centre d'une case sur la grille.
Là, on peut vite s'arracher les cheveux, à moins de dissocier l'axe X et Y.
Direction de l'actif = 0, l'actif est au dessus d'un décor, fixer la position X à X moins un (-1).
Direction de l'actif = 16, l'actif est au dessus d'un décor, fixer la position X à X plus un (+1).
Direction de l'actif = 24, l'actif est au dessus d'un décor, fixer la position Y à Y moins un (-1).
Direction de l'actif = 8, l'actif est au dessus d'un décor, fixer la position Y à Y plus un (+1).
Avec seulement cinq lignes, on gère la couche obstacle.
***
3) Le résolver de niveaux.
4) La disparition dans l'ordre des atomes.
Là, on peut vite abandonner, si la molécule possède une trentaine d'atomes, à moins de faire preuve d'astuces donc d’espièglerie.
Avec logiquement une position x,y, préalablement mémorisée, on compare la position x,y d'un actif (atome).
Position x,y, mémorisée est égale à position x,y d'un atome, passe à l'atome suivant, ajoute 1 au compteur.
Le compteur est égal à trente, fin du niveau, niveau suivant.
La mise en pratique:
https://mega.nz/#!udRWiARL!gctMb2jQnp0rV8Id-yd0ZynGJLSoAqf13P7gdodD_aY
____________________________________________________________________________________
Mine de rien et mine de crayon, il s'agit du making off d'un prototype, vous venez de jetez un coup d’œil dans l'antre, d'un clickeur expérimenté.
En espérant que cela vous apporte un peu d'idées concernant une méthodologie.
Merci de votre attention.
Cordialement.
Klougy.
A+++
© Lors d'un "gros" projet, savoir réduire les lignes (conditions) est indispensable, une habitude à prendre.©
Un forum apporte des solutions au coup par coup, pas des notions de programmation.
En plus clair tôt ou tard vous serez seul à klik coder, et seul face à des choix cornéliens, des compromis selon le projet.
Sans notion de programmation, il sera difficile de finaliser un projet un tantinet sérieux.
Un projet de jeu vidéo, débute par un prototype, CTF propose un kit un peu déroutant, une page blanche à remplir.
Pour un jeu basique, la procédure est simple, la phase schématique, afin de parvenir à un training mode, une base valable donc fiable et sans bug.
Le niveau de base sera ensuite copié, collé, modifié, afin d'obtenir un autre niveau et ainsi de suite.
Autant dire que si la base est mauvaise, le projet sera mauvais, au début sans expérience, on perd du temps pour ensuite en gagner.
Il y a un effet kiss cool, plus la méthodologie est au point, plus on peut l'affiner, plus on finalise rapidement.
Pour ma part, je mets au point des groupes d'événements, sur lesquels on peut ajouter sans prise de tête d'autres groupes, mais ceci est une autre histoire.
Le sujet du jour, savoir réduire les conditions.
En matière de klik coding, on ne part pas du travail des autres, mais de son travail.
© Le meilleur moteur est celui que l'on comprend de A à Z.©
Réduire les conditions, consiste à trouver des trucs et astuces, afin d'alléger les "commandes", le travail de CTF.
Avec des conditions moins nombreuses, il est plus facile par la suite d'ajouter d'autres conditions.
Cela réclame de la méthode, de la discipline, de la rigueur, de la persévérance, de l'obstination.
Si le klik coding n'est pas ordonné, commenté, inutile de dire que réaliser un jeu vidéo peut vite devenir un cauchemar.
Une phase schématique permet de résoudre peu à peu, les problématiques liées au projet, en effectuant des tests.
Ne travaillez pas dans le vide, constituez une base de données "moteurs" relatifs à une problématique, un cahier des charges.
Au départ on peut gribouiller un schéma de programmation, en partant de la fameuse question "how to play".
____________________________________________________________________________________
La phase schématique pour un remake du jeu Atomix, une phase non optimisée d'environ 40 lignes.
https://mega.nz/#!6cQwSSaZ!U1I9FPfk5BOvqJVQmTvvXljvcPhYzDas6MkO8WvF3uY
Déjà pour en arriver là, il y a du boulot, beaucoup de scènes tests, etc...
La phase schématique optimisée de 14 lignes, on peut encore la réduire mais trop optimiser une phase schématique peut devenir contre productif.
Quand on reprend le prototype, on ne sait plus ce qui a été fait, le code klik doit rester lisible et accessible.
https://mega.nz/#!vZA3UZBT!Aue_96GFhDU1DgmxQ4XlDAlFnnu8jg9vUjs8VRGdeuA
A vous de décortiquer les phases afin de capter les subtilités.
____________________________________________________________________________________
Les difficultés rencontrées.
1) Pas d'exemple, de modèle klik concernant le jeu Atomix.
***
2) La gestion des collisions ("bug" CTF à contrer, "contre" moteur de déplacement).
https://mega.nz/#!yERlyQrQ!5PG0zxm1z1kNrhvj4fTD-L98ESjjwuV50eMHJV_PL5k
La gestion des collisions, étant la principale problématique, je vous propose de la résoudre pas à pas.
Dans ce cas particulier, le mieux est de gérer l'axe X et l'axe Y, séparément lors d'un déplacement, ne pas confondre un déplacement avec un drag and drop.
L'astuce utilisée pour gérer les collisions est fort simple.
a) Arrêt d'un atome.
Actif est en collision avec un décor (un obstacle). >> Actif stop.
Là, rien de compliqué.
b) Atome stoppé, position au centre d'une case sur la grille.
Là, on peut vite s'arracher les cheveux, à moins de dissocier l'axe X et Y.
Direction de l'actif = 0, l'actif est au dessus d'un décor, fixer la position X à X moins un (-1).
Direction de l'actif = 16, l'actif est au dessus d'un décor, fixer la position X à X plus un (+1).
Direction de l'actif = 24, l'actif est au dessus d'un décor, fixer la position Y à Y moins un (-1).
Direction de l'actif = 8, l'actif est au dessus d'un décor, fixer la position Y à Y plus un (+1).
Avec seulement cinq lignes, on gère la couche obstacle.
***
3) Le résolver de niveaux.
4) La disparition dans l'ordre des atomes.
Là, on peut vite abandonner, si la molécule possède une trentaine d'atomes, à moins de faire preuve d'astuces donc d’espièglerie.
Avec logiquement une position x,y, préalablement mémorisée, on compare la position x,y d'un actif (atome).
Position x,y, mémorisée est égale à position x,y d'un atome, passe à l'atome suivant, ajoute 1 au compteur.
Le compteur est égal à trente, fin du niveau, niveau suivant.
La mise en pratique:
https://mega.nz/#!udRWiARL!gctMb2jQnp0rV8Id-yd0ZynGJLSoAqf13P7gdodD_aY
____________________________________________________________________________________
Mine de rien et mine de crayon, il s'agit du making off d'un prototype, vous venez de jetez un coup d’œil dans l'antre, d'un clickeur expérimenté.
En espérant que cela vous apporte un peu d'idées concernant une méthodologie.
Merci de votre attention.
Cordialement.
Klougy.
A+++
Utilisateurs en ligne
- Aucun utilisateur en ligne
- 14 visiteurs au total
