Como testar jogo multiplayer sozinho na máquina

Montar o esqueleto de rede de um jogo e descobrir que você precisa de um amigo online só para ver se a conexão funciona é uma das frustrações mais comuns de quem começa. A boa notícia é que dá para testar jogo multiplayer sozinho na sua própria máquina, rodando o host e o cliente ao mesmo tempo, lado a lado, sem depender de ninguém. No Godot 4 isso é quase trivial graças a um recurso embutido no editor, e neste guia você vai ver o fluxo completo: abrir várias instâncias, decidir quem é host e quem é cliente, conectar por localhost, organizar as janelas e automatizar o papel de cada uma com argumentos de linha de comando. No final, um resumo rápido de como o mesmo conceito se aplica na Unity.

A ideia por trás de tudo é simples. Um jogo multiplayer é só dois ou mais programas conversando por uma conexão. Nada obriga esses programas a estarem em máquinas diferentes. Você pode rodar duas cópias do mesmo jogo no seu computador, fazer uma abrir o servidor e a outra conectar nele, e para a lógica de rede não faz diferença nenhuma: os pacotes vão e voltam exatamente como iriam entre duas máquinas, só que pelo caminho interno da sua própria máquina. É o ambiente de teste ideal, porque é rápido, repetível e isola o seu código de qualquer problema de rede de verdade.

Run Multiple Instances: o atalho nativo do Godot 4

O Godot 4 traz um recurso que resolve o problema com dois cliques. No menu Debug, no topo do editor, existe a opção Run Multiple Instances. Ao abrir esse submenu você escolhe quantas cópias quer rodar: 1, 2, 3 ou 4. Selecione 2 para o caso mais comum (um host e um cliente), e depois rode o projeto normalmente com F5. O Godot vai abrir duas janelas separadas, cada uma um processo independente do seu jogo, prontas para se conectarem.

Essa é a diferença que economiza horas. Antes desse recurso, era preciso exportar uma build e abrir o executável ao lado do editor, ou ficar manipulando cópias do projeto na mão. Agora você itera direto do editor: muda uma linha de código, aperta F5, e já tem duas instâncias novas conversando. Para quatro jogadores, escolha 4 instâncias e o Godot abre as quatro de uma vez.

Um detalhe prático de produtividade: as janelas costumam abrir empilhadas no mesmo ponto da tela. Vale configurar o tamanho e a posição da janela no projeto, ou arrastar as janelas para cantos diferentes assim que abrem, de modo a ver o host e o cliente ao mesmo tempo. Ver as duas telas lado a lado é o que torna o teste útil: você aperta um botão numa janela e confere na hora se a ação aparece na outra, que é exatamente o que a sincronização de rede precisa garantir.

Conectando host e cliente por 127.0.0.1

Com duas instâncias abertas, falta decidir quem faz o quê. Uma instância cria o servidor e a outra conecta nele usando o endereço de loopback, o famoso 127.0.0.1 (ou o apelido localhost). Esse endereço sempre aponta para a própria máquina, então o cliente que conecta nele está falando com o servidor que está rodando ali do lado, na mesma máquina. Os pacotes nem chegam a sair para a placa de rede.

No Godot 4 o código é curto. O host instancia um ENetMultiplayerPeer, chama create_server e entrega o peer ao sistema de multiplayer. O cliente faz o espelho com create_client, apontando para 127.0.0.1:

extends Node

const PORTA: int = 8910
const MAX_JOGADORES: int = 4

func virar_host() -> void:
    var peer: ENetMultiplayerPeer = ENetMultiplayerPeer.new()
    var erro: int = peer.create_server(PORTA, MAX_JOGADORES)
    if erro != OK:
        push_error("Falha ao abrir o servidor na porta %d" % PORTA)
        return
    multiplayer.multiplayer_peer = peer
    print("Host no ar na porta %d." % PORTA)

func virar_cliente() -> void:
    var peer: ENetMultiplayerPeer = ENetMultiplayerPeer.new()
    var erro: int = peer.create_client("127.0.0.1", PORTA)
    if erro != OK:
        push_error("Falha ao iniciar conexao com o host local.")
        return
    multiplayer.multiplayer_peer = peer
    print("Cliente tentando conectar em 127.0.0.1:%d." % PORTA)

