Soldier Blade: can you be Mr. Perfect ?

Quelque part entre 2000 et 2001, mon frère me ramène un émulateur PC-Engine et une quantité impressionnante de ROM pour aller avec. N'étant pas un fan de Bonks, je lève un sourcil circonspect. Une machine de 1989 ? T'es sérieux, là ? Mais deux semaines plus tard, j'arrive au bout de Tyrian, donc je jette quand-même un coup d'oeil à ce que son CD a dans le ventre ...

Et je tombe sur Soldier Blade. J'ai toujours eu un faible pour les shoot-em-up (un reste de ma phase 'quand je serai grand, je serai astronaute' d'avoir lu les Yoko Tsuno, j'imagine), mais à part Warhawk sur C64, je dois bien reconnaître que j'ai finalement assez peu joué aux titres de shoot, largement dominés à l'époque par le style 'R-Type' où le vaisseau explose au moindre pet de moustique.

Tyrian était plus dans la veine de Warhawk, avec une barre de bouclier qui compense la majeure partie des tirs encaissés. Mourir, dans l'un comme dans l'autre, c'était recommencer le niveau du début, parfois en aillant perdu une partie de ses power-ups dont je dépends tant. D'où mon attachement à Tyrian où au moins on fait l'acquisition de certaines armes de manière définitive.

Soldier Blade avait un comportement différent et assez unique pour moi: on peut stocker des power-ups, les consommer comme super-bombes (généralement contre les boss), les combiner pour monter en puissance (si je ramasse 3 power-ups "laser" à la suite, sans ramasser de 'plasma' ou de tirs rouges, je passe au laser-niveau-3 en trident. Cerise sur le gateau, si j'ai le laser-3 et que je ramasse un 'plasma', je passe directement à plasma-3 (note bien ça, Space Invaders Extreme).

Si je me fais latter, mon vaisseau explose, éparpillant mes power-up autour de moi. Un autre vaisseau arrive alors assez rapidement à la rescousse pour reprendre le combat. Suffisamment rapidement pour que je puisse récupérer au moins 2/3 des power-ups perdus. La pénalité est beaucoup moins rude que dans un R-Type où on redémarrerait avec un vaisseau "tout nu".

Avec une bande-son tout en synthé qui donne la super-pèche, des graphismes certes aux coloris limités mais réalisés avec un brio, le jeu a beau tourner sur un processeur 8-bit, je suis scotché. Mais voilà: le jeu ne propose aucune sauvegardes et cet émulateur-ci, contrairement à z-snes et nesticle (que j'ai beaucoup utilisés sur mon AMD K6-II à l'époque) n'offre pas de save-states. Du coup, le seul moyen d'aller plus loin dans le jeu en cas de game over, c'est de recommencer et de s'améliorer. Recommencer de la mission 1.

Bref, après quelques semaines d'entrainement intensif (l'avantage d'avoir réussi en 1ere session à l'unif, c'est qu'on a deux mois de vacances ;-) arriver à la mission 6 était devenu une sorte de formalité. Un peu comme faire ses gammes. Y arriver avec suffisamment de vies pour pouvoir atteindre ce que je croyais être le boss final, c'était une autre histoire: on parle quand-même d'un niveau 2 fois plus long que les autres, avec des espèces de boss rush. Battre le boss final, je n'y suis jamais parvenu. Il aurait presque fallu faire un sans-faute jusqu'au boss pour pouvoir tenter le coup.

Si le jeu n'est pas à proprement parler un 'bullet hell', il y a quand-même énormément de projectiles à éviter, chacun susceptible de détruire notre vaisseau. Si bien que j'ai fini par prendre conscience que je jouais mieux quand je n'essayais plus de regarder en détail les différents objets du jeu. Je fixais mes yeux au centre de l'écran (non plus sur mon vaisseau) et je concentrais mon attention sur ma vision périphérique. Je pouvais alors bien mieux détecter les différent mouvements et guider mon vaisseau vers les zones dégagées.

Je ne suis pas devenu "Mr. Perfect". Je n'ai pas fini le jeu. Peut-être si j'avais pu me rendre compte que le vaisseau-compagnon peut faire office de bouclier contre à peu près tous les projectiles ?

out'm'up

The inscene'99 visit had been quite as success, especially regading the 100K game competition. My brother and I then tried to figure out what we would do on the next instance - obviously, our chance of making a good game were higher than making a big demo like the one envisioned for "samedi, tous in my home".

