samedi, décembre 13, 2014

Amélioration Spongebop ...

Je me suis amusé l'autre jour à imaginer comment les SpongeBops pourraient être plus interactives dans le jeu. Les faire flotter sur l'encre, bien sûr, mais aussi les transporter comme les dumbladors. Et pourquoi pas s'en servir également comme d'un "parapluie" contre les jets d'encre ?

So far, we can grab spongebops while they're swinging, and use them to reach higher places ... but that requires significant learning of the game mechanics. Dumbladors can be used to detach them but so far, it doesn't bring much difference. I wanted to add "carrying" and floating, which is now ongoing. I'd also love to make carried sponge a protection against falling ink droplets...

mardi, décembre 09, 2014

Leçon de tuning: la théorie


 
Tune it well ...
Animating a running pendat within restricted pixel space turned out better than I initially expected. Now, I have to tune that additional move to ensure it improves the gameplay. The speed at which it moves, the distance from which Bilou is detected and the acceleration were all arbitrarily picked while writing the script. They work rather well, but they can surely be tuned for maximal results.

Bien. J'ai rajouté une animation pour que le crayon-soldat puisse charger Bilou quand il l'aperçoit. Reste du coup les questions de tuning à régler:
  • à quelle vitesse doit-il courir ?
  • à quelle distance peut-il "sentir" Bilou ?
  • combien de temps doit-il mettre pour atteindre sa vitesse maximale ?
L'enjeu de ces règlages ? faire en sorte que les réflexes puissent continuer à tirer le joueur d'affaire et éviter de se retrouver dans une situation à la Rick Dangerous où le joueur doit mémoriser tout le parcours pour pouvoir jouer.
Bilou and Pendat positions over time
The issue with arbitrary values is that they can twist the gameplay towards a state where players can no longer react to what happens and have to memorize the level just to complete them. I have been convinced by Kirby Kid's blog that this is not the way platformers should be built and that they should instead allow to be "played while reading" once we mastered core skills (estimate trajectories, press buttons, read timings) and learnt game's physics. As our player has reaction time to the walk/rush transition of the pendat (a) and that Bilou needs some time e.g. to reach a height where collision no longer occurs (b) -- and possibly only keeps that height for some time (c), values exists where player cannot possibly escape. These must be avoided.

Je me suis donc donné deux cas d'étude: "Bilou tombe devant le pendat et doit s'échapper en courant" et "Bilou doit passer par-dessus le crayon en sautant". A partir de là, on peut représenter la distance Bilou-crayon au cours du temps et voir s'il y a ou non risque d'avoir une collision.

T_player_reacts + T_Bilou_reaches_speed < T_pendat_clears_distance
T_player + T_Bilou < Pendat_Detection_Distance / Pendat_max_speed

A sa vitesse actuelle, le pendat met 81 frames (1" 36 centièmes) pour aller de sa position actuelle à celle de Bilou. Bilou, lui, met 30 frames (1/2 seconde) à atteindre sa hauteur maximale (b) et on peut compter qu'il y reste 20 frames (c), pendant lesquelles le Pendat aura avancé de 30 pixels ... Assez pour se croiser sans accroc. J'ai vu la plus jeune testeuse de la S-team réussir ce saut d'instinct. Celà signifie qu'elle a un temps de réaction d'au plus 600ms ... Hmm ... Oui, le pendat actuel est loin de demander des efforts de réactivité puisqu'on estime à 200ms un bon temps de réaction à un stimulus, pouvant descendre près des 100ms pour un sportif entrainé. Et puisque Bilou est quasiment au centre de l'écran, celà signifie que si on voit le pendat quand il fait demi-tour, il nous attaque sitôt qu'il se retourne. Rétrécir la distance de détection et la compenser par un "sursaut" du crayon pourrait améliorer la situation

While my testing-nephews were giving it a try, I went through to "escape case" -- run away or jump over -- to map where would time go. Not even the youngest player had issues with the original timings, which left a generous 600ms to the player to dodge the rush. That's about 3 times the delay usually presented for fast reaction. It "turned" out that direct rush of the pendat is not the most dangerous -- so I can easily shorten the detection distance and have pendat entering the screen walking and only start chasing Bilou when at a distance close to 1/3 of the screen width. What is truly dangerous is that bounce when he enters a wall, and then quickly turns back. It means if you're waiting for him at the top of that wall, your window to sneak behind is small. In fact, the thing that may prove more stressful is to shoot him down with a blador. But that should simply tease you to get the straight-throw power-up ;)

