Home / Projects / Shiver / IPC Architecture
The three processes
Shiver Editor — The user-facing C# application. Spawns and manages the other two processes. Communicates with both via IPC.
Why use inter-process communication at all?
The Shiver Editor is a C# WPF application. The engine is C++. Putting both in the same process means either the engine has a C# binding layer that is conditionally included (complexity, fragility) or the editor is also C++ (a significant constraint on what UI frameworks you can use). Neither is appealing.
Running them as separate processes with a defined message boundary keeps each side free to be implemented in whatever language makes the most sense. It also makes the boundary explicit: you can't accidentally couple the editor and engine through shared state because there is no shared state. Everything has to go through the wire.
The tradeoff is latency and serialization overhead. For the kind of interactions a game editor needs — “move this object”, “recompile this shader”, “stream me a frame” — that overhead is acceptable.
With this design the Shiver Engine Runtime powering games can be compiled identically for the editor, a video game or other tools.
The Shiver Data Service has it's own reasons to live in it's own process: it simplifies operations that are global to a game project. Without this system-wide service we would have to either restrict the number of open editors (or other writable processes such as data builds) or manage significant complexity ensuring every data operation has a mechanism to synchronize data writes safely.
“But this other tool doesn't do it this way”
I'm aware. I won't be expanding on this reasoning any more here, but I'd be happy to discuss with you any time. This is one of my favorite topics.
ØMQ and FlatBuffers
Messages are transported with ØMQ and serialized with FlatBuffers.
ØMQ handles the transport and socket lifecycle without requiring a broker process. The messaging patterns it supports (request/reply, pub/sub, push/pull) map well to the different kinds of communication an editor needs — some messages need acknowledgement, others are fire-and-forget notifications.
FlatBuffers provides zero-copy deserialization, which matters when streaming large amounts of data (scene state, asset payloads). The schemas are shared directly between the editor, SES, and SDS, which keeps the message format as the single source of truth across all three.
Startup sequence
The editor spawns both co-processes and then waits for initialization signals from each before it considers itself ready. More detail on the specific message flow and socket topology to come.
xo © 2026 all rights reserved — attribution