Charlie the Duck

Imagine: you're in 1998 or so, using the University Internet room over lunch time with the hope of filling your two precious floppies with some more tutorials on how to make interactive software with the DJGPP compiler (and find the DJGPP make tool, which the previous library you brought back apparently needs for building). And you suddenly stumble upon some Super Mario World clone for MS-DOS ! The same web page also mentions another platformer: Charlie the Duck.

Un jeu de plate-forme où on rebondit sur des monstres pour les vaincre et où on ramasse des bonus qui font "blip". Le ton est enfantin, les graphismes sont colorés ... On s'offre même un peu de scrolling parallaxe.

Si ça ne vous impressionne pas, c'est parce que je n'ai pas encore précisé qu'il s'agit d'un shareware réalisé pour MS-DOS. Et par une seule personne s'il vous plaît: Charlie the Duck. 

Il me semble bien que j'étais tombé dessus la première fois aux alentours de '97 ou '98, pendant que je cherchais des infos sur les DOS Extenders, les bibliothèques graphiques pour DJGPP du style de Allegro et ce genre de choses. Et il est fort probable que je sois d'abord tombé sur le clone de Mario World du même auteur avant de tomber sur Charlie... mais je n'ai pu trouver aucune infos corroborant cette impression. Mais j'avais été impressionné. Puis un peu déçu: Mike non plus n'avait pas encore trouvé de solution convaincante au problème de la musique de fond pendant que le jeu tourne.

I did check Charlie back then, and was impressed by its reactiveness and the amount of mechanics implemented. Think about it: Charlie can even warp to other places by diving into some pools of waters. How many Mario clone do you know that provide a true replacement for the warp pipes ? But there was one thing the MS-DOS version of Charlie was lacking: music. And after 3 years of RSD-GameMaker, that was a no-go. I can't remember whether some part of Charlie the Duck was open source but the minute I noticed it was mute, it stopped matter. Even though there was his "tile studio" application using DJGPP+Allegro on sourceforge

But meanwhile, Mike Wiering -- the sole Charlie author -- was busy in another University.   

Je sais que je suis retombé sur Charlie et Mike au début de ce blog, ou plus précisément sur le TFE de Mike que j'ai pris à l'époque pour une thèse de doctorat. L'équipe de recherche sur la programmation fonctionnelle du coin voyait d'un bon oeil la création d'une bibliothèque de création de jeux (de plate-forme) pour étoffer son palmarès d'applications et comme le langage s'appelait "Clean" (il est assez proche d'Haskell, au passage), on a eu droit à la Clean Game Library. Le document est sympa et utilise abondamment Charlie pour les illustrations. La bibliothèque est en théorie multi-plate-forme mais a été distribuée pour DirectX. Elle a aussi permis à Mike de faire une suite à son jeu, qui reçoit un accueil mitigé suite à des ajouts/suppressions de mécaniques de jeu.

Je n'ai jamais oublié Charlie, même si avec le temps, je l'ai confondu avec le jeu-référence d'un bouquin qui parlait du mode X (et de la bibliothèque FastGraph ?) Et en re-creusant un peu le sujet pour ce post, je tombe sur un morceau croustillant de Wikipedia: 

Game-Maker seems also to have made an impression in the Benelux, with references in various academic papers,^[26] coverage in the largest game magazine in the region,^[27] and dissection by the local demoscene.^[28]

Parce que si [26] est la présentation de Mike à la conférence IFL aux Pays-Bas en '99, si je n'ai jamais entendu parler du magazine [27], la démoscène locale, c'est bibi, et la dissection, ce sont mes posts ^_^Eh oui, les gars: vous êtes en train de lire un site web référencé sur Wikipédia!

Mike's master thesis  turned into a paper for the Implementation of Functional Language workshop in 1999 "Using Clean for Platform Games", where Clean is a functional language designed at his University. Yet, that was building for Windows and DirectX 5 while I remember playing the game on MS-DOS.

