Showing posts sorted by relevance for query biloucorp. Sort by date Show all posts
Showing posts sorted by relevance for query biloucorp. Sort by date Show all posts

Monday, August 22, 2011

Funky work at BilouCorp !


Il semblerait que dans un univers parallèle du Web, Bouli est directeur des recherches à la BilouCorp! Le rôle de Funky Funghi dans tout ça reste quelque peu mystérieux.

Bref, au moment où je trouvais que dev-fr, c'était un peu mort pour la DS, Nuki me relance... Une autre génération où le "game-making" s'est spécialisé au point qu'il y a maintenant des RPG makers ... sisi.

This month, I have been contacted by funny people naming themselves "Bilou Corp" and having a special team named "Funky Work". The similarity with Bilou and Funky Funghi amuses me.

Saturday, November 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.

Saturday, November 20, 2021

Smashing pixels

I did a few tries to render the heavy punch smashers for the pyramid in SEDS, and most of them were deceiving. My best render So far was crafted with the Gimp using the style and palette of an inspiring Sonie-like indie game dubbed "Kyle and Lucy".
Since I had a day off yesterday, I brought them back on top of my Pyramid level mockup. After all, the pixels for the Smashers were all mine. They just needed to be moved out that Kyle-and-lucy environment.

I also took the opportunity to try another approach: some structures in the School Zone are made of wooden, gianthands. What if I turn then upside down? Can I get something Convincing by Shading them with blues and pretend they're now metallic?
 

Bon, ceux-ci ne sont pas les premiers gros-poing-écrabouilleurs que je tente, mais les précédents ne ce sont pas vraiment révélés concluant (#euphémisme. Voir ci-dessous). Mais là, je retombais sur un screenshot de Kyle & Lucy sur lequel j'avais profité de la palette pour redessiner un gros poing d'un autre genre alors que j'avais toujours mon mockup "desertcolor.xcf" ouvert. J'ai fait un test. 

Et tant qu'à faire, j'ai essayé un autre truc que j'avais en tête: retourner le poing-pillier de la SchoolZone et lui donner une teinte blue-métallique, histoire que ça ne fasse pas trop bois. Les avis sur twitter sont assez unanimes: c'est le gros poing du bas qui gagne. Par contre, un truc de cette taille en métal, ça ne fait pas fort égyptien. L'histoire a beau ne pas se dérouler sur Terre, je prends note: je m'en tiendrai à un gros-poing en pierre.

I haven't been running any twitter poll this time, but I still managed to gather interesting comments. Generally, the bottom puncher are perceived superior to the recycled school-zone structures flipped and recolorized. Of course, I should have X-flipped them for coherent lightning with the rest of the scene.
Among others, Joke@bilouCorp pointed out that Egyptians did not have the technology to produce large metallic structures. That's both quite irrelevant (since Bilou's pyramid is nowhere near the Nile and not even on our planet) and super-important, because I want people to feel like if they were in an Egyptian pyramid while at the same time feel like it is something else. If I come up with hammers looking like they're from the Misty Mountains or from Vinea, they won't "buy" it. Similarly, although I won't use the Egyptian hieroglyphs, I'll use glyph-like writings anyway and not neon ads.

Et je ne résiste pas à l'envie d'en profiter pour vous présenter le projet Kyle & Lucy de Cellar Chateau. Un jeu bien dans la veine de Sonic 2, avec ses sols qui font des crolles, ses boucles et ses tremplins. Je trouve très bien trouvé l'introduction des rollers aux pieds des héros félins (déclenchés dès que la vitesse est suffisante), ce qui permet de garder une animation lisible tout en ayant une vitesse de déplacement digne de Sonic.
On est ici dans une "zone de la musique" qui n'a pas à rougir devant celle de Rayman ou de Zool. Chapeau. Il faut dire que le talentueux Lapper (qui nous présente les avancées de son projet "Sonic Studio" sur sa chaîne Youtube) prête main forte au niveau du graphisme.

Maybe you had never heard of Kyle and Lucy before. It's another game project I'm following on twitter, with Sonic-inspired gameplay and surrealistic aesthetics. The music zone is clearly one of my favourite. Everything looks so readable there. Note how the designer has given Kyle retractable rollerblades so he could zoom through the level without having to move his legs at ludicrous speed!


Saturday, November 16, 2013

