Skip to main content

Activities, Policies, and Queue

This page owns Valenar's runnable-work vocabulary and the queue model that turns intent into executed play.

The live executable terms on this page are activity and policy. Higher-level planning can group likely activities above executable work, but it does not replace activity or policy vocabulary.

Canonical wording here defers to ../gd-canon.md and ../gd-glossary.md. Character skill and assignment context live in gd-character-skills.md, gd-characters-and-retinue.md, and ../ux/gd-character-screen.md.

Core Terms​

  • An activity is runnable work and the atomic executable unit the queue runs.
  • A technique is a learned method a character can bring into player-facing missions, assignments, or higher-level planning; it is not itself the queue row and it does not replace activity or policy.
  • Higher-level planning can group likely activities for a mission or repeatable routine. It is contextual guidance above the queue, not a SECS keyword, and it does not replace activity or policy.
  • A policy is a chooser that picks among activities.
  • A queue is the concrete ordered list of work the current actor is committed to next.
  • Objectives, clues, missions, and higher-level planning explain why and how the player is doing something; the queue explains what is executing now.
  • Legacy shorthand should be rewritten to activity rather than treated as a second behavior noun.

Current Shape​

The current prototype is centered on the MC's queue.

  • The player inspects Territory facts, camp state, inventory, and nearby leads.
  • The player queues activities such as scouting, gathering, resting, crafting, building, or site interaction.
  • Early play is dominated by short atomic activities rather than large bundled plans.
  • Later repeated patterns can surface as reusable plans without changing the atomic activity execution model.
  • The server owns execution and returns read models that the client renders.
  • Higher-level planning surfaces such as ../ux/gd-current-plan.md sit above the raw queue instead of replacing it.

An overnight camp routine is the clearest example of the distinction. The player may think of "make camp for the night" as one composed plan, but the queue still executes atomic activities such as preparing shelter, setting a watch, treating immediate needs, resting, and breaking camp.

Where Skills Enter​

  • Players do not queue raw skills. They act through techniques, missions, assignments, and planning surfaces, and the executable layer still resolves as activities and policies.
  • Skills matter here because they feed resolved channels through modifiers and formulas, unlock or stabilize techniques, and change the risk, speed, quality, safety, power, or control of the activities that actually run.
  • Queue-facing readouts can therefore surface resolved values such as MoveSpeed, CraftQuality, SpellStability, Accuracy or Dodge ratings, ManaEfficiency, or FireControl rather than pretending the player queued a raw skill.
  • Higher-level plans can package likely techniques and activity sequences, but they are still planning constructs above the queue rather than a second executable layer.

Technique Typed-Arg Pattern​

A Technique is a vocabulary token describing a learned method. It is not a queue row, not a SECS keyword, and not a runtime entity. Technique is not declared as a SECS scope and is not declared as a SECS template.

When an activity is parameterized to call for a technique, it takes a TechniqueRef typed arg. The activity dispatches the technique outcome through on_action hooks and channel resolution, not through a separate runtime noun. The character's known techniques are derived from skill level and surface on the Character screen as read-only information; they are character data, not queue rows.

Skills feed channels that bias technique outcomes. A character with higher Fieldcraft, for example, gets better results from a Sure Fire technique dispatch because Fieldcraft channels (e.g., FireEndurance, ShelterStability) are modified by skill level. The technique typed-arg lets a single generic activity (e.g., a generic camp setup activity) resolve different outcomes based on which technique was selected and which skills the assigned actor brings.

This pattern keeps the activity surface generic-mechanic — content rows do not get their own per-row activity identifiers — and pushes content differentiation into typed arg data and skill-fed channel resolution. See ../../../../docs/design/behavior-vocabulary.md for the generic-mechanic vs. content-row discipline this dispatch pattern satisfies.

Design Rules​

  • The queue must stay readable at a glance.
  • Activities must remain grounded in real world state, items, sites, travel, or actor condition.
  • Higher-level plans should explain a composed approach, not replace the activity rows the player still needs to inspect and reorder.
  • Policies should only appear where the game is genuinely choosing among valid activities on the player's behalf.
  • The queue is not the same thing as the objective layer. Objectives explain the campaign context; queued activities execute a slice of it.
  • Old shorthand in file names should be treated as legacy wording for activity rather than as a competing behavior noun.

Scale Across The Acts​

  • Act 0 and Act 1 are mostly MC-queue driven and activity-heavy.
  • Act 2 and Act 3 add settlement-facing work that competes with expedition work.
  • Later acts rely more on higher-level planning, policies, delegated actors, and realm-scale coordination, but the queue still matters anywhere the player needs concrete execution detail.