Como Fazer um Jogo de Carro Multiplayer na Godot

Fazer um jogo de carro é um projeto ótimo para aprender, e como fazer um jogo de carro multiplayer é a pergunta que vem logo depois, quando você quer correr contra um amigo em vez de contra a máquina. Vou te avisar de cara: o carro é um dos casos mais exigentes de multiplayer, porque a física muda a cada quadro e o olho percebe qualquer travada. Mas também é um dos mais gratificantes de resolver. Neste post eu te levo pelo caminho conceitual, do mais simples ao mais avançado, usando a Godot como referência e código GDScript tipado onde fizer sentido.

A ideia central é esta: num jogo de carro, você não sincroniza um clique ou um turno, você sincroniza movimento contínuo. Posição, rotação, velocidade e derrapagem estão sempre mudando. Isso é diferente de um jogo de tabuleiro em rede, onde basta avisar "joguei a peça aqui". Entender essa diferença é o que separa um carro que desliza suave na tela do amigo de um carro que teleporta e trava. Vamos construir esse entendimento por partes.

Comece pelo mais simples: multiplayer local

Antes de pensar em internet, considere o multiplayer local. Nele, os dois carros rodam na mesma máquina, em tela dividida ou na mesma pista, cada jogador num controle ou num conjunto de teclas. Não existe rede, não existe latência, não existe sincronização. Os dois carros são apenas dois objetos na mesma cena, lendo entradas diferentes. É o ponto de partida mais honesto, porque você monta a jogabilidade (direção, aceleração, colisão, voltas) sem nenhuma das dores da rede.

Se o seu objetivo era jogar no sofá com um amigo, isso já resolve, e você economiza semanas de trabalho. Se o seu objetivo é online pela internet, o local ainda vale como primeira etapa: você valida que o carro é divertido de dirigir antes de embrulhar tudo em rede. Eu sempre recomendo nascer local e crescer para online, nunca o contrário. Se quiser ver a base de um carro na Godot antes de duplicar, o carro top-down 2D na Godot cobre a direção e a física de um veículo single-player que você vai reaproveitar aqui.

O salto para o online: por que o carro é difícil

Quando você coloca os dois carros em máquinas separadas, cada cópia do jogo só enxerga o próprio mundo. O carro do seu amigo, na sua tela, é só um desenho que você precisa atualizar com a informação que chega pela rede. E aí mora o problema: a rede não entrega essa informação instantaneamente nem a cada quadro. Ela chega em pacotes, com atraso e em intervalos. Se você simplesmente colar a última posição recebida no carro remoto, ele vai andar aos pulos, teleportando de um ponto a outro.

Por isso o carro é o exemplo clássico onde técnicas de suavização importam. Você recebe poucas atualizações por segundo da posição do carro remoto, mas precisa desenhar sessenta quadros por segundo. A diferença entre travar e fluir é o que você faz nesse meio. É um problema de rede, não de física, e é o coração do trabalho de um jogo de corrida online. Antes de seguir, vale fixar os fundamentos gerais de rede em como fazer um jogo multiplayer, porque tudo daqui pra frente se apoia neles.

Host e cliente: quem manda no carro

Agora a pergunta decisiva: quem decide onde o carro realmente está? Se cada máquina simular a própria física e também a do adversário por conta própria, as duas vão divergir em segundos. Uma acha que o carro bateu no muro, a outra acha que passou reto. A corrida vira duas realidades diferentes. A solução é a autoridade: alguém precisa guardar a versão oficial do estado.

No modelo host e cliente, um dos jogadores (ou um servidor) assume o papel de host. Ele simula a física oficial de todos os carros e manda o resultado para os clientes, que seguem o que o host diz. Isso impede a divergência e também corta a trapaça, porque um cliente não consegue simplesmente declarar que ganhou a corrida: quem valida é o host. Esse é o modelo de autoridade de servidor, e eu explico ele a fundo em autoridade de servidor na Godot. Na Godot você marca qual nó é autoridade de qual par e usa isso para decidir quem simula o quê.

Sincronizar a física do carro na prática