A comment by my peer "Gedeon" about how it was a shame that crazy brix was only using boxes for collisions pushed me towards the implementation of some pixel-perfect collision routines. I remember I wanted to do some pinball game, but after all, it was decided to go for a shoot-em-up. Our secret "games to do" folder had a long list aborted shmups, from the "Polycosmos" conversion of "space Mission", the failed "cosmowars" on RSD Game-Maker, and the aborted "Bilou sky quest" ... Nothing getting any close to our childhood golden award "Warhawk". So I picked the "Tyrian" palette and started to pixel some ships.

Retournons au passage à l'an 2000. La Inscene '99 avait plutôt été un succès en particulier pour mon jeu 100K, Crazy Brix. Deux choses étaient claires: 1) on y retourne l'an prochain et 2) on a plus de chances de parvenir à refaire un p'tit jeu en 1 an que d'aligner une mégadémo sur le thème "Samedi tous in my home"... Gédéon m'avait motivé à dépasser le simple test de boîtes de collisions pour le prochain titre. ça pourrait convenir pour un pinball ou un shoot-em-up. 

Des shoot'em'up abandonés, j'en ai déjà une belle liste derrière moi, à l'époque: le Space Mission pour C64, la BD impliquant le polycosmos, le "Bilou Sky Quest" annulé par un verre de Franta et le Cosmowars foireux sous Game-Maker. Pourtant j'aime ça quand c'est bien fait. Que ce soit Warhawk ou Tyrian si il y a des étoiles et des barres de vies, je suis partant. Et comme j'avais la palette de couleurs de Tyrian sous la main, justement, je me suis lancé.

The assembly code for crazy Brix was quite horrible, and I remember taking care of increasing the quality of the organisation for out'm'up. Especially, frames-to-aminations, level layout, and to some extent the sprites behaviour were described in a "data-oriented" macros system that looked a bit like game script, but converted straight into binary pointers and values -- something that was apparently common in MegaDrive games development.

The second key development was to support a dynamic list of sprites, allowing fancy explosions, lots of shots and even powerups where crazybrix couldn't even accomodate for anything but a ball and a paddle. Two lists, in fact. This engine was the first time I decided to split objects in two separate casts to reduce the amount of collision checks required.

While the level design wasn't very inspired, the game received a brilliant soundtrack, a classic but good-looking starfield effect and Out'm'Up won the first place - although mostly due to the lack of significant competition.

Même s'il a disposé de 3 fois moins de temps que Crazy Brix, Out'm'Up a eu droit au niveau programmation à tout ce qui faisait défaut à son prédécesseur: des effets d'explosions, des power-ups, des sprites ennemis, des niveaux programmables.

J'avais même une structure 'scriptable' pour permettre à mon frangin de passer au level design une fois le travail sur le son terminé, mais il n'y a jamais montré beaucoup d'intérêt. L'aventure s'arrêtera donc une fois la première place de la Inscene y2k empochée. Ce sera mon dernier projet en VGA + S3M. mon dernier projet MS-DOS.

Thumbs up for Hydorah

I haven't played Hydora, yet : that will be within 12 minutes when downloading is complete if my emulator feels so (yep, I'm a Linux user ;). Meanwhile, I had a look at Locomalito's "making of" document, which I enjoyed a lot. It's very fun to see how others organise a pet-project like this -- I mean, a passion-fueled one, not how you should have a art manager, a level designer, a team of beta-testers and blablablah. ^_^

Long live indie games !

Bion, je n'ai pas encore joué à Hydorah, qui n'aura fini de télécharger que dans 12 minutes, mais je suis déjà fan. Entretemps, je dévore le "making of" de Locomalito ... une initiative très sympathique qui me permet de découvrir la passion du jeu vidéo partagée par d'autres... Les petits carnets de croquis et tout ça ;)

oamstack from XeO³

Bion, ajouter des sprites dans tous les sens, c'est sympa. Continuer à avoir des sprites dans le 2eme niveau, c'est mieux. L'ennui, c'est que le GuiEngine, comme son nom l'indique, a été au départ conçu pour gérer des interfaces graphiques (SEDS et LEDS), et pas des jeux, ce qui signifie qu'il n'y a pas la possibilité à ce niveau de libérer des sprites -- ou plus précisément, les OAM, c.à.d. les zones en mémoire vidéo qui décrivent l'emplacement et les propriétés des sprites. Qu'à celà ne tienne: m'inspirant du "stack allocator" pour 6502 du projet XeO³, je rajoute une petite surcouche ...

