Skip to content
THE DEVELOPMENT WIKIPROJECT I SPACE FANTASY · CO-OP FPS · ROGUELIKE

Run, checkpoint and travel flow

The host owns run phases and shared progression. Clients request actions and present the accepted state. Current source order is menu/lobby → active stage → collection → reward selection → countdown/loading → next active stage.

Before the run

Players choose two weapons and a seven-slot classless ability loadout. The main menu exposes weapon selection, ability selection, editable guided builds, local settings, hosting and code-based joining. In the private lobby, readiness and host-accepted builds determine starting availability; starting locks new admission and run loadout changes.

Menu drafts, applied local preferences and host-accepted loadouts are different states. A visible draft does not bypass host validation.

Active combat

The encounter director owns admissions and boss entry after the kill objective; survivors remain. Normal production enemies remain passive, while separate opt-in fixtures implement credit-funded arrivals and boss reinforcements and an active shooter/search foundation. For example, clearing a purchased group earns space without an immediate credit refund/refill. Run cores can be collected during Active and Collection. The host owns kills, damage, rewards, participants and stage identities.

If no living participants remain, final defeat wins the active-tick outcome. The run snapshots results and performs cleanup rather than opening a successful checkpoint.

Checkpoint, rewards and travel

  1. Boss clear increments completed stages and enters Collection. Living adds clear without extra kill/loot credit, and checkpoint recovery applies.
  2. Players can walk and collect placed cores. Combat stays blocked.
  3. Every remaining participant must be alive and provide fresh accepted outside→inside portal position evidence. Already being inside is insufficient; leaving invalidates readiness until a new entry.
  4. Once everyone is portal-ready, collection seals and Selection begins. Uncollected placed cores are forfeited.
  5. Each participant resolves pending reward choices. The category/core system validates eligible choices and records awards under run/stage/reward identities.
  6. With no pending choices, a three-second TravelCountdown begins, followed by Loading and the next Active stage.

This order supersedes older descriptions of one entrant transporting everyone after choices. Disconnect removal updates the participant requirement; clients cannot manufacture portal proof with a UI click.

Stage sequence and final results

The current authored sequence is VerdantRelay → PrototypeStageTwo → PrototypeArena → PrototypeStageTwo. Later indices clamp to the final scene. A finished four-stage victory condition is not established by these four entries.

Final defeat caches kills, damage, upgrades, stages and player/run telemetry before clearing temporary state and returning to the menu. Host loss uses session recovery to return peers to menu; no host migration is assumed.

Source: run rules, run director, menu controller, scene sequence.