prosperon/docs/design/actor_use_cases.md

Actor Use Cases for Prosperon

Confirmed implementation targets. These are the concrete reasons actors add value beyond basic frame scheduling.

1. P2P Networking (Lockstep + Input Streaming)

Actor security model enables safe P2P:

• Lockstep: Both peers run the same actor with the same inputs. Actors are deterministic (same messages in = same state). Synchronize input streams.
• Input streaming (GGPO-style): Each peer sends inputs to the other. Actors only see inputs, not internal state, so cheaters can't fabricate state — only send inputs that the other peer validates by running the simulation.
• Security-first actor system makes this safe by design.

2. Game Sharing (DS Download Play Style)

Send entire cell packages over the network. Receiver runs the game in a sandboxed actor.

• A cell program/game sends its entire package (code + assets) using the cell package system.
• The other person runs it in a sandboxed actor — can't touch host filesystem, can't read save data, can only draw sprites and send messages through the allowed interface.
• Same trust model as mod sandboxing but for complete games.

3. Mod Sandboxing

Untrusted code runs in its own actor, communicates through a controlled message interface.

• Mods can't corrupt game state.
• Related to game sharing — same isolation model.

4. Background Asset Loading

Refactor the resource manager (currently single-threaded) into an actor:

• Game sends: {type: 'load', kind: 'image', path: 'player'}
• Resources replies: {type: 'loaded', path: 'player', data: <blob>}
• Game never blocks. Request assets, keep running, handle them when they arrive.
• Sprites show placeholder until real texture lands.
• This is the natural actor pattern: send a message, get a message back.

5. Editor <-> Game Isolation

Editor runs as a separate actor, sends commands to the game actor.

• Can't corrupt game state.
• Clean separation of concerns.
• Editor can inspect/modify game state only through the message interface.