Skip to main content
Possession is the design for a person, agent, or system to request a controlled change to a game session. The acting participant, its authority, the target session, and the permitted action all matter. The same action can require different permissions depending on who requests it and which game or session is involved. This page describes the game-specific control mappings and proposed interaction flow.

​
Playing and Possessing

Ordinary gameplay uses a game’s player controls. Possession uses a separate interface to change state such as lives, difficulty, or an on-screen message. That distinction affects how an experience is run. A mode that allows an operator to change game state needs to explain which interventions are permitted and how they relate to scoring or competition.

​
Sector 13 (sector-13)

A space game with multiple sectors, enemies, and power-ups.

​
Control mapping

The documented Sector 13 design names alice-sdk.js as the game-control integration.

​
State model

The documented state.ts model includes:
  • lives: remaining lives, with a documented default of 3.
  • score: the current score.
  • powerups: the active weapons and power-ups.
  • rofAdjust: the rate-of-fire adjustment.
  • fear: a level used to affect visuals and audio.
These mappings describe the game-control design. They do not establish that a public possession interface is available.

​
Ninja vs EVILCORP (ninja)

Ninja vs EVILCORP is a stealth platformer.

​
Planned controls

  • set_difficulty: select NORMAL, EASY, SUPER EASY, or NIGHTMARE.
  • set_level: move the player to a particular level.
  • show_message: display text on the canvas.
These are planned integration capabilities.

​
Possession Flow

The proposed flow has four steps:
  1. Identify the target: find the intended game and session.
  2. Select a permitted action: choose a control supported by that game and allowed for the acting participant.
  3. Request the change: associate the target, capability, and requested value with the participant’s authority.
  4. Observe and record: inspect the result and retain a record of what changed.
A game identifier and a requested capability alone do not establish authority to change that session.