Como Fazer um Jogo Multiplayer no GDevelop

Se voce chegou aqui procurando como fazer um jogo multiplayer no GDevelop, a primeira coisa que preciso dizer e boa e ruim ao mesmo tempo: da para fazer sem escrever uma linha de codigo, mas multiplayer nunca e um recurso que voce simplesmente liga. E uma forma diferente de pensar o seu jogo. Neste post vou te guiar pela ideia geral, pelos recursos reais que o GDevelop oferece e, principalmente, pelo caminho honesto de comecar pequeno em vez de tentar recriar um jogo online gigante no primeiro dia.

O GDevelop funciona com eventos, aquele sistema de condicoes e acoes que voce monta arrastando blocos. Isso significa que a parte da rede tambem vai ser montada assim, sem sintaxe de programacao. So que nao se engane: a dificuldade do multiplayer nunca esteve na sintaxe. Ela esta em entender que voce vai ter dois jogos rodando ao mesmo tempo, em maquinas diferentes, e que eles precisam concordar sobre o que esta acontecendo. Esse e o verdadeiro desafio, e nenhum motor no-code apaga ele.

O que muda quando o jogo deixa de rodar sozinho

Um jogo single-player vive dentro de uma maquina so. Quando o personagem se move, a posicao dele existe ali, na memoria daquele aparelho, e ninguem mais precisa saber. No momento em que voce coloca dois jogadores em maquinas separadas, essa verdade se quebra. Cada copia do jogo so enxerga o proprio mundo, e voce passa a ter a obrigacao de contar para a outra copia o que aconteceu do seu lado.

Vale separar dois cenarios que muita gente confunde. Existe o multiplayer local, em que dois ou mais jogadores compartilham a mesma tela e o mesmo jogo rodando (pense em dois personagens na mesma cena, cada um num controle ou num conjunto de teclas). Ai nao ha rede nenhuma, nao ha internet, e tudo continua acontecendo dentro de uma unica maquina. Esse tipo e absurdamente mais simples, porque nao existe distancia entre os jogadores nem informacao para transmitir. Se o seu objetivo e um jogo de sofa, comece por ele, porque metade das dores de cabeca do multiplayer some.

O outro cenario e o multiplayer online, em que cada jogador esta na sua propria maquina, possivelmente em outra cidade. Ai sim entra a rede, a latencia, a sincronizacao. Quando as pessoas perguntam como fazer um jogo multiplayer no GDevelop pensando em jogar com um amigo pela internet, e desse segundo caso que estao falando, e e nele que vou focar a maior parte do texto.

A ideia de peer-to-peer, ou os jogadores conversando direto

O GDevelop tem um recurso de comunicacao peer-to-peer, o famoso P2P, construido sobre uma tecnologia de web chamada WebRTC. O nome assusta, mas a ideia e simples e ate elegante. Peer-to-peer quer dizer que os jogadores conversam diretamente um com o outro, sem um servidor central segurando a partida inteira nas costas. O jogo do seu amigo manda dados para o seu jogo, o seu manda de volta, e assim os dois se mantem atualizados.

Ai vem a duvida obvia: se eles conversam direto, como um encontra o outro na imensidao da internet? E aqui entra a unica peca central que existe nesse modelo. Precisa haver um intermediario leve, um ponto de encontro cuja unica funcao e apresentar os jogadores. Ele troca os enderecos, faz a apresentacao e sai de cena. Depois desse aperto de mao inicial, a conversa de verdade acontece direto entre as maquinas. Pense num garcom que so leva voce ate a mesa do seu amigo e vai embora, deixando voces dois conversando sozinhos. Esse intermediario e leve justamente porque nao carrega o jogo, so faz a apresentacao.

Esse desenho tem uma consequencia pratica que voce precisa gravar: P2P e otimo para poucos jogadores e para prototipos. Com uma dupla ou um grupinho pequeno, funciona muito bem e sem custo de infraestrutura pesada. O problema aparece quando a quantidade de gente cresce, porque cada jogador precisa manter conexao com os outros e a quantidade de informacao trafegando explode. Vou voltar nesse limite mais para o final, porque ele e o divisor de aguas entre um projeto realista e uma frustracao garantida.

O modelo de host: alguem precisa mandar

Imagine dois jogadores numa partida e uma pergunta boba: quantos inimigos existem na tela agora? Se cada copia do jogo decidir isso por conta propria, elas vao divergir em segundos. Uma acha que o inimigo morreu, a outra acha que ele ainda esta vivo, e o jogo vira uma bagunca onde ninguem concorda com nada. Para resolver isso, o multiplayer trabalha com a ideia de autoridade.

Na pratica, um dos jogadores assume o papel de host. Ele e o dono da partida. O host guarda a versao oficial do estado do jogo, aquilo que realmente vale: o placar, quantos inimigos existem, quem esta vivo, quem pegou qual item. Os outros jogadores seguem o que o host diz. Quando ha um conflito, a palavra final e dele. Isso nao e um detalhe tecnico chato, e o que impede o seu jogo de virar duas realidades paralelas.

Isso muda a forma como voce pensa a logica dos seus eventos. Certas decisoes so o host deve tomar. Se cada jogador puder decidir sozinho que derrotou o chefe, voce vai ter dois finais diferentes acontecendo ao mesmo tempo. Entao voce desenha o jogo para que as coisas importantes passem pelo host, e os demais recebam o resultado. E um jeito diferente de organizar a cabeca, mas depois que cai a ficha, muita coisa fica mais simples de raciocinar.

Sincronizar posicao e variaveis: o coracao do trabalho

