GamEditorDS

Du point de vue du moteur de jeu, un niveau est avant tout une grille dont chaque case reçoit des propriétés: solide, solide uniquement quand on tombe, pente, spécial, etc.Les "blocs spéciaux" ne sont pas compris par le moteur de jeu lui-même (d'où ... [More] leur caractère "spécial") mais décrits dans les scripts qui définissent les règles du jeu.Ainsi, quand Bilou touche par exemple un Bonus, le moteur de jeu récupère quelques bits d'information pour chaque pavé (8x8) de la grille constituant le bloc (16x16) et reconstruit un numéro de bloc spécial (de 0 à 255) qui permettra de retrouver les instructions à exécuter (faire un son, déclencher une animation, donner des points, etc.)Quand Bilou touche une pente, en revanche, le moteur de jeu sait qu'il doit aller regarder une petite table indiquant la hauteur de chaque pixel de la pente. A priori, la forme de cette pente pourrait être n'importe quoi. Mon éditeur de niveau connaît les pentes à 45° et à 22.5°Mais voilà: j'aimerais pouvoir avoir plus de souplesse: des escaliers, des coudes, par exemple. Un petit schéma de rien du tout qui traîne depuis des années (2010?) sur un bloc de brouillon en atteste. "Le mieux serait d'avoir deux boutons 'pente' [dans l'éditeur de sprites] qui forcent le remplissage d'une ligne de 64x16 pixels avec des pentes suivies (les modèles)"  ajoute encore le calepin.En effet, la technique que j'envisageais alors consistait à utiliser comme information supplémentaire la position du graphisme au sein d'une ligne de blocs dans l'éditeur de niveau (une "tranche" de 16 pavés de 8x8 successifs). On pourra alors convertir l'information de la grille "pente compliquée vers la droite" en "transition douce de 0° à 22°" parce qu'on est dans le 6eme pavé sur une tranche de 16.Sur les dernières années, ça n'a jamais été mis en service et mes derniers tours d'horizon dans le code de l'éditeur de Sprites me confirme que travailler "par tranche de 16 pavés" serait un vrai casse-tête (le mode et le moment de l'allocation des pavés dans la mémoire vidéo n'étant absolument pas prévu pour ça).Et cet été vient une idée qui jette un autre éclairage sur ce problème: "Les pentes douces, c'est un problème pour l'éditeur de niveaux. Ce n'est pas quelque-chose à régler dans l'éditeur graphique.Et l'éditeur de niveau sait par contre traiter des groupes de chiffres pour montrer qu'un bloc spécial est soit un bonus, soit des pics, etc. En prenant donc un type de pavé qui dit "pente compliquée, regardez les chiffres en-dessous pour en savoir plus", je peux diriger le moteur de jeu vers une autre table de hauteurs qui définit la pente (parmi 16 pentes possibles), mais aussi éventuellement fixer le coefficient de friction (sol dur, glissant, boue-qui-ralentit, etc.)Il me tarde d'essayer ça ^_^ [Less]

Il est temps de passer du 'test fonctionnel' à quelque chose de plus "habillé" pour le dernier niveau vertical. Jusqu'ici, je m'étais contenté d'un minimum de graphisme (les blocs-sol) pour vérifier si les sauts étaient possibles. Il est temps de ... [More] dessiner le reste des objets.Ouais, sauf que pour avoir des dessus-de-fardes-sur-lesquels-on-marche un peu partout dans le niveau, c'est pas forcément simple. J'avais pensé à des "couches" suggérées par différentes couleurs (il y a déjà une convention dans l'ensemble du jeu du genre farde verte = mur, farde brune/mauve/vert-foncée = plate-forme semi-solide), et faire des structures un peu imbriquées comme avec mes bons-vieux-buissons.Sauf que pour faire facilement ce genre de choses avec un tileset réduit, je jouais sur les deux plans de tiles, toujours le même pour ce qui est par-devant, l'autre pour tout le reste. Mais mon moteur de jeu ne permet pour l'instant de changer la palette de couleurs que pour les tiles d'arrière plan: les tiles d'avant-plan sont systématiquement "verouillés" sur la palette #0 et les bits correspondants sont utilisés pour encoder le type de bloc.Bref, pour cette fois-ci, je vais me débrouiller en créant "à la main" des tiles supplémentaires qui "combinent" les deux couches, avec des imports de palette, mais ce ne sera pas beau à regarder dans l'éditeur (parce que le joueur ne devrait pas voir la différence, lui). Décidément, tout cet été pousse vers un déplacement des propriétés du niveau hors des couches de "rendu". [Less]

(enfin, le porte-mine, plutôt). Les aspects techniques pour avoir une petite image originale au chargement de chaque niveau sont réglés. Je gribouille un peu pour avoir les 4 images qui me plaisent pour raconter l'histoire de School Rush (invasion ... [More] des crayons-soldats, résistance, déroute et vengeance des soldats en question).Ce qui s'avère être plus ou moins l'opposé de ce que j'avais prévu de faire raconter au cancrier dans la BD, en fait ... donc il va me falloir encore au moins une dernière image. [Less]

J'ai attaqué une révision du code de contrôle entre le moteur de jeu et l'affichage de l'écran du livre-magique. J'ai déjà remplacé les tests douteux sur des variables obscures supposés indiquer si on est sur le menu ou dans le jeu par une commande ... [More] explicite "hud.mode=%c" Je continue avec une simplification des relations entre "GameScript", "GameWindow" (qui s'appelle toujours CmdWindow parce qu'elle s'occupe des fichiers .cmd) et "Hud". Le Script et le HUD sont maintenant créés avant le chargement du niveau, le "setup" qui permet au HUD de savoir quel objet est le héro, où sont les compteurs, le score, etc. se produit explicitement lors du dernier "end"Enfin, je suis prêt pour un 'hud.show "somefile.spr"' qui me permettra de raconter une petite histoire sur l'écran du bas avec une image différente pour chaque niveau. [Less]

Voilà ... quelques retouches à mon projet "blogpress" puisque je m'étais fait exiler sur le vieux PC bruyant où je l'avais développé. Et j'en extrait un livre de 600 mini-pages avec les posts sur le thème "quel jeu ?"Bien sympa. En Français ... [More] exclusivement (puisque je filtre le contenu des balises "" au moment de l'export pour le format .epub), et perfectible: j'approche les 50Mo pour un thème (une dizaine de tags sur le blog) trop d'images dupliquées. Il faudra les identifier (fdupes) et n'en garder qu'une de chaque la construction d'un chapitre par tag est plus intéressante parce qu'elle permet de cibler la lecture (en tout cas pour moi) Tous les liens page-à-page sont pour l'instant perdus (si on clique dessus, la liseuse essaiera d'aller se connecter sur le blog) Enfin, je serai prêt à affronter les plages et les plaines de jeu ^_^ [Less]

