Sand falls

Il faut bien l'admettre, dans toutes ces animations de Bilou qui est repoussé par les chutes de sables et de décor en pseudo-3D réalisé à grand coup de HDMA, la chute de sable tout en pixels statiques, ça ne rendait pas particulièrement convainquant. C'est donc maintenant ma dernière étape avant une petite riliize de ma démo 3-écrans.

Anokolisa mock up, initial reference

Almost every time I posted a video about Bilou being pushed by sandy slopes or about the pyramid background 3D scrolling, I couldn't help being sorry for the flat, uninspired, unanimated sands fall that are present since the first release of the 'three rooms' demo. That's the last thing I want to fix before I release a new one.

ça fait un moment que j'avais ce mockup d'Anokolisa parmi mes images à étudier et j'avais même quelques gribouilles assez réussies de comment ils étaient construits ... mais vous en conviendrez, du miel et du sable, ça ne s'écoule pas granchement de la même manière.

J'ai fini par retourner regarder les graphismes de la Sandopolis Zone dans Sonic & Knuckles ... qui au final étaient assez simples de ce côté-là: un cycle de 4 couleurs dans la palette, un tramage par-ci, une rangée de pixels transparents par là ... j'ai essayé de m'en inspirer et ça rend assez correctement pour une première démo, je trouve. Il me reste encore à animer 'le sable qui descend le long de la pente'. Voyons si le week-end m'offre le temps de faire ça ;)

But it is a bit tricky to find good pixelart reference for such item. For quite some time, I thought I could use something inspired by Anokolisa's Hive tileset, until I realised that it would never flow like sand, no matter how close I could get from that brilliant design. Neither Souldiers nor Megaman could help, but I finally remembered about Sonic's Sandopolis Zone, burried in early reference hunts. A quick check on youtube convinced me that, once in motion, they are good looking. Their design is quite simple, though: wavy patterns of 4 colours that will be palette-cycled. When they have to become half-transparent, non-solid tiles, they are alternated with empty columns or dithered with transparent pixels. That's enough for a CRT screen, but I will likely require something a bit more subtle for the LCD screen of the Nintendo DS. Well, my pattern is more angled, but it seems to be good-looking enough, given mastodon reaction.

