Data Structures and Data Tables

Use a Data Structure to declare typed fields for Object state. Use a Data Table to organize reusable rows of content or configuration.

For a game with several enemies, the enemies can share a Health schema while keeping independent current health. An item catalogue, by comparison, needs reusable rows such as name, price, and description. Choose the data system according to the job.

Object State with a Data Structure

Define fields such as current, maximum, and invulnerable in a Health Data Structure. Add a Data Structure component to the Object and give its slot a useful name, such as health.

The Object supplies defaults or supported overrides for its values. Each live instance has its own state. Read self.health.current in compatible Logic and update it with Change Component Value.

Use a structural Object contract when a reusable Function needs access to that exact named Data Structure slot and schema. This makes missing fields visible during authoring instead of assuming every Object carries them.

Build and Inspect a Health Component

For a target with three health points, configure the schema, component slot, and access contract as follows:

1. Create a Data Structure resource named Health.
2. Add a Number field named current with an authored Value of 3.
3. Add Health as a Data Structure component on the Target Object.
4. Rename that component instance to health.
5. Declare a structural Object requirement for the health slot and Health schema in Logic that uses the field.

These names serve different purposes. Health is the resource and schema. The component instance name health is the access path on the Object. The field current belongs to that schema. Together, self.health.current identifies this live Object’s field.

When a Function receives the Object through a victim Parameter, the same field is addressed as victim.health.current. Selecting a different compatible victim changes which instance is read; it does not change the schema.

Verify That State Belongs to the Instance

Place three copies of Target. Damage the first once, then damage the second once. Each should go from three to two. If the second starts at one, inspect whether the first hit changed a Project Global or resolved the wrong live target.

Start a fresh run to restore authored defaults. Changing a value during play changes runtime state; it does not make that value the default for every future instance.

Use explicit fields when other Logic needs to inspect state. A damage Function can update current, a visual Logic can select a hurt appearance, and a HUD can display the health of its selected player. Each dependency should name the Object and component contract it needs.

Content with a Data Table

A Data Table can hold rows for items, dialogue-related content, or other configuration. Use the table Actions to select or query rows, then consume their typed results.

Resource names in a table can select project Things when a receiving field supports that kind. Check the selected resource’s existence and type; writing a name does not guarantee that a matching resource exists.

Design Rows Around Stable Game Concepts

A small shop catalogue could contain an item identifier, a Text label, a Number price, and a supported Thing reference for the item’s presentation. Keep identifiers stable when player inventory or saved progress refers to them. Changing display text should not accidentally create a different item identity.

Use the Data Table Actions for the required operation. Inspect each Action’s input fields and produced result before wiring its consumers: selecting a row, reading a cell, and changing a cell have different contracts. A result is available where that producing Action’s flow permits it; persist needed values in explicit state for later Events.

Begin with two rows and one successful lookup. Test a missing row before adding a large catalogue. Decide whether a missing item should show a fallback, stop the purchase, or produce a diagnostic, and implement that decision in the caller.

Decide Which System Owns a Change

Keep a player’s current health on the player instance. Keep an item’s base description in reusable content. Keep a project-wide score in a declared Project Global when all relevant Logic needs it.

If several Logic Components must coordinate, give them explicit access to shared Object fields. Private Local Variables remain local to their attachments.

Value	Suitable owner	Reason
One enemy’s current health	Its Health component	Changes independently for each live enemy
One Function’s temporary damage calculation	That Function’s Local Variable	Needed only during that invocation
An item’s base description and price	Reusable table content	Many callers need the same definition
The round’s defeated-target count	A declared Project Global	Shared by target Logic and the round display

Avoid storing the same authoritative value in several places. If the HUD displays a copy of an Object field, define when that sample updates; do not let unrelated Logic treat the display copy as a second health source.

Repair Missing Field Access

Check the resource schema first, then the receiving Object’s named component, then the Logic contract. A Health resource existing in the project does not mean that every Object has a health component. A component using a different schema can also fail the requirement even when it contains a similarly named field.

Read Object contracts and variables and shared state when deciding which callers should have access.