I was making sure that sprites could be reclaimed and that you keep seeing little stars even if you got hit > 60 times ... Just one problem here : Engine::allocate is the only way to inform the GuiEngine of how much sprites it should sync to the DS video memory ... As the level is reset, that number is reset to 0, but since all the Gobs of the level have just been "pushed" in the oamstack ... well ... Engine::allocate() is never called and thus no sprite show up ... at all. Trivial to fix, but reminds me that you should always think twice when you alter the behaviour of something ... And that was a nice occasion to mention Dailly, Kekule & Russel's work on XeO3 : the Ultimate shoot'm'up for Commodore Plus/4 (which has some armalyte taste, if you ask me) and how this code gets inspiration from the 6502 "stack allocator" for bullets in that game.

Ca n'a pas tout à fait marché, mais presque: le GuiEngine retient le nombre de sprites qu'il a effectivement alloué et ne copiera en VRAM que ceux-là. Or, lorsque le niveau recommence, tous les OAMs précédemment restent dans la "pile de sprites recyclés" alors que le GuiEngine pense qu'il n'y en a aucun en service. Le résultat ? Bin le jeu tourne, mais plus aucun sprite ne s'affiche. C'est plutôt bête comme chou à régler, donc je vais aller règler ça pendant que vous découvrez en détail cet étonnant projet XeO³ mené par Mike Dailly, un (ancien ?) programmeur de chez DMA design dont je suis le blog depuis un moment.

edit: Btw, yes, this implies u8 oamstack[128] because there is at most 128 OAMs per screen and that the game is only on one screen. I can't think of another allocation scheme that would save me more and don't disturb run-time operations. I'd love to extend the mechanism to GameObject structure themselves (which have higher allocation overhead)

edit++: funny, they seem to use the same kind of "script-encoded-into-asm-constants" approach than I used in 2000 for Out'm'UP :).

Les collisions

Les collisions, c'est probablement un des éléments les plus important de la gestion des sprites dans un moteur de jeu. Outre l'aspect purement technique "y a-t-il ou pas collision" et l'aspect d'optimisation "comment tester les collisions entre N sprites (potentiellement (N*N-1)/2 calculs) en un temps raisonnable", il y a le côté "logique du jeu": comment vont réagir les différents objets en cas de collision.

Mes premiers jeux étaient assez élémentaires de ce point de vue là: collision = touché sauf si ybilou+8<ymonster. une tentative un peu simpliste de simuler le "pogotage de cafetière à la SuperMario".
Mais ça, c'était du temps du BASIC. En 1997 (déjà programmeur en assembleur et bricolant mon 'mod player à l'époque), je suis à l'unif le cours d'algorithmique de PaDM ou je découvre les joies des listes liées et où SJ me guide tout doucement vers la compréhension que "tes 'registres de sprites' ressemblent à des variables-membre en POO".

Collisions play a major role in game engines. So far, in my former game attempts, i mostly focused on "how do we know there is a collision?" or "how can i support many sprites without slow-down due to O(N²) collisions detection effort?". This time, i'm rather focusing on "what shall we do once a collision is detected?". Collisions are event that will affect the state machine of our sprites... of both sprites that are involved in the collision. My first "serious" design effort on collisions management dates back from "Out'm'Up" game for the 100K-game competition at Inscene'2K (a demoparty in Belgium), the distilled wisdom resulting on my effort to build an "Ultimate Game Maker" between '97 and '99.

Rétrospectivement, ça fait un peu peur: après 10 ans de programmation, je n'avais pas encore terriblement évolué dans ma manière d'approcher les problèmes de quand je programmais mon "Calimero" en BASIC C64 à grand coup de Gotos. Seule grosse différence, je tentais de reproduire en Software (via des "registres" pour la position, la vitesse, la puissance, etc.) le hardware idéal pour mon moteur de jeu. Un variante non-déclarée de la machine virtuelle donc, mais qui me poussait à sur-définir des éléments tout à fait accessoire du genre "combien de bits pour le niveau d'attaque et le niveau de défense du sprite ?"

Out'm'Up, mon dernier shoot en date