I did discover that back in the early blogging days. "Clean Game", that was something I was eager to read. When it turned it was using a haskell cousin over DirectX, it cooled down any urge-to-post-about-it I initially had. But fun fact, Mike did mention RSD Game-Maker into his thesis, and somebody on the Internet found it peculiar that it happened only a few hundredths of km away from that small other country where someone had been writing scripts to extract and repair old RSD games ... And so, thanks Mike, for your duck and for contributing to Wikipedia linking to this very blog ^_^

On a retrouvé Basket Island

On peut difficilement sous-estimer l'importance du musicien Français Maf sur la musique de mon frère. Assez pour le détourner du genre "Luc Baiwir" omniprésent depuis le concert de '97. Ce que ça a de bien, c'est qu'on peut alors utiliser les commentaires qu'il laissait dans ces pour retracer les influences ... comme le fait que c'est par l'intermédiaire du magazine "PC-Team" que nous avons découvert ledit Maf.

Parmi les titres qu'il avait partagés via la rubrique "productions des lecteurs", il y avait notamment une série de modules faisant référence à une mystérieuse "Basket Island".

Eh bien il est temps de lever ce mystère: quelqu'un a mis en ligne une vidéo de la diskette de démo du jeu "Basket Island" sur lequel l'équipe Syndrome dans laquelle Maf travaillait avec Guillaume Werlé (code) et Raph Le Gall (gfx).

This is the story about a French prototype game named "Basket Island". We had started our university years, and we encountered a collection of .MOD files French musician Maf wrote two years earlier. Some of them were referring to a then-mysterious "Basket Island" project, and my brother especially liked how he managed to have syncoped beat in the otherwise square playback of modtrackers. The influence went beyond mere technique and my brother started investigating the sample set and the style of Maf until he was ready with his own "CJ(is)land" tune.

