"Sandbox.Json.Serialize always writes indented JSON"

• A JSON payload sent over a bulk or per-tick network channel is much larger than the data it carries.
• Bandwidth on a save-and-sync or replication channel is dominated by newlines and indentation, not content.
• There is no obvious knob on Sandbox.Json.Serialize to turn the pretty-printing off.

Sandbox.Json.Serialize always writes INDENTED JSON. Its serializer options are an internal, get-only property with no public overload to change them, so every byte of a payload built through it pays for newlines and per-level indentation on top of the actual data.

For a one-off save file the extra bytes barely matter. But any code path that Json-serializes something for a bulk or per-tick network channel is paying a size tax with no built-in way to opt out.

Re-drive the same engine serializer — same converters, same naming policy — through a non-indented/compact writer instead of calling Json.Serialize directly. The wire format ends up identical to the indented output except for the whitespace, so nothing on the deserialize side has to change.

Measured 41–56% size reduction on bulk channels from this change alone.

Prove it before shipping. Don't trust "the compact output looks the same." Pin it with a round-trip:

1. Serialize your data through the compact writer.
2. Parse that compact output back.
3. Re-serialize the parsed result through the original indented Json.Serialize path.
4. Diff against the original indented payload — it must be byte-identical.

If the round-trip diff is clean, the only difference between the two paths is whitespace and the switch is safe.

Whitespace on a save file is free; whitespace on a channel that fires every tick is a permanent multiplier on your bandwidth bill. Because the compact path reuses the same converters and naming policy, you get the saving without changing your schema or your readers — but only if you verify the round-trip, since a subtly different serializer would corrupt data silently.