Bref, les années "Ultimate Game Maker" sont loin, maintenant. Si je reprends de temps en temps la farde bleue à carreau où tout cela est consigné, c'est plus par nostalgie que pour son contenu. Ou pour dater une technique ancestrale. En juin 2000, par exemple, j'expérimente dans "Out'm'up" une technique dont je ne me séparerais plus: les castes de sprites. Dans toute collisions, il y a toujours un sprite actif (qui cherche la bagarre) et un sprite passif (qui subit la collision). Le sprite passif appartient à une des deux castes possibles (hero ou evil) et le sprite actif ne cherchera pour ses collisions que dans la liste de la caste correspondance. En clair, celà signifie que les tirs de mon p'tit vaisseau ne testeront jamais que les "ennemis" (et pas les autres tirs ou les bonus) et que les ennemis ne se testent pas entre-eux (mais uniquement vis-à-vis du joueur). L'un dans l'autre, la technique s'est montrée tout à fait satisfaisante vu la quantité d'objets à l'écran (on est encore loin d'un Bullet Hell, bien sûr, mais n'empèche).

Active/Passive
The core concept is that in a collision between two sprites, one is *active* and the other *passive*. I.e. the passive sprite has just registered itself in a list of "sprites that accept collisions", but the active sprite is the one who will scan that list for a match. Together with that mechanism comes the idea of *casts*. We only have a limited number of such "lists" where sprites can register -- one per sprite cast. And so far, in all games two casts seems to be enough: heroes and evils. In a laser-ufo collision, for instance, the UFO is passive evil and the laser is active. That means that the laser only checks UFOs for collisions, not other lasers or explosions, bonuses, etc. In the UFO-spaceship collision, the spaceship is passive hero and the UFO is active. You'll note that the cast of the active sprite is irrelevant in a collision. So far, it has proven much more efficient and flexible than adjusting "power levels" (in RSD Game-Maker, all sprite had a power level, and when the collide, the one with the highest level kills the other one. period)

Si ça peut paraître un peu annecdotique dans un jeu de plate-formes, ça n'en reste pas moins la base de la gestion des collisions dans ma dernière démo. J'y ai ajouté le système des masques inspiré du code de Jill of the Jungle qui, une fois que j'aurai bricolé l'évaluateur d'expressions, permettra de faire réagir les personnages différemment selon la "source" de la collision. Petit exemple ici avec le "pendat" et ses réactions possible en cas de collision avec un objet lancé, avec un encrier bloquant ou avec le personnage.

In a platforming game like Bilou, this needs to be extended. Not only the cast of the 'hitter' is important, but also its nature, which i intend to implement through collision flags, drawing inspiration from Jill of the Jungle source code. Every "active area" defines a set of flags that identify "what it is" while "passive collision areas" indicate "what they are sensitive to". You can then have a penguin monster that takes a single hit unless it is hit by F_FIRE, which kills it instantaneously.

While the cast of a sprite never changes, each state can define various areas, with different flags. That allows us to have e.g. a special "strike" move with an additional, powerful attack area or a move that unveils a weak point. The game script defines transition on a per-area basis, so what happens when you hit one weak point can be different than what happens when you hit another area. Now, i still have to "make it so" in the code, and make the result of "area masks" visible to my "GobExpressions". In an attempt to separate the concerns, each sprite will take care of its own state manipulation: we won't have the pencil 'killing' anyone directly, but i expect that i might need some information about "the other guy" anyway (relative position, speed, etc.)
J'aurai donc bientôt réglé le bug qui "blesse" Bilou à chaque fois qu'il ramasse un bonus et un état dédié 'blessé' me permettra de rendre plus facilement Funky Funghi infranchissable. Par contre, rendre certains ennemis "solides", même quand Bilou est invulnérable temporairement, ça reste un challenge.

2024 #choice reality check: Well, now that I have access to countless hitbox reveal (mostly by Upsilandre), it turns out that having separate active and passive boxes (typically called hitbox and hurtbox) is the de-facto solution. Having a separate list for player and foes also is. But the more I progress, the more it shows that additional casts will be required for bridges and things alike. Nothing has been coded so far, though.

Seafox

Un chouette petit jeu qui trônait sur la même disquette que WarHawk de notre bon vieux commodore. L'illustration même du principe d'un jeu d'arcade : des contrôles simples, un écran unique et une difficulté progressive par un système de mission. Notre vaillant petit sous-marin (repeint en jaune pour la version "DS") s'attaque à des convois marins (la ligne la plus haute) et tente de les couler. Ces convois sont protégés par des croiseurs (la deuxième ligne de bateaux) sur lesquelles vos charge mer-mer iront rebondir et couleront (avec risque pour vous d'y laisser votre peau). Evidemment, vos activités de piraterie ne restent pas longtemps inaperçues, et la compagnie (l'armée ? va savoir ...) qui gère ces caravanes maritimes envoie à vos trousses ses chasseurs sous-marins.

