Como Fazer um Jogo Multiplayer na Unity (Netcode)

Se você chegou aqui procurando como fazer um jogo multiplayer na Unity, vou ser direto logo de cara: essa é uma das partes mais difíceis do desenvolvimento de jogos, e não existe botão mágico. Mas também não é impossível para iniciante. A Unity tem uma solução oficial chamada Netcode for GameObjects (abreviado como NGO), e ela foi feita justamente para você não ter que inventar do zero toda a parte chata de rede. Neste guia eu mostro o caminho mínimo para dois jogadores se conectarem e verem o mesmo jogo, com código C# real e sem enrolação.

Antes de qualquer coisa, um aviso honesto sobre a curva de dificuldade. Multiplayer não é "single-player com um jogador a mais". É um modelo mental diferente. No jogo single-player, existe uma verdade só: a máquina do jogador. No multiplayer, existem várias máquinas que precisam concordar sobre onde estão as coisas, e a rede entre elas tem atraso e pode falhar. Se você ainda está aprendendo a mexer na Unity, faça um ou dois jogos single-player pequenos antes. Multiplayer vai cobrar tudo que você sabe de C# e um pouco mais.

O modelo host: a forma mais simples de começar multiplayer na Unity

O Netcode for GameObjects trabalha com três papéis: servidor, cliente e host. Entender essa divisão resolve metade da confusão de quem está começando.

O servidor é a autoridade. É quem manda no estado do jogo: a pontuação real, a vida de cada jogador, a posição oficial dos inimigos. O cliente é cada jogador conectado, que envia comandos e recebe atualizações. O host é um atalho prático: uma única instância que roda o servidor e um cliente ao mesmo tempo, na mesma máquina. Ou seja, o jogador que abre a partida como host está jogando e servindo o jogo simultaneamente.

Para aprender, o modo host é o melhor ponto de partida. Você não precisa de uma máquina separada só para rodar o servidor. Um jogador vira host, os outros entram como clientes, e pronto. É o mesmo modelo que muitos jogos indie de co-op usam de verdade, então não é um atalho "de mentira": é uma arquitetura legítima.

Na prática, os três modos viram três chamadas de método no NetworkManager:

using Unity.Netcode;
using UnityEngine;

public class ConnectionMenu : MonoBehaviour
{
    public void OnHostButton()
    {
        // Servidor + cliente na mesma instancia
        NetworkManager.Singleton.StartHost();
    }

    public void OnClientButton()
    {
        // Apenas cliente, conecta em um host existente
        NetworkManager.Singleton.StartClient();
    }

    public void OnServerButton()
    {
        // Servidor puro, sem jogador local (servidor dedicado)
        NetworkManager.Singleton.StartServer();
    }
}

Esses três métodos (StartHost, StartClient e StartServer) são o coração do fluxo de conexão. Ligue cada um a um botão da sua UI e você já tem o esqueleto de um menu multiplayer.

NetworkManager e transporte: o que você configura primeiro

O NetworkManager é o componente central de qualquer projeto multiplayer com NGO. Você cria um GameObject vazio na cena, adiciona o componente NetworkManager e ele passa a coordenar tudo: quem conecta, quais objetos existem na rede e qual player prefab é criado para cada jogador que entra.

Junto com ele vem o transporte. Transporte é a camada que efetivamente manda os bytes pela rede. O NGO usa o Unity Transport (o componente UnityTransport), e é ali que você define o endereço e a porta de conexão. Para testar em rede local, você aponta o cliente para o IP local da máquina que está rodando o host. Nada de nuvem ainda, nada de configuração complicada de servidor: só um IP na sua própria rede.

Vale instalar o Netcode for GameObjects pelo Package Manager da Unity, na aba de pacotes oficiais. Ele não vem ativado por padrão em todo projeto, então esse é literalmente o primeiro passo prático depois de criar a cena.

NetworkObject e NetworkBehaviour: o que existe na rede

Aqui está uma regra que economiza muita dor de cabeça: nem tudo no seu jogo precisa saber que existe rede. O menu, os efeitos puramente visuais, o áudio local, nada disso precisa ser sincronizado. O que precisa aparecer para todos os jogadores é que vira objeto de rede.

