1
I Use This!
Inactive

News

Analyzed 8 days ago. based on code collected 13 days ago.
Posted almost 11 years ago by [email protected] (Sylvain Pypebros)
J'ai une démo du jeu "Bilou : Rush to Completion" sur deux niveaux. L'envie de vous faire une release et d'avoir enfin des avis plus diversifiés sur le fonctionnement me brûle les doigts, mais je dois patienter encore un peu. Il y a dans le jeu un ... [More] mode "tutoriel" ou "*deline" dans lequel on peut prendre tout son temps pour explorer les actions possibles parce que l'encre ne monte pas. L'ennui, c'est qu'actuellement, ce mode est activé par défaut et qu'il faudra compléter une ou deux fois les niveaux avant qu'un véritable challenge se présente pour les joueurs plus aguerris. Je dois donc ajuster un rien mon écran d'accueil pour qu'il permette de prendre le mode "*deline" seulement volontairement.I'd love to release my "rush to completion" demo now, but I must not rush it. Right now, it would start too easy on every game, forcing you to go through repeated 3 minutes of "tutorial-difficulty". I don't want to ruin the experience that way. [Less]
Posted almost 11 years ago by [email protected] (Sylvain Pypebros)
oh well, it might turn into level 3 ...At last, I have a second level matching the "rush game" design that accidentally arose from the "non-tutorial" level 1 crafted last december. This one won't be 4-years-old-friendly, I'm afraid, but there are ... [More] still plenty of safety nets and alternate faster path for trained daddies. This is somehow giving it some Sonic flavour more than Mario spirit, but without making it roller-coaster looking where you can't figure out how you could perform better. Here, the closer you are from the bottom of the screen, the slower you'll progress (and the more likely you're to be in trouble when the ink will rise faster).Et voilà enfin un second niveau pour le jeu de course contre la montre l'encre avec Bilou proposé par Piek suite à la disposition du niveau de prise en main construit en décembre dernier. Il plaît moins à ma grande de 4 ans, qui le trouve déjà trop effrayant malgré les "sécurités" rajoutées ici et là. Sécurités qui ne sont efficace pour la plupart que si l'encre reste gentiment à son niveau le plus bas, et qui sont disponible uniquement un bref instant pour une montée lente de l'encre. Bien sûr j'ai gardé des passage plus corsés dans le haut du niveau pour les papas pressés (et pour échapper à l'encre une fois qu'elle monte d'avantage). On retrouve un côté "Sonic" avec des chemins plus rapides mais plus techniques et d'autres plus lents mais plus accessibles ... sauf qu'ici on a en plus la convention "en haut = rapide, en bas = sûr (s'il n'y a pas d'encre)".I still have technical issues, though. A couple of curious movements may still make you stuck into walls, despite the basics of my game engine are to avoid such situations.I'm also very close to the maximum number of "OAMs" the console can handle. If you stun all the bladors in the level and drop them in places where they cannot recover, the barrier of 128 OAMs will explode and things will start to disappear. The solution is simple and has been post-poned for a while: manage dynamically the monsters of the level, freeze some that are off-screen for too long and start using those that are getting in-range. This is video game programming 101 since the start of scrolling games (only 10 live monsters in a game of Super Mario World while you may have 10 times more monsters on the map) but the superior processing power of the DS allowed me to be "lazy" up to now.I'd still probably be nowhere if I hadn't quick-injected a screen copy/paste feature in LEDS. Level 3 will definitely be easier to make if I take time to ensure attaching GOBs in LEDS never break the level script (e.g. by making the attachment instruction always appearing after the two involved GOBs are created :P) [Less]
Posted almost 11 years ago by [email protected] (Sylvain Pypebros)
Oui, voici *encore* Bilou coincé dans un mur. A mon avis, une sombre combinaison d'une animation de transition qui tente de suivre le mouvement avec le passage vers un état qui n'est pas sensé utiliser ce type de suivi. Dans ces conditions, difficile ... [More] de se rendre compte de l'évolution de la difficulté du niveau au fur et à mesure que la vitesse de montée de l'encre augmente O_o.Ce qui est curieux, c'est que selon le "contrat" entre personnages et contrôleurs, il ne devrait jamais y avoir un "déficit de mouvement" tel qu'il puisse m'envoyer dans un mur ...Bilou atterit, il a toujours une vitesse horizontale et l'animation tombe/marche est activée;le DPAD est relâché mais avec son inertie, Bilou va continuer à accumuler des déplacements-en-retard;au moment où il passe de "marche" à "arrêt", Bilou fait un pas quantique vers l'intérieur du mur;une fois bloqué dans le mur, Bilou y reste.Si je retire l'animation de transition, le problème disparaît.  [Less]
Posted almost 11 years ago by [email protected] (Sylvain Pypebros)
Des corrections tous azimuts et nous y voilà: l'encre monte. C'est encore assez imparfait comme vous pouvez le voir: les vagues créées à la volées ne sont pas ajustées les unes contre les autres. J'ai aussi un retard dans l'évaluation de la position ... [More] de la caméra qui provoque un traît vide quand on fait monter l'écran, mais ça, ça devrait être trivial à corriger. Bref "rush to completion" commence à prendre forme. Dommage qu'il n'y ait apparemment pas de NéoCompo cette année >_< Fixes here, and there, and here we go: the ink moves up, stops at a desired height in the level, and looks "solid". It's not quite perfect as you can see: there are "seams" between wave sprites. There's also a glitch when tracking vertical movement, but at least "Rush to Completion" is taking shape. Too bad there won't be a Neoflash competition this year ToTedit: au final, j'ai remplacé le "chenillard de vagues" par un système où les même vagues sont utilisées d'un bout à l'autre du niveau, mais partent s'afficher à l'autre bout une fois qu'elles atteignent la fin de l'écran d'un côté. Plus simple, plus fiable (les vagues restent toujours à une position multiple de leur taille), plus facile à mettre au point (grâce à une extension d'Inspector Widget pour passer en revue la liste des GOBs) ... cette fois, ça marche. Je me serais quand même épargné un beau mal de crâne si mon moteur de jeu avait pu m'indiquer à l'avance les zones de collisions inopérantes parce que trop larges ou les vitesses excessives lorsque les deux objets impliqués dans un "CopyCoordsController" sont trop loins l'un de l'autre. [Less]
Posted almost 11 years ago by [email protected] (Sylvain Pypebros)
Un peu mieux avec les deux morceaux de l'encre, hein ;) couvrir presque l'entièreté de l'écran n'est pas mal non plus. J'ai encore une drôle d'asymétrie provenant du fait que c'est le bord gauche des vagues qui s'aligne avec les "masters" (les bords ... [More] du 'serpent d'encre'). Mais là, c'est *repos*.I simply used AnimEDS to craft a sprite with both ends of the wave, and it already looks better. Fixing the CopyCameraCoords code so that the whole screen can be covered also improves the look, for sure. I still have an issue with the left border that creates much more dense waves due to an alignment asymetry at spawning, but that will be sorted out later. [Less]
Posted almost 11 years ago by [email protected] (Sylvain Pypebros)
The ink swamp wormNow *this* is looking better. It tooks two "masters" (one to the left, the other to the right) to ensure that I have a chain of wavelets GOB looking still, and looking to occupy the whole level. I will definitely need a wider GOB ... [More] for the wavelet so that the spawn rate is enough to cover the screen even when the camera accelerates, and I'll need to investigate the camera offsets (currently, some values curiously refuse to work). But at least I get spawning and termination of wavelets as expected.Hmm. J'aime mieux ça ^_^ Un "maître" de chaque côté, qui s'assure qu'il n'y ait plus de vagues à une extrémité et qui en génère une nouvelle s'il n'y en a pas au-dessus de lui. Il me restera des règlages avant que ça n'ait une belle tête de mer d'encre, mais on s'approche de l'objectif.Il faudra aussi que je trouve un moyen d'arrêter la montée implacable de cette encre, au fait ^^" [Less]
Posted almost 11 years ago by [email protected] (Sylvain Pypebros)
La première implémentation de l'encre qui monte n'est pas franchement un succès. J'avais oublié que les zones sensibles d'un GOB (hitbox) ne peuvent pas se trouver en-dehors de son rectangle vital (bounding box). J'avais aussi oublié qu'un nouvel ... [More] objet généré par un GOB apparaît systématiquement à l'emplacement de son "père". Les alignements de coordonnées partiels et impliquant la caméra, par contre, donnent pleinement satisfaction.Pour ce qui est de l'affichage de la "grosse zone noire" par-dessous les vagues (l'encre proprement dite), j'ai décidé de laisser ça sous la responsabilité du code spécifique au jeu qui gère aussi l'affichage du score [Less]
Posted almost 11 years ago by [email protected] (Sylvain Pypebros)
J'avais eu l'occasion de télécharger Sonic 2 pour Androïd, temporairement gratuit, sur la recommandation de mon frère. Une valeur sûre, de 1992. Emerald Hill et ses ponts spiralés ... La Chemical Zone et ses blocs lambinants qu'il faut escalader ... [More] après avoir dévalé des pipe-line de liquide bleu-louche.J'essaierais bien d'aller jusqu'à la Mystic Cave voire Oil Ocean, mais pour tout dire, les contrôles sur tablettes sont une catastrophe! Le bouton de saut ne réagit pas systématiquement, ce qui est un comble pour un jeu de plate-forme où les réflexes sont si importants. Ça fonctionne un peu mieux quand on appuie vers la mi-hauteur, mais ça veut dire que presque tout ce qui se trouve devant Sonic devient masqué par ma main >_<What good is a free copy of Sonic 2 if you can't play it ? And how could play a reflex-based platformer when your hands are hiding half of the play screen ? How could you have proper timing when you can't have your hero reliably jumping on "button" press ? And if trying to move backwards may be ignored because you suddenly move out of the active detection region ? [Less]
Posted almost 11 years ago by [email protected] (Sylvain Pypebros)
Scribbled notes on how to extend runme tool with a way to import plug-ins (or Dynamically-Loadable Object Directories -- DLODs) that would contain a set of controller, guns and effects required for a given game. So far, changing some of Bilou's ... [More] behaviour require that you recompile controllers.cxx, which in turns mean that you also need to re-compile runme if you want it to work with your new code. I'd like instead that the map file indicating where the support code entry points are so that we can have DLODs that are statically-linked to work with one instance of runme, and loaded at a specific location in the DS's 4MB of RAM.That's on my secret todo-list for about 7 years, but that won't be for this summer.In a similar approach, I'd like a gobscript-to-c++ compiler that would replace run-time parsing of the script with build-time generation of a series of constructor/setters or static data.Dinner Time. See ya. [Less]
Posted almost 11 years ago by [email protected] (Sylvain Pypebros)
I know that C++ has pitfalls and numerous weapons for you to shoot at your own feet, and the behaviour of iterator has already puzzled me a couple of time, but I wasn't expecting *this*. I wasn't expecting the position returned by a single there = ... [More] list.rbegin() to be different depending on when you de-reference it. Like, pushing 3 items, invoking there = list.rbegin(), pushing 3 more items and figuring that *there now let me access the 6th item 0_o. I had to check the source code of stl_list.h to understand how reverse_iterator is just a façade calling operators of a companion bidirectional-iterator as expected to be appropriate, and how the 'end' of a list is materialized by a 'guard' node hosted by the list itself (an academic workaround), meaning that when you ask for rbegin(), you're actually positioned exactly on the same node as with begin(), but now operator* finds it smart to move one position backward just before returning the target.Eh bien, on dirait que le C++ me réserve encore quelques surprises. Il m'avait semblé judicieux de réécrire une partie de la gestion des monstres de LEDS en utilisant une std::list et des itérateurs, mais je me suis rendu compte hier que du coup, éditer un niveau détruisait systématiquement toutes les informations sur les monstres. Un effet qui est resté caché lors des tests en émulateur, vu que desmume ne modifie jamais de façon durable les fichiers. Je vais donc laisser tomber le "rbegin" ('donne moi le premier élément de la liste lue à l'envers') au profit d'un --list.end() ('donne moi l'élément juste avant y-en-a-plus') parce que ce dernier, au moins, est évalué au moment où on le demande et pas à la volée au moment où l'on s'en sert.Je sens de plus en plus le besoin de tests systématiques de mon code, mais en environnement émulé, j'ai du mal à percevoir comment les mettre en place. [Less]