Not translated yet — showing English.
How the SDK Is Built
How the SDK is written, and how it runs. Why one idea looks slightly different in Python and in Unreal C++, and what sits between your call and the wire.
Written from the general to the particular
The SDK is one design with two ways to narrow it, and the order is the rule: nothing moves down a level until the level above can't express it.
| Level | What lives here |
|---|---|
| The common principles | Identical in every binding: behaviour is declared as an attribute beside the thing it describes; every declaration you push is a declaration the admin panel renders; your code addresses modules and nothing else. |
| The language's shape | Only what a language's paradigm cannot express the common way. C# has attributes and Python has decorators — the same declaration, spelled the way each language already spells that idea. A language with no such construct carries the same declaration a different way, and that carrier is named where it applies rather than assumed. |
| The engine's shape | Only what a game engine reshapes on top of its language. Unreal C++ is not plain C++ — it has its own object model and its own build-time reflection, so a declaration there rides inside the engine's own reflection macro, in the position where that macro already takes specifiers. Unity C# is not server C# either: an older runtime, a smaller base library. |
Read top down, this is why the six tabs on every example are not six different APIs. They are one API, spelled six ways, and the differences you can see are the two lower levels showing through.
How it runs, from your code downwards
Your game code sees modules, and the vocabulary stops there.
- Modules are what you address. They form a graph, not a tree, and what that buys is Inheritance & Composition.
- The four primitives are what modules are assembled from — events, RPC, data and subscriptions, groups. A room, a chat and a matchmaking pool are the same group primitive under different rules.
- The hub is underneath, and you never call it: dependency injection, module mounting, the user session, state recovery, and message quality of service. It is named once on Under the Hood.
- Transport adapters sit at the bottom, one per protocol, and the hub hides them completely. There will be several — WebSocket, our own UDP, HTTP — and which one carries a call is not something your code decides or notices.
What a module tells you about delivery is its quality of service — at-least-once, or at-most-once — and nothing else. The transport underneath can change without changing your code.
What you get out of this
- One SDK, not a client one and a server one. What a call may do is the actor's grant, not a build flag. That is Authority.
- A declaration is the input to everything. Push it and the typed API appears, the admin panel renders it, and the codegen for each binding follows. See Schema as Code.
- Modules compose rather than inherit. How, and what "inheritance" means here, is Inheritance & Composition.