Fine-tuning.

    Raw as raw can be: here's a collection of "todo items" related to the "20 years anniversary level" that has staid draft since my first re-contact with the BilouCorp. It's not very sexy, but at some point, gameplay fixing is also those kind of fine-tuning.
  • [done] BIGFALL Camera: a maximum vertical speed of 7 for the camera is a minimum as Bilou's maximum vertical speed is near 6 (pixels/frame). It feels better when the camera is controlled by the DPAD (holding down when falling) rather than activated automatically when reaching a specific velocity. With those settings, the player has 0.5 second between the time pencils appear at the bottom of the jump-of-(fai|dea)th and contact with the ground. half that time is required to manoeuvre Bilou away by 16 pixels, that leaves ~0.25 seconds of reaction time to the player.
  • [done] Spongebops appearing on the bottom of the screen due to wrapping of the Y coordinate by the DS hardware (?) mislead the player into believing that there's an invisible sponge that will reveal if they jump into endless pits.
  • [wish, AskTheTeam] Bonus room with a "hidden exit" should better be replaced with a room that offers a limited time to collect all the items and brings you back to the level when completed (as in DKC). Until the engine can support that, make sure the room's exit is as close as possible from its entry, so that realizing that you can't come back through the path you picked doesn't prevent you from going further with the game.
  • [done] Chalk do break, much more easily than pencils. Use some chalk picture for the break-through platform on the desktop.
  • [done] Add an 'onscreen' controller that triggers an event when an object gets offscreen, so that 'stunned' animations can be completed and items no longer "magically disappear".
  • [done] with a horizontal top speed of 540, running becomes enough to clear the pencil-pit area: no more bouncing-on-bumpers or grabbing-sponges is necessary. with momentum limited at 480, it is still feasible to clear the pencils, but it requires to jump when Bilou's first feet is already out of the safety area, so the bumber is "safier", and it could be made more in the middle of the platform as initially designed, so you don't necessarily fall into the pencils if you miss it.

Croyez-le ou non, mais j'ai réussi à recontacter la "Bilou Corp", et j'ai donc une toute nouvelle toudoulisse pour le niveau-anniversaire. C'est un peu brut, vous m'excuserez peut-être un jour. Plein de petits règlages à faire: les vitesses de caméra quand on tombe, le remplacement du crayon-qui-casse par une craie-qui-casse, etc.

Sunday, November 10, 2013

L'avis de Joke

Longue session de beta-testing hier avec Joke de la BilouCorp -- une corporation sans lien direct avec mon personnage fétiche mais néanmoins fort sympathique et versé dans la conception de jeu vidéo -- si bien que ce matin, je passais le démarrage du niveau en mode "image par image" pour comprendre d'où venait ces "à-coups" quasi systématique quand on descend de la latte pour aller se mesurer à notre premier crayon.

  • il sautille un peu sur la descente de la règle au début
  •  … la caméra ça va je trouve
  •  ça manque d'effet sonore pour les sauts et rebonds 
  • le premier saut qu'on doit faire d'un crayon à l'autre avant le pot d'encre, je remarque qu'on peut pas y arriver si on ne se tourne pas d'abord dans la bonne direction
  • La gomme du crayon c'est volontaire la possibilité de passer derrière ? le fait qu'on soit propulsé en sautant quand on est dessus n'a pas l'air de nous aider à passer. il faut prendre de l'élan je pense, ça complique les choses
 Il y a deux ans, j'aurais plus ou moins considéré ça comme du temps perdu: ce sautillement ne gène en rien le gameplay... mais ça fait tache et en plus, c'est la première chose que le joueur va voir du jeu. Donc, je creuse à grands coups de ddd avec la méthode désormais bien rôdée de "je m'arrête avec Inspector Widget dans la situation qui m'intéresse avant de mettre mes breakpoints".
Après une bonne heure d'inspection méticuleuse, j'arrive à la conclusion que le code du moteur de jeu, des contrôleurs etc. est 100% clean: c'est dans l'animation que ça coince. Pour une raison encore inconnue, une des étapes d'animation force le déplacement à être horizontal plutôt que de s'adapter à la pente en cours ... bizarre, bizarre.

Je ressors donc mon "extracteur d'animation en vrac (à perforation en vrille): il y a en effet quelque-chose de louche avec les animations de marche de Bilou. Les étapes d'animations qui se comportent bizarrement ont un bit "déplacement vertical autorisé" qui reste à zéro. Chose intéressante: le pendat (qui était incapable de suivre les pentes) a systématiquement ce bit à zéro. Dumblador, lui a son bit "déplacement vertical autorisé" mis pour chaque étape.

J'aurais été bien incapable de dire en aveugle à ma fée quelle manipulation elle aurait du faire pour changer ce règlage dans AnimEDS, ce qui signifie que c'est un des contrôles-candidats pour un menu déroulant ou quelque-chose de ce genre.
En fait, c'est le petit "!" devant "y" qui doit être retiré pour "déverouiller" l'animation verticalement.

Mais alors ? Si ce sont des règlages au niveau de l'animation (et pas d'une étape isolée), pourquoi cet étrange étape verouillée dans la marche de Bilou qui ne l'est pas pour le reste ? Sans doute parce qu'il s'agit de la liste de commandes générée pour permettre de boucler la boucle, et que son code n'a probablement pas eu droit à sa mise à jour (ouuuuh ^^").

J'édite l'animation en hexadécimal dans Midnight Commander ... Je recompile à cloche pied ... Bilou retient son souffle: c'est l'heure du test fatidique ... attente insupportable de 15 seconde pendant que la caméra re-traverse le niveau à contre sens pour venir se centrer sur Bilou au départ.

Ah oui! Bien mieux! La descente est fluide, la remontée aussi... Il me reste à aller corriger AnimEDS, donc.