Quanto Custa Manter um Jogo Online? A Conta do Servidor

Se você está planejando um jogo multiplayer, precisa encarar uma pergunta antes de escrever a primeira linha de netcode: qual é o custo de servidor de um jogo online, e quem paga essa conta depois do lançamento? A resposta incomoda porque quase ninguém mostra. Vídeos de devlog celebram a primeira partida sincronizada, tutoriais ensinam a conectar dois clientes, e ninguém abre a planilha do que significa manter aquilo no ar por anos. Este post abre a planilha. Não com preços inventados de provedor, que mudam todo mês e variam por região, mas com a estrutura da conta: quais modelos de arquitetura existem, quais variáveis fazem o número subir e quais custos ficam escondidos até ser tarde demais.

A intenção aqui é simples: te dar o mapa pra você decidir, de olhos abertos, se o seu projeto aguenta ser online. Porque prometer "multiplayer" na página da Steam é assinar um contrato de custo recorrente, e contrato se lê antes de assinar.

Jogo online é custo para sempre, single-player termina no lançamento

Essa é a diferença que muda tudo, e vale gastar um parágrafo nela porque é o erro de planejamento mais comum.

Um jogo single-player tem estrutura de custo de produto: você investe tempo e dinheiro na produção, lança, e a partir dali cada venda é quase toda margem. O jogo funciona no computador do jogador. Se você nunca mais tocar no projeto, ele continua jogável daqui a dez anos.

Um jogo online tem estrutura de custo de serviço: a produção é só a entrada. Depois do lançamento, todo mês chega a fatura de servidor, banda, banco de dados e ferramentas. E ela chega independente de venda. Se o jogo flopar, você paga pra manter servidores vazios ou desliga e enfrenta os jogadores que compraram. Se o jogo estourar, a conta cresce junto com o sucesso, porque mais jogadores simultâneos significam mais máquinas.

Repare no paradoxo: no single-player, sucesso é só receita. No online, sucesso é receita e custo ao mesmo tempo. Por isso jogos online de estúdio grande são desenhados desde o início com monetização recorrente, passes, cosméticos, assinatura. Não é ganância aleatória: é a natureza do serviço cobrando.

Se você ainda está decidindo se multiplayer faz sentido pro seu momento, o post sobre se vale a pena fazer jogo multiplayer sendo iniciante trata da decisão pelo lado da complexidade técnica. Aqui o foco é o lado financeiro, que costuma ser o golpe seguinte.

Custo de servidor de jogo online: os quatro modelos de arquitetura

Não existe "o" custo de servidor. Existe uma escada de arquiteturas, e cada degrau tem uma ordem de grandeza diferente. Você escolhe o degrau quando escolhe o design do jogo.

Modelo 1: peer-to-peer com host do jogador. Custo de servidor: quase zero. Um dos jogadores hospeda a partida na própria máquina e os outros conectam nele. Você não paga máquina rodando simulação de jogo. O "quase" existe porque, na prática, os jogadores precisam se encontrar: um serviço de lobby ou relay pra atravessar NAT e firewall quase sempre entra na equação, e alguns têm camada gratuita que atende jogos pequenos. O preço real do P2P não é financeiro: é vantagem de latência pro host, fragilidade contra cheat (a máquina de um jogador é a autoridade) e partida que morre quando o host desconecta. Pra co-op casual entre amigos, é frequentemente a escolha certa. Pra competitivo, raramente.

Modelo 2: servidor dedicado alugado. Custo mensal recorrente e previsível. Você aluga máquinas de um provedor de nuvem ou de hosting e roda nelas a versão servidor do seu jogo. Agora existe uma autoridade neutra, o que resolve cheat e vantagem de host, e a partida não depende de nenhum jogador. Em troca, a fatura chega todo mês, e ela escala com o número de partidas simultâneas: cada partida ocupa uma fatia de CPU e memória, e quando as máquinas enchem, você aluga mais. É o modelo padrão de jogos de sala (partidas de 2 a 16 jogadores) com pretensão competitiva.

