40 lines
2.0 KiB
Markdown
40 lines
2.0 KiB
Markdown
# 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.
|