Actorics is not generative AI in any form. It does not generate art, audio, text, levels or dialogue. The runtime selects an action from a set your designers authored — the same thing a behavior tree does, except the opponent stops falling for the same tactic. No language models. No network calls. No tokens.
Opponents, bosses and squadmates that stop falling for repetitive player tactics during combat. Evaluated locally on the CPU within your frame budget. Zero network calls. Zero cloud token bills. Fully constrained by Designer Envelopes.
This sandbox is a JavaScript illustration of the mechanic, not the Actorics core. Timing values come from the Envelope controls below; no performance number is measured here.
Hand-authored trees get solved by players. Cloud agents don't fit in a frame. The behavioral layer sits between the two, and it is still written by hand.
One tick, five stages. The controller proposes; the Envelope decides what is allowed; commitment keeps animation intact. Select a stage.
The same runtime, pointed at four jobs studios already pay for in hand-tuning, QA hours or empty lobbies.
Nothing below is estimated. The first table is a measured run of the core itself. The second is per-character engine telemetry: a value appears when the testbench harness produces it, until then the slot stays empty.
| CHANNEL | RESULT | CONDITIONS |
|---|---|---|
| Training time, all 48 subtasks | 15–20 s | Standard CPU, no GPU · 0.2 s per epoch |
| Reload of learned state | 0.1 ms | From the saved state file, no retraining |
| Accuracy on unseen data | 99.20–99.26% | Balanced accuracy · 10,000 held-out samples · holds whether trained from scratch or reloaded from saved state |
| Learned state file | ≤ 1 MB | All 48 subtasks in one file |
| Forgetting | 0% | Learning new subtasks does not degrade earlier ones |
| Build targets | x86-64 · ARM64 | Rust + ISPC |
Abstract math subtasks, not game characters. Per-character numbers come from the engine testbench below.
| CHANNEL | TARGET SPECIFICATION | STATUS | METHOD |
|---|---|---|---|
| CPU time per agent tick | Bounded, single core, no GPU | — . — — µsAWAITING TESTBENCH HARNESS |
Engine profiler, mean and peak per frame |
| Scaling to 50+ active agents | Linear, inside frame budget | — . — — msAWAITING TESTBENCH HARNESS |
1 / 10 / 50 agents, same scene |
| Memory per character | Fixed pool, allocated at spawn | — — KBAWAITING TESTBENCH HARNESS |
Module plus learned state, measured size |
| Learned state save size | Fits native SaveGame slot | — — BAWAITING TESTBENCH HARNESS |
Serialized blob, versioned format |
| Network traffic | 0 bytes | BY CONSTRUCTION [0 BYTES] |
By construction: the runtime opens no sockets |
| Allocations inside tick | 0 | SPECIFIED TARGET |
Allocation tracing under profiler. Target, not yet a result |
| Cross-platform determinism | Bit-identical actions, x86-64 and ARM64 | IN PROGRESS |
Record inputs, replay 100×, compare action hash |
We don't publish synthetic benchmarks. Every value will be published raw, without smoothing, together with the testbench project.
Every decision is written into the debugger your team already opens. Pause the fight, scrub back two seconds, read why the character did what it did.
10:30:22.140 [PERCEPTION] PLAYER SPAM DETECTED: ROLL_LEFT (COUNT: 4)
10:30:22.142 [DESIRED] FIRE ACTION: SWEEP_LOW_COUNTER
10:30:22.143 [ENVELOPE] PASSED: REACTION_TIME 180ms >= FLOOR 150ms
10:30:22.144 [COMMITMENT] LOCKED: POINT_OF_NO_RETURN REACHED
Illustration of the log format.
The runtime MVP is ready and pilot slots are open. The core is open so anyone can check it; studios pay for engine integration, tooling and the author in the pilot.
Free · MIT-0
Fixed fee per title, or optional 1% royalty
Fixed fee per pilot