widget (t.a.g.)

"widget" is a category of coding-related posts that discuss programming the GUI components of libgeds used in the *EDS tools and runME.

It's not quite 'user interface', which instead discusses what sort of widgets/activities/feedback are interesting for a desired user experience, nor 'user guide' which present how to use the *EDS tools themselves.

No, it's really a sub-part of the 'coding' posts, but which are very unlikely to have any mean if you're interested to use the GEDS game engine. That's more for the "applications" section.

user interface (t.a.g.)

You're done reading posts of the "user interface" category.

These described thoughts about human/software interaction for tools rather than the mechanics used in video games. Sometimes it introduces new widgets, sometimes I'm just taking a step back and revise the existing UI in terms of accessibility, ergonomy or ease-of-use.

It's not to be swapped with user guides that present how the software with that interface can be used to achieve the desired actions.
Voilà, vous avez lu tout ce qu'il y avait dans la catégorie interface utilisateur. On y retrouve les réflexions sur les interaction homme-machine, plus pour les programmes outils que pour les mécaniques de jeux. Oarfois on on y parlera de nouveau widget et parfois je prends juste un peu de recul pour réfléchir aux interfaces existantes, leur accessibilité, leur ergonomie ou leur simplicité d'utilisation. A ne pas confondre avec les guides d'utilisateur

Unit-test [t.a.g.]

I'm not a unit-testing guru, but at some point, I had to start running automated tests on my game engine because it became more complex and I had less and less time to spend pressing 'STEP' buttons in emulators and debuggers.

I still struggle a bit to decide whether what I'm doing is unit testing or not, but I encountered two qualities that "allow" you to claim you're doing unit-testing:
- the test is "fast" to run (shorter than recompiling the project, at least?)
- the test helps you localize problems.

It's a kind of time-investment compared to guru meditation.

tutogit [t.a.g]

Well, if you're an English reader, chances are this category wasn't convincing for you. There's a good reason for that: the set of presentation posts that was used to promote the libgeds tutorial branch on github was initially posted on gbatemp forums. There was a french translation too, but on deserted boards that are likely to turn 404 fairly soon. 

But don't worry: the whole story in English is now available as a pdf.

sketch (t.a.g.)

