Saturday, November 18, 2017

power-button bug

On the game design axis, I am quite satisfied with the final level of school Rush and how it integrates with the earlier levels. It took A. (from the S-Team) Some 30 attempts to beat it, but she didn't turned mad or bored, and even enjoyed being wrapped to level 1 afterwards.

On the technical side, my latest personal tests hit me with a bug I thought I fixed long time ago: getting stuck in a ceiling, There are few places where this can happen in the game, but if it happens, you will remain stuck, possibly forever unless you use the power button to trash all your progress and reboot. Would a player feel like starting the game again in such conditions? I don't think so.
 
The thing is, the basis pretty hard to track, a bit tedious to reproduce and all my attempts to fix it have failed ... so far.

What I truly need is a tool that will allow me to identify the sequence of state transitions that led to the offending state when I finally manage to reproduce it. Another debugging tool that would complement Inspector widget for cases that cannot be solved by single-stepping on setting breakpoints.

edit: let's stop rambling, let's start cracking ...

Bug is tedious to reproduce

Then let's make it easier to reproduce. Let's have e.g. a build of the game with much more lives, more hitpoints if needed, that drop you in a place where it is easy to try reproducing the bug. Let's go to that level with the DS, too, and try to get into the wall in as many ways as possible (runMe is neat for that because it let me launch any level), to get a better understanding of the conditions that make it happen.

Moreover, we're running on an emulator, here. And emulator typically have a free save-state mechanism. I'm unsure whether it works flawlessly with desmume, but it's worth giving it a try.


Bug is hard to track

Then let's make our best to get as much information as we can from a succesful run.

Granted, the ideal would be to have a curve plotted, annotated with state changes, in readable colors and where I could get any set of gob variable at any time by just pointing at a spot on the curve. But we don't have that. Granted, last time I had to use both ddd breakpoints and Inspector widget, but that doesn't mean I cannot do better this time.

So the ideal would be a time machine that let me replay things if I ever manage to produce the bug, and view what happened in slow motion, eh ? Wait ... that tool exists already. That tool is ... recording game + Inspector widget as an animation and replaying it!


Bug couldn't be fixed so far.

I thought I knew what happened by looking at the code that makes Verso bounce, because I know I had to fix the problem for Verso (the bouncing eraser). And the solution was to detect the impact's vertical speed to tell ceilings apart from floors, and prevent the 'fail [assuming on the ground]' from happening when what really happened was 'fail [on the ceiling]'.

So after I located something similar with the "HIT" state of Bilou, I thought I got rid of the problem. But since I don't have well-isolated test cases for the state machine (yet), seeing the bug again doesn't mean that the fix wasn't effective: simply that it might not be an isolated case.

To be continued ...

Friday, November 17, 2017

most vexing (gobscript) parse


My scripting language is far from perfect, but this one is really the most vexing issue I have encountered so far. I mean, it is hard to debug, counter-intuitive, and it feels more like a question block turned into a thWomp and smashed you. It gave no clue, no warning, you did nothing wrong, but still get smashed.

The core of the issue lies in how collisions are handled:

  • There is always an active "collider" and a passive "collided" object. 
  • collider area is allowed to expand to any size (within int size limits). 
  • collided area will only be checked if the object's boundary box intersected with the active area.

The third constraint comes from performances considerations. But unfortunately, it means if you create a passive area larger than the object's own size, nothing will complain, you will see boxes intersecting, bar no collision will ever occur.

I'll need to take some time to add warnings

Tuesday, November 14, 2017

Qui est volontaire ?

Je voudrais pouvoir faire une série "tutorielle" pour introduire progressivement les concepts de mon moteur de jeu et fournir une base de travail à d'éventuels game-makers amateurs qui voudraient s'essayer sur DS. Je voudrais aussi qu'ils puissent avoir quelques graphismes de référence, y compris les personnages.

ç'aurait pu être la bestiole de Pipemare (RSD), mais j'ai du mal à me l'approprier. ça ne peut pas être Jack Boost, Badman, Spector, parce qu'ils ne m'appartiennent pas en tant que personnage. Je n'ai pas envie que ce soit Bouli ou Biokid parce que j'y suis trop attaché, alors qui ?

For ten years now, I've been developing a game engine for the Nintendo DS. It isn't perfect but it already allows to do interesting things. And while most of the homebrew we've seen in the golden era of NDS development were using static screen, with GEDS, we have the full power of large maps and parallax scrolling.