Des petits écrans qui s'enchaînent, des persos qui suivent le ballon et tentent de mettre des paniers. De quoi convaincre une autre équippe de Posse Press responsable du magazine AMIGA DREAM en '96 de partager l'info avec leur lecteurs. Cette démo fait suite à une autre diskette qui présentait un slideshow de captures d'écrans (ou juste de maquettes, en fait ^^") sur une des musiques de Maf.

I recall my brother did call Maf at some point (pricy, international phone call), and likely this is where we learnt that Basket Island had been an amiga game project, but it never got completed. Nowadays, there are a few videos of the recovered demo disks Maf's demoscene group had sent to game / amiga magazine to promote the game.

Le jeu n'aura jamais été fini. Je vous laisse le soin de creuser les liens à la recherche d'une raison officielle. De mon côté, entre la musique qui s'arrête sans prévenir dans la démo et l'instruction invalide je dirais que toute sympathique qu'ait été la démo, il y avait un gros travail de nettoyage à fournir pour que le code devienne stable et fiable. En plus de ça, on se rend également compte en regardant les phases de jeu que l'IA du joueur 2 n'arrive pas vraiment à défendre son panier et que la dynamique du jeu ne permet pas non plus au joueur humain de s'interposer pendant les phases de contre-attaque. Un peu comme si on avait été face à un pacman où les fantômes ne vous pourchasse pas vraiment, mais se contentent de tourner en rond. 

Despite brilliant graphics and clean rendering, the demo also show that the game engine lacked stability and that gameplay was still very rough, hardly fair to the human player. I guess that's why killed the project before it could be shipped ...

Probable que tôt ou tard, l'équipe (ou ses membres ^^") ait fini par se concentrer sur un projet plus fiable pour assurer leur avenir.

Slurp'n'Burp

At some point between '97 and '99, my brother suggested that we make a 2-players cooperative (?) pacman clone: Slurp'n'Burp. Of course, by then I had no idea how the original ghosts 'AI' was coded, so I came up with this complex algorithms where every hallway is a sensor.

While the ghosts wanders around the maze, they 'poll' hallways to know whether they have seen a player. If the hallway has seen a player, it can tell which direction to go, the ghost then goes hunting; at corners, the hunting ghost polls which branching hallway has suggestions to find the player. If none has, the ghost is "lost". It picks a branch, goes to the other side of it and polls again. if nothing works, it takes back the route it had found and picks another branch. 

I have no clue whether it would have worked, as I've never coded more than the sound configuration menu of Slurp 'n Burp. The actual pacman AI is much more cleaner and elegant, of course. (and has been extensively discussed, including here) 

Of course, my bro's blog has precise logging of when it happened, since he immediately wrote songs for it and logged the date.  knowing that Greedy is out in September '97 and that we track demoscene pretty frequently through #PossePresse magazine at that time, I still think it is perfectly possible that Eclipse prod inspired us.

(recovered from tweets posted in November 2021)

Ultimate Game Maker

 There has been references to Ultimate Game Maker here and there in this blog, but if I want to explain what the project was, I'll need to detail a bit what I was doing just before.

Most of it was working on the early Clicker project, which was mostly meant to be a GUI library and desktop environment over a DOS extender, by then. It was also a mix between Nowan's C code and my assembly code so I had been defining every possible widget with a bit-level memory layout of how they would be managed as if the GUI handling code was a co-processor.

Meanwhile, I was more or less done with the RSD Game-Maker. It had too many limitations for the games I wanted to make. Games that could match Super Mario World.

Unlike Nowan, I had little interest in replacing Ms-Word with something better, but quite quickly, I started to use Clicker GUI project to revise the Game Maker I knew. There was little depart from RSD editor at that point. We see that on the 'monsters editor' screen that still has a grid to define monsters 'walking path'. But it already had a few critical extensions like "Monster is affected by gravity (needed for Bilou)" and "Monster can shoot" (needed for Badman III).

Ultimate Game Maker started while I was waiting for over 1 hour every morning for my university courses to start, and before the distance between Internet and classrooms shrunk.

I then started to cover a good deal of pages with a sort of class hierarchy starting with 'sprites' (purely decorative entities) up to playable characters (PERSO depicted here). Each of these class of game entity comes with a detailed set of "registers" and code pointers. They can detail things like attack and defence levels (inherited from RSD), invincibility frame counters, but also position and frame identifier within animation tables.

Like I did with Clicker, each of these 'registers' is carefully assigned an 8-, 16- or 32-bit size and the size of each set of registers is accounted. All of this is of course completely obsolete.

I also draw from Clicker's fonts rendering the idea that it is best to have generated code used to pset some pixels while others are left untouched on those pre-MMX, low-bandwidth video adapters.

That idea extended quite naturally to the fact that most characters in Bilou are meant to be made of small sprites. They are called 'blobs' in this work, and you'll have some 'registers' that identify the first and last 'blob' in the list that can receive hits and first/last blob that can give hits.

There is one hiatus, however, that will never be resolved: those strict hierarchies with pre-defined roles (a bonus - which can be collected - is not an object - which can be picked up) will never accomodate with koopas that switch roles between pick-me-up shell and self-moving ennemies.

Nathan Am Error

I'm reading a book about the NES: "I AM ERROR" by Nathan Altice. I guess you're not surprised. After all, I've been reading Pix'n'Love take on Donkey Kong, "L'Histoire de Mario" and "the Playstation Revolution". But this book is published at MIT press, and written by someone who has a thesis in arts, not an engineer or a game reviewer.

Yet, he got deep into nitty-gritty details about how tiles are used to build the images produced by the PPU, and how game developers and Nintendo themselves tried and extended the features of the NES as competing micro-computers were trying to bridge the technological gap.

Quelque-part entre les chroniques de la saga Zelda et "la révolution playstation", je vais bientôt ranger un outsider: "I AM ERROR" par Nathan Altice. Outsider parce que ce livre-ci a été pensé comme un ouvrage de référence universitaire par un expert d'une faculté "arts & culture" qui va étudier en détail en quoi les limites de la NES ont influencé les gens qui ont créé dessus, leurs oeuvres et les gens qui ont découverts leurs oeuvres, un peu comme on pourrait écrire un livre sur la technique des pigments dans les peintures de la renaissance et l'impact que le changement de matériel pour les pinceaux a eu sur l'oeuvre de Léonard de Vinci. Ici, bien sûr, il sera plutôt question du nombre de couleurs et de tiles, des possibilités de scrolling puis des puces et astuces que les développeurs de jeu et de chez Nintendo ont utilisé pour faire des histoires toujours plus grandes, dans des environnements toujours plus vastes .

I found it pretty surprising that the first generation of NES game had to be soldered for either horizontal and vertical scrolling. Then, cartridge started to include chips that would allow to switch between the two, like with the custom "UNROM" in Mega Man and the official "MMC1" in subsequent Mega Man games. Of course, I already knew that some cartridges featured more than mere ROMs, be it only for the SuperFX in StarFox. But the NES mappers had more arcane things to do and were not that much advertised. And they came as a second choice, as the initial extension roadmap was the disk system and its video RAM where the PPU expected to find tiles and sprites ROM.

En découvrant les maps des jeux Capcom sur NES, j'avais déjà supposé que la console imposait le choix du sens de scrolling: horizontal ou vertical. J'étais loin d'imaginer que pour faire un jeu tel que Megaman qui alterne phase horizontale sur phase verticale, il aura fallu bricoler les cartouches et leur rajouter une puce de contrôle, parce que Super Mario Bros, par exemple, a soudé le choix d'un scrolling horizontal. Toutes ces puces -- les "mappers" -- sont bien plus fréquentes que le SuperFX de la superNES, mais pourtant il n'en a presque jamais fait mention. C'est un détail pour le joueur, presqu'un secret de fabrication. Un secret peu avouable pour les développeurs qui avaient au départ misé sur le "famicom disk system" qui remplaçait la ROM graphique de la cartouche par une RAM remplie à partir du contenu d'une diskette. Pourtant, c'est bien en ajoutant une puce de RAM que Super Mario 3 est capable de retenir quels blocs ont été cassés (la NES n'ayant que 2KB!, à peine de quoi retenir le contenu de 8 écrans).