You have just reached the last post in the "sketches" category. This tag is assigned to all those posts which features an original doodle (usually from the Bilou's world characters) as an illustration. Quality may vary widely depending on the time I took to draw the illustration -- i.e. it hasn't an artwork quality level -- and the technique I used to make it enter the digital world, but it should focus on original material (that is, not seen yet on an older post here or in the Bilou's Book

Voilà, c'était le dernier billet dans la catégorie croquis. J'ai marqué "sketch" tous les posts qui ont un petit dessin original pour les illustrer (d'habitude avec des personnages tirés de l'univers de Bilou). La qualité est assez variable en fonction du temps que je me suis laissé et de la technique pour numériser l'idée, mais il s'agit bien de choses créées pour les besoins du blog et donc pas de petit extrait du Bilou's book.

tiled [t.a.g.]

Great. You've read through all the posts related to the management of a tile-based level and how the game logic uses it. The basis is also covered in the tutorial branch through the 'cando()' function that filters contents of the map to say whether we're green to do some kind of move or not.

Tileset [t.a.g.]

Before I can show you how to load graphics with the GEDS engine, I must ensure you all know about how the NintendoDS builds the image we see on screen. I'm using the tiled mode here, where pictures are made of elementary 8x8 pixels elements called "tiles".

You have likely seen level editors where people drop little blocks to create their level rather than using larger "assets". The tiled mode pushes that one step further by structuring the video memory so that it natively works with little, 8x8 blocks. That is, one part of the memory will store such block and the other a 'map' telling which block to use at which place. Some can be used multiple times, some will not be used on this image. The technique is as old as the 8-bit era and was also used in almost every 16-bit machine.

What has changed over the generations is the number of individual colors that can be used in a tile (from 3 to 255) and the number of layers of such tiled maps that you can compose to get your final image (from 1 to 4).

A large part of the .spr files created by the Sprite Editor for DS is a dump of the "tileset" part of the video ram, so that you can easily load it and start rendering scenes with them.

Code:

  SpriteRam myRam(WIDGETS_CHARSET(512));
  SpriteSet mySet(&myRam, BG_PALETTE);

  mySet.Load("efs:/bg.spr");

There is not much the application program needs to do about it: the SpriteSet object of libgeds will exchange data between video memory and SD card storage (or here, filesystem embedded within the .nds ROM). All we need to do is tell it where to store the color map (the palette, the NDS has a specific slice of video memory for that purpose) and where to store the tiles (as we may want to keep some room for a text font and screen maps themselves). Starting at 'character 512' is an easy way to avoid conflicts with things set up by the engine, but you could very well create myRam(BG_GFX) and claim that all the (upper screen) video memory are belong to you.

• see complete tutorial code on github
• see corresponding post (#2) in gbatemp tutorial thread.

superpowers (t.a.g.)

You have made it to the last post about superpowers. These posts track my thoughts about temporary mechanics that could be used in my full-featured "Bilou's Adventure" game. Their fundamental difference against primary mechanics is that they must be acquired before you can use them, and could be lost while playing.

storyline (t.a.g.)

You've reached the oldest "storyline" post.

These posts talk about the development of the background of "Bilou's Adventure" game, e.g. the addition/refinement of which zones the world will offer to explore, etc.

It contained some historical elements, although there's more history than just presenting the storyline (the story was pretty much missing in the '94-'96 16-bit prototype.

sprtools (t.a.g.)

Wow. You've gone through all the posts about my own tools for my own SPR file format ! I'm impressed.
It may sound an odd idea to run your own file format when doing a video game. This is mostly motivated by the odd memory structure of the DS video chip, tiled to the bones. '.spr' file are mostly a VRAM dump with IFF-like headers, created by my SpriteEditor. "sprtools" are all the PC-side programs that manipulate those dumps, converting, extracting, recombining pixels and checking more complex data structures embedded within the file, such as the list of "free tiles" within a chunk of video memory.

state machine (t.a.g.)

This is the category of technical posts that discuss the use of (finite) state machine as the primary abstraction to build sophisticated behaviours for characters in video games (and side-scrolling platformers in particular).

This is to meet the observation that, in games I loved, one cannot really speak about "artificial intelligence" for ennemies. However, they have behaviours more sophisticated than a mere goomba. More like a Zelda boss, they alternate between states where they have different hit boxes corresponding to harmful blades or weak spots. A sophisticated state machine usually translates into deeper interplay with the game.

In my PhD thesis, I have observed that a strong design for the basic elements of a virtual execution engine allows a much more efficient handling of tasks. Reading open-sourced code from other games conforted me in the idea that a plain 'think()' method for handling all the possible cases of a complex character is a nightmare to work with. In an interpreted language, it would translate into repeated evaluation of tons of conditionals that could otherwise have been avoided.

As a result, the line between compiled and scripted code revolves around those state machines: the compiled code executes whatever is to happen in the current state, a data structure (built from script parsing) defines links between states, and interpreted expressions rule conditional transitions and side-effects, which allows strong reduction of the amount of interpreted symbols per game frame.

scripts (t.a.g.)

Amazing. You've been scrolling through the whole set of 'scripting' posts. I bet you have realised that these are posts about automating things using some scripting language, like Perl, bash or tcsh (yes, I've taught myself python fairly late).

If you know my pet project enough, you've noticed we aren't at all speaking of scripting game logic with LUA or my own GobScript, right ?

J'y crois pas ... vous vous êtes vraiment farcis tous mes posts sur les langages de scripting !? Vous aurez remarqué, du coup, qu'il s'agissait des langages pour automatiser des tâches sur PC, comme du PERL, du bash ou même un peu de TCSH dans les posts plus anciens. Pas du tout de mon propre langage de description des machines d'états 'GobScript', hein ;)

Oh, and yeah, there's also a tag dedicated to those scripts that manipulate .spr files to extract/merge/twist spritesheets and animations. That's sprtools. This category is for more general-purpose scripts.

I've been doing more bash only over my 'embeddever' years, and I could use more defensive bashes tips if I'm to do that again.

screenshot (t.a.g.)

You've enjoyed the list of all the posts that featured a real screenshot.

They usually introduce a new feature in my tools or a significant visual progress in games. Not all of these are pictures taken with a real camera (hopefully), and they are conveniently complemented by videos (mostly screencasts) for more dynamic features.
In contrast, mock ups are made-up pictures (typically featuring Gimp) for things that do not exist yet out of my personnal virtual world (running Mind OS :)

palette (t.a.g.)

There was a thing with 8-bit consoles and 16-bit machines: you wouldn't have the bandwidth to select precise color for each individual pixel. The digital-to-analog circuitry that provides signal to your screen might have 5- or 6-bit resolution, you're still stuck to 4 or 8 bits per pixel instead of the 15 (or 18) you should be allowed to use.

The solution was to let you select a subset (usually 16, 256 if you were lucky) of the possible colors you could use at once (per screen or per-object if you were lucky) and have a fast 'palette' memory in addition to the large 'video' memory.

It was a significant artistic constraint, but it allowed tricks like palette cycling animation, fade-in/fade out by palette edition alone and of course palette-swapping to provide more visually unique content with the same video contents.

Of course, pixel artists will speak about 'palettes' when they speak of the restricted set of colours they're using for one particular piece. I'd rather use the tag 'colours' for that purpose.

PPP Team (t.a.g.)

You have reached the last tag of the PPP Team category.

This thread is dedicated to all those games that were planned or developed by the core team "Piet, Pierrick and Pype" in the '90es, and the characters that were involved in these games, such as Badman or Biokid. Most of these were either made in MS QuickBasic or with RSD Game-Maker.

Some of these post may also be presenting thoughts about (hypothetical) porting of PPP-era game on the Nintendo DS and the GEDS engine.

You can find some more info about those games on the RSD-era spin-off page or on Aderack's wiki.

OAM (t.a.g.)

You already know sprites are movable images that can be freely placed over the background image in a computer game. Now that you've read all of the OAM tags, you also know that a sprite as we see it in-game is often built of multiple hardware sprites which usually have quite restricted size (e.g. 8x{8; 16} for NES, 8x8 to 64x64 for DS, but not e.g. 24x16).

VRAM alone doesn't make a sprite.

Each hardware sprite is controlled by an entry in the graphic chip's descriptors, giving its position and other attributes (like flipping bits) and that completes the sprite tiles storage (spritesheet) in either ROM or video RAM.

On the nintendo consoles, these are named Object Attribute Memory entries. I use that 'OAM' term when I truly mean "a hardware sprite", not a Game Object's rendition on screen (sprite).

modplayer (t.a.g)

Think about a spreadsheet. Imagine cells contain notes rather than numbers... and that somehow, by changing the color of a cell, you change the instrument that will be played for that cell. Columns are channels, rows are time slices. One page of your spreadsheet is a pattern, usually little more than a few drum loops with a part of the melody line and whatever else it needs. Your song is longer than this, of course, so it will need more patterns, and you may want to repeat some of them (you need a chorus, right?) so you have an extra list telling in what order to play them.

Now to make 'instruments', think you have sampled something with a microphone or another Audio In feature. Save all this (patterns-spreadsheets plus samples) together with a few extra info (song title and samples names) with the .MOD extension and voilà. You've got a module. To hear it again, you'll need a module player. I've used a lot of them, and I still do. I've studied the code of some of them. I've wrote a few and I'm still working on one for the Nintendo DS. Posts with the 'modplayer' tag should tell you more about it.

Quand on me demande ce que je veux dire avec mes 'modules', je retombe généralement sur cette explication d'une 'feuille excel qui contiendrait des notes de musique'. Cette feuille, on l'appelle un pattern. Elle se joue en boucle jusqu'à ce qu'on dise au programme d'en jouer une autre. Pour chaque note, il faudra un son numérisé à rejouer -- un sample -- soit à la fréquence où il a été enregistré, soit à une fréquence plus haute ou plus basse pour avoir d'autres notes.

Un 'modtracker', (ou juste un 'tracker'), c'est le programme avec lequel on les écrit. Un 'modplayer', c'est un logiciel ou une bibliothèque logicielle qui permet de les rejouer. Depuis que mon frangin a mis la main sur un tracker, comprendre, écrire et bidouiller des modplayers, c'est une partie fondatrice de mes activités de bricologicien.

mybrew (t.a.g.)

You've reached the last post in the "mybrew" thread.

These post present the software development and releases I've been through on the Nintendo DS. That captures everything about the sprite editor, the level editor and the animation editor that I intend to use for building Bilou's adventure, plus the Multi-purpose transfer-and-testing tool dubbed 'runme' and (of course), all the demo games that fill the gaps until the future Grand Release, such as Apple Rumble, apple assault and the other gedsdemo :P

It may miss some mere coding or documenting posts, and is wider than just the milestones. It doesn't cover the projects that haven't started yet such as Deep Ink Pit, although it has received a codename and a gameplay target.

Although all this software is homebrew (and open-source, btw), the 'homebrew' tag is for other's software on discussed on this blog.

Somehow, it would be a shame to keep that for myself. If I'm right, it would be as good as having a game maker for NDS on the NDS. I started a tutorial series on github to share the knowledge of how to use my homebrew engine. The first layer is a framework of compilation scripts (Makefile) together with low-level libraries (including a modified version of 0xtob music player. Well, everything needed to get a first program built and running.

KISS (t.a.g)

Keep It Simply Simple

I have a natural twist towards over-sophisticated designs. I certainly prefer Great Ball Contraptions over the shortest path. I've spent countless hours of my childhood trying to build a mechanical pattern to have a spider-like LEGO robot. I need to monitor my own designs again and again to ensure my software doesn't end up so sophisticated that it becomes impossible to think about it over the time of a tea cup.

There were likely too little words in this section, showing that the road is still long.

Mechanics (t.a.g.)

This is a term I borrow from Kirby Kid -- aka Richard Terrel.

Mechanics are the player initiated actions from controller inputs as designated by the game designers. These actions have effects on the gamestate in terms of the variables and dynamics of the gameplay system

.

In fact, if we consider that gameplay is the part that defines and rules interactions between game elements based on user inputs, mechanics are actually atomical element of the gameplay.

Une mécanique de jeu, ça va être un élément atomique de gameplay. Et le gameplay, c'est l'ensemble des règles déterminant les interactions entre les éléments du jeu sur base des actions de l'utilisateur. Oui, je comprends: ça paraît très formel, mais c'est justement l'idée derrière l'emprunt de ces termes à Richard Terrel: permettre de formaliser le discours sur un jeu. Dans mon cas, je fais principalement des jeux de plate-formes, donc mes mécaniques principales seront 'sauter' et 'courir'. je leur donne des tags dédiés. Je les note en Anglais et en majuscules (JUMP) quand je veux vraiment dire 'la mécanique du saut // le fait que le joueur pousse sur le bouton de saut pour faire sauter le personnage'.

I'm mostly building platformers here, so my primary mechanics are JUMP and RUN. I can modulate them with FLOAT. I don't quite have a shooting or fighting character, but it instead GRAB and THROW things.

As you have noted, I use all-caps when I want to obviously refer to gameplay actions (mechanics) within the text. I promise I won't shout too much.

Readme: KK: Mechanics & Abstractions (p.2)

Mario (t.a.g.)

Yep, I mean the mustachied one.

At first, I had in mind not to create a "Mario" tag (nor any tag for Nintendo or any third-party character). If a reader would have liked to read "all references to Mario" on this blog, the search feature is there.

However, with the time, it turned out that the Super Mario series is an inevitable reference point in the design of Bilou's adventure. So a Mario tag appeared nonetheless to collect all those comparisons.

Similar tags were then introduced for other key reference games such as Rayman, Sonic and Keen Commander or Fury of the Furries or even Rick Dangerous.

Other reference points are picked more occasionally, such as games from Titus Interactive, Kirby or WayForward (Shantae). For these, I'm afraid you'll still have to rely on the search feature of the online blog.

 

Oh; and if you're here because you followed the 'keen' tag and you're done reading all I had to say about that, consider paying Bobby Prince's blog a visit ;) He's the one who made the iconic soundtrack of Commander Keen games.

let's try (t.a.g.)

 You're done with the "gameplay experiments" (let's try) posts.