Modelo 3: serviços gerenciados de relay, matchmaking e orquestração. Custo por uso. Entre o P2P puro e o servidor alugado na mão existe uma camada de serviços que resolvem pedaços do problema: relay de tráfego, matchmaking, listagem de salas, orquestração que liga e desliga servidores conforme a demanda. O modelo de cobrança costuma ser por uso, por jogador conectado, por gigabyte trafegado ou por hora de servidor. A vantagem é não pagar por máquina parada e não construir infraestrutura. A desvantagem é que o custo por unidade é maior do que operar na mão, e você fica acoplado ao fornecedor. Pra indie, é quase sempre o melhor custo-benefício inicial: começa barato, escala junto, e a engenharia que você economiza vale mais do que a diferença de tarifa.

Modelo 4: infraestrutura própria de mundo persistente. O degrau mais caro que existe. É o modelo do MMO: servidores ligados 24 horas por dia mesmo sem ninguém online, porque o mundo persiste. Banco de dados de contas, inventário e economia com backup e redundância. Equipe de operação pra acordar de madrugada quando cai. Não é uma conta de servidor, é uma folha de pagamento com servidores dentro. Se esse é o seu sonho, leia antes o raio-x completo de como fazer um MMORPG e o que ele exige de verdade, porque o custo de infraestrutura é só um dos monstros da lista.

A regra prática: cada degrau dessa escada multiplica a conta. E o design do jogo, não a engine, é o que define o degrau. Um jogo de turnos assíncrono e um shooter competitivo de 60 tickrate podem ser feitos na mesma Godot, mas vivem em planetas financeiros diferentes.

As variáveis da conta: o que faz o número subir

Já que preço de provedor muda toda hora, o que vale a pena aprender é a fórmula. A conta de servidor de qualquer jogo online é dominada por quatro variáveis:

Jogadores simultâneos (CCU). A variável mestre. Não importa quantas cópias você vendeu, importa quantas pessoas estão online ao mesmo tempo no pico. É o pico que dimensiona a infraestrutura, porque servidor caindo no horário nobre é a pior propaganda possível. E o pico é traiçoeiro: no dia do lançamento ou numa promoção, ele pode ser dez vezes a média. Você paga pela capacidade do pico ou usa orquestração elástica que acompanha a demanda.

Região. Latência não perdoa distância. Se você quer servir bem jogadores do Brasil, Europa e Ásia, precisa de servidores nas três regiões, e cada região é uma infraestrutura replicada. Muitos indies começam com uma região só, e isso é uma decisão de escopo legítima: atender bem uma região é melhor do que atender mal o mundo.

Tráfego. Cada estado sincronizado (posição, rotação, vida, projéteis) vira bytes por segundo multiplicados pelo número de jogadores. Provedores cobram por dado que sai do servidor, então um jogo que sincroniza tudo pra todos paga essa gula em dinheiro. Técnicas de otimização de rede reduzem a conta diretamente, e o post sobre netcode e otimização de latência em multiplayer mostra como isso se faz na prática.

Tickrate. Quantas vezes por segundo o servidor simula o mundo e envia atualizações. Tickrate maior significa jogo mais responsivo e mais CPU e banda consumidas por partida, ou seja, menos partidas por máquina, ou seja, mais máquinas. Um jogo de cartas vive bem com poucos ticks por segundo. Um shooter competitivo quer dezenas. Essa escolha de design é uma escolha de custo.

Monte sua estimativa assim: pico de CCU esperado, dividido em partidas, vezes o custo de CPU e banda de cada partida, vezes o número de regiões. Preencha com os preços atuais do provedor que você pesquisar no dia. O exercício de montar a fórmula vale mais do que qualquer número que eu poderia chutar aqui.

O custo escondido: o que a planilha de servidor não mostra

A fatura da nuvem é a parte visível. O que quebra projetos costuma ser o resto:

Manutenção contínua. Sistema operacional do servidor precisa de atualização de segurança. Dependências envelhecem. A plataforma muda API. Nada disso adiciona feature ao jogo, e tudo isso consome suas horas todo mês, pra sempre. Hora de dev é o custo mais caro da planilha, mesmo quando o dev é você e "não custa nada".

