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.

Testpoints and borders

 Testpoints are the oldest check technique I've been using to implement collisions in my games. From Calimero to Bilou and even Crazy Brix. The idea was simply to check the color of a specific point on screen to decide whether it is solid or not. In Calimero, white was solid, and black was not. In Bilou (QuickBasic), pixels with all their 4 lower bits set were non-solid. Everything else was.

But by 2000, it was no longer sounding sufficient. I had a long technical discussion with Gedeon by then, who was enthusiast about Crazy Brix, but pointed out that ball/bricks collisions were imperfect. I had found (by browsing and floppy-swapping- and printing and reading) mask-based techniques for sprite-to-sprites collisions through shifting and masking. But I was still missing a way to do the same for ground and walls.

Then I came up with a paradigm shift: instead of doing checks on a bitmap, I could have a vector-based description of the level boundary and wrote a letter to Gedeon to present him how I'd do it.

There are still testpoints associated with sprite positions, but now they can be attached to the closest level boundary. They can be split in 4 casts depending on whether they should block as floor, ceiling or walls. Once a testpoint is associated with one border, checking whether we're in or out is trivial. One test, and that's it.

My idea was that we could build a graph or a network of boundaries for each cast, so we can switch from one boundary to its neighbour.

I had high hope to use that in my Ultimate Game Maker, but it although I said to Gedeon that navigating the 'network' shouldn't be that hard, just having a Mario-pipe in the level and falling below its height would make our 'right wall' (initially far away) become very near, and possibly skipping many other obstacles that are "shadowed" by the pipe.

edit: by re-typing this on 2021, it turns out that the solution to boundaries network might simply be to use something inspired by the 'portals' used in 3D engines (Ogre ?): above my Mario-pipe, you'd have an "empty" right-wall. That means when you're jumping and have no walls in front of you, the scanning is halted by a 'right-portal' that just serves the purpose of saying 'there's a pipe right below me'. Only when you go past the horizontal position of the pipe, you unlock the wall-boundaries that are further away.

Ah. Bin c'était supposé être un post de traduction d'un vieux post pour le tag-de-la-semaine et à y re-réfléchir, j'en viens à me dire que la clé, pour pouvoir utiliser ces bordures, c'est de rajouter des bordures-portail pour prolonger les bordures réelles. ça conserve le potentiel de décrire la structure du niveau avec moins de données qu'une tilemap, mais par contre il risque d'y avoir du travail pour l'édition de niveaux...

Et en cherchant un peu (autre chose), je retombe sur des illustrations qui doivent dater d'après la lettre à Gédéon, mais d'avant la tentative de moteur 3D pour Bilou.

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.

Hi. I'm Bilou.

Salut à tous! C'est un peu la pagaille dans le "moteur de jeu". Permettez que je laisse Bouli s'occuper de tout ça et que je vous raconte un peu comment tout a commencé.

Hi there. It's me, Bilou. Bouli says the "game engine" is wrecked, but since I'm just the pilot here, there's little I can do to help, so why wouldn't we use that time to know each other better ?


On est en 1993. Deux potes se rencontrent à l'école. Ils partagent une passion pour la musique et le désir de créer des jeux vidéos. Le frère de l'un va se retrouver l'interface entre le PC familiale, les idées de gameplay et les conseils de programmation du nouveau mentor pour tenter de donnée vie à tout ça à grand coups de DATA ...

It all started in '93, with two class mates sharing passion for music and video game design that turned friends. One's younger brother will become the idea-to-machine interface to convert all those ideas into a bunch of GOTOs and DATAs to bring the game to live. His handle was 'Pype' so far, and he's our host today.

Pour une raison nébuleuse, le frangin en question. Notre hôte, connu aujourd'hui sous la signature de "Pype" manque d'être rebaptisé "bilou" pendant cet après-midi. Si bien que c'est automatiquement en "BILOU.BAS" que seront sauvés mes premiers pixels sur processeur Intel... Encore quelques heures et le nom de "Bilou" sera définitivement transféré de Pype a ma propre bouille ronde.

But on that very day, he was about to be re-named "Bilou" by the two friends. That nickname was used so much on that afternoon that he used it when it was about to save my very first implementation on PC ... "BILOU.BAS". Hopefully, with a few more hours, *I* turn to be Bilou and he can remain "Pype".