These posts present some game design that were not initially planned but reveal required to improve the game, usually after some "guest star" suggestion.

That's also the proof I dropped my "arguing" phase and admitted that "okay. Let's prototype it, try it and we'll see what it is really worth without all the should and the would and the could. When I have to explain it to someone else, I usually say "well, my natural reaction is to deny the issue so I force myself to ask what if Miyamoto / Michel Ancel had just said that?"

Comme disais Mollusk (PAlib): ne vous posez pas de question: codez (un proto).

inkjet (t.a.g.)

 Not the printers model, you fool. The character in the School Zone that can throw ink drops at you.

It is one of the original design for the school zone, with pendats, erasers, pencil sharpeners (redesigned as dumblador) and sponge (redesigned as spongebop)

C'est mes 4 mousquetaires de l'école en folie: crayons, gomme, encrier, taille-crayons. Ah oui, et l'éponge, aussi. Bon, bin on va dire "le club des 5". Ils ont reçus des p'tits noms au fur et à mesure que je les redesignaient (ou redessinaient), comme 'pendat' pour les crayons-soldats en 2001. "recto/verso" pour les gommes en 2004 (au pif). 'dumblador' pour le taille bête comme ses pieds et 'inkjet' pour l'encrier qui projette des gouttes. Et 'spongebop' pour l'éponge qui fait le pendule.

