Cómo está construido el SDK

Cómo está escrito el SDK y cómo se ejecuta. Por qué una misma idea se ve un poco distinta en Python y en Unreal C++, y qué hay entre tu llamada y la red.

Escrito de lo general a lo particular

El SDK es un solo diseño con dos formas de acotarlo, y el orden es la regla: nada baja de nivel mientras el nivel de arriba pueda expresarlo.

Nivel	Qué vive aquí
Los principios comunes	Idénticos en todos los bindings: el comportamiento se declara como un atributo junto a lo que describe; cada declaración que subes es una declaración que muestra el panel de administración; tu código se dirige a los módulos y a nada más.
La forma del lenguaje	Solo lo que el paradigma de un lenguaje no puede expresar de la manera común. C# tiene atributos y Python tiene decoradores: es la misma declaración, escrita como cada lenguaje ya escribe esa idea. Un lenguaje sin una construcción así expresa la misma declaración de otra manera, y esa manera se nombra donde corresponde, en lugar de darse por supuesta.
La forma del motor	Solo lo que un motor de juego cambia encima de su lenguaje. Unreal C++ no es C++ a secas: tiene su propio modelo de objetos y su propia reflexión en tiempo de compilación, así que ahí una declaración va dentro de la propia macro de reflexión del motor, en la posición donde esa macro ya recibe especificadores. Unity C# tampoco es el C# del servidor: tiene un runtime más antiguo y una biblioteca base más pequeña.

Leído de arriba hacia abajo, esto explica por qué las seis pestañas de cada ejemplo no son seis API distintas. Son una sola API escrita de seis maneras, y las diferencias que ves son los dos niveles inferiores que se asoman.

Cómo se ejecuta, desde tu código hacia abajo

El código de tu juego ve módulos, y el vocabulario termina ahí.

Los módulos son aquello a lo que se dirige tu código. Forman un grafo, no un árbol, y lo que eso te da se explica en Herencia y composición.
Las cuatro primitivas son las piezas con las que se arman los módulos: eventos, RPC, datos y suscripciones, grupos. Una sala (room), un chat y un pool de emparejamiento (matchmaking) son la misma primitiva de grupo con reglas distintas.
El hub está debajo, y nunca lo llamas: inyección de dependencias, montaje de módulos, la sesión del usuario, la recuperación del estado y la calidad de servicio de los mensajes. Se menciona una sola vez, en Bajo el capó.
Los adaptadores de transporte están en la base, uno por protocolo, y el hub los oculta por completo. Habrá varios — WebSocket, nuestro propio UDP, HTTP — y tu código no decide ni nota cuál de ellos lleva cada llamada.

Lo único que un módulo te dice sobre la entrega es su calidad de servicio — al menos una vez (at-least-once) o como máximo una vez (at-most-once) — y nada más. El transporte de abajo puede cambiar sin que cambie tu código.

Lo que ganas con esto

Un solo SDK, no uno de cliente y otro de servidor. Lo que puede hacer una llamada depende de los permisos otorgados (grant) al actor, no de un flag de compilación. Eso es Quién toma las decisiones.
Una declaración es la entrada de todo. La subes y aparece la API tipada, el panel de administración la muestra y le sigue la generación de código para cada binding. Consulta Esquema como código.
Los módulos se componen en lugar de heredar. Cómo lo hacen, y qué significa aquí “herencia”, se explica en Herencia y composición.