Yet so far, I have failed to offer a workable starter kit for the libgeds and dsgametools. Apple Assault source code is mostly obsolete. Discovery packs for LEDS and AnimEDS weren't really helping to kick into game development. And my tilesets are too complicated for a 8-years-old to start sketching levels.

I'd like to take some time to craft something better. A small tileset inspired by Kenneth Fejer mockups. A generic-enough-but-yet-inspiring character that could be sent onto a Commander Keen / Nicky Boom-like adventure.


J'ai envisagé de commencer par un exemple basé sur Out'm'Up, SeaFox ou Crazy Brix, mais aucun n'est vraiment pratique pour montrer ce dont le moteur GEDS est capable (scrolling multi-niveaux, animation modulaire, etc). Non, il me faut une aventure à la Nicky Boom ou Commander Keen.

Reste les personnages secondaires que j'ai développés. Nono le gamin malchanceux (une version anonymisée de Badman, en sorte), Mo le sorcier maladroit, Mol la taupe punk ou Mike Boost, le talentueux mais ténébreux. Ou alors affubler spector d'une tête de souris ?

Rien de complètement convaincant. Reste la possibilité de faire des pixels sur mesure. Voici donc "power kid", qui a l'avantage d'être un perso rigolo.

Of course, given the amount of games I have contributed to together with other PPP Team members, it may sound weird that I'm on a quest for a character to drop to the public domain. The thing is, most of them were designed by other members (Badman, Jack Boost, Biokid) or collectively... or were pastiche of copyrighted characters (Calimero, Xeen, Frogger). My best candidate would be the punk mole I inserted in Badman II and who was playable in my brother's "4 to save Toon Land", althoug -- as you can see from the sketches -- it is definitely not the only option.

Wednesday, November 01, 2017

Rendez-vous avec la S-Team

Ah. Enfin l'occasion de faire tester mon niveau vertical à la S-Team au grand complet! Et de plus entouré de p'tits n'veux de 8-10 ans qui ont fini par venir s'agglutiner autour de L (la benjamine) tandis qu'elle s'entrainait à aller le plus haut possible dans le niveau final. Les ainés auront eu du mérite puisqu'ils se sont accrochés pour aller jusqu'à la dernière section (rouge) malgré un kolossal bug qui permettait aux pendats de laminer Bilou en un seul contact, faisant fi de ses 5 points de vie ...

A défaut de la photo de famille, donc, un petit aperçu des différentes sections du niveau en question. Mon frangin, hier, avait réussi à frôler le dernier écran et approuvé la difficulté avec la mention "vache, mais pas trop". (il avait atteint le haut de la zone jaune et je l'y ai ré-emmené pour qu'il voit la fin)

Un playtesting bien utile puisqu'il m'a permis d'identifier quelques coins piégeux de la map: images qui font penser qu'il y a une plate-forme alors qu'il n'y a rien, voie à suivre peu claire qui a conduit A (la cadette) à se lancer dans l'encre à plus d'une reprise, trop confiante de la distance que Bilou pourrait parcourir en un saut sans se douter que le bon chemin était en réalité derrière elle. Après 3 ou 4 essais, elle parvient au passage critique "des gommes" (zone jaune) où il faut enchaîner les rebonds avec très peu de "filet". Heureusement, en général, à ce stade-là, on a pris suffisamment d'avance sur l'encre pour pouvoir réessayer quelques fois. Et à mon grand soulagement, elle a passé ça en une seule vie. Ni elle ni L n'aura eu de difficulté avec le duo d'éponges de la section orange (re-ouf).

I got the opportunity to have the final level of School Rush heavily play-tested (at last) and got many small things (and other-not-so-small) fixed. It is always a pleasure to see kids and teenagers challenging each other on my game. I'm impressed they kept doing their best despite I had an awful bug that allowed pendats to one-shot the player almost everytime. Nonetheless, the best trained of the testers managed to climb almost to 3/4th of the final level, beating the "bouncing erasers climbing" part at her first attempt.

Thanks to those playtest, I had fixed some phantom platforms here and there, ensured idle inkjets (those that don't shoot by default, as on the title screen) always notice you when you jump into them, allowed to swim-up to escape the ink even when you don't end up in the final depth of the ink, got the "torchlight feature" rendering correctly ... And before you ask, yes, I took the week off ;-)


