Builder Guide

Wielders and the Summons Menu

Decide who may call each summon, let players manage assignments in-game, and rename the technique to fit your lore.

3 min read Summons summons wielders party vocabulary

Who gets to summon is a design decision, not a technical one — and different games answer it differently. Everyone calls anything. Only the chosen one summons. Each spirit binds to a single bearer at a time. Ichiloto supports all of these through a small policy block, and stays out of your way when you want none of them.

Open by default

A summon with no wielder rules is open: every party member can use it, no assignment needed. If that is your game, you are already done — this page is for when you want more structure.

The wielders block

Add a wielders block to a summon's data file to restrict it:

'wielders' => [
  'mode' => 'characters',       // 'all' | 'roles' | 'characters'
  'characters' => ['Luna'],     // used when mode = characters
  'roles' => ['Summoner'],      // used when mode = roles
  'tenancy' => 'exclusive',     // 'shared' | 'exclusive'
],

Eligibility (mode) answers who may hold it:

  • all — any party member.
  • roles — only characters whose role name is listed. Build a Summoner class and gate the big spirits behind it.
  • characters — only the named characters. This is the FFX pattern: in a game where only Yuna summons, every summon names her.

Tenancy answers how many may hold it at once:

  • shared — any number of eligible members.
  • exclusive — one bearer at a time. The spirit must be released before another member can take it, which makes assignment itself a strategic choice before a tough fight.

Declaring wielders makes the summon assignment-based: a character must satisfy the rules and currently hold the summon for it to appear in their battle menu.

Granting and assigning

Seed starting assignments in actor data:

// assets/Data/Actors/Luna.php
'data' => [
  'name' => 'Luna',
  // ...
  'summons' => ['ifrit'],
],

Or assign from your game's own scripting — the party enforces eligibility and tenancy for you:

$definition = new SummonCutsceneLibrary()->findById('ifrit');

$party->assignSummon($definition, $character);      // true when the rules allow it
$party->unassignSummon('ifrit', $character);
$party->getSummonHolders('ifrit');                  // Character[]
$party->canAssignSummon($definition, $character);

Assignments serialize with the character, so they survive saving and loading without any extra work.

The in-game Summons menu

Any project with at least one summon gets a summon screen in the in-game main menu. It is the player's codex and management surface in one: pick a character, and every summon appears with its move name, its wielder rules, and a status:

  • [Open to all] — no policy; the whole party can call it.
  • [Assigned] — held by this character; confirm releases it.
  • [Available] — eligible; confirm assigns it.
  • [Held by <name>] — an exclusive summon bound to another member.
  • [Not eligible] — the character fails the summon's role or name rules.

Tab cycles through party members, and pressing confirm opens the summon's codex entry — its lore, move, element, attributes, strengths, and weaknesses, alongside the wielder rule and the current character's standing. Inside the entry, confirm assigns or releases policy summons; cancel returns to the list.

The info panel explains each summon's rules in plain language, so the player always understands why something is or isn't available — and the screen stays present even in all-open games, because reading about your summons is part of owning them.

Renaming the technique

"Summon" is your game's word, not the engine's. Rename it game-wide, or per character role — for lore where one tribe summons while another petitions:

// config.php
'vocab' => [
  'command' => [
    'summon' => 'Summon',            // game-wide label
    'summon_by_role' => [            // per-role overrides
      'Oracle' => 'Petition',
      'Vanguard' => 'Request',
    ],
  ],
],

A character whose role has an override sees that word in their own battle menu; everyone else sees the game-wide label. Every renamed label routes exactly like the original — submenus, help text, empty-state messages, and the menu screen's title all follow the vocabulary automatically.

Between the policy block, the vocabulary, and the menu, the machinery disappears into your fiction: the player never sees a "summon system" — they see that Luna alone hears the spirits, and that her tribe calls it a petition.