Les plate-formes

Le prochain "gros challenge" pour mon moteur de jeu (sur lequel je cogite actuellement, en tout cas), c'est sans hésitation les plate-formes. Tous ces objets mobiles, assenceurs, radeaux, etc. qui tout en ayant leur comportement propre altèrent celui du personnage ou agissent comme des parois solides. Bref tout une série d'objets qui vont venir perturber les belles règles de gestion des collisions du moteur de jeu.

J'en suis encore fort au stade "conceptuel", qui est franchement sympa dans ma manière de travailler, puisqu'il s'agit de "mises en situations" à coup de crayon pour voir si la solution que j'ébauche tient suffisamment compte des différents aspects. Du style "non, on ne peut pas lier définitivement un contrôleur à une plate-forme, parce qu'il pourrait y avoir aussi des petits vers sur les champignon-ascenseurs".

Après deux ou trois tentatives peu convaincantes, j'en arrive à la conclusion que mon système "un contrôleur par état" est un peu limitatif. De la même manière que j'essaie de faire de la composition de micro-programme dans mes recherches sur les protocoles réseaux, pourquoi ne pas faire de la composition de contrôleurs dans le moteur de jeu ?

Encore trop tôt pour commencer à faire des changements dans le code, mais on dirait bien que ce genre de mécanisme qui transforme la fonction de contrôle unique en "lire_le_pad -> pousser_un_objet -> suivre_une_pente -> marcher" s'appliquerait aussi bien aux objets déplaçables ou aux pentes fixes (en plus des plate-formes mobiles). Le même micro-comportement "marcher" pourrait prendre comme "input" la lecture du pad directionnel ou la position relative de Bilou par rapport à un appleman ...

Plein de choses intéressantes, donc, que je continuerai à creuser dès que j'aurai un peu dompté la forêt vierge qui me sert de jardin.

Je vous parle d'un temps que les moins de 20 ans...

Bien avant Internet, du temps où les diskettes étaient molles et que les écrans étaient le plus souvent monochrome, je programmais déjà. Petit retour sur la version "BASIC" de Bilou en image, stimulé par le fait que j'ai utilisé la "distribution" de Bilou pour QEMU comme .torrent de test dans les TPs de mes étudiants (pas de téléchargement proposé, parce que je me suis rendu compte que certains paramètres y étaient encore incorrects :P)

Tout d'abord, construire le niveau lui-même. A grand coup de "Data" qui sont lues séquentiellement à partir d'un autre point du programme. Une sorte "d'Embedded File System" avec ses avantages et ses inconvénients, l'inconvénient majeur étant sans doute l'impossibilité de construire son niveau autrement qu'au clavier.

Vous reconnaissez la scène dont la capture d'écran est sur ce blog depuis des mois ?

Venait ensuite la 'routine de gestion de l'écran', quelque-part au coeur d'une énorme boucle du genre:

• lire les DATA et les afficher
• select CASE ecran
• ajuster la position de Bilou et boucler

Cette "routine" va dessiner tout ce qui n'est pas décor (ennemis, bonus, dégradés, etc) avant de traiter en boucle le comportement de ces objets avec des sous-routines (ouf. Il y en a quand-même) genre "move" pour Bilou, "pomme" pour tester si bilou touche une pomme, "gold" pour tester s'il touche une pièce d'or, etc. Vous avez vu cet horrible hack ? répéter n fois ce qui ne dépend que de Bilou avant de passer au test de timer histoire que Bilou puisse effectivement se déplacer plus vite que le petit ver. On a échappé au 'FOR I = 1 TO 1000 : NEXT', ceci dit.
Des choses aussi élémentaires que "suis-je mort" ou "faut-il passer à l'écran suivant" devaient être répétées pour chaque écran. Wéééééé. :P

Allez, un autre petit écran. Je me suis demandé en reparcourant le code "mais enfin, pourquoi diable ce "if ... then mort". Bin parce que sinon, Bilou pouvait se promener allègrement dans les pics dessinés un peu plus haut. J'aurais pu trouver autre-chose... une couleur mortelle, par exemple.