Même N. s'y sera réessayé, alors qu'il avait plutôt snobbé Bilou au profit de ses jeux sur smartphone ces dernières années (bah, il a genre 17 ans, l'ainé, maintenant). Un cycle de 3 vies lui aura été nécessaire pour reprendre un peu le jeu en main, mais après ça, il atteignait sans problème la zone verte avec 2 power-up mais n'aura pas poussé jusqu'au jaune, L. insistant pour faire un nouvel essai.

Par contre,

Monday, October 30, 2017

.fr ?

Bon, je ne vais pas y aller par quatre chemins: animer ce blog en bilingue devient trop lourd pour moi. Entre le boulot qui me tient beaucoup plus devant un écran, les trajets en tous ssens pour les activités extra-scolaires des loustics, et -- avouons-le -- un laptop moins convaincant dont l'écran n'a jamais la taille qu'il faudrait, je peine déjà à rédiger ce qui me passe en tête quand je gribouille une page de notes sur ma tablette-liseuse-scanneuse.

Alors le faire en deux langues, ça devient vraiment infernal. C'est aussi au détriment du projet lui-même. En théorie, la France arrive toujours en n°2 dans les statistiques. Ai-je encore des lecteurs francophones ? (ai-je encore des lecteurs tout court ?)

N'hésitez pas à vous faire entendre: le sondage "English /Français" court toujours.

Panic! GameInfo reading out of buffer!

Pretty weird error message. I don't know what triggers that. It doesn't interrupt the emulated program but kills the emulator itself, even when we're running in gdb-debugging mode. It happens while parsing some line of text in my "wave.cmd" script unless I invoke GobAnim::setWindowed() on an animation earlier on. The object parsed when the crash occurs has no relationship with the GobAnim that gets windowing-enabled.
  • Panic! GameInfo reading 302251 out of ROM (302254)
  • halting emu: ARM9 PC=020406A0/02000F0B, LR=0204069C 
  • ARM9 halted 
  • halting emu: ARM7 PC=037F9B84/037F9B7C 
  • ARM7 halte
The crashing address happens to be within memcpy.

  break *0x20406a0 if $r3 + $r0 > 0x300000 && $r0 < 0xb000000

could be working, except that GameInfo doesn't start at offset 0, but apparently rather at offset 0x08000000.

A bit more digging (setting the right breakpoint, using one more desmume patch to reveal registers R0 through R3) finally allowed me to get a stack trace....
And the offending memcpy was part of a buffer refill for waves.cmd file. For some reason, by incrementing the size, I hit a threshold where one more copy is needed, but then the very last bytes can't be read because the emulator believe they should always pick a 4 bytes from the current position (instead of an aligned 32-bit word holding the byte). Simply adding a zz.zz file that will come past the waves.cmd file make the code work again.


Tuesday, October 24, 2017

Finishing steps for School Rush

  • [true] ensure the music track for the last level is different
  • bring in the amazing books as the background for the final level
  • make a funny "true ending" sequence
  • [done] draw something for the missing loading screen(s?)
  • [done] inkjets start aggressive in hard mode
  • [wish?] page-swap bonuses as player progress into the levels to m4ke him b3liv3 th3 m4th 4r3 t4king 0v3r th3 w0r1d (originally mentioned here)
  • [done] resume the normal level order/spawn points.
And I still don't have vertical movement for floating spongebop.

Yup. No code tonight. Just took some time to crawl through the old "todo" posts and collect a list of things that are still pending. As I can allow less and less time at once on my hobby project these days, I need to organize myself more ...

To be honest, I'm starting to be attracted more and more by things that aren't related to School Rush and less and less by finishing School Rush itself. Possibly because we're approaching a big release at work ... possibly because the Internet seems not to care a lot about the idea of rushing School Rush.

I wanted to temporarily disable the "window" feature on the torch-light GOB (just to check it has the shape it should), but when I do so, I get a cryptic "Panic! GameInfo reading out of buffer!" message from desmume... I'll have to investigate that.

edit:
  • [done] With the window disabled, it looks like the OAM flipping isn't working for my torchlight-sprite. I'll have to understand why
  • [done] While hacking the get-ready-to-swim fix, it looks like I broke a rule in the Bilou-got-hurt rules, allowing pendats (which are both hurting and solid) to combo-kill you
.