Com o host definido como autoridade, o que você transmite? No mínimo, para cada carro: posição, rotação e velocidade. A velocidade importa muito no carro, porque ela permite ao cliente prever para onde o carro vai entre uma atualização e a próxima, mantendo o movimento suave em vez de esperar o próximo pacote parado. Na Godot, o nó MultiplayerSynchronizer automatiza boa parte desse envio: você aponta quais propriedades sincronizar e ele cuida de mandar as mudanças para os pares.

Aqui vai um recorte tipado de como o host aplica a entrada e o resultado é propagado. A entrada do jogador vira movimento só na autoridade, e a posição resultante é o que os clientes recebem:

extends CharacterBody2D

@export var aceleracao: float = 600.0
@export var velocidade_max: float = 400.0
@export var atrito: float = 300.0

func _physics_process(delta: float) -> void:
    if not is_multiplayer_authority():
        return
    var entrada: float = Input.get_axis("freio", "acelerar")
    var direcao: Vector2 = Vector2.RIGHT.rotated(rotation)
    velocity += direcao * entrada * aceleracao * delta
    velocity = velocity.limit_length(velocidade_max)
    velocity = velocity.move_toward(Vector2.ZERO, atrito * delta)
    move_and_slide()

Repare no is_multiplayer_authority(): só a máquina que manda naquele carro roda a física. Nas outras máquinas, o mesmo carro só recebe a posição via sincronizador e é desenhado. Esse padrão (simular só na autoridade, replicar nas demais) é o que mantém todo mundo na mesma corrida.

Interpolação e previsão: disfarçando a latência

Receber a posição não basta, porque ela chega atrasada e espaçada. No cliente, você interpola o carro remoto: em vez de pular direto para a última posição recebida, você desliza ele suavemente entre a posição atual e a nova, ao longo de alguns quadros. O olho enxerga movimento fluido mesmo com poucas atualizações por segundo. Para o próprio carro do jogador, a técnica é a previsão no cliente: você move o carro na hora, respondendo ao controle sem esperar o host, e corrige se o host discordar. O jogador sente resposta imediata e as pequenas correções passam despercebidas na maioria das vezes. Essas duas técnicas são o que fazem um carro online parecer bom, e eu aprofundo o tema em otimização de latência em multiplayer.

Eventos da corrida: voltas, batidas e o fim

Além do movimento contínuo, uma corrida tem eventos discretos: cruzou a linha de chegada, completou uma volta, bateu, pegou um item. Esses eventos devem ser decididos pelo host, nunca pelo cliente sozinho, pelo mesmo motivo de sempre: evitar divergência e trapaça. Na Godot você usa RPC para isso. O cliente avisa a sua intenção, o host valida e dispara o evento oficial para todos. "Jogador cruzou a linha" é uma decisão do host que ele anuncia para a sala inteira, e aí o placar bate em todas as telas.

Esse desenho (física contínua sincronizada pela autoridade, eventos discretos validados pelo host) é a espinha de um jogo de carro multiplayer sólido. Se você montou tudo até aqui na rede local, conectar por IP entre dois computadores da mesma casa é o teste mais fácil, coberto em conectar por IP na rede local.

Local, online e a decisão de arquitetura

Fechando o caminho: você viu que local é o começo mais simples, que o online exige autoridade de host e sincronização de física, e que interpolação e previsão são o que deixam o carro suave. Falta uma decisão grande, que muda o custo e a segurança do seu projeto: usar P2P (ou host e cliente) ou um servidor dedicado. Para uma corrida casual entre amigos, o host e cliente resolve sem gastar com infraestrutura. Para um jogo competitivo com ranking, onde trapaça é um problema real, o servidor dedicado passa a fazer sentido. Eu comparo os dois modelos em P2P ou servidor dedicado, e se você está em dúvida de qual engine usar para esse tipo de jogo, veja a melhor engine para jogo multiplayer.

O resumo que eu quero que fique: comece pequeno, valide o carro dirigindo bem no local, só então embrulhe em rede, deixe o host mandar na física e use interpolação para disfarçar a distância. Multiplayer de carro parece intimidante, mas é só uma sequência de decisões simples tomadas na ordem certa.