ObjectDefinitionRegistry

The one table of what every moving object type is, how it is drawn and which shared rules apply to it.

Location

Purpose

A world's moving objects (lifts, enemies, treasure, eggs, keys, exits, effects, the enemy Blupis...) are identified by a Def::ObjectType number from 0 to 203, the same numbers as the original game's world files. ObjectDefinitionRegistry holds one ObjectDefinition per type: how it renders, which texture sheet its sprite comes from, whether a world may place it, what kind of thing it is, and a set of declarative capability flags such as "touching it kills" or "dynamite destroys it".

It is one of the project's two single sources of truth (the other is BlockDefinitionRegistry for blocks). Rendering, the world loader, InteractionSystem and the editor read their per-type facts from here instead of keeping their own lists of type numbers. GetObjIcon in ObjectIcons.cpp supplies the animation frame (sprite icon) for a type at a given animation phase.

Collaborators

Uses

• Def::ObjectType (include/GalaxyEggbert/Def/ObjectType.hpp): the type numbers, which must never be renumbered.
• ResolveObjectIconFrame (ObjectIcons.cpp): the frame tables taken from the original's animation data.

Used by

• WorldRuntime: skips records whose type is unsupported or Null, reads mobileWorldSupported and patrolMotion while importing objects.
• InteractionSystem: lifts, enemy contact, pickups, dynamite, exits and the compass target all test capability flags.
• src/GalaxyEggbertCNA/GalaxyEggbertGameScene.cpp: calls ResolveObjectVisual for every object when it builds the frame for WorldRenderer.
• The editor: EditorPalette.cpp, ObjectPlacement.hpp (one exit per world, via levelExit), ObjectPathMarkers.hpp (route cubes from the patrol fields), WorldEditorUpdate.cpp.

ObjectDefinition fields

Every field of struct ObjectDefinition, with the types the table in ObjectDefinitionRegistry.cpp sets (as of 2026-11-10). Types not listed keep the default.

Key members

A selection of the public API of ObjectDefinitionRegistry.hpp and ObjectIcons.hpp (types in signatures shortened: ObjectType is GalaxyEggbert::Def::ObjectType).

ResolvedObjectVisual carries definition, renderMode, textureSource, icon and visible. Resolve takes the icon from the frame tables, unless a per-object visualIconOverride (a tile look, for example a lift's) is given: then the icon is that tile and the sheet is object-m.png. For the phase-dependent arc (38) the sheet is blupi1.png for the first 30 ticks of its 90-tick cycle and element.png after. An object is visible when its render mode is not Hidden and its icon is not negative. Older predicates such as IsUniformCubeObject and IsExploPngSourced remain as registry-backed compatibility accessors; new code uses ResolveObjectVisual.

How it is used

Gameplay code asks a capability question instead of comparing type numbers. The dynamite blast in src/GalaxyEggbert/Game/InteractionSystem.cpp:

for (auto& victim : objects)
{
    if (!victim.active || &victim == &obj)
    {
        continue;
    }
    if (!GetObjectDefinition(victim.type).dynamiteDestructible)
    {
        continue;
    }
    ...

The scene builder in src/GalaxyEggbertCNA/GalaxyEggbertGameScene.cpp resolves each object's look once per frame and draws lifts and crates as textured cubes:

const auto visual = ResolveObjectVisual(obj.type, static_cast<int>(obj.phase), obj.visualIcon);
if (!obj.active || !visual.visible || visual.renderMode != ObjectRenderMode::SolidCube)
{
    continue;
}
...
const auto tileUv = tileAtlas_.GetTileUv(visual.icon);

Whether a billboard icon is replaced by a 3D model pose is decided separately, by ObjectModelTable from avatars3d/objects/<name>/icons.txt; the registry only names the icon.

Rules and invariants

• Single source of truth. A new object behaviour or a changed classification goes into this table first; consumers follow. Do not add parallel lists of type numbers elsewhere.
• The capability flags are deliberately not a general behaviour-dispatch table. Each one replaces an exact membership test whose members are treated identically at the call site; distinct state machines (a bulldozer, a fish) stay in code.
• Type ids are the original's and are stored in world files: never renumber them.
• The registry is engine-independent and immutable after construction.
• The patrol timing table is mirrored by CREATURE_TIMING in tools/worldkit.py; change both together, then run tools/audit/patrol_envelope.py.

Tests

VerifyInteractionSystem, VerifyShippedWorlds and VerifyGEEditorObjects exercise the table indirectly through its consumers.

Related pages

• BlockDefinitionRegistry: the matching table for blocks
• MoveObjectRecord: how an object is stored in a world file
• WorldRuntime, InteractionSystem, WorldRenderer
• Tutorial: changing a block or object behaviour
• Object lifecycle
• Testing