indie (t.a.g.)

You've reached the last post about indie games.

This was the collection of posts that relate to somebody else's creation of what I see as "grown up garage games", where games are made along the creator's own vision of what is fun without trying to stick to pre-established rules. That used to represent a large fraction of games produced back in the MS-DOS and C-64 era, and it looks nowadays as a kind of protected minority :P

I do not try to cover that extensively, as this is not the main purpose of this blog, but some of those games become inspiring or reference point for my own game/level/monster design experiments and thoughts.

I also draw a line between "indie" (which usually happens on systems with (freely?) available, official development kits) and "homebrew" (which uses some underground, community maintained development kits on platforms where this was not intended by vendors).

iGobController (t.a.g.)

This is the category of technical posts that discuss the introduction of separate classes to drive behaviour of characters in specific states.

The name "controller" comes from the initial idea that this part of the soft acts as virtual joysticks for the various objects. The "tracker" controller, for instance, would have "pressed right" if the hero is on the right of the tracking monster. Controllers arise from the desire to keep the game engine game-agnostic, and to provide a clear API line between reusable code and project-specific code, while keeping the interpretation cost low.

Further evolution of the game project suggested that behaviour needs one extra level of flexibility: some part of a behaviour (i.e. walking on sloped ground) is shared by several characters (heroes and baddies) while other part (i.e. reading DPAD) is ignored by most monsters, but shared by most (but not all) the states of the hero. This sub-division is referred to as "chained micro-controllers" in this blog.