Moderação e suporte. Onde dois estranhos se encontram online, aparecem toxicidade, golpe e denúncia. Alguém precisa responder. Chat aberto multiplica o problema. Muitos indies cortam chat de texto livre exatamente por isso, e é uma decisão de custo tão real quanto escolher provedor.

Segurança e cheat. Jogo online é alvo. Cheaters afastam jogadores legítimos, e ataques de negação de serviço em jogos pequenos existem, às vezes vindos de um único jogador banido e rancoroso. Mitigar isso tem custo em serviço e em tempo.

O dia de desligar. Todo jogo online morre um dia, e o desligamento é um custo que ninguém orça. Se o jogo exige servidor pra funcionar, desligar significa apagar o produto da biblioteca de quem pagou. A pressão de comunidade e de consumidor em cima disso só cresce, com movimentos públicos cobrando que jogos comprados permaneçam jogáveis. O plano barato se faz no início: um modo offline, suporte a servidor hospedado pela comunidade, ou ao menos honestidade na página da loja sobre a dependência de servidor. Adicionar isso depois é reescrever arquitetura.

Alternativas de escopo que cortam a conta sem matar o jogo

A boa notícia: "jogar junto" não exige servidor dedicado. Existe um cardápio de conexão entre o offline e o MMO, e ele é a principal ferramenta de corte de custo:

Co-op local e tela dividida. Dois controles, um sofá, custo de servidor zero. E com as ferramentas de streaming de jogo que as plataformas oferecem, amigos remotos conseguem entrar numa sessão local sem você escrever uma linha de rede.

Multiplayer assíncrono. Rankings, fantasmas de corrida, mensagens deixadas no mundo, turnos por notificação. Os jogadores se sentem acompanhados sem nunca estarem conectados ao mesmo tempo. O backend disso é um serviço web simples e barato, ordens de grandeza abaixo de simulação em tempo real.

Salas P2P pequenas. Co-op de 2 a 4 jogadores com host do jogador e um relay leve pra conexão. É o formato de milhares de indies de sucesso, cabe no bolso e entrega a experiência de jogar com amigos.

A pergunta certa de design não é "como faço multiplayer" e sim "qual é a menor forma de conexão que entrega a fantasia do meu jogo". Muitas vezes a resposta corta 90 por cento da conta.

Checklist antes de prometer "online" na página da Steam

Prometer online em público é o ponto sem volta. Antes disso, responda por escrito:

1. Qual modelo de arquitetura o design exige? P2P, dedicado alugado, serviço gerenciado ou persistente? Se a resposta for "persistente", volte dois passos e questione o design.
2. Qual é o pico de CCU realista no lançamento? Não o dos sonhos, o realista. E a infraestrutura aguenta dez vezes isso por um fim de semana?
3. Quantas regiões no dia 1? Uma é uma resposta aceitável. Diga isso com clareza.
4. Quem paga a fatura no mês 24? Se o jogo vender pouco, você banca o servidor por quanto tempo? Se vender muito, a monetização cobre o custo que cresce junto?
5. Qual é o plano de fim de vida? Modo offline, servidor comunitário ou aviso honesto de dependência de servidor?
6. Quem modera? Existe chat? Existe denúncia? Existe alguém pra ler as denúncias?
7. O jogo sobreviveria sem online? Se sim, considere lançar single-player primeiro e adicionar online depois de validar que alguém quer o jogo. Servidor vazio é o custo mais triste que existe.

Se você travou em duas ou mais perguntas, o projeto não está pronto pra promessa. E tudo bem: cortar "online" do escopo antes do anúncio é planejamento. Cortar depois é crise.

A conta do servidor não deve te assustar pra longe do multiplayer, deve te colocar no degrau certo da escada. Jogo online bem dimensionado é um serviço saudável. Jogo online prometido no impulso é uma assinatura mensal que você fez em nome do seu eu do futuro. Monte a fórmula, escolha a arquitetura pelo design, planeje o fim de vida, e aí sim escreva o netcode.