Now I have to aslo animate the slope itself, but checking Souldiers again, I believe I might better spawn waves periodically and let them roll down a static ground than trying to animate it all as I did for the sand falls (scoop: I'm not using palette cycling this time)

rules.gam

Plus proche de nous, mais en partie lié avec ce nouveau projet "behaviour editor",il y a le besoin de pouvoir utiliser un seul même fichier pour définir certains morceaux des scripts qui décrivent les niveaux. Ce n'était pas trop un soucis avec Apple Assault, un jeu dont les "règles" était assez simples, mais qui devient plus pénible à gérer avec School Rush.

Un niveau de School Rush décrit plusieurs types de choses: des resources (map, planches de sprites), des personnages (à travers les fichiers .cmd de comportement à charger), les positions et paramètres des personnages (définis par l'éditeur de niveau) et ce que j'appelle "les règles du jeu": réactions quand un compteur arrive à zéro, valeur initiale des compteurs (p.ex. le nombre de point de vie restant pour le joueur) et les propriétés des blocs spéciaux.

Pour l'instant, ces règles sont répétées à chaque niveau, et plus le projet avance, plus le risque augmente d'avoir un niveau ou p.ex. il est impossible de reprendre de la vie parce qu'il y a un bug dans les règles dans ce niveau-là.

Et le nombre d'animations pour les bonus augmente encore la pression sur ce point chatouilleux.

Extraire tout ça en un fichier qui serait "importé" par chaque niveau devrait être possible sans trop de difficultés, de la même façon que les machines d'états ne sont décrites qu'une seule fois et importées dans les niveaux où on a besoin d'elles. Par contre, pour pouvoir continuer à utiliser les indices graphiques dans l'éditeur de fichier, il faut qu'il sache qu'il doit y chercher les descriptions des blocs spéciaux.

Cela dit, en refaisant un peu d'exploration dans les sources de LEDS, j'ai noté que c'est simplement sur base de l'extension de fichier (.spr, .map, .cmd) que le code destiné à charger le niveau décide de ce qu'il va faire de chaque "fichier supplémentaire renseigné par le script du niveau). On devrait donc pouvoir utiliser un autre type d'extension (.gam ?) pour que l'éditeur de niveau s'y retrouve. Tout simplement.

MapAnim : done

Once again, properly mapping the codebase before starting to program got a loong-delayed-feature added to the engine within an afternoon. The code was actually written bottom up, starting with the revision of the "clearblock" function up to the script parsing code. 

I love so much the new little bounces and stars, I couldn't play the game without them anymore :P

Et donc les voilà, ces petites étoiles qui accompagnent la disparition des bonus et cette gomme rebondissante que l'on me recommandait. Je vais bien vite me refaire une version de School Rush qui intègre tout ça, parce qu'on y prend terriblement vite goût ^_^

Le nouveau système me permet aussi d'affiner un peu le comportement de la gomme rebondissante: elle ne projette plus Bilou immédiatement en l'air: au départ, elle n'est qu'un détecteur et devient un rebondisseur uniquement avec la première étape d'animation. Du coup, ça permet au joueur de mieux ajuster ses mouvement avec ce qui se passe dans le jeu (enfin, je trouve). 

QuickLinks: implementation notes and early specification sketches. 

Adding the MapAnim

 Allons-y donc pour l'ajout d'un nouveau type d'animations dans mon moteur de jeu: la modification du contenu de la map elle-même dans le temps. Jusqu'ici, c'était limité à "faire disparaître le bloc en (x,y)" ou "retire-lui ses propriétés, mais laisse-le visible" (pour les bonus cachés). ça peut marcher pour certaines choses, mais ça suppose que les éventuels effets liés à la disparition soient entièrement pris en charge par un sprite supplémentaire. Idéal si l'image doit quitter son emplacement (un morceau de pont qui tombe, un décompte des points qui monte, etc), celà dit.

Let's have one more way of animating things in my game engine. One that would be suited to special blocks, and that update the map content at a specific location over time. The only thing I could do so far would be to shoot a sprite-manipulating game object and make the block disappear. That's mostly appealing if you want a picture to move away, like broken bricks, falling logs and the like. 
The "BlockAnim", used to animate the ink, is not interactive and apply simultaneously to all the instances on screen. It can make SMW coins spin, but it cannot leave a trail of sprinkling sparkles behind.

Now, let's resume the coding, I'll keep you updated on the outcome. I already love the animation I designed last night for the bouncing erasers ^_^.

Il y avait aussi les "blockanims", qui permettraient par exemple de faire tourner les pièces de Super Mario World sur elles-même. On procède alors par une mise à jour de la mémoire "tiles" et toutes les instances de l'objet sont mises à jour simultanément sur l'image à l'écran.

Le nouveau "MapAnim", lui, correspond plutôt aux besoins pour faire bouger un buisson devant lequel on passe, mettre des petites étoiles là où il y avait un bonus, etc. Comme vous pouvez le constater sur les diagrames, le mécanisme qui permet de mettre à jour le niveau (les données gérées par la classe InfiniMap) n'est pas particulièrement simple. Il met en jeu une description de chaque type de bloc spécial (les BlockInfos) et un objet temporaire capturant "tel bloc à tel endroit" (le BlockArea) qui permet d'interagir avec le personnage (GameObject) qui vient de passer par là. C'est finalement InfiniMap lui-même qui procède à l'effacement sur base du résultat du test de collision. La seule bonne nouvelle, c'est que c'est assez souple pour permettre des (petites) portes, des bonus, des bumpers et même les guides invisibles qui font faire demi-tour aux encriers.

pauvre Game Feel

Je n'ai pas de définition de "Game Feel" à proposer. C'est juste un mot pour parler de ce qui fait que le jeu semble attrayant, divertissant. Les petits nuages de fumée de Rayman, les bananes qui s'envolent vers le compteur de DKC, la pièce d'or qui bondit hors des blocs-question dès Super Mario Bros sur NES...

Toutes des choses dont mon School Rush est actuellement dépourvu, comme le faisait remarquer Romain Claude:

Après le feeling avec le jeu c'est une tonne de choses à soigner : les réglages des paramètres physiques, les animations, tous les petits détails de feedback à droite à gauche qui rendent le tout "rewardant" et jouissif. Pour le moment le jeu est assez dépourvu de tout ça. Les gommes rebondissantes par exemple, si elles étaient animées cela rendrait le rebond plus satisfaisant et plus clair sur le fait que cet objet réagit.

Et qui est repris également sur le forum "e-magination", même rien qu'en regardant les images d'accroche:

Ce serait chouette que les bonus affichent un petit effet quand on les récupère, selon moi, ce serait moins "tristoune"

 J'y ajouterais bien un peu de secousse de caméra quand on donne un coup de poing au sol, si jeu peux.

It seems like people have dedicated the words "game feel" for all those little details that make a videogame feel more alive and reacting to player's actions. Dust clouds, sparkles, bananas flying towards their counter and things alike. It is becoming a recurring comment on current School Rush that I lack such little animations that should provide important feedback and make the player smile. 

Unfortunately, I have considered them as unimportant for most of the development and I'm now near the limits of the current game engine, especially when it comes to new graphics for the sprites. Both eraser-bumpers and disappearing bonuses will thus have to be implemented that patching the tilemap according to some animation commands ... something for which I haven't got code for. So far, the closest I had was pushing new graphics into the sprite/tilesets, which animates all the instances simultaneously.

Pour les bonus et les gommes animées, par contre, ça demande d'ajouter au map elle-même (et pas le remplacement des images du tileset comme c'est le cas pour les animations non-interactives : l'encre, les pommes qui se balancent dans la Green Zone, etc). J'avais pensé un temps m'en sortir avec un sprite temporaire, mais ma planche de sprite est trop remplie pour que ça puisse passer.
Je vais donc devoir rajouter au moteur de jeu un composant que j'ai retardé depuis probablement trop longtemps: l'animation d'un objet par manipulation du contenu de la map elle-même.

gedsdemo : get it!

Avec un petit desmume intégré à ubuntu, plus "byzanz" pour la capture vidéo (en .gif ... y'a mieux, mais c'est plus cher), et voilà un petit aperçu du rendu de la greenzone ...

vous pouvez télécharger la démo ici.

Okay, time for a demo. Here's what my Game Engine for DS (geds) looks like with a greenzone tileset and some sprites for the Bilou game ... captured out of desmume rendering using "byzanz".

Sorry for lacking time to translate former posts that describe my work. Hope i'll be able to do that soon.


PS: le moteur de jeu est et restera Open Source, mais en revanche, les droits d'auteurs habituel s'appliquent aux graphismes intégrés dans la démo.
Please keep in mind i spent hours on the art, and that unlike code, it is not open for reuse.

vu sur wayofthepixel et dev-fr.