homebrew (t.a.g.)

You've reached the last post in the "homebrew" thread.

These posts present essentially work done by *other* homebrewers -- that is, people who decide to build software as a hobby, usually with no profits-making plans (unlike most of indie developers) and on systems where you're not supposed - as a regular customer - to do so. That may be games I liked, libraries I used or simply projects I find exciting.

I'm doing homebrew too, but that's filed under the mybrew thread.

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 -->

game [t.a.g.]

Have you liked the posts related to games I practiced (in general) ?

Sure, there's a good deal of nostalgy in these posts, but also some more recent productions. I tend to have a preference for independent productions, mostly because I never really got convinced by 3D gameplay and love the charm of garage-style games which contain the sort of unexpected fantasy of my childhood.

Of course, I'm not running windows on my computer, but rather linux, and I don't devote a significant share of my budget to gaming (and globally try not to pirate softwares) so that sort of reduces the set of games I can experience, or significantly delay my observations compared to release dates.

*but* ... since 2019, I now own a Nintendo Switch, so I can get demos, run "recent" games, spend money on Mario and Zelda again, and hope for ports of the hits I missed in 201x

Form Fits Function [t.a.g.]

You've been reading all the posts that contain thoughts about the role of form-fits-function in gameplay studies.

I'm sure there are more aspects of monster design that will interest you.

Flickr (t.a.g)

It is one of those online free services I had joined, before it got swallowed by some internet giant. But since I was there, I started collecting pictures I was shooting of NDS development as well.

So this tag should be used whenever a picture shown in a blog post is actually backed by a more complete photo on flickr, just in case somebody might one day want to print this all and have sub-pixels details of a screenshot.

design [t.a.g.]

Level design is the first item I considered when starting to think about video games beyond a pure technical point. I use to think about it as the art of drawing interesting maps. If it looks cool on a sheet of paper, then it's great level design.

