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.
No comments:
Post a Comment