Chegamos na parte onde voce vai passar a maior parte do tempo. Sincronizar significa fazer com que uma informacao que existe no jogo de um jogador apareca, atualizada, no jogo do outro. O exemplo mais claro e a posicao dos personagens. Quando o seu amigo anda para a direita, o jogo dele sabe da nova posicao, mas o seu jogo nao faz ideia ate que essa informacao atravesse a rede. Voce precisa, entao, mandar a posicao dele de tempos em tempos, e o seu jogo usa esse dado para mover o boneco do amigo na sua tela.

Alem da posicao, ha as variaveis. Vida, pontuacao, estado de um item, se uma porta esta aberta ou fechada. Tudo isso e informacao que precisa ser combinada entre os jogadores para que a partida faca sentido. A logica e sempre a mesma: quando algo muda de um lado, esse lado avisa o outro, e o outro atualiza a sua copia. Parece trivial escrito assim, mas o segredo esta em escolher o que sincronizar e com que frequencia, porque mandar informacao demais deixa o jogo pesado, e mandar de menos deixa ele com aquela sensacao de que os personagens teletransportam.

Aqui aparece o incomodo classico do multiplayer, a latencia. A informacao leva um tempinho para ir e voltar pela internet, e nesse intervalo o outro jogador ja se moveu mais um pouco. Por isso os jogos online usam truques para suavizar o movimento, fazendo o personagem deslizar ate a nova posicao em vez de saltar seco. Voce nao precisa dominar isso no comeco, mas e bom saber que aquele engasgo nao e necessariamente um bug seu, e sim a fisica da rede aparecendo. Se voce estudar como isso e resolvido em geral, vai ver que a ideia se repete em qualquer motor, seja no GDevelop, seja em Godot ou Unity, com nomes diferentes mas o mesmo problema por baixo.

Lobbies: juntando os jogadores antes da partida

Alem do P2P mais cru, o GDevelop ganhou um recurso mais recente voltado a lobbies de multiplayer. A ideia de um lobby e aquela sala de espera onde os jogadores se reunem antes de comecar. E ali que as pessoas entram, veem quem mais esta na partida e disparam o inicio quando o grupo esta pronto. Esse tipo de recurso alivia parte do trabalho de conectar os jogadores, porque cuida da etapa de organizar quem vai jogar com quem antes de a acao comecar.

Nao vou inventar telas, nomes de menu ou passos exatos, porque esses detalhes mudam com o tempo e a documentacao oficial e o lugar certo para conferir. O que importa entender e o conceito: um lobby existe para resolver o encontro entre jogadores de um jeito mais amigavel do que trocar codigos de conexao na mao. Se voce for por esse caminho, siga a documentacao atual do GDevelop e teste cada etapa com calma, porque a interface e o fluxo evoluem entre versoes.

O conselho honesto: comece com dois jogadores e pouca coisa

Se ha uma unica coisa para levar deste post, e esta. Nao tente fazer um jogo online de trinta pessoas no seu primeiro projeto de rede. Comece com dois jogadores e o minimo de informacao sincronizada possivel. Sincronize so a posicao de cada um e talvez uma variavel simples, como pontos. Faca esses dois personagens andarem pela tela e se enxergarem. So isso ja envolve host, conexao, sincronizacao e latencia, ou seja, todos os conceitos fundamentais ao mesmo tempo.

Quando essa base minima estiver funcionando, ai voce adiciona uma coisa de cada vez. Um tiro que precisa aparecer para os dois. Um inimigo controlado pelo host. Um placar que se mantem igual nas duas telas. Cada acrescimo vai te ensinar mais do que qualquer tutorial, porque vai te forcar a pensar quem tem autoridade sobre aquilo e como a informacao viaja. Multiplayer se aprende por camadas, e pular camada e a receita mais rapida para um projeto travado e abandonado.

Vale reforcar o limite do P2P com todas as letras, sem hype. Peer-to-peer brilha em jogos de poucos jogadores e em prototipos, e para a maioria dos projetos de quem esta comecando, isso e mais do que suficiente. Um jogo cooperativo para dois amigos, um duelo, um pequeno grupo, tudo isso e territorio confortavel. Agora, jogos grandes com muita gente na mesma partida pedem outra coisa: um servidor autoritativo, uma maquina central que roda o jogo de verdade e que todos os jogadores obedecem. Esse modelo aguenta muito mais gente e e mais dificil de trapacear, mas e outro nivel de complexidade e de custo. Voce entra em territorio de infraestrutura paga, e vale entender o custo de servidor de um jogo online antes de mirar tao alto. Prometer que o P2P vai segurar um jogo online massivo seria mentira, e prefiro te poupar dessa decepcao.

Por onde seguir

Multiplayer e um daqueles assuntos que parecem impossiveis de longe e viram naturais depois que voce faz o primeiro personagem de outra pessoa aparecer na sua tela. Aquele momento e magico, e vale todo o esforco de entender host, sincronizacao e os limites da rede. O GDevelop te da os recursos reais para chegar la sem escrever codigo, mas quem faz o jogo concordar consigo mesmo e voce, com bons eventos e boas decisoes de arquitetura.

Se voce quer a visao mais ampla, indo alem do GDevelop e comparando abordagens, vale ler o nosso guia pilar sobre como fazer um jogo multiplayer, que amarra os conceitos que vimos aqui num panorama maior. E se voce estiver na duvida entre motores no-code, da uma olhada em como fazer um jogo multiplayer no Construct, porque comparar como cada ferramenta resolve o mesmo problema deixa o conceito muito mais claro na sua cabeca. No fim, o motor e detalhe. O que fica com voce e a forma de pensar rede, e essa voce leva para qualquer projeto.