IDApTIK

If you have to ask, you're already compromised.

Invisible Door: Action Point Trauma Inc. Kickers

An asymmetric two-player infiltration game. One of you goes in. The other keeps you alive from a screen. Neither of you is fully in control, and that is the point.

---

What this is

IDApTIK is a game about infiltration, deception, and trust, usually misplaced.

One player is the infiltrator: moving through the world, dodging obstacles, bypassing security, staying unseen. The other is the hacker: watching remotely, opening doors, timing elevators, rewiring electronics, cutting the lights, and generally trying to keep the infiltrator breathing.

Control is not shared. It is asymmetric. The infiltrator moves; the hacker watches. If they do not work together, someone gets caught. The recurring problem is that the hacker's competence and the infiltrator's survival are loosely correlated at best.

"Breaking in is easy. Getting back out is harder. Especially when your escape route depends on a hacker who swears he knows what he's doing, right up until he accidentally reboots the entire security grid."

How it plays

Underneath the platforming sits a grounded network simulation, so the hacker is solving a real, legible network rather than pressing a "hack" button.

• Grounded access. The hacker starts from a specific device and sees only what is reachable from where they are.
• Real topology. Star networks, subnets, zones (LAN / VLAN / External), routing, DNS resolution, traceroute hop paths.
• Movement through the network. SSH between devices, session chaining, and pivoting so you attack from a compromised machine's perspective.
• Pressure. Active trace timers during intrusions, action-based alerts (failed logins, port scans), and passive logging for post-incident investigation. Bounce through intermediate machines to slow the trace.
• The physical layer bites back. Power grids, signal strength, cut cables, and physical location all affect what the hacker can do, and the infiltrator can open doors the hacker cannot reach remotely.

The two roles share one world. The hacker has a physical presence and real discovery risk; this is not a disembodied support role.

Roadmap

Development runs in vehicle-named phases, smallest viable thing first:

Envelope → Wheel → Skateboard → Bicycle → Chassis → Motorcycle → Computer Game

• Envelope (v0.1) — minimum viable game: core movement, basic hacker interactions (doors, elevators, overrides), first art, documented mechanics.
• Wheel — refined movement and interaction; stealth responsiveness; expanded hacker capabilities (security loop manipulation, timed overrides, sabotage).
• Skateboard — deeper asymmetric multiplayer; multi-phase infiltration; infiltrator/hacker communication.
• Bicycle — strategic depth; AI countermeasures that react to interference.
• Chassis — richer environmental mechanics (terrain, sound sensitivity, misdirection); first non-linear missions.
• Motorcycle — the full experience: adaptive security AI, emergent tension, the complete multiplayer framework.
• Computer Game — beyond proof of concept.

Tech

The Rust era's stack is being pinned as decisions are made, and each decision is recorded as an ADR under docs/adr/ rather than asserted here and quietly contradicted later.

• Gameplay truth: Rust/Crusoe — an engine-agnostic core, with Bevy as the selected graphical frontend over it (ADR-0008).
• Multiplayer / session: Elixir/OTP — Bandit + Phoenix Channels, not LiveView (ADR-0002).
• FFI / ABI policy: Zig unified hexadeca APIs/FFIs for the adapter and Idris2 for ABI contracts. The current implementation still exports its C ABI directly from Rust/Crusoe and contains neither Zig nor Idris2 source; remediation is tracked in #103 (ADR-0001).
• Config: Nickel (typed configuration).
• Toolchains: pinned in mise.toml + rust-toolchain.toml; just runs tasks. Provision with just setup (or just bootstrap for a fast, prebuilt-only bring-up), and check with just doctor.

Still open: persistence/versioning and the long-term Rust↔Elixir wire encoding.

Run ./launcher.sh for the player-facing menu: choose solo or multiplayer, then choose the Infiltrator or Hacker seat for multiplayer. Both paths launch the Bevy GUI. It is the sole player-facing entry point; relay and seat-process machinery lives under scripts/ as a guarded internal component. Connection trouble is covered by docs/MULTIPLAYER-TROUBLESHOOTING.md. Before launch, the menu and ./launcher.sh --doctor review the player machine, OS/kernel/WSL transport, graphics coprocessor, audio, pinned dependencies, Tailscale and reachability. ./launcher.sh --repair performs safe dependency and guided network remediation; ./launcher.sh --flowdiags opens a friendly HTML decision flow, and ./launcher.sh --man displays the complete manual. Hosts invite peers only after the green READY FOR JOINERS result; joiners get their own build/reachability checklist and green joining result.

Layout

crates/idaptik-core     engine-agnostic gameplay truth — the network sim + Ghost Lobby scenario, no rendering
crates/idaptik-ffi      Current Rust-exported C ABI; Zig/Idris2 policy gap (#103)
crates/idaptik-tui      ratatui/crossterm evaluation frontend + --headless/--replay/--export verifier over core (ADR-0004)
crates/idaptik-bevy     selected Bevy rendering frontend (ADR-0008)
crates/idaptik-net      Phoenix Channels client over burble game-session fabric (ADR-0006)
config/                    Nickel — typed, schema-checked game/network config
docs/adr/                  architecture decision records

just runs the common tasks (just doctor, just test, just run-bevy, just loopback-check, just config-check); toolchains are pinned in mise.toml + rust-toolchain.toml. The loopback gate starts a throwaway server from the sibling metadatastician/burble checkout; IDApTIK no longer contains its own relay server.

UMS-authored package proof

The game owns the versioned package and gameplay contracts in contracts/idaptik/v1; Universal Modding Studio consumes them without the game depending on the UMS UI. From the sibling UMS repository, run:

just roundtrip-idaptik

That command compiles the UMS Ghost Lobby profile source, hands the exact temporary artifact to IDApTIK's real package loader, executes a grounded camera uplink, snapshots, restores, replays, and fails unless events and final state match.

Status: implemented and CI-gated in Universal Modding Studio. The UMS profile compiler consumes this repository's contracts/idaptik/v1, then the real IDApTIK loader executes, snapshots, restores and replay-checks the emitted package. UMS remains absent from the shipped game runtime.

The current Enaction evidence covers extracted interpolation parity; IDApTIK still uses Bevy's fixed-step accumulator, so no broader timing adoption is claimed.

Licensing

IDApTIK is layered, and each layer is licensed for what it is. The whole project is open and is built to stay open.

Layer	License
Engine & code	AGPL-3.0-or-later
Game content (art, levels, narrative, character designs, audio)	CC-BY-SA-4.0
Names & marks (IDApTIK, IDApTIK, Moletaire)	Trademark, all rights reserved

The engine is strong copyleft: anyone who builds on it, including as a hosted service, must share their entire derivative source. The content is free culture: you may use, modify, and even sell derivatives, provided you attribute and keep them under the same share-alike terms.

Contributing

Contributions come in under the Developer Certificate of Origin (DCO 1.1); sign your commits with git commit -s. See CONTRIBUTING.md.

Status

Envelope-stage vertical slice. The deterministic Ghost Lobby simulation, TUI, delay-lockstep netplay, Bevy renderer, and UMS v1 package boundary are implemented. IDApTIK's Rust suites, Bevy frontend, Nickel contracts, and the Burble-backed two-seat session path and cross-repository UMS round trip are CI-gated. The next milestone is a coherent player-facing Bevy shell with first art, real-window validation, and documented mechanics.

---

The infiltrator moves. The hacker watches. Try to leave together.