Para um GameObject participar da rede, ele precisa do componente NetworkObject. É o NetworkObject que dá a cada objeto um identificador único que todas as máquinas reconhecem. O player, os inimigos, os projéteis, a bola do jogo: tudo isso carrega um NetworkObject.

Já os seus scripts que precisam de lógica de rede não herdam de MonoBehaviour, e sim de NetworkBehaviour. Essa é a diferença que muita gente esquece. Um NetworkBehaviour te dá acesso a propriedades essenciais como IsServer, IsClient e IsOwner, que respondem à pergunta "quem está executando este código agora". Isso é fundamental, porque o mesmo script roda em todas as máquinas, e você precisa saber em qual papel ele está rodando para tomar decisões diferentes.

Sincronizar estado com NetworkVariable

Chegamos ao primeiro problema concreto: como fazer a vida de um jogador ser a mesma em todas as telas? A resposta mais direta no NGO é a NetworkVariable<T>.

Uma NetworkVariable é um valor que o Netcode sincroniza automaticamente entre servidor e clientes. Quando o servidor muda o valor, todos os clientes recebem a atualização. Você não escreve o código de envio: declara a variável e o NGO cuida do resto.

using Unity.Netcode;

public class PlayerHealth : NetworkBehaviour
{
    // Valor sincronizado do servidor para todos os clientes.
    // Por padrao, so o servidor pode escrever.
    public NetworkVariable<int> Health = new NetworkVariable<int>(100);

    public void ApplyDamage(int amount)
    {
        // So faz sentido rodar no servidor: ele e a autoridade
        if (!IsServer) return;

        Health.Value -= amount;
        if (Health.Value < 0)
        {
            Health.Value = 0;
        }
    }
}

Repare em dois detalhes. Primeiro, a NetworkVariable<int> é inicializada com um valor padrão (100). Segundo, a checagem if (!IsServer) return; no começo do método. Por padrão, só o servidor pode escrever em uma NetworkVariable, então tentar alterá-la no cliente não vai funcionar como você espera. Essa é a autoridade do servidor aparecendo na prática. O cliente pode ler Health.Value à vontade (para mostrar na UI, por exemplo), mas quem muda o número é o servidor.

Executar lógica remota com ServerRpc e ClientRpc

NetworkVariable resolve estado contínuo, tipo vida e posição. Mas e quando você precisa de uma ação pontual, como "atirar agora"? Para isso existem os RPCs (Remote Procedure Calls), que são chamadas de método que atravessam a rede.

Existem duas direções. Um método marcado com [ServerRpc] é chamado no cliente mas executado no servidor. É assim que o jogador pede uma ação: "servidor, quero atirar". Já um método marcado com [ClientRpc] é chamado no servidor e executado nos clientes. É como o servidor avisa todo mundo: "toca o som do tiro em todas as telas".

using Unity.Netcode;
using UnityEngine;

public class PlayerShooter : NetworkBehaviour
{
    void Update()
    {
        // So o dono deste player le o input dele
        if (!IsOwner) return;

        if (Input.GetButtonDown("Fire1"))
        {
            ShootServerRpc();
        }
    }

    [ServerRpc]
    void ShootServerRpc()
    {
        // Roda no servidor: aqui voce valida e aplica a logica real
        // (spawn do projetil, gasto de municao, etc.)
        FireEffectClientRpc();
    }

    [ClientRpc]
    void FireEffectClientRpc()
    {
        // Roda em todos os clientes: efeito visual e som
        Debug.Log("Tiro disparado, toca o efeito nesta tela");
    }
}

Preste atenção na convenção de nome: métodos ServerRpc precisam terminar com o sufixo ServerRpc, e métodos ClientRpc com o sufixo ClientRpc. Isso não é estilo, é exigência do NGO. Se você esquecer o sufixo, o código nem compila. E note o if (!IsOwner) return; no Update: só o jogador dono daquele player deve ler o input dele. Sem essa checagem, o input de um teclado iria mexer no player de todo mundo.

O fluxo completo fica assim: o cliente lê o input, chama o ServerRpc, o servidor valida e aplica a lógica de verdade, e então dispara um ClientRpc para todos verem o resultado. Esse vaivém é a espinha dorsal de quase todo jogo multiplayer.