C'est le début de l'âge d'or. Quels que soient les projets qui trottent dans la tête des membres de la toute nouvelle équipe -- PPP Team -- c'est moi, Bilou, qui suis au centre. Bilou Ski, Bilou Karting, Bilou's Adventure, Bilou's Quest, Biloutris. Tout y passe. Les lignes de code se cristallisent ... les démos deviennent jouables.

Somehow, it was the golden era. Whatever game the team dreamt of, I was the star in there. Bilou's adventure, Biloutris, Bilou Ski, Bilou Karting, Bilou's Quest, Bilou's Sky Quest ... name it, you'll have it. Code line piles up and demos start to be playable.

Malheureusement, les outils de développement de l'époque sont loin d'avoir la flexibilité et la convivialité des Unity d'aujourd'hui. On se bat tantôt avec l'espace mémoire, tantôt avec le nombre de couleurs, tantôt avec la puissance de calcul insuffisante... les grands projets piétinent.

But unfortunately, even the compilers that turned "calimero" into an executable will fail on the increased complexity of my world. Every additional colour on the gamefield requires a re-write of the engine and of all the level designed so far. Despite an all-shiny Master Boomer, they struggle to bring background music to the game ... It all looks unfinished to the foreign eye.

Les potes de PPP Team mettent alors la main sur un outil qui va les occuper pendant près de 2 ans: le RSD Game Maker, qui permet de suivre une nouvelle idée de jeu dans la semaine où elle germe... On dessine ses niveaux directement ... on les teste dans l'après-midi. Mais les interactions sont limitées et ce type de gameplay n'est pas pour moi. Mon destin est de sauter sur la tête de chenilles géantes et de me faufiler sous des champignons et des gommes sauteuses... Pas de tirer au lance-flamme sur des tronc rampants.

A few month later, the PPP Team get their hands on another tool that will keep them busy for 2 years: the RSD Game Maker. With a few clicks and some improved understanding of English, they can build a 4-level game in a single afternoon, and a Commander-Keen-sized quest in a couple of months. New heroes appear, pastiche and tributes alongside original characters. But the engine cannot be bent to my signature move of caterpillar-stomping and my world of bouncing mushrooms and switches: it's an engine for flamethrowers, weapon level ups and locks.

Quand j'y repense, je me console en me disant que le game-maker lui-même portait dans ses limites sa propre obsolescence. En 1997, Pype se met en tête d'exploiter ses nouvelles connaissances en Assembleur pour construire un Ultimate Game Maker, haute résolution, son HiFi stéréo, plus de couleurs, des monstres au comportement dignes de Super Mario World ... et la liste s'allonge au fur et à mesure que le jeu vidéo vit sa Grande Mutation de la IIIeme Dimension. Ça tourne à la définition d'un OS complet, qui aurait les bon format de fichier pour tout ... qui serait moins lourd et plus convivial que Windows ... Je me retrouve à jouer le rôle de simple mascotte en attendant mon heure.

But even that was meant to end at some point. In 1997, as the PPP Team is about to split, Pype has gathered some assembly language tools and decide to start designing and building the Ultimate Game Maker, with high definition graphics (that is, 800x600 by then), millions of colours, hi-fi stereo Impulse Tracker modules with up to 32 tracks, parallax scrolling and large sprites with behaviour comparable to Super Mario World ... And the list keeps growing as the video game industry's IIID revolution is re-shaping the platforming genre. And rather of growing bottom-up, all this digs deeper and deeper towards the building of a full operating system kernel that could run either the game, or the development tools... And I'm left being a mere sketch on the logo, even though I'm at the top.


Et puis un jour, un coup de crayon un peu plus affirmer vient me sortir de l'oubli. A court d'idées de griboulliages en attendant un cours de réseaux, Pype se dit "pourquoi pas faire un mini-strip qui raconte le parcours de Bilou".

And then, all of sudden, a line of pencil draws me out of the shadow. Out of T-shirt design ideas while he's waiting for a course to begin, Pype wonders "why not a comic strip that relates Bilou's adventure ?". Old characters get a revamp, New non-playing characters appear, a back story grow up ... and a couple of pages appear on a website -- although it never quite turned out into a web comic. This is the first milestone towards an art blog that will then host some Nintendo DS sprite editor developments before this very blog spawns to bring me back to full activity.