Au passage, il n'y avait plus de sprites dans le QuickBasic (pas plus qu'en EP-BASIC). Tout fonctionnait par copier-coller entre l'écran et des variables tableau (ce que les amigaistes appelaient sans doute le "blitting", mais qui en l'occurence était du PUT et GET. Concept farfelu, ces "copies" pouvaient faire appel à un opérateur booléen pour combiner les pixels existant et ceux du buffer. Je suis parti de jeux monochrome où j'effaçais le personnage du fond noir en le "XOR"ant avec lui-même pour finir par utiliser un système de masque en deux passes (AND/OR). En l'occurence, dans ce jeu-ci, j'avais droit à 15 couleurs de fond (respectant le pattern xxxx1111) et 15 couleurs de sprites (0000yyyy) de sorte qu'un "AND" bit-à-bit entre un sprite et le fond affichait le sprite, et une couleur automatiquement transparente (255). De tous mes hacks, je crois que ça reste le plus tordu. Toute tentative de programmer sa propre routine d'affichage en BASIC étant évidemment inimaginable, car d'une lenteur affligeante.

Figurez-vous que même les tests étaient lents. Je veux dire les "if-then-else" Du coup, j'essayais dans mes routines de comportement (appelées plusieurs dizaines de fois par seconde quand tout allait bien) d'en utiliser le moins possible. En témoigne ce genre d'expression optimisée -- surréaliste aujourd'hui -- qui utilisait le signe de la différence de position pour ajuster la vitesse du "Bubble Bat". Il m'en reste encore des séquelles aujourd'hui (cf. Coding Funky Funghi).

*deline

Ce blog risque fort de prendre quelques "semaines sabbatiques". Après 9 mois de préparation, la petite "*deline" devrait montrer le bout de son nez dans les jours qui viennent. Je suis plutôt accaparé par les derniers préparatifs.

My blog is likely to slow down for a few weeks. We've been waiting for *deline during almost 9 month and she's likely to pop up in the next few days. All my 'free' time is somehow absorbed into painting, cleaning, shopping and similar activities.

Bilou on DS [en FAQ]

I guess it is time to state clearly what the ultimate project "Bilou Homebrew" is. For a couple of years, I've been blogging development progress in an attempt to build a game dubbed "Bilou's adventure" on the nintendo DS. It is actually a revival of my teenager project (on PC/Amiga by then). I compiled a little FAQ list that should cover the big idea, trends and similar stuff for those who just stumble upon the blog and want to know more about the background and motivations.

Les lecteurs francophones ont déjà la version originale de cette FAQ dans un article d'hier.

Who is Bilou ?

A fictional character -- a blue ball with googly eyes, and "surrounding" feet and hands -- used as the heroes of my video games. I usually consider that I borrowed his initial design from my friend Pierrick, and over the years, I've built a whole little cartoon world around him, with influences from Lewis Carrol's Wonderland, early cartoons together with Commander Keen and SuperMario. Oh, by the way, it's a French name, to be pronounced "Bee-loo".

Why on nintendo DS ?

The DS is the computer I'm dreaming of since my early C64. It has hardware sound mixing, multi-layer graphics with hardware sprites, and much more. It has a touch screen just precise enough to allow graphic applications and game controls inherited from the SNES (imho, the best game controller ever). WiFi and SD cards (when homebrew-ready) makes it ready to communicate with the rest of the world, too. It might be a little scarse on resources with "only" 33+66MHz and 4Mo RAM, but imho, it just puts the coder at challenge to make things efficiently and to thing small enough in a world where over-provisioning kills the beauty of optimization. Still, unlike former 2D game consoles (SNES/Genesis), it still allow a nice environment and do not *require* optimization of every little bit.
And most of all, it does exists. If i was to code my stuff on anything else, chances are that i would first re-implement a virtual DS.

What kind of game ?

My favourite genre is side-scrolling platformer, so Bilou will be a platformer. That being said, I'm still undecided on the gameplay I'd love to give to the game. Will it be a Sonic-like race ? A Fury-like puzzle or a Johny Biscuit arcade puzzle ? Will it provide Keen-like exploration or Cave Story-inspired RPG ? I cannot tell. Chances are that I'll be investigating all those aspects in the future years, through standalone demos showing only a few levels at a time. Not only it will deliver fun to fans & players, but it allows me to keep on moving.

