Como o SDK é construído

Como o SDK é escrito e como ele roda. Por que a mesma ideia fica um pouco diferente em Python e em Unreal C++, e o que existe entre a sua chamada e a rede.

Escrito do geral para o particular

O SDK é um único design com duas formas de especializá-lo, e a ordem é a regra: nada desce de nível enquanto o nível de cima conseguir expressá-lo.

Nível	O que fica aqui
Os princípios comuns	Idênticos em todo binding: o comportamento é declarado como um atributo ao lado daquilo que ele descreve; toda declaração que você publica é uma declaração que o painel de administração exibe; o seu código se dirige a módulos e a nada mais.
A forma da linguagem	Só o que o paradigma de uma linguagem não consegue expressar do jeito comum. C# tem atributos e Python tem decorators — é a mesma declaração, escrita do jeito que cada linguagem já escreve essa ideia. Uma linguagem sem essa construção leva a mesma declaração de outra forma, e essa forma é nomeada onde se aplica, em vez de ficar subentendida.
A forma da engine	Só o que uma engine de jogo remodela por cima da sua linguagem. Unreal C++ não é C++ puro: tem o seu próprio modelo de objetos e a sua própria reflexão em tempo de build, então ali a declaração vai dentro da macro de reflexão da própria engine, na posição em que essa macro já aceita especificadores. Unity C# também não é o C# do servidor: o runtime é mais antigo e a biblioteca base, menor.

Lida de cima para baixo, a tabela explica por que as seis abas de cada exemplo não são seis APIs diferentes. São uma API escrita de seis jeitos, e as diferenças que você vê são os dois níveis de baixo aparecendo.

Como ele roda, do seu código para baixo

O código do seu jogo enxerga módulos, e o vocabulário para aí.

Os módulos são aquilo a que você se dirige. Eles formam um grafo, não uma árvore, e o que isso traz é o assunto de Herança e composição.
As quatro primitivas são as peças com que os módulos são montados — eventos, RPC, dados e assinaturas, grupos. Uma sala (room), um chat e um pool de matchmaking são a mesma primitiva de grupo com regras diferentes.
O hub fica por baixo, e você nunca o chama: injeção de dependência, montagem de módulos, a sessão do usuário, recuperação de estado e qualidade de serviço das mensagens. Ele é apresentado uma única vez, em Por baixo dos panos.
Os adaptadores de transporte ficam no fundo, um por protocolo, e o hub os esconde por completo. Serão vários — WebSocket, o nosso próprio UDP, HTTP —, e qual deles leva uma chamada não é algo que o seu código decide nem percebe.

O que um módulo diz sobre a entrega é a sua qualidade de serviço — at-least-once ou at-most-once — e nada mais. O transporte por baixo pode mudar sem que o seu código mude.

O que você ganha com isso

Um único SDK, não um de cliente e outro de servidor. O que uma chamada pode fazer vem das permissões concedidas (grant) ao ator, não de uma flag de build. Isso é Quem toma as decisões.
A declaração é a entrada de tudo. Publique-a e a API tipada aparece, o painel de administração a exibe, e a geração de código de cada binding vem em seguida. Veja Esquema como código.
Os módulos se compõem em vez de herdar. Como, e o que “herança” quer dizer aqui, está em Herança e composição.