Still, if you think about it, Super Mario Bros. was already using the full range of pixels that the PPU could use. Embedding more graphics in the game is useless without a technique that could change which 16KiB slice was used. I suspected such techniques existed by 1998 when I first saw nesticle's video "pattern table" window contents updating as SMB3 played out. Those techniques are reminiscent of memory-paging techniques already in use on mainframes by then, but I was far from imagining the level of sophistications those chips could have, having different page sizes depending on the game's need regarding animation or environment diversity, ultimately embedding even additional sound chips and ways to offer real free, 4-direction scrolling.

Ce n'est qu'à travers ce genre de ruse -- pagination pour passer de l'overworld de Zelda à un des donjons, copie à la volée de sprites présents dans la ROM-programme vers la nouvelle RAM auquel le processeur graphique (PPU) a accès -- que les développeurs NES vont pouvoir faire mieux et plus riche que Super Mario Bros, qui saturait déjà les 16KB de mémoire que le PPU sait utiliser. Ici aussi, j'avais soupçonné ce genre de technique en voyant tourner SMB3 dans Nesticle, mais j'étais loin de me douter de la diversité des approches, des subtilités ajoutant des nouveaux systèmes d'interruptions sur une ligne précise de l'écran (devenue partie intégrante des designs de Nintendo depuis la SNES) ou l'intégration d'une puce sonore additionnelle que la NES utilisera comme elle aurait utilisé "l'entrée micro" du 2eme contrôleur de la Famicom.

En revanche, "comment on fait tenir un niveau sur 100 bytes" restera une curiosité dans ce livre. Dommage pour moi. Heureusement - j'imagine - pour la majorité des étudiants qui commandent le livre sur MIT Press...

I'm just slightly disappointed that "how SMB level were packed to a mere hundred of bytes" is the sole sequence that reveal how NES games were created with such a level of detail. I might have to dig for Megaman disassemblies ...

Life-changing books [3/3]

1998. Bilou devient la cerise sur le gateau du projet "Ultimate Game Maker". Pour le réaliser, j'ai attaqué très sérieusement la lecture des documents (et les sources) de TRAN sur le mode protégé du 80386, les moyens de passer en mode "unreal" (code 16 bits avec données 32 bits) et ce genre de choses en ligne droite de la démoscène PC.