En fait, le rebond contre le mur est beaucoup plus piégeux. J'imagine que c'est dû à la cassure du mouvement, plus difficile à estimer. Et l'atteindre avec un taille-crayon affecté par la gravité sera plus délicat, mais pas trop quand-même puisque le crayon a le bon goût de rester dans la zone active du taille-crayon pendant sa courbe. Ouf.

Avec tout ça, le "croco-désagrafeur" retombe dans l'oubli ...

dimanche, décembre 07, 2014

Super State Bros.

Une tentative de mesurer la complexité du comportement de Mario dans Super Mario World, avec l'idée de le comparer à celui de Rayman, histoire de mieux comprendre comment ce genre de chose peut monter à 15K de code source. Par comparaison, le code de Bilou prend 900 lignes de script et pas loin de 20K ... La partie des "micro-contrôleurs" qui définissent les actions élémentaires combinées dans la machine d'états prend pas loin de 1300 lignes de code, soit presque 40K caractères. C'est mesuré à la grosse louche vu qu'il y a aussi parmi ces contrôleur du code qui ne concerne que SpongeBop (pour l'instant), etc. et surtout une bonne dose d'annotations pour InspectorWidget.

How complex is a platformer character behaviour ... let's say Super Mario in Super Mario World ? Does that help me understand whether 15KB of code for Rayman Origins is compact, regular or stunning -- as it looked to Pasta Games developers who converted it into Jungle Rush game ? To figure out, I tried to depict a state-machine-like representation of all the states Super Mario can take, where a different state implies different reaction to player input.

In figures, that sums 21 different states for Mario, 6 of them working only with specific level elements and 6 others requiring a power-up. To my surprise, Rayman Origins accounts for a quite similar number of states, mostly because punching and kick'ing suspend some actions and can be cancelled like in a fighting game, therefore asking for a dedicated state while Super Mario's fireball can be spawned without cancelling any other move. The original Rayman on PSX had much simpler behaviour, with only 11 distinct states.


En chiffres: 9 états de base pour Mario ("soulignés"), 6 états supplémentaires pour interagir avec des éléments précis des niveaux (entre parenthèses) et 6 autres états qui ne sont disponibles qu'à travers un power-up. Graphiquement, la "sprite sheet" de Super Mario World est plus vaste, mais je n'ai pas répliqué ici "saute, saute avec un champignon, saute avec une fleur de feu, saute avec une plume, saute avec yoshi" parce que tous sont identiques au niveau du code de comportement: ils réagissent de façon identique au commandes du joueur.

En comparaison, je n'ai compté que 11 états dans le comportement du premier Rayman sous DOS/PSX, dont 5 doivent être débloqués au cours de la progression du joueur. Bien moins complexe qu'un SMW, donc. Mais les baffes (qui affectent la vitesse de Rayman), les attaques-rodéo et autres glissades, les rebonds et la nage de Rayman Origins.

Le personnage de Xargon en est à 10K symboles (389 lignes de code)... Ah, oui ... il faudra que je regarde d'un peu plus près le code de Keen Dreams.

dimanche, novembre 30, 2014

Le Tuning

La première remarque de Kirby Kid concernant le jeu "School Rush" m'avait un peu décontenancé. Je ne voyais pas bien ce qu'il entendait par "des problèmes de tuning" (non, quand-même pas au point d'aller acheter des néons bleus, mais pas loin).
A rediscuter par la suite, je me dis que les fleurs-piranha de Super Mario Bros sont certainement le meilleur exemple de gameplay bien tuné -- appelons ça "accorder les personnages du jeux" comme on accorderait ses cordes de violon ? -- que l'on puisse donner.

It took me time to figure out what sort of "tuning" Kirby Kid expected me to bring in. I finally realized that one of the best example of gameplay tuning is the way Piranha plants grow and shrink in Super Mario Bros. If you try and speed-run the game like in the first series of pictures, you'll see the plants active during almost all the time their pipe is visible on-screen. If you rather progress forward without stopping, but without running, chances are that the plant will be retracting while you reach the pipe but you've been warned as the plant was out when it entered the screen. If you happen to experience difficulties approaching the pipe (due to a tedious jump ?) chances are that you'll be threatened by the second raise of the plant.

Hopefully enough, when you're on the pipe, the plant are too shy to pop out and gnap you.


La première série d'image vient d'un speedrun du jeu. On approche donc les deux plantes carnivores à la vitesse maximale de Mario. Les plantes sont ici ouvertes dès leur apparition à l'écran mais ne vont se rétracter que quelques blocs avant de quitter l'écran.

La deuxième série d'images vient d'une vidéo de type "let's play" avec un joueur non entraîné, qui prend le temps d'éliminer les goombas avant d'arriver au tuyau. Avec une vitesse de marche normale, on arrive sur l'obstacle juste au moment où celui-ci va se rétracter. 20 ans (au pif, hein) avant fl0w, voici déjà un premier exemple de jeu qui adapte sa difficulté au niveau du joueur, puisqu'il y en aura davantage pour celui qui fonce tête baissée que pour celui qui avance modérément...

samedi, novembre 22, 2014

Les tiles ... du C64 à la NDS

Chose plutôt inhabituelle, après pas loin d'un an de bidouille, mon premier article sur le site de la BilouCorp est finalement en ligne. J'avais envie d'y faire une rétrospective sur ce qui a fait de certaines machines des plate-formes assez merveilleuses pour la programmation de jeux vidéos et de jeter un coup d'oeil à la façon dont leur caractéristiques techniques ont formatté les jeux qui ont tourné dessus. Le premier jet, c'est donc sur les les tiles, ces petits pavés graphiques qui m'ont accueilli sur le C64 dans "Space Mission" et que je reprogramme dans SEDS pour vous faire les jeux de Bilou. Bonne lecture.

Some of us read and listen to English fairly fluently. For those, watching a video like the making of ROM city rampage gives a nice overview of what happens inside an 8-bit, tiled game. Mechanism within 16-bit and even 32-bit tiled games are essentially the same, with variations on the limits. For those who don't, I took the time to write down a cover of essential mechanisms like palettes, MAP area and the like and have it hosted at BilouCorp website.

mardi, novembre 18, 2014

Economiser des pixels

Imaginons un instant que je tente de faire l'animation du crayon-soldat qui court derrière Bilou juste en pixel art ... Il me faudrait avant tout gagner assez de place sur mes planches de sprites. Heureusement, les "1002/1024 tiles used" sont un peu surfaits. Si je visualise le contenu de la VRAM, les sprites colorés en rouge sont ceux dont je n'ai en fait aucun besoin. Ceux en vert sont ceux qui pourraient bénéficier du système d'animation par copie qui est à la base de l'encre-qui-monte.

This is the current content of the 64K of sprite sheet in the School Rush game. Sprites in red are unused and could be dismissed. Sprites in green are those who could benefit from the streaming technique (updating VRAM content as the frames advance. Given that I used only 6 16x16 blocks for the pendat so far, I could have the room for a pixel art running pendat, after all ...

mercredi, novembre 12, 2014

L'histoire de Rayman

*deline, très fière, vous présente le nouveau livre de Rayman.
Très chouette ouvrage de Michaël Guarné que nous offrent là les éditions Pix'n'Love. Plus aéré et aussi plus détaché que l'histoire de Mario mais quand heureusement plus consistant que le trop graphique "histoire de Sonic", je ne regrette pas ma pré-commande. Bien sûr pour celui qui avait déjà la bio de Michel Ancel et le mook contenant le dossier Rayman, il y aura des redites, mais l'intervention de nouveaux collaborateurs -- chose rendue possible puisqu'on s'intéresse ici à une série, donc avec les anciens épisodes vus sous différents angles.

Mais il y a tout de même quelques belles perles pour l'amateur de game design que je suis, à commencer par une double page dédiée à la "bible du game design", ce cahier graphique de Michel Ancel rédigé dans l'idée de faire passer son jeu au mieux auprès des frères à la tête de Ubisoft. Ça me rappelle très fort le genre de documents que mon frangin plaquait sur ma table à dessin entre '93 et '94, avant qu'on ne mette la main sur notre game-maker.

http://critical-gaming.com/blog/2010/12/31/about-that-indie-feel-pt2.html
"Mario Can't Grab" (Kirby Kid)
J'ai halluciné en découvrant le nombre de 15,000 caractères de code pour le comportement de Rayman dans Rayman Origins. S'il y a une bonne dose de mouvements dans ce jeu, on est quand-même pas dans un jeu d'échec non plus... Puis je suis retombé sur une petite image de Kirby Kid à propos de Super Mario Bros. Ici, pas de roulé-boulé ni de wall-kick, mais on retrouve déjà la petite différence entre un jeu qui a été discuté entre testeurs et joueurs ou un jeu fait "en aveugle": si un petit coup d'anti-gravité permet de continuer un mouvement plus à même d'aider le joueur, alors on donne cette anti-gravité.