On the same 5"1/4 floppy than WarHawk stood SeaFox. The ultimate example of a good ole' arcade shoot-m-up game : simple but efficient controls, a single screen and a progressively increasing difficulty. Our (yellow on the mockup) submarine try to sink sea fret of some kind (the top line) that are protected by armored ships (the bottom line). As that "shipping Guild" doesn't seem to like your piratery activities, it sends its own sub-fleet to kill you.

As being in the process of trying to revive the game on Nintendo DS (hence the mockup), i've been (of course) re-playing it extensively this week-end to pinpoint important gameplay elements. Ridiculous do i hear ? well, you do not want me to screw it up "à la Tetris DS", do you? Okay. As far as it goes, the relative speed of sprites (torpedos, ships, submarine, fleet) seems to be of high importance: you can escape a opponent sub only vertically : it is just too fast horizontally. You can shoot them with torpedos, but only left-to-right: your sub never turns back.

(PS: I started coding it this week-end and i'll translate more as code progress. It's time i take care of that coffee breach on deck 2. The bridge is yours.)
L'expérience du "tetris DS" et de Space Invaders Extreme m'a appris au moins une chose: quand vous reprenez un vieux jeu, faites-le bien ou ne le faites pas du tout. Donc, au niveau du gameplay, quelques petites contraintes supplémentaires viennent pimenter l'affaire:
• un seul missile et une seule torpille à la fois sur l'écran.
• les chasseurs 'suivent' votre sous-marin horizontalement et traversent l'écran, soit de gauche à droite, soit de droite à gauche.
• votre sous-marin se déplace plus rapidement de haut en bas que de gauche à droite, les chasseurs, à l'inverse, montent et descendent difficilement mais avancent deux fois plus vite que vous (la vitesse de vos torpilles).
• Le fuel (temps) ainsi que le nombre de torpilles est limité.
• Les croiseurs sont légèrement plus lents que le sous-marin, et les navires facilement deux fois plus lents que les croiseurs.
• Votre sous-marin est toujours pointé vers la droite et ne peut donc tirer des torpilles que dans cette direction.

En principe, la caravane passe en boucle jusqu'à son élimination complète. Ca par contre, ça ne me plait pas trop. Je ferai en sorte qu'elle ne défile qu'une seule fois, mais avec la possibilité pour notre petit sous-marin de passer en mode "turbo" pour aller la rattraper et lui tendre une deuxième embuscade . . . ensuite ... hmm ... pourquoi pas voir couler les navires dans l'écran du bas ... il faudra (peut-être?) les éviter et ils pourraient laisser s'échapper des bonus (ultra-missile pouvant couler un croiseur, torpilles plus puissantes, renfort de fuel, brouillage sonar (invisible aux chasseurs)) etc.

Oh, oui. Dans la version C64, tous les navires ont la même taille ... bin à défaut de les faire aussi variés que sur commodore, les miens ont des tailles assez variables ... on pourrait presque jouer au combat naval, tiens ;)

Enfin, faisons d'abord le code tout simple, on enjolivera ensuite ^_^

allez, let's go : je commencej'ai commencé la programmation ce week-end (par des ajouts à mon moteur de jeu et des petites classes pratique genre "Contrôleur-qui-suit-une-cible", etc.)

Note pour plus tard : dans le jeu C64, les "recharges" sont effectuées par un sous-marin qui lache un dauphin une fois arrivé dans le coin inférieur-droit de l'écran. Une sorte de poisson-pacman va tenter de gober les munitions du dauphin on a en gros qu'un demi-écran pour faire la recharge, et surtout, la destruction du dauphin déclenche immédiatement l'envoi d'une sorte de baleine vengeuse à laquelle vous ne pourrez pas échapper. Greenpeace veille ^_^. Ca me paraît un peu beaucoup pour une première implémentation, mais c'est à mon avis un des éléments du gameplay qui en faisait un jeu sympathique et attachant (au risque de distraire le jeune joueur de la mission de base -- couler les navires -- d'ailleurs).

