Target Definition Authoring

Definition Role

The target definition is the main design asset for Interaction Framework. It answers three questions: where can the player interact, what commands are available there, and what happens when those commands execute. Runtime components consume the definition and handle registration, focus, activation, and presentation.

Starter Authoring Flow

Use the editor-provided starter rows when they exist. If a definition has no points, use Add Point; the action creates a normal point with one default variant and one default command row. The first pass is usually editing that point id, command id, input action, proximity, and prompt behavior rather than adding new rows.

Editor Layout

The asset editor is split around the same content model. The left Points list selects the authored point and shows Point Details below it. The center Variants list selects the active variant and shows the Command Surface for that variant. The right inspector shows Variant Details above Command Details. Use the Authoring tab while editing content, Debug when inspecting runtime state, and Validate before using the definition in play.

Point Authoring

Each point represents an authored interaction affordance. Configure the point id, point kind, point-of-interest behavior, proximity ranges, projection settings, and variant list. A point can be normal, linked-group based, or composite depending on how it should participate in a resolved surface.

Variants

The center Variants list shows each authored state for the selected point or linked group, including badges such as Default or Linked and inline requirement chips when present. Variants are point states. A single default variant can remain unnamed. When a point has multiple variants, assign unique variant ids so runtime overrides, automatic selection, composite surfaces, and validation can distinguish them. Variants can carry command rows, requirements, prompt payloads, policy profile overrides, projection overrides, proximity overrides, and transition delays.

Command Rows

The Command Surface shows the command rows for the selected variant. Selecting a row opens Command Details on the right, including the Solo/Co-op mode control, input action, prompt provider, requirements, execution, and Multi Participant settings when Co-op is selected. Command rows define prompt entries. A command row can be a real command or a More marker used for paging. Real commands need valid command ids. Interactive commands need input actions. More markers need next and back input actions. Hold and multi-tap patterns need positive timing/count settings.

Requirements

Requirement entries can be attached to points, variants, and commands. Entries support operands, expression indentation, inversion, UI failure policy, and prompt text providers. Use requirements to block availability, choose variants, and explain why a command is unavailable.

Execution Actions

Execution actions are instanced objects that react to command lifecycle outcomes. They can run when a command starts, completes, cancels, or fails, and they can scope behavior to the initiator, target, participants, or configured participant group depending on the action.

Prompt Text And Widget Payloads

Prompt providers produce the user-facing text and parts for a command. Widget payloads let a target or variant push widget class overrides and payload data into the UI. Use prompt providers for text behavior and widget payloads for visual or data payload behavior.

Policy Profiles And Theme Colors

Policy profiles let definitions reuse interaction behavior settings. Theme color specs and refs give UI widgets named colors for prompt presentation, editor previews, and project-specific visual language. New definitions normalize a default theme color so points, variants, and commands can reference a stable color name.

Recommended Authoring Order

1. Edit the starter point and confirm focus with one command.
2. Assign the point id, command id, and input action before adding more rows.
3. Add point bindings on the target actor if the point needs a specific transform.
4. Add variants only when the point has real gameplay states; assign variant ids once there is more than one variant.
5. Add requirements and unavailable text after the happy path works.
6. Add execution actions that change target state.
7. Add widget payloads, projection overrides, and theme colors when the UI needs richer presentation.
8. Add linked groups, composite groups, paging, or multi-participant routes only when the simpler structure cannot express the design.

Authoring Pass Order

1. Start with the editor-created point, variant, and command row when present.
2. Stabilize ids first: FInteractionRuntimePointId, FInteractionRuntimeVariantId, FInteractionRuntimeCommandId, target save ids, and owner save ids.
3. Configure point proximity and point-of-interest behavior before tuning focus scoring.
4. Keep one unnamed default variant until the point needs multiple runtime presentations.
5. Add command requirements before execution actions so blocked commands fail before changing state.
6. Add widget payloads and theme colors after prompt entries are working.

Validation Mindset

Most target-definition mistakes come from unstable ids, duplicated default rows, missing command input actions, multiple variants without unique ids, or execution actions placed on commands that should only display prompt text. Use Validation Reference and Troubleshooting when an authored row looks correct but does not show at runtime.

Complete Authoring Pass

A complete target definition pass moves from identity, to geometry, to presentation, to validation, to effects. Work in that order so each layer has a stable base.

1. Stabilize ids: point ids, command ids, variant ids when needed, linked group ids, composite ids, target save ids, and owner save ids.
2. Configure point kind, point bindings, proximity, focus priority, projection overrides, and point-of-interest behavior.
3. Keep one default variant unnamed until the point needs multiple states. Add variant ids only when multiple variants exist.
4. Author command rows with row kind, activation mode, input pattern, input action, More/Back marker input, prompt provider, requirements, execution actions, theme color, and multi-participant settings.
5. Add policy profile overrides only where the default profile does not match the point, variant, group, or command.
6. Add widget payloads and theme colors after the command surface appears correctly.
7. Run validation and fix ids, missing inputs, composite shape mismatches, variant ids, and command row issues before testing runtime behavior.

Authoring Boundaries

Target definitions are content. They should describe what can happen and how it should be presented. Target components and interactor components decide what is happening right now. Execution actions change state after activation. Requirements block or allow commands. Widgets display projected state. Keeping those responsibilities separate makes definitions easier to reuse and debug.