Il y a environ 2 ans, quand j'ai reçu le commentaire d'Eric sur School Rush, j'étais en pleine tentative de changer radicalement la manière dont fonctionne le chargement des niveaux dans GEDS. Malheureusement, rien ne se déroulait comme je voulais. ... [More] Du coup, sa remarque Pourquoi le chargement des niveaux est aussi chaotique ?? est un peu restée en suspens. Je ne savais pas vraiment en faire grand-chose. Entre-temps, le projet de "marché au bonus pendant les temps de chargement" est passé à la trappe en faveur d'un niveau-à-vies/power-ups. Le chaos du changement de niveau (en partie dû au fait que j'aime bien savoir si les étapes se passent correctement en phase de développement, j'avoue) est masqué par un "rideau noir", mais le temps de chargement, lui, est toujours aussi long.En relisant son commentaire cette semaine, juste après avoir ajouté une "page-de-livre magique" supplémentaire, je me rends compte que l'écran du bas (le livre, donc) ne subit presque aucun changement pendant tout le chargement.En haut, tous les graphismes sont re-chargés, puis la nouvelle map est mise à l'écran, puis -- seulement quand tous les scripts ont étés traduits en machines d'états et tous les personnages positionnés -- on peut positionner la caméra dans le niveau à l'endroit où doit commencer l'action.Mais en bas, rien ne se produit jusqu'à ce que le niveau soit déclaré "prêt". Je peux donc repêcher une des illustrations qui servaient à présenter les niveau de difficulté et les donner en pâture au joueur -- peut-être avec un message adapté à sa performance (première arrivée dans le niveau, première raté dans le niveau, dernière chance).  J'ai un premier prototype pour ce genre de chose. Afficher l'image au moment où on commence le chargement, c'est facile. Je dois maintenant retrouver dans la séquence "démarrage du niveau" le moment où le niveau va démarrer de sorte qu'on puisse éviter un "glitch" du genre "la page de chargement était affichée, la page de jeu s'affiche un instant, puis l'écran devient brusquement noir avant de se rouvrir sue la page de jeu". N'est-ce pas, Eric ? [done] glitchless showScreen() while loading. [unplanned but done] refactor so that "hud.mode" is defined through script [unplanned todo] refactor so that showScreen is called from "hud.load/show" [done] adapt the picture to show to the level we're in [todo] adapt the position to show to the lives we have (for specific messages) [todo] make it tell the story of the game [Less]