Many game development studios faced a hard time switching to 2D to 3D at the end of the 90's. Things were quite troublesome for my little self too. I had at last access to massive knowledge about VESA, sound cards and newer tools such as DJGPP compiler and early mikmod player source code ... but it was clear 320x200 MS-DOS games were gone for good. My quest for an improved Game-Maker software turned into a quest for a better operating system to run both game engines and game development tools. Filesystems that would make sharing of samples across a large bank of tracked songs trivial, etc. The cornerstone book for that shift is Andrew Tanenbaum's book on operating system, found somewhere in the university's library, and it will stay at my home, studied dailynightly as the Clicker 32 operating system project shaped up.

Je tombe ensuite sur un bouquin à la bibliothèque universitaire qui présente les structures de système d'exploitations avec environ 2 ans d'avance sur la matière dans mon cursus. Pendant à peu près 8 mois, le bouquin sera emprunté presqu'en permanence, et je remplis des carnets entiers de notes de lectures, d'idées pour aller au-delà des techniques habituelles avec l'idée de construire un système idéal où les politiques de gestion de mémoire et de temps CPU peuvent être échangées en temps réel (comprenez, lors du démarrage ou de l'arrêt de Bilou pour revenir au game maker).

Je vais ensuite tomber sur une description assez détaillées de Linux pour me permettre de définir les objectifs avec assez de précision, et identifier les aspects originaux de mon propre design. Un grand nombre des idées de base visent à donner une sensation de programmation Amiga sur une plate-forme multi-threads x86, avec les pilotes de périphériques vus comme des sortes de co-processeurs. Cette quête va m'occuper l'esprit jusqu'à mon travail de fin d'études et au-delà.

A second book, detailing the internals of the Linux system further refined what I did not wanted to have. Like a monolithic system, purely based on function calls. I wanted to give the programmer in the Clicker operating system the feeling to work on a virtual Amiga-like platform, with programmable co-processors for virtual memory, sound mixing and window compositing tasks, where you could hot-swap the process scheduler.

All this started 100% assembly, but that project taught me to use the C language for what it is and to avoid assembly whenever possible. The reason was you are too much bound to what you write. Do you realize there's a mistake in your algorithm ? you'll be to go through registers allocation planning and pipeline optimization once again.

Le projet Clicker sera aussi celui qui me fera lâcher l'assembleur pour chercher à comprendre le véritable fonctionnement du langage C grâce au bouquin de Kernighan & Ritchie. Les algorithmes utilisés pour la gestion de la mémoire deviennent tout simplement trop sophistiqués pour rester écrits en assembleur. Corriger une erreur de conception dans un code de recherche "best fit avec back-tracking" revient à reprendre le design d'une page blanche, re-réfléchir à l'affectation des registres et revoir tous les efforts destinés à assurer un comportement optimal sur le double pipeline du Pentium. C'est tout simplement intenable.

Kirby 3D