Quem manda: servidor autoritativo

Já falei de autoridade algumas vezes, mas vale fechar o conceito porque ele decide a qualidade do seu multiplayer. Servidor autoritativo significa que o servidor é a única fonte de verdade. O cliente nunca aplica uma mudança importante sozinho: ele pede, e o servidor decide.

Por que isso importa? Porque o cliente roda na máquina do jogador, e o jogador pode alterar o próprio cliente. Se o cliente pudesse dizer "minha vida agora é 999" e todo mundo aceitasse, qualquer um trapacearia em cinco minutos. Com servidor autoritativo, o cliente pode até pedir isso, mas o servidor ignora um pedido inválido. É por isso que os exemplos acima sempre checam IsServer antes de mudar estado e usam ServerRpc para pedir ações.

O contrário disso seria confiar no cliente, o que é mais fácil de programar e péssimo para qualquer jogo competitivo. Comece já pensando no servidor como autoridade. Reescrever essa lógica depois dá muito mais trabalho do que fazer certo desde o começo.

O conselho mais importante: teste com duas instâncias antes de pensar em nuvem

Aqui vai a parte que separa quem termina de quem desiste. Antes de sonhar com servidor na nuvem, matchmaking global e milhares de jogadores, faça duas instâncias do seu jogo conversarem na sua própria rede.

O jeito mais simples é fazer um build do jogo, abrir esse build como cliente e rodar o editor da Unity como host (ou vice-versa). Uma instância vira host, a outra conecta pelo IP local, e você joga contra si mesmo. Se dá para ver o outro player se mexer, atirar e tomar dano nas duas telas, o seu multiplayer funciona. Isso é uma vitória enorme e você conseguiu sem gastar um centavo com hospedagem.

Só depois que o jogo funciona de verdade em rede local é que faz sentido pensar em subir para um servidor dedicado na nuvem, e mesmo aí o custo de servidor de um jogo online precisa caber no seu bolso. Contratar máquina na nuvem antes de o jogo funcionar é a forma mais comum de queimar dinheiro cedo demais. Rede local primeiro, sempre.

Se você quer entender o multiplayer de forma mais ampla, sem se prender à Unity, o guia geral de como fazer um jogo multiplayer cobre os conceitos que valem para qualquer engine. E se você ainda está decidindo a ferramenta, vale comparar com a versão desse mesmo processo no GameMaker, que tem um público bem diferente.

E se eu estivesse em dúvida sobre a engine?

Uma pergunta honesta que aparece muito: será que a Unity é mesmo a melhor escolha para o seu projeto multiplayer? Depende. A Unity tem uma solução oficial madura, muito material e um C# que serve para carreira fora de jogos também. Mas ela não é a única opção séria, e para alguns perfis a Godot faz mais sentido. Se essa dúvida ainda te trava, dá para resolver lendo a comparação completa entre Godot e Unity e, do lado da linguagem, a diferença prática entre C# e GDScript. O importante é não ficar preso na escolha da ferramenta: qualquer uma das duas te leva a um jogo multiplayer se você terminar o que começou.

Fechando: o caminho mínimo que funciona

Resumindo o mapa que você precisa seguir. Instale o Netcode for GameObjects pelo Package Manager. Coloque um NetworkManager com o Unity Transport na cena. Ligue StartHost e StartClient a botões. Marque os objetos que aparecem para todos com NetworkObject e troque MonoBehaviour por NetworkBehaviour nos scripts de rede. Sincronize estado contínuo com NetworkVariable, use ServerRpc para o cliente pedir ações e ClientRpc para o servidor avisar todo mundo, e sempre deixe o servidor como autoridade. Depois teste com duas instâncias na rede local.

Não vou romantizar: você vai travar em algum ponto, provavelmente na primeira conexão que não completa ou num objeto que só aparece numa tela. Isso é normal e faz parte. Multiplayer é difícil para todo mundo, inclusive para quem faz isso há anos. Mas o caminho existe, é oficial, e cabe em um projeto de fim de semana se você respeitar a ordem: rede local primeiro, nuvem depois, e o servidor sempre no comando.