Il y a environ 2 ans, quand j'ai reçu le commentaire d'Eric sur School Rush, j'étais en pleine tentative de changer radicalement la manière dont fonctionne le chargement des niveaux dans GEDS. Malheureusement, rien ne se déroulait comme je voulais. ... [More] Du coup, sa remarque Pourquoi le chargement des niveaux est aussi chaotique ?? est un peu restée en suspens. Je ne savais pas vraiment en faire grand-chose. Entre-temps, le projet de "marché au bonus pendant les temps de chargement" est passé à la trappe en faveur d'un niveau-à-vies/power-ups. Le chaos du changement de niveau (en partie dû au fait que j'aime bien savoir si les étapes se passent correctement en phase de développement, j'avoue) est masqué par un "rideau noir", mais le temps de chargement, lui, est toujours aussi long.En relisant son commentaire cette semaine, juste après avoir ajouté une "page-de-livre magique" supplémentaire, je me rends compte que l'écran du bas (le livre, donc) ne subit presque aucun changement pendant tout le chargement.En haut, tous les graphismes sont re-chargés, puis la nouvelle map est mise à l'écran, puis -- seulement quand tous les scripts ont étés traduits en machines d'états et tous les personnages positionnés -- on peut positionner la caméra dans le niveau à l'endroit où doit commencer l'action.Mais en bas, rien ne se produit jusqu'à ce que le niveau soit déclaré "prêt". Je peux donc repêcher une des illustrations qui servaient à présenter les niveau de difficulté et les donner en pâture au joueur -- peut-être avec un message adapté à sa performance (première arrivée dans le niveau, première raté dans le niveau, dernière chance).  J'ai un premier prototype pour ce genre de chose. Afficher l'image au moment où on commence le chargement, c'est facile. Je dois maintenant retrouver dans la séquence "démarrage du niveau" le moment où le niveau va démarrer de sorte qu'on puisse éviter un "glitch" du genre "la page de chargement était affichée, la page de jeu s'affiche un instant, puis l'écran devient brusquement noir avant de se rouvrir sue la page de jeu". N'est-ce pas, Eric ? [done] glitchless showScreen() while loading. [unplanned but done] refactor so that "hud.mode" is defined through script [unplanned todo] refactor so that showScreen is called from "hud.load/show" [todo] adapt the picture to show to the level we're in [todo] adapt the position to show to the lives we have (for specific messages) [todo] make it tell the story of the game [Less]

Henk Nieborg, maître incontesté du Pixel art qui s'inscrit sur Patreon, c'était plutôt inattendu. Mais un artiste d'un niveau pareil qui propose des tutoriels, c'est le bienvenu. L'image ci-contre n'est pas directement un des tutoriels du maître ... [More] , mais le résultat de ma session de "pixel study" pour voir un peu comment il choisit ses couleurs. Résultat ? Eh bien, si le buisson d'arrière plan correspond assez bien à ce qui est recommandé d'ordinaire (décalage chromatique entre les ton obscurs et les tons clairs), j'ai été assez surpris de voir la palette pour la terre rester pratiquement sur la même tonalité (avec uniquement un changement de luminosité) et de voir que toutes les couleurs utilisées pour les "herbes" sont complètement saturées...PS: c'est moi ou les herbes font penser à des cheveux en bataille ? Y'a quelque-chose à creuser pour Bilou, là ^_^ [Less]

Un stage bonus pour refaire le plein de power-up quand on est malencontreusement tombé dans l'encre, je trouve ça une bonne idée. Recycler pour ce faire le tout premier niveau de mon frangin (Calimero) ? J'aime beaucoup (et lui aussi ^_^).Par contre ... [More] , démarrer du début "historique" de ce niveau-là et laisser le joueur galérer pour trouver les power-up et rester en vie jusqu'à la sortie ... peut faire mieux. Et ce serait d'autant plus intéressant de faire mieux que ce niveau bonus pourrait aussi être l'endroit idéal pour se familiariser avec les power-ups en question, sans subir le stress de l'encre qui monte.D'où l'idée de faire débarquer le joueur à des points différents du niveau, selon le nombre de fois où il y retourne. Devant un des power-ups d'abord, puis devant celui qui permet de débloquer l'autre, puis enfin au "début historique".Du coup, ça demandera d'avoir des portions de script qui sont lue ou non selon un des compteur du jeu. (qui est aussi un préambule aux check-points). [Less]

Le niveau-tour ? je n'y ai pas vraiment touché ces derniers jours. Par contre, j'ai enfin "débloqué" la manière d'y accéder. Ou mettre les indices pour l'énigme, quelle sera cette énigme, et aussi mettre ça en place.