Welcome to the Tagtionary

Over the years, this blog has grown and explored many directions: level design, implementation, pixel art, ... I won't claim it covers all you could ever wonder about game development, because I'm focusing on games that catch my attention and that leaves away entire genres.

At some point it became necessary to create a "dictionary of tags" and that became the tagtionary. Feel free to use it to see what is to explore. You're at the entrance gates of some ancient city. It isn't quite abandoned yet.

What will you read next ? 

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.

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), only some are hosted on flickr (and only small size is on the blog) 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 :)

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.

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.