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)

There was a time were the network wasn't interconnected yet and had to travel the real world enclosed in sectors of floppy disks that were actually floppy. Screens had usually no colors but I was already coding. Here are a few shots of those coding sessions, with the BASIC version of Bilou's adventure.

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

A level was built out of 'DATA' lines that encoded pixels or tile arrangement for a room. But that wasn't quite enough. Over the background layer, I had small chunk of code that placed interactive graphics, and a loop that animated every object on the room, tested for collisions with bonuses, bumpers, etc. and "doors" area towards the next screen. Yes, every room with its own game loop. Never do that again, kids.

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" (/bi.lu/).
Bilou is around since 1993, and a good deal of previous games (including a QuickBasic platformer and an RPG) are also covered in the "history" thread of this blog. Bilou teams up with Bouli, the yellow guy with a red hat, as a freelance space explorer for the Stellar Convention. Bilou is the AstroCruiser's pilot and Bouli the ship's engineer.

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.

Admittedly, the hardware will turn old-fashioned before I'm done, but I bet there will still be people enjoying 256x192 display when that will happen. The game logic is platform-agnostic and most of the game engine equally is, btw.

What kind of game ?

My favourite genre is side-scrolling platformer, so Bilou will be a platformer. The initial vision is a grand adventure game, with a whole planet to explore, myths, mysteries and epic fights. 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. The arcade-inspired Apple Assault is such a first milestone on the long road I'm walking on. I will divide and conquer, one area at a time. I will experiment and, hopefully, draw lessons.


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 we find some videos ?

With running 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 reused 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.
One of the corner stone of my development kit so far is runme, a home-made swiss knife that let me transfer files between DS and the PC over wifi, view them or hear them ... It also contains the game engine so that it can run a level, launch the editors, transfer some altered ennemies behaviour and run the level again. If the game engine itself needs an upgrade, runme (and the editors, SEDS and LEDS) can download a new copy of itself and "reboot" in a few seconds.

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.

What experience of video game do you have ?

I've never been a professional game developer, if that's what you meant. Yet, it's now been over 20 years that I'm developing games, starting with simple Quizz in C64 Basic, then including two platformers and one "RPG" in QuickBasic for DOS. Two of these were featuring Bilou as main character. I entered 100k game competition on the Belgian demoscene with two arcade games embedded in my own x86-assembly module player, in 1999 and 2000, and got the 1st place each time -- mostly due to the lack of serious competition, I must say. That's for programming. With a few friends, collectively (un)known as "PPP Team", we also designed a dozen of platformers for MS-Dos using Recreational Software's Game-Maker. If you're curious about this, just read the "pppteam" thread of this blog.

How can we contact you ?

Just leave a comment on any of these posts. Comments aren't shown publicly until approved by myself and I get periodic notifications when new comments are awaiting for moderation. If that's not quite fine for you, feel free to send your mail to pype_1999.geo @ yahoo . com

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 is available here.

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.

Homebrew ?
Le développement officiel sur console Nintendo est très fermé. Ca va plus loin qu'un simple SDK coûteux ou qu'un droit de regard sur ce qui est publié et ce qui ne l'est pas. Sans une structure commerciale pré-existante et bien reconnue, c'est l'impasse. Heureusement, il existe des outils permettant malgré tout de programmer la console sans passer par le kit officiel. On dit que les jeux et programmes faits de cette façon sont "fait-maison" ("home-brew" a un petit côté "je distille mon alcool de framboise en effilant les tubes de verre moi-même" qui colle assez bien au résultat comparé au développement sur d'autres plate-formes plus ouvertes). Si vous savez ajouter des jeux sur votre DS via une carte-mémoire type SD ou micro-SD à l'aide d'un gadget acheté à un ami ou sur Internet, vous avez ce qu'il faut pour faire tourner les jeux homebrew. Bravo. ^_^

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.

Non, ça n'ira pas...

Je bricole ces derniers jours la partie du GameEngine qui permettra d'appeler du code C++ à partir des transitions : les GunFactories (essentiellement parce que c'est une généralisation du mécanisme destiné à permettre aux sprites de tirer d'autres sprites). Comme premier test, évidemment, j'essaie de créer une action externe capable de charger un nouveau niveau (ou de recharger le niveau en cours).

Je voulais gérer tout ça directement depuis le GameScript, mais ça ne marche pas... Ca ne peut pas marcher. Le GameScript ignore d'où lui proviennent les lignes du script, et il contient tout l'état en cours du niveau. Tant que le GameScript existe, les sprites se déplacent, se collisionnent, etc. On n'a pas envie que Bilou se fasse toucher alors qu'il vient de finir le niveau.
Je dois remonter plus haut dans la logique du programme, et faire de "l'inter-niveau" un état de fonctionnement indépendant (c'est à dire une fenêtre différente, vu la structure que j'ai donnée à mon "GuiEngine").

At some point, i want my little scripts to be able to invoke some more sophisticated C++ code. It is clearly needed to fire lasers, for instance. The C++ code will create the new GOB, adjust its location, register it and so on. It will also be useful to trigger sound effects or any kind of graphic effect you can think of in response to collisions or "level events". But most of all, samy is my hero I need it to load levels in-game.

Yet, it isn't as straightforward as i thought it'd be in first place. I need an intermediate "state" where the loading is already taking place but the game's logic is suspended. Something like an IntermissionWindow where i can play a little animation while the script is being parsed, etc. Morukutsu uses something similar (a StateManager pattern) in Inside the Machine, and i have such a "menu -> level1 -> intermission -> level1 (you'll better watch your steps this time) -> intermission -> level2" system in my "Gui Engine" used in SEDS and LEDS. So despite I find it weird to involve the GuiEngine within the game, that's actually the way to go.

• LevelGun.shoot() modifies some state in GameScript that indicates a new level should be run and that's level2
• it will then send an event to the GameWindow that in turns activate IntermissionWindow
• by leaving one window, we invoke cleanup such as killing the gamescript and so on.
• We're on intermission window. we can play a little animation, showing the score or a "retry/abort" question. Some background loading could happen here, though i not quite don't know how exactly.
• When the level is ready, we return to GameWindow where the gobs are actually instanciated, the level music launched and game control restored.

It requires a little more thinking as the GameScript will actually be shared by both windows (in order to do some preloading). I think i could live with something that do all loading in the GameWindow.

Grosso modo LevelLoaderGun.shoot() devra provoquer qqch comme GuiEngine::setwindow(intermissionWindow), qui nous mettrait un (retry / exit to main menu)

Dans "Inside the Machine", Morukutsu nous avait fait quelque-chose dans cette veine-là via son "state manager". Bref, il y a un peu de re-design à faire mais je n'ai pas encore le recul nécessaire.

edit: c'est fait. Voir LoadingWindow dans game.cxx et LevelGun dans guns.cxx