I started thinking about game design after I experienced new Super Mario Bros for the first time, and immediately compared it to SMB3. It captures the rules and the decisions that affect the whole game, especially how you manage game-over, save states, character abilities and whether they are progressively revealed, etc. If you can't alter it with e.g. RSD game-maker or an editor in any way, then it's likely game design.

Le premier élément de design auquel je me suis confronté, c'est le design des niveaux. Enfin, quand j'ai commencé à aller au-delà de l'aspect purement technique de la réalisation et à embrasser aussi la conception de jeu. Je définirais le level design comme "l'art de dessiner des cartes intéressantes". Si ça a l'air cool sur papier, c'est un bon level design.

Après, il m'a fallu faire la distinction entre gameplay et monster design. Certains niveaux -- chouettes au départ -- perdent toute leur saveur si on change le comportement des ennemis qu'ils hébergent. ça, c'est du 'monster design'. Mais le gameplay va au-delà des interactions avec les structures, le personnage et les ennemis. Le gameplay prend aussi en compte ce qui se passe entre les mouvements de l'utilisateur et les règles de bases du moteur de jeu. C'est la partie du jeu qui ne sait pas être représentée sur papier et pour laquelle l'expérience est indispensable: la partie que même une capture vidéo ne montre pas et qui mets en jeu notre dextérité, nos réflexes et notre sens du timing.

It took me time to realise the difference between gameplay and monster design. I had noted that some levels may be completely boring if you change the behaviour of the monsters that are in.

But gameplay goes beyond that interplay between static structures of the level, player's avatar and monsters. It really defines what goes between user input and game engine core rules. It's the part of the game that definitely *cannot* be depicted on paper and that *need* to be experienced. The part that Youtube cannot show you and that stress your dexterity, reflexes and timing.

dslinker [t.a.g.]

Running homebrew software on a Nintendo DS needs a little help ... a device called "a linker" that typically looks like a DS/GBA game, but that include a (micro)SD card reader. Finding, maintaining and using those device is sometimes a story of its own, as Captain N typically hunt corporates that manufacture them and puts pressure on governments to make those things illegal and pretend that people who sell them are evil criminals.

coding [t.a.g.]

How brave you are! Truly !

I mean ... You made it! You've been reading through the *whole* set of "coding"-related topics. They weren't just todo lists, but true stories about behind-the-scene hacks, fixes, eurekas and such that turn dreams into reality.