Can we give it a try ?

Yes, we can. Small "milestone" demos are proposed along the path and advertised in the "downloads" section of this blog. Keep in mind that these are always "work in progress". I don't have a very large testers community at hand (only a few friends have homebrew-ready devices, often the exact same hardware as myself), so a fresh look at how things should be is always of interest. It might not always be possible to follow such advice, though. For those of you who don't have a DS, demos should run in emulators as well (they're tested on Desmume).

Where can i find some videos ?

With runable demos at hand, i'm less and less inclined to take the time to shoot pictures or videos of my work. It takes an awful lot of time that I could instead give to programming the game, and it's incredibly difficult to have a decent quality with the tools I've got. That being said, I'm interested in any picture/video you've shot and put online here or there. Just link to them with a comment in the corresponding demo.

How do you realise such a game ?

I implemented a fresh game engine in C++, and reuse 0xtob's C++ modplayer (NTXM, from the NitroTracker project), thanks to the "devkitpro" environment in Linux. A few tools on the PC side are developed in PERL, as well.
I intend to keep the game logic apart from the engine thanks to a custom scripting "language" inspired from former successes such as Another World or SCUMM. The script only take care of "events", letting the C++ part handling the boring work of detecting collisions, moving sprites, etc.

Will I ever find Bilou in a store ?

Unlikely. I'm not targetting a commercial release and I don't think it would make my life any better if I did. Nintendo is virtually throwing independent developers away and the video game industry has become a world where economic efficience dictates the rules. This is the opposite of "garage coding" I've known and cherished during my childhood. I prefer follow outsiders such as Cave Story or Qwak, do something i'd love to have. Maybe I will one day have a few units produced somewhere in Asia and sell them on Internet, like what happened for Qwak on GBA. Time will tell.

What about PC / Wii / Xbox ? What about 3D ?

Equally unlikely. I've never been seduced by the control of a virtual avatar in a 3D environment as a player, nor by the look of a 3D world (My favourite episode of Rayman ever is episode #1 starring Mr Dark). Moreover, 3D games requires another set of programming techniques, development tools and animation skills that I don't have. I usually find PC game development libraries as boring. I've tried that path for some 10 years and it just resulted in yet another revolutionary Operating System project that fell asleep.
That being said, i'm curious of how i could possibly add 3D items in a 2D platformer. New Super Mario Bros has opened an interesting path in that direction.

Open Source ?

The game engine and game development tools I'm working on in the "Bilou on DS" game project are open source and freely available in the "dsgametools" sourceforge project. My goal is to get as close as possible to a "game maker" suite fully running on DS: level edition, graphic editors, character / ennemies behaviours, etc. In a few years, you could use them to write your own games as well.
Yet, I keep my intellectual property (that is, copyrights) on Bilou's universe and all my pixel art. I don't want that X starts working on a "follow up" game, or see any graphical content in a Flash game by Y ... That's the reason why I put demos online in a "all-in-one .nds binary package", to avoid having my work ripped. I kindly ask you to respect this choice. If you find yourself fan of my work so hard that you want to provide fan-made level packs, the "dsgametools" should let you sketch your ideas on a "sketched-by-yourself" version of the environment. We can later discuss your prototype/ideas and see whether a cooperation is possible.
I know the true fan will understand and agree with my choices.

gun.shoot(this)

Tout comme les contrôleurs, les "générateurs-d'objets-en-cours-de-jeu" (baptisés iGun, pour faire simple) sont des classes C++ paramétrées par le script et associées à certains états ou transitions pour ajuster le comportement du jeu.
Pour les contrôleurs, je les avais associé à l'état courant. Facile (presque trop). Pour les "guns", j'hésite. Le script ? une transition ? un objet graphique ? Qui aura accès directement à la classe, et qui n'y accède qu'à travers les méthodes d'un autre ? C'est le genre d'indécision que je déteste en POO, typiquement parce qu'en programmation impérative, le problème ne se pose pas.

• C'est au niveau des transitions que les guns sont utilisés. Je peux éventuellement capturer ce qui m'intéresse lors du parsing.
  
• Je n'ai droit qu'à 16 guns dans une 'palette' d'effets
• Je veux éviter de devoir ré-instancier des guns identiques (contrairement à ce qui se passe pour l'instant avec les contrôleurs où je dois avoir autant de GravityController que d'états affectés par la gravité).

Not quite "analysis paralysis", but still not enough time after lunch to figure out the best way to add iGun into the object-oriented game engine. It is used by Expressions (after all, guns are used to shoot new GOBs into the playground), but it's only one of the 16 guns an expression has, and it is likely to be shared by many states. What scope should it have ? which object will 'host' it, etc.

I'm undecided. I'll have to leave it for further code refactoring.

Bref. Je devrai revoir cette partie-là un autre jour: mon temps de midi touche à sa fin...

Bilou sur DS

Ce billet est une tentative de FAQ reprenant une partie de mes discussions ou de réaction aux commentaires récents de nouveaux arrivants qui ne m'ont pas vu gribouiller des p'tits Bilous dans tous les coins depuis des années.
An English translation of this FAQ will be made available in a later post.

Qui est Bilou ?
Un personnage imaginaire -- une balle bleue avec de grands yeux, des pieds et des mains "en orbite" -- servant de héros à mes jeux vidéos, que je tiens initialement de Pierrick, et autour duquel s'est construit tout un petit monde "cartoon" où l'on retrouve des influences de Lewis Carol et des premiers dessins animés, mélangées à du Commander Keen et du SuperMario.

Pourquoi sur DS ?
Parce que la DS est la plate-forme dont je rêve depuis que j'ai un C64. Mixage son en hardware, graphisme multi-couche et support des sprites en hardware. Elle combine un écran tactile assez précis pour des applications graphiques et des contrôle de jeu à la SNES idéaux. Elle a des possibilités d'interconnexion avec le reste du monde et du stockage local pour peu qu'on se donne la peine de les faire fonctionner. Elle est un peu restreinte en resources (33+66Mhz et 4Mo de RAM), ce qui oblige le dévelopeur à chercher des solutions plutôt que de coder comme un bourrin, mais elle a quand-même assez de puissance pour ne pas nécessiter que _tous_ les aspects ne nécessitent une micro-optimisation pour pouvoir faire quelque-chose d'intéressant comme une SNES ou une Genesis. Ses possibilités 3D ne sont pas extraordinaires, mais si jamais je veux m'en servir, elles sont mieux documentées que les nvidias.
Enfin, elle existe. Si je devais coder mes jeux ailleurs, il y a de fortes chances que je commencerais par me donner l'équivalent de la DS en machine virtuelle.

Quel genre de jeu ?
J'ai un faible pour les jeux de plate-forme, donc ce sera un jeu de plate-forme. Ceci dit, j'ai encore des hésitations sur le type de gameplay. Course rapide à la Sonic ? Puzzle à la Fury ? Arcade à la Johny Biscuit ? Exploration à la Commander Keen ? Avec une composante RPG comme dans Cave Story ? Il y a de fortes chances pour que je touche un peu à tout avec des petits groupes de niveaux d'une sorte ou de l'autre, sans chercher à intégrer le tout au départ. Ca permet aussi de continuer à avancer et à proposer du fun aux joueurs.

Peut-on l'essayer ?
Oui. Les démos sont annoncées au fur et à mesure dans la section "downloads". Il s'agit de travaux en cours : je n'ai pas une équipe de béta-testeurs très étendue, et un regard neuf est toujours apprécié, même si certaines propositions ne seront pas adoptées telles quelles.
Pour les faire tourner, il vous suffit d'une DS "homebrew-ready" ou d'un émulateur.

Où sont les vidéos ?
Je ne fais que rarement des photos d'écran et encore moins souvent des vidéos. Celà demande un investissement en temps colossal pour avoir quelque-chose de correct à montrer. Si vous mettez en ligne des photos ou vidéos de mes productions, je vous invite à l'annoncer à tous via un commentaire sur la démo en question.

Comment est-il programmé ?
Le moteur de jeu est en C++, de même que le modplayer responsable de la musique, le tout dans l'environnement libre "devkitpro" sous Linux. Le côté "PC" de certains outils est généralement bricolé en PERL parce que je le vaux bien. Je tente de garder au maximum la logique de jeu séparée via un langage de script spécifique, dans la veine du micro-basic d'Eric Chahi (Another World) ou de SCUMM (Maniac Mansion et successeurs). Tout ce qui doit être invoqué en permanence (moteur de collision, déplacement des sprites, lecture des touches, etc.) est gardé en C++ de sorte que les scripts n'interviennent que lors d'évènements (changement d'état d'un personnage, collision, fin d'une animation, etc.)

Verra-t-on Bilou dans les magasins ?
C'est très peu probable, et ce n'est pas mon but. La politique commerciale de Nintendo laisse très peu de place aux petits développeurs indépendants. C'est un autre monde où un jeu doit être rentable et disponible dans les bacs à Noël. Je m'appuie sur l'expérience de Cave Story et de Qwak. Je cherche à faire un jeu amusant, et il sera prêt ... quand il sera prêt. L'aventure a commencé il y a 15 ans. L'expérience de Qwak, ce jeu GBA homebrew produit en série limitée et vendu sur Internet, ouvre aussi des perspectives intéressante pour passer du stade "petites démos" à un "produit fini". On verra en temps utile.

En 3D sur PC / Wii / Xbox ... ?
C'est très peu probable également. Je n'ai jamais été séduit par le contrôle d'un personnage dans un environnement 3D. Celà demande également des techniques de programmation, d'animation et de développement très différentes de ce que le "développement-dans-le-grenier" permet. J'ai exploré cette piste pendant une bonne 10aine d'années sans réel succès, et l'arrivée des nouvelles consoles ne change pas fondamentalement la donne.
Intégrer des éléments 3D dans le jeu pique ma curiosité, mais pas au point de quitter l'approche "pixel art" que j'ai choisie.

Open Source ?
Le moteur de jeu et les outils que je développe dans le cadre du projet "Bilou sur DS" sont disponibles dans le projet sourceforge "dsgametools". Mon ambition est de m'approcher autant que possible d'un système de "game maker" entièrement présent sur DS: édition des niveaux, des graphismes, du comportement des personnages, etc. Vous pourrez donc les réutiliser pour créer votre projet complet.
En revanche, je conserve la propriété intellectuelle intégrale sur l'univers et les graphismes de Bilou. Je ne souhaite pas que X fasse une "suite" au jeu, ni que Y réutilise tel ou tel élément dans son jeu. Pour cette raison, les démos disponibles et à venir sont distribués comme un .nds "tout-en-un". Je vous demande de respecter ce choix. Si vous êtes fan de mon travail au point de vouloir proposer un "level pack", les "dsgametools" vous permettront de "schématiser" vos idées et de produire un prototype sur lequel on discuterait d'une collaboration.
Le vrai fan comprendra et respectera ce choix.

Critical Thinking

Layton revisité par Spartine

Sacré professeur Layton! Le voilà qui renouvelle l'intérêt pour la petite DS et le genre "aventure/énigme" avec une bonne dose d'humour. Les vieux de la vieille (comprenez, ceux qui ont bricolé une roue-de-la-mort avec des pièces LEGO pour pouvoir jouer à Monkey Island) regretteront peut-être le côté "déconnecté" des énigmes par rapport à l'environnement du jeu. Les vrais fondus d'énigmes devront se contenter de leurs rubriques de Sudokus, puisqu'ils connaissent probablement déjà la moitié de celles qui sont proposées dans le Village Mystère (si je vous dis, rivière, chou, chèvre, loup, ...)

Mais l'un dans l'autre, c'est une recette gagnante et à mon avis plus agréable que les "Objections!" de l'autre avocat ou les Elite Beat Agent. Il va falloir que je me mette en chasse : plus je l'essaie plus je le trouve à mon goût.

Pour les connaisseurs, une petite savoureuse : Le professeur Layton revu et corrigé par Spartine - la fille que ce soir elle dîne en enfer, et qui anime le fanzine du forum "dev-fr" sur lequel je traine de temps en temps.