The basic structure of the engine is described below. This includes how the engine handles its main game loop by executing the verbe from orders each frame.

The orders are one of the most important objects in the engine. Rather than having multiple nested game loops for the different areas of the game like the multi-platform engine this engine has a single global game loop which main purpose is to execute the orders, as long as the game is not paused. The orders are stored in a linked list where each order contains a pointer to the previous and next item.

An order mainly consists of a verbe, parameters and display object.

A verbe is a value describing what the order should do each frame. The value is used as an index in an array of functions and is what gets called each frame. The parameters in the order are stored as 16 16-bit values, but can be used differently depending on the verbe. Each verbe expects different parameters, ranging from pointers to different types of object data or functions and values describing its current state.

The following list of verbes comes from the earliest prototype:

03: v_plateforme1
06: v_anim_joystick
07: v_recaloum
10: v_deplace
15: v_movespr
17: v_follow_scroll
18: v_event
19: v_bande_x
20: v_main_scroll
21: v_sub_scroll
25: v_basic
26: v_generateur
29: v_anim_simple
30: v_anim_custom
31: v_anim_bboss
34: v_recul
35: v_clignote
36: v_board
50: v_plateforme2
51: v_main_scroll

A display is an object containing a sprite or other type of graphics to be rendered to the screen. It also keeps track of some of its properties, such as position, collisions, display priority and more.

When a level is loaded by the game it gets created using commands in a “make-level loop”. In the later prototype and final game this was expanded to be used for loading worlds and the fixed data as well.

Each command consists of the type of command as well as its parameters. The purpose of most commands is to transfer data from the ROM to the RAM. If the data is compressed, which is usually the case for graphics, the unzip command is used. There is a specific command for loading maps which has parameters for the tile and event maps.

Each level in the game consists of an event map. This map describes which events should trigger at what points in the level. Although this system appears to allow for different types of events it is only ever used to spawn in different types of multi-sprite objects.

A multi-sprite is a class of objects primarily triggered by events and used in the game's levels for things like enemies and platforms. There are different types of these with some being referred to as mega-sprite objects if they have additional data defined. Other multi-sprites are used for things like displaying the game's backgrounds. If so they are not triggered by events but rather created by an order or from the level creation commands.

These objects all commonly contain a value describing the number of displays it uses (this value may be 0 if the game dynamically handles this itself), an optional pointer to character data and a verbe. It also contains the parameters to be used for the verbe. When this is loaded, known as being inserted, an order gets created for it to ensure its verbe gets executed each frame.

The character object is used by multi-sprites to define common properties such as colliders, hit-points and display priority. Its usage sometimes differs depending on the verbe.

Many of the multi-sprite objects have verbes which allow transitioning between different states. In the multi-platform engine this is handled based on two values, the Etat and SubEtat. In this engine however it is handled differently depending on the verbe. Some verbes have the object define an array of possible states it indexes while others transition between them through pointers linking them together.

Like the multi-platform engine states are heavily connected to the animation the object should play. Usually it will have a pointer to the animation data and define properties for how it is to be played, for example its speed and if it should be flipped. A state can also spawn in other objects through its insertion value. This is an index in a table of spawnable objects. Unlike the multi-platform engine, which had to pre-load these objects as always objects, this engine allows objects to be dynamically added and removed due to its way of storing everything in orders.

Graphics are stored in Atari Jaguar Object structs. For the sprites these are always bitmap graphics which either use the 4 och 8 bpp mode.