You definitely deserve

     *
      }( 1 ){
        \ /*
       o[ ]o
     ___  ___
    /   \/   \
    /  ^   ^ \
    /__ooOOoo_

The Ultimate Ascii aRt Trophy of Awesomeness!

Franchement, je suis impressionné! Lire tous les posts de la catégorie "coding", c'est du costaud. Si ça n'avait été que des toudou-listes, mais non. Les hésitations, les bidouilles en coulisses, les correctifs, les eurekas, les victoires. Bref, tous ces petits moments numérisés qui ont conduit à réaliser un rêve ...

NB: I guess you have noted that I use tag cxx for things about c++, since blogger doesn't seem reliable in whether it supports '+' in tag names or not.

choice (t.a.g.)

You've reached the last post about major project choices.

These posts sets the boundaries of what I do and what I let for others to do. Not all of them are technical choices, but when they are, they usually have a significant impact on what the project will support.

Il y a ce que je choisis et ce à quoi je renonce dans tout projet. Si je veux voir certaines choses aboutir, je dois en laisser d'autres aux autres. Ils ne sont pas tous des choix techniques mais quand c'est le cas, ils ont généralement un impact significatif sur ce que le projet deviendra...

c64 (t.a.g)

micro-ordinateur hors du commun ... celui sur lequel j'ai appris à programmé et celui sur lequel j'ai découvert les joies du jeu vidéo. Mon frangin nous a construit une ligne du temps de nos jeux vidéo, y compris (sur base des hit parades et autres journaux personnels) les jeux auxquels ont avait accès à l'époque de l'arrivée de C64 en 1984 ...

 

BASIC [t.a.g.]

Young me, showing off BASIC stuff

Yes, I mean Beginners' All-purpose Symbolic Instruction Code, which has been my sole programming language between '86 and '95 and which I've kept using until Y2K -- although more and more occasionally, as I getting more proficient in assembly.

The big issue with BASIC was that I was always trying to do things that are too big for it. Whether 'space mission' spaceship simulator and maze runs project on C64 or Calimero platformer with line-numbered programming language for a platformer ... And it wasn't much better for Bilou's Adventure which MS QuickBasic couldn't compile properly because it was using too much pictures (although it could be interpreted perfectly well :-/)

One thing was great, though: you could quickly start a new project. Something that stopped being true when I started working with C and makefiles, only to find it back with PERL.

artwork (t.a.g.)

There aren't much of them, I'm afraid. These were the posts featuring higher-quality drawings (i.e. not mere sketches), preferably properly scanned -- although good quality camera shots are accepted as well.

Amiga (t.a.g.)

 Uh ? Oh yeah. So I have a tag for Commodore Amiga stuffs despites

• never having used more than an Amiga joystick back then
  
• still not having an Amiga and not planning to hunt for one
• having used very little Amiga emulation because finding kickstart ROMs again is a pain.

Why so ? Because Amiga was the pinnacle of the crazindies era of game development in the 90's that bred titles from Alfred Chicken to Zool. Video games magazines that weren't PC-only were covered of screenshots of appealing games that were readily available on Amiga and might have a decent PC port in a hopefully not-so-distant future.

Because even 30 years later, I'm still amazed by the technology of the copper + blitter much more than I am by pixel shaders.

And because there was so much talented pixel artists in studios like the Bitmap Brothers!

Will there be Bilou on Amiga ? Well, with at most 32 colors plus extras, it isn't exactly the dream machine to do it. And there doesn't seem to be a wide amiga users base among Bilou followers either Bon, autant que vous le sachiez: l'Amiga (500) m'avait fait un gros effet à l'époque, et son approche hors du commun des graphisme continue à attirer mon attention. Cela étant, ça n'en fait pas la machine de rêve pour faire tourner un jeu Bilou, même si historiquement, ça avait sans doute fait partie du projet. Une chose est sûre: il y avait place pour un projet Clicker aussi sur Amiga et il est fort probable que si j'avais quitté le monde 8-bit par la porte Amiga plutôt que la porte 8086, je ferais partie de ces gens qui ajoutent régulièrement des modules à leur Amiga pour le maintenir à flot et écouter Nectarine avec.

adventure (t.a.g., Bilou's)

This is the last post in the (Bilou's) Adventure thread.

These posts presented you whatever is related to the "great project" of having a platformer game starring my blue ball Bilou (and possibly co-starring his sidekick Bouli) collecting the 7 magic stones and saving the world from some impending disaster. As you have guessed the storyline is still subject of major changes from times to times and the gameplay mechanics are still largely under study, but one piece at a time, it builds up.

The game will features different zone on the planet Bilou's cruiser is crashed, including (at least) green zone, school zone, desert zone, fire zone, ocean zone, castle zone and lost zone. I keep giving them generic names so far, to avoid setting excessively strong boundaries to creativity and imagination.

20 years anniversary (t.a.g)

Somewhere in 1993,  my brother would come back home with a sketch of a new Bilou level (there had been some since October) and a monsters design sheet with all the adversaries we could find in the School Zone.

My computer so far would only render black and white and produce beep sounds. Playing the school zone was some kind of un-achievable teenagers dream, just like performing (and winning) the Eurovision song contest had been some years earlier. 

En 1993, mon frangin me ramenait un croquis d'un premier niveau pour la "School Zone", accompagné des designs de monstres de son camarade de classe Piek pour notre futur jeu Bilou. Vu notre matériel de l'époque, la transposition en jeu vidéo relevait alors du fantasme d'adolescent.

20 ans plus tard, avec un premier moteur de jeu pour Nintendo DS et des graphismes qui commencent à ressembler à quelque-chose le rêve est à deux doigts de devenir réalité. Mettant de côté mes projets de mini-jeux, je m'attaque à une transposition aussi fidèle que possible de la map tracée par le frangin en vue d'en faire un niveau-démo destiné à fêter les 20 ans du personnages.

Nearly 20 years later in 2013, I have my game engine for Nintendo DS running simple games and fair quality school zone graphics. I have plans to use them in an arcade-like climb-as-high-as-you-can game, and I'll put them aside to convert my brother's vision into a one-level demo of that early level. Will I be on time to celebrate the 20th anniversary of Bilou as a character ?

{ Nintendo DS release date }

(too bad, they missed Mar 10 by so little)

US & Japan already had it since November-December 2004