Du sympa et *beaucoup* de récup dans ce nouvel opus de la chiquelette rose la plus populaire du monde Nintendo... Variante simple mais efficace des power-up centimes de vie à récolter: la couleur indique la valeur (comme les rubis d'Hyrule) et de mignonnes petites fleurs dévoileront un bonus quand on passe devant.... Allez, bonne nuit :)

I completed tonight the Kirby 3DS game I borrowed to my brother a couple of month ago. Quite cute, as one could expect. The depth exploring system doesn't add much to typical 2D gameplay (not more than offering 2 screens, at least) but it doesn't ruin the experience either. They put effort in the boosted vacuum mechanic, that's quite obvious. Using the colour of 'coins' to indicate they have higher value worked better than glueing 10 coins together. Taking note ...

Par contre, avec ses interactions avant-plan/arrière plan, son gameplay 2D dans un environnement 3D et sa structure très géométrique (contrairement à Donkey Kong Returns, beaucoup plus organique), Kirby Triple Deluxe est certainement le jeu qui vous donne la meilleure approximation de ce que j'avais en tête quand j'ai commencé à étudier le phong shading pour faire un Bilou à base de 3D, en 1998. Et les pieds de Kirby qui ne se plient pas quand il bouge vous donne aussi une bonne idée de pourquoi je n'ai pas continué dans cette voie-là après les premiers essais de rendu dans un modeleur.

Lost levels: the Clicker era

Et puisqu'on est dans une phase "déterrage de vieilleries", voici un mock'up de ce que j'espérais atteindre avec mes éditeurs de jeu ultimes aux alentours fin 1998, une fois que l'environnement Clicker serait suffisamment complet. Assez loin de SEDS, hein?

Allow me to chain to another oldies-digging: some mockups of what the Ultimate Game Maker should have looked like if Clicker was already working in 1998. The blue-balls background reuse some graphics I used for my very first website, The font is the default one for Deluxe Paint II. I guess that's before I get seriously into 3D modelling with moray, given the icons look, but we can already see the side handles for pull-menus discussed with one of my brother's musician contact who should have collaborated to the creation of the sound tracker.

Un tournant majeur du projet aura lieu en octobre 2001, lorsqu'Eugenia Loli-queru sur OSNews.com dresse la liste de tous les projets alternatifs à l'occasion de la sortie de Windows XP. Clicker32 y apparaîtra 2eme, derrière SkyOS et juste devant RDOS, provoquant 11436 visites en un jour (j'en avais jusque là une trentaine).

Chose amusante, c'est parce qu'un autre développeur d'OS amateur avait trouvé sympa le petit Bilou qui servait de curseur souris à la version 0.9.x de Clicker 32 que j'ai déterré mes autres Bilous puis que je m'y suis remis.

Synopsis reloaded

Voilà donc un exemple de "synopsis" ... le feu et l'eau ont trouvé leur place, idem pour la "castle zone", dont j'ai enfin trouvé les antagonistes. Il reste pas mal de zones "creuses", dont seul le nom est défini. "sky road, lost temple, hills top" etc. Mais globalement, l'exercice a étéfertile, et plus facilement exploitable que les "world maps" d'un ancien projet: "Rock Story"

So here's the first attempt on a synopsis. There are still many "placeholders", but fire, technical, water, sky, temple and stuff found their place. Last time I did such an attempt on "game design", it was for the "Rock Story" lost project, which my brother never found interesting. In some sense, the "willy-inspired" game map sounds like a better tool than Donkey Kong Country-inspired "world maps".

related tune

history (t.a.g.)

you've reached the last history post.

These posts present the development of games that pre-date this blog, digs of old paperwork on ancient machines. This is not only nostalgia, which would also encompass games of those times which I enjoyed and similar things. It's wider than the sole development of the story line for Bilou's Adventure and captures a lot of other "PPP Team" games & tools.


Some milestones:

• 1989: first hand on the Great Giana Sisters and first "quarters" into a Super Mario Bros arcade machine.
• 1990 : Playing Rick Dangerous at the computer store roughly every week. Planning a cover of "le Labyrinthe d'Errare" on C64 (Role-playing Book)
• 1991: First platformer project on my 8086 computer while my brother discovers Blues Brothers (titus) and Commander Keen (ID software)
• 1992 : Super Mario World arrives in Europe.
• Fall '93 : first Bilou projects
• Easter '94: I buy VGA graphics and 8-bit PCM sound for my 80386 computer. I want to make a Z:LA clone on PC.
• 1995 : RSD Game Maker year, launching the Badman series. (Rayman is released in Q4)
• Summer '96: the last one with a working C64 around, replaced by a Pentium 120MHz, my first machine with a CD-ROM reader. On my quest for an assembly module player. I can now play Rayman!
• Fall '97: Done with PC-Bot, my first major C program. First steps on Internet, starting the Ultimate Game Maker research.
• Winter '98: Upgrading the pentium into AMD K6-II, demoscene-ready. Teaching myself C++ for the first time.
• Summer '99: Crazy Brix converted into 100K game for Inscene
• Summer Y2K: Out'm'up, my last game for the PC platform. 
• 2001: first hand on a PSX system.

'90 -- '91 -- '92 -- '93 -- '94 -- '95 -- '96 -- '97 -- '98 -- '99 -- '00 -- '01 -- '02 -- '04 -- blogging -->