No começo, a forma mais simples de escolher o papel é colocar dois botões na cena: um "Host" e um "Cliente". Você abre as duas janelas, clica em Host numa e em Cliente na outra, e pronto, o teste roda. Isso funciona perfeitamente e é o jeito recomendado para os primeiros experimentos. Se você quer entender a fundo a parte de endereços, porta e firewall quando sair do localhost para a rede de verdade, o guia de conectar por IP na rede local no Godot cobre esse próximo passo.

Automatizando o papel com argumentos de linha de comando

Clicar em botões toda vez cansa quando você está testando dezenas de vezes por hora. A solução elegante é deixar o jogo decidir o próprio papel ao iniciar, lendo um argumento de linha de comando. A convenção mais usada é passar --server para a instância que deve ser o host. Se o argumento estiver presente, a instância abre o servidor; se não estiver, ela conecta como cliente.

No Godot você lê os argumentos com OS.get_cmdline_args():

func _ready() -> void:
    var args: PackedStringArray = OS.get_cmdline_args()
    if args.has("--server"):
        virar_host()
    else:
        virar_cliente()

Com isso no lugar, basta configurar uma das instâncias para abrir com o argumento --server e a outra sem nada. No editor, você define argumentos extras em Project, Project Settings, na seção de execução, ou passa pela linha de comando ao chamar o executável exportado. O resultado é que, ao rodar, uma janela já nasce host e a outra já nasce cliente conectando no localhost, sem clique nenhum. É o fluxo que acelera muito a iteração quando a rede já está estável e você quer focar no gameplay.

Esse mesmo padrão de argumento é o que você vai reaproveitar quando chegar a hora de rodar um servidor sem janela, por exemplo um servidor dedicado headless no Godot. A instância que recebe --server pode rodar em modo sem interface gráfica, e a lógica que você testou localmente continua valendo.

Erros ao testar jogo multiplayer sozinho

Mesmo no conforto do localhost, algumas coisas travam e vale saber onde olhar. O primeiro erro clássico é esquecer que create_client retornar OK não significa que conectou, significa apenas que a tentativa começou. A confirmação vem pelos sinais connected_to_server e connection_failed, que você deve conectar e tratar. Se a conexão falha instantaneamente mesmo no localhost, quase sempre é porque o host não subiu antes do cliente tentar, ou a porta está diferente entre os dois.

O segundo tropeço é a porta ocupada. Se uma instância anterior do jogo não fechou direito e ficou segurando a porta, a nova tentativa de create_server retorna erro. Por isso o código acima checa o retorno de create_server: em vez de seguir como se tudo estivesse bem, ele avisa. Ao testar com várias instâncias, feche todas as janelas ao terminar, para não deixar processos fantasmas segurando a porta.

O terceiro ponto é confundir o que a conexão faz. Conectar duas instâncias é só o começo: a conexão transporta dados, mas você ainda precisa de RPCs ou de nós sincronizados para que o estado realmente trafegue entre host e cliente. Se as duas janelas conectam mas nada se move de um lado para o outro, o problema não é a conexão, é a camada de sincronização. Para essa parte, veja o básico de RPC no multiplayer do Godot, que mostra como uma função chamada numa máquina roda na outra.

O equivalente na Unity, em resumo

A Unity não traz um botão nativo tão direto quanto o Run Multiple Instances do Godot, mas a necessidade é a mesma e a comunidade resolveu de dois jeitos. O primeiro é o ParrelSync, uma ferramenta gratuita que cria clones do seu projeto que ficam sincronizados com o original. Você abre um segundo editor apontando para o clone, roda os dois ao mesmo tempo, e tem host e cliente conversando por localhost, do mesmo jeito. O segundo caminho, mais rústico, é gerar uma build do jogo e abrir o executável como cliente enquanto o editor roda como host, ou abrir duas cópias da build.

O conceito não muda de engine para engine: duas instâncias do jogo na mesma máquina, uma como servidor e outra como cliente, conversando pelo endereço de loopback. Se você ainda está decidindo qual motor usar para o seu projeto online, vale comparar as opções antes, porque cada engine tem seu fluxo. De todo jeito, dominar o teste local é o que separa quem itera rápido de quem fica travado esperando um amigo entrar. Comece sempre por aqui: duas janelas, localhost, host de um lado e cliente do outro. Quando a lógica funciona assim, você já tem a base pronta para testar com um jogo multiplayer de verdade em duas máquinas e, mais tarde, pela internet.