Auto Snapshot

[Belmaxi]

Problem or use case

when I need to save snapshot, I need to write callbacks again and again.It's better to make a new way to save and load snapshot

Proposed solution

Auto work!

Component

C# Client (cli/)

[boomlulu]

Thanks for the feedback! This is a great point worth discussing from a framework design perspective.

Design Philosophy: Where the Framework Draws the Line

BoomNetwork is a sync framework, not a game framework. Our responsibility is to ensure that snapshots are delivered correctly — the transport, ordering, delta diffing, and recovery logic. What goes inside the snapshot is your game's business.

What we own:

• Snapshot lifecycle: when to capture, when to send, when to apply
• Delta tracking (dirty flags, slot management)
• Snapshot recovery on reconnect

What we intentionally don't own:

• How you serialize your game state (binary, JSON, MessagePack, protobuf — whatever fits your team)
• What fields you include
• Compression strategies

This boundary exists for good reasons: serialization requirements vary wildly across games — a voxel world snapshot looks nothing like a card game hand, and forcing a single serialization contract would create friction rather than reduce it.

---

On the "write callbacks again and again" pain

This is a real ergonomics problem. The current ISnapshotable pattern requires manually wiring up every field, which gets tedious.

There are two directions we could go:

1. Convention over configuration — provide base classes or source generators that auto-serialize fields marked with an attribute (e.g. [SyncState])
2. Pluggable serializer — a lightweight utility package that integrates with your serializer of choice, giving you a clean Capture() / Restore() API without the boilerplate

---

Status

A first-party snapshot serialization utility is on our TODO list. It would be an optional add-on (not part of the core), so teams who have their own pipeline can ignore it entirely.

If you have specific requirements or constraints (target platform, performance budget, existing serializer you're already using), feel free to share — it'll help us design something actually useful rather than generic.