Les anciens personnages se font un lifting. De nouveaux intervenants apparaissent... L'idée plaît. Un mini "web-comic" vient s'ajouter aux réalisations de la branche "demoscene" de PPP Team. Plus tard, ça tournera au blog et sur ce blog, on se dira que, quand-même, ce serait rigolo de se faire un Sprite Editor sur Nintendo DS .. la boucle est bouclée.

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.

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.

"Je vous présente les bordures!"

Je viens de retomber sur une lettre -- datée du 8 janvier 1900 -- que je n'ai jamais envoyée à son destinataire, Gédéon (qui signe de temps en temps un commentaire du nom de 'Ged' sur ce blog). Il faut dire qu'après la Inscene '99 et la collaboration de CJ à son jeu "insane bugs" (une sorte de remake de micromachines), on avait entamé une correspondance sur des sujets traitant de la réalisation de jeux vidéos, que j'illustrais assez abondamment de mes Bilous, évidemment.

edit 2021: finally translated.

A cette époque, en pleines études, je codais surtout pour les TP de l'université, mais je n'avais pas énormément le temps de mettre en oeuvre tout ce à quoi je réfléchissais pour mon "Ultimate Game Maker"

Voilà ce que celà disait:

Hello, Gédéon.

Je crois bien que j'ai trouvé un truc cool pour modéliser les niveaux dans Bilou! un truc plus smart que ces "tests de couleurs" puants que j'ai utilisé dans la version BASIC du jeu!... Je te présente les bordures.
L'idée est la suivante: tes sprites possèdent un certain nombre de "testpoints" et les déplacements ne sont possibles que pour certaines valeurs de ces test-points (pas question de faire marcher Bilou dans le vide, hein!)

D'autre part, tu plaques un peu partout dans ton niveau des bordures. Ces bordures sont des éléments logiques qui ne correspondent à aucun affichage. Elles sont liées logiquement de telle manière que l'on peut facilement savoir quelle bordure est située à gauche, droite, au-dessus ou en-dessous d'une bordure donnée. Les bordures sont également séparées en 4 classes: plancher, plafond, mur-gauche et mur droit.

Ca va, je ne vais pas trop vite ?

Bon. Voyons comment ça marche. Lorsqu'un sprite crèe ses test-points, il leur fournit à chacun une classe correspondant à la classe de bordure avec laquelle ils réagissent. Du coup, on s'empresse de lier chaque test-point à la bordure de même classe la plus proche (euh, ça ne devrait pas être trop sorcier).
Voilà un aperçu de la chose en cours ... tu peux facilement savoir si tu es "dans le mur" ou pas: il suffit de regarder de quel côté de la ligne le point se trouve. Dès que ton point sort du "champs d'action" de sa bordure, on cherche quelle est la nouvelle bordure et on y relie le testpoint (après quoi on effectue le test habituel).

C'est-y-pas merveilleux, tout ça ?

Allez, une dernière idée qui m'est venue comme ça, en écrivant cette lettre (pour être sûr que tu n'arrives pas à dormir cette nuit ;-)
Au lieu des testpoints, tu pourrais faire des "bordures" pour les sprites aussi (en fait, à partir de la bounding box), mais tu risquerais d'avoir plus de calculs à faire ...)

Enfin, ça m'éviterais d'avoir des bugs à la "Crazy BriX".
Allez,
Bion, depuis, l'eau a coulé sous les ponts. Le coup des "bordures" était bien alléchant, il permettait de passer à la 3D avec moins de prise de tête que si on doit procéder pixel par pixel (c'était le cas dans Bilou en Basic, comme je le mentionnais dans la lettre), mais par contre je n'ai jamais trouvé le véritable "truc pas trop sorcier" pour déterminer quel est la prochaine bordure du même type, en particulier lorsqu'il y a plusieurs plate-formes les unes au-dessus des autres (classique dans un jeu de plate-forme, évidemment).

Pour la version "DS", je me rabats principalement sur des tests "tile par tile" (et prout pour la 3D), et les "bordures" serviront principalement pour des plate-formes mobiles, nuages, et autres joyeusetés ... Une sorte de manière de passer outre les limitations typiques des jeux "game maker".

Voilà. Bonne année à tous.