PS: mon frère est sur la brèche pour le son, bien sûr ... Par contre je cherche un artiste pour me refaire les fonds (là, j'ai pris une image sur Internet -- et donc pas libre de droit -- juste pour avoir une idée de ce que ça donnerait ...)

Biokid NT : countermeasures

Quelque part en 1996, mon frère Piet me pond une storyline un peu abracadabrante inspirée d'un vieux souvenir (le Stoner): votre PC est infecté par le terrible virus Terminator 007. Le seul moyen d'en venir à bout, c'est le nouvel anti-virus interactif de PPP Team Software: Biokid.

Back in 1996, my brother's mind give birth to a curious story: your PC is infected by a dangerous virus -- the Terminator 007 -- and the only thing that can get rid of it is the brand-new interactive antivirus from PPP Team Software: Biokid. To put it simpler, Biokid is a crossing over between Megaman character and Commander Keen level design where you hunt for keys and weapon upgrades in maze-like platformer. It turned into one of our best production on RSD Game Maker.

L'idée, c'était de tenter de s'approcher du gameplay d'un Megaman. Mais là, j'ai envie d'un petit jeu au principe plus simple (un shoot'm'up) que Bilou pour roder un peu mon Game Engine, et plutôt que de ressortir Bilou Sky Quest (C64) ou d'essayer un portage de Out'm'up (assembleur, Y2K), je me suis dit que j'allais ressortir Biokid dans un nouveau mode de jeu: "Counter Measures".

Plus question d'assurer passivement la défense de votre réseau: Biokid prend les devant et part vaillamment à l'assaut du plus grand Botnet qu'il vous a jamais été donné de combattre.

I was thinking of giving my game engine for DS a try in a different setup : a shoot-m-up. I could have reused "Out'm'Up", our brain-free shooter that won the 100K game competition at Inscene Y2K. Or I could have revived "Bilou Sky Quest", the test game I made on C64 with the "Shoot-Em-Up Construction Kit". For some reason I started dreaming of a shooter featuring Biokid who'd now have to protect your corporate network proactively and fight the largest and scariest Botnet ever fought. (hmm. I could have been "inspired" by the Bionet EU project a colleague of mine is working on, btw).

edit: bon, comme vous le voyez, côté graphique, il y aura du boulot ... je voudrais recréer une ambiance "newschool" inspirée de Matrix, Tron et autres Space Invaders Extreme ... on verra ce que ça donne ...

[C64] Shoot'm'up Construction Kit

Au terme d'une fameuse séance de LOAD "$", j'ai finalement remis la main sur un joyau que l'on croyait perdu depuis longtemps: la version commodore de Bilou's Sky Quest, ma tentative de shoot'm'up avec le "game maker" limité connu sous le nom de "SEUCK" (Shoot'em'up Construction Kit), qu'on a eu par des moyens plus ou moins obscurs au tournant de l'été 1998(?) (un mois avant que notre vénérable commodore ne grille, donc).

Seule une version assez rudimentaire a l'air d'avoir résisté au temps, pour ce qui est des exécutables, en tout cas (~10 minutes de chargement). J'ai bien les fichiers "données" de version a priori plus récentes, mais rien n'est sûr. Et comme je n'ai évidemment plus l'éditeur lui-même, l'histoire en reste-là pour l'instant. Je vous invite à passer faire un tour sur ma collection de vidéos pour voir ça en live, ou sur celle de frikilokooo, pour avoir une idée du fonctionnement de l'éditeur ...

Et pour ceux qui ont un player flash bien à jour, vous avez des vidéos de meilleure qualité dans la collection de mon frère.

It's been a long (and über-fun) LOAD "$" story, but we (my bross and I) finally retrieved the long lost "jewel": the Commodore 64 version of 'Bilou's Sky Quest'. It was a Shoot'm'up game i made up during the 1998 summer using Sensible Software's Shoot'm'up Construction Kit (SEUCK), about one month before we burnt out the C64. It seems that only an early release of the game has survived the 10-years time travel (or at least in an executable form), but i have good hope that some of the other files i've located on the disks might be sources of later versions (with better graphics and more interesting ennemies).
Now i'm investigating the options of connecting the C64 and its floppy drive to a PC system so that i can 1) retrieve the binary and data files and export them to the world and 2) import the SEUCK software back on the C64 to build playable disks of the later version... Of course, we shot video of the whole event, which you can watch on youtube by clickings links in the french text ^^"
edit: le cable PC-C64 s'appelle "X1541". Il passe du port parallèle au lecteur de diskette (5 petites pinoches à brancher) après quoi le programme "Star commander" sert à lire et écrire sur la diskette...

edit++ voir les conseils de TORX et la causette sur le blog "Commodore User Charleroi"