Conceitos principais

Os termos que as demais páginas usam sem explicar. Cada um tem uma definição curta e um link para a página onde está o mecanismo por trás dele.

Três assuntos são grandes demais para um verbete e ganharam página própria: Quem toma as decisões — quem está chamando e o que só isso já decide; Como o SDK é construído — do que o SDK é feito; Herança e composição — como os módulos se apoiam uns nos outros.

As quatro formas de trabalhar com um módulo

Todo módulo oferece exatamente quatro coisas, e toda página de módulo se organiza em torno delas. Esse é o modelo de programação:

Forma	O que significa
Declarações	o que existe e como se comporta, escrito no código ou no painel de administração; o modelo é o mesmo nos dois casos
Hooks	as suas regras, que a plataforma chama em etapas nomeadas; publicadas como cloud functions
Eventos	o que a plataforma avisa que aconteceu — assine em vez de ficar consultando
Operações	o que você pede ou comanda, a partir de uma função ou de um cliente

Ator

Quem está fazendo a chamada. O que uma chamada pode fazer depende do ator por trás dela, nunca do build em que o código foi compilado. O argumento está em Quem toma as decisões; o mecanismo (permissões atômicas, papéis (role) compostos, InterfaceGrant), em Access & Roles.

Os nomes de atores nestas páginas vêm dos presets que a plataforma traz. Um projeto pode dar nomes próprios aos seus atores; os presets são:

player · backend-service · operator · host · moderator · schema-author · architect · bot-brain · room-owner · room-visitor · entry-validator · spectator · match-organizer · warehouse-keeper · seller — e any quando a página se refere a todos eles.

Local de execução

Onde o código roda. Estas quatro tags aparecem em toda tabela de operações:

Tag	Local
`fn`	Cloud function (C# · TypeScript · Python · Go). A autoridade fica no servidor; o lugar principal das suas regras
`cl`	Cliente do jogo (Unreal C++ / Unity C#). API simétrica; os papéis liberam menos
`mc`	Quem hospeda a sala (room): um cliente mestre (master-client) — um cliente que é dono de uma sala — ou um servidor dedicado Unreal com a sua chave de host
`adm`	Painel de administração / CLI / MCP — onde o SDK e o plano do operador compartilham o mesmo modelo

Onde o código roda não diz em nome de quem ele roda

Onde o código roda e qual interface de ator ele tem são perguntas separadas. O mesmo código tem os mesmos direitos onde quer que esteja; só mudam as permissões concedidas (grant).

Projeto e ambiente

Um projeto é o backend de um jogo, com um esquema e os seus dados em ambientes isolados (dev, prod). Toda chamada roda dentro de um projeto + ambiente.

Entidade

O substantivo central. Uma entidade é uma declaração de esquema mais os seus aspectos vivos: dados 0..*, estados 0..*, RPC 0..*, eventos 0..*, hooks e histórico de mudanças. Um tanque, uma porta, uma barra de stat e uma missão são todos entidades; a diferença está só nos aspectos que cada um carrega. As combinações comuns vêm prontas como presets (GameObject, Stat, Character, Interactable, Projectile). Veja Entity.

Estado esperado

Um pedido de transição pode indicar o estado que espera encontrar, e aí o resultado é esse estado ou uma recusa. Um pedido que não indica nenhum é avaliado contra o estado em que a máquina está quando a plataforma o processa — nunca contra o estado do momento em que foi enviado.

A resposta descreve aquele momento e não promete nada sobre o que vem depois: se a transição de outra pessoa chegar enquanto a resposta está a caminho, a resposta continua verdadeira e não é cancelada.

Indique o estado esperado quando ele importa

Quando o resultado depende do que havia antes, indique o estado esperado. Caso contrário, não leia a resposta como um snapshot que vale depois da chamada.

Sala

Uma sala é uma sessão de jogo, não um lugar onde o seu código roda. Para a plataforma, tanto faz quem a hospeda: um servidor dedicado, um cliente mestre ou o próprio backend. O funcionamento interno da sala é nosso; você conduz a sala de fora, a partir de cloud functions e clientes, por meio de declarações, hooks, eventos e operações. Veja Rooms.

Canal e fluxo

As primitivas assíncronas por baixo de tudo. Um canal é um tópico pub/sub endereçável: uma sala, um grupo, uma entidade ou um canal seu. Um fluxo (stream) é um envio em partes, em qualquer direção: arquivos são consumidos à medida que as partes chegam, consultas podem vir como fluxo, e um RPC pode se espalhar por um grupo e recolher as respostas. Veja Core.

Primitiva

Um dos quatro tijolos de que todo módulo é montado: eventos (declarar, emitir, assinar), RPC (chamar do outro lado da rede), dados e assinaturas (a mecânica de sincronização) e grupos (uma lista, muitos ouvintes). Uma sala, um chat e um pool de matchmaking são a mesma primitiva de grupo com regras diferentes.

Contrato dos hooks

Um só contrato em todo lugar. Um hook before roda antes da validação, recebe o payload tipado e pode alterá-lo ou rejeitá-lo. Um hook after roda depois que a operação foi confirmada, recebe o pedido e o resultado e só pode acrescentar efeitos colaterais — ele nunca faz a operação falhar. Os hooks têm ordem, e toda etapa registrada da plataforma pode recebê-los. Veja Extensibility.

Delta e revisão

Os clientes recebem o estado como deltas: só os campos que mudaram, codificados em relação ao último estado que o receptor confirmou. Todo registro carrega uma revisão; escritas condicionais são rejeitadas quando ela não confere. Um único conceito de versionamento atende à sincronização, à concorrência e ao histórico. Veja Data & Subscriptions. (O que o Unreal chama de replication — qual cliente vê qual estado e com que frequência — fica aqui e em Visibility e Prediction & Lag Comp. A página O que sobrevive à perda de um host trata da outra questão: qual máquina é dona de uma entidade e qual será a próxima.)

Tick

As salas simulam em passo fixo. Toda mudança de estado leva o número do seu tick; sincronização, predição, compensação de lag e histórico contam em ticks, não em tempo de relógio. Os dados carregam o momento real do evento, o que torna exatos o rewind e a reconciliação. Veja Prediction & Lag Comp.