samedi, décembre 31, 2005

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.

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

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), 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 :)

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

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.

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.

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.

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.

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

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.

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.

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.

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
     ___  ___
    /   \/   \
    /  ^   ^ \
The Ultimate Ascii aRt Trophy of Awesomeness!

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.

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.