The ZKM Base Classes

This is a set of classes, built to work with the Brick Engine, that provide enough functionality to make game-writing as close to a minimal-effort process as possible.

These classes were originally developed for the v5 update of the Brick Engine game, ZKM, and have since been expanded and made more generally useful. They are available for incr Tcl, and it's my hope that they will be ported to other languages.

• Cutscene - a simple class that displays a static cut scene
• Item - a class to create in-game objects and let them interact (always subclassed)
• Level - a level class that manages items, player controls, and camera movement within the game loop (always subclassed)
• Load - a wrapper class for asset-loading functionality
• Map - a map-loader
• Menu - a simple menu class
• Overlay - an on-screen heads-up display
• Runner - the overall game loop class that manages transitions between levels

A game is made of up levels. Levels may or may not be sequential.

All items have a class (defined separately from their class name) and a type. The class can be used to filter out classes of items from collision detections, and the type can be used for specific item identification.

All items have six callbacks, of which any may be no-ops:

• action (called once per frame)
• collision (called when an item has hit another item, to determine what the resulting action shall be)
• activate (called when another item activates the given item, e.g. the player shoots a gun)
• deactivate
• refill
• reposition

Items (player, enemies, bullets, etc) that can be affected by other items are responsible for their own collision detection, either manually or by using the provided interact method.

When an object is checking collisions with other objects, it first retrieves the name of the collision method for the other object. If one is set, the object calls that and reads the result. The result is a two-element list. The first element is the type of action, and the second is the specific value:

• hit x (the collision causes x damage)
• inventory y (the object receives a new object y, usually the collided object)
• exit z (exits this playfield, goes to z)
• method w (call method W on the sprite, passing in the collision-detection result)

The built-in item interact method provides a convenient wrapper to this code, so that all you need to do is pass in a block of code to handle each of these possible results.

Objects which are “consumable” have a refill method. Whenever a new item is collected, every object with a refill method has that method called, and passed to it every object in the inventory. The consumable can, at that point, adjust any object's properties.

This allows for situations such as: you have a gun, and you pick up ammunition for it. The ammunition object adds its quantity to the gun's property and deletes itself. Alternately, you don't have a gun but you pick up the ammunition for it. The ammunition does nothing until you pick up the gun. When you pick up the gun, the ammunition's “refill” method is called and it adds its quantity to the gun's property.

I will soon post examples taken straight from ZKM.