Configurar e manter um servidor dedicado para um sandbox de sobrevivência
Um servidor dedicado não é a mesma partida jogada com mais pessoas: é uma infraestrutura que tem de se manter de pé mesmo quando ninguém está ligado. A diferença sente-se à primeira paragem imprevista, quando se percebe que a última gravação útil é de há quarenta minutos. Este guia reúne os critérios que realmente contam, por ordem de impacto.
Dimensionar o equipamento pelas grandezas certas
A quase totalidade dos servidores para sandbox de sobrevivência é composta por um processo predominantemente monolítico: alguns subsistemas correm em threads separadas, mas o ciclo de simulação principal continua ligado a um único núcleo. Daí decorre uma regra operacional pouco intuitiva: entre um processador com muitos núcleos lentos e outro com poucos núcleos rápidos, para esta carga compensa o segundo. O número de núcleos serve para evitar que cópias de segurança, compressão e processos de sistema roubem tempo ao ciclo principal, não para aumentar a capacidade de jogo.
A memória consome-se em proporção à superfície de mundo carregada e ao número de entidades construídas. Uma base madura com milhares de elementos construídos e centenas de contentores ocupa muito mais do que o requisito mínimo declarado sugere. É prudente encarar o valor mínimo como ponto de partida e prever pelo menos o dobro se o mundo tiver de durar meses.
O disco conta num único momento, mas é um momento crítico: a gravação, quando todo o estado é serializado e escrito. Num disco mecânico esta operação produz um bloqueio percetível por todos os jogadores ligados. Uma unidade de estado sólido reduz o fenómeno; separar o volume das cópias de segurança do das gravações ativas elimina-o quase por completo.
Os parâmetros que decidem o carácter do servidor
Cada título usa nomes diferentes, mas as opções que realmente alteram a experiência são poucas e recorrentes.
| Parâmetro | Efeito prático | Critério |
|---|---|---|
| Intervalo de gravação | Quantidade de progresso perdido em caso de paragem anómala | Intervalos curtos em mundos pequenos, mais longos em mundos grandes para evitar bloqueios frequentes |
| Tick rate | Reatividade da simulação e do combate | Aumentar só se o processador aguentar sem saturar o núcleo principal |
| Degradação das estruturas | Sobrevivência das bases durante as ausências | Deve ser comunicado com antecedência: define o horizonte de planeamento dos jogadores |
| Multiplicadores de recolha | Ritmo da progressão | Valores altos reduzem a logística a uma formalidade e encurtam a vida do mundo |
| Lugares de jogador | Carga global sobre a simulação | Melhor começar baixo e aumentar depois de medir os tempos de fotograma no servidor |
Um erro recorrente é alterar várias opções ao mesmo tempo ao primeiro sinal de lentidão. Se mudarem simultaneamente o tick rate, os lugares e o intervalo de gravação, nunca se saberá qual das intervenções produziu a melhoria. Uma alteração de cada vez, com pelo menos uma sessão completa de observação entre elas.
Gravações e cópias de segurança: duas coisas diferentes
A gravação automática serve à continuidade da partida; a cópia de segurança serve para reparar um dano. Confundi-las é a causa mais comum de perda definitiva de um mundo, porque uma gravação corrompida sobrescreve a anterior e, se não existir outra cópia, não há nada a recuperar.
Um esquema mínimo que funciona: cópias horárias mantidas durante um dia, cópias diárias mantidas durante uma semana, uma cópia semanal conservada por mais tempo, todas num volume diferente do de trabalho. A cópia deve ser verificada pelo menos uma vez, iniciando uma instância de teste sobre o ficheiro arquivado: uma cópia nunca testada é uma hipótese, não uma garantia.
Antes de cada atualização do servidor convém encerrar o processo de forma limpa e esperar que a gravação final esteja concluída. Interromper o processo durante a escrita é a maneira mais rápida de obter um ficheiro de mundo ilegível.
Atualizações e modificações
As atualizações são o momento de maior risco, sobretudo quando o servidor usa modificações de terceiros. Uma modificação compilada contra uma versão anterior pode impedir o arranque ou, pior, arrancar e escrever dados incompatíveis na gravação. A sequência segura é sempre a mesma: encerramento limpo, cópia de segurança completa, atualização do servidor, verificação das modificações uma a uma numa instância de teste e, só no fim, reabertura ao público.
Vale também a disciplina inversa: não instalar uma modificação num mundo ativo só para a experimentar. Muitas modificações acrescentam dados persistentes que permanecem na gravação mesmo depois de removidas, e limpá-los dá mais trabalho do que a experiência valia.
Monitorizar as coisas certas
Três indicadores bastam para perceber o estado de saúde de um servidor. O tempo de processamento por tick do lado do servidor diz se a simulação está a acompanhar; a ocupação de memória ao longo da sessão revela as fugas progressivas, que se manifestam como lentidão crescente ao fim de muitas horas; a duração da operação de gravação, se aumentar com o tempo, indica que o mundo está a acumular entidades acima do limiar gerível.
Quando a duração da gravação duplica face às primeiras semanas, o problema quase nunca é o equipamento: é o número de objetos abandonados, de estruturas já não utilizadas e de contentores dispersos. Uma limpeza periódica das ruínas inativas influencia mais o desempenho do que qualquer atualização de componentes.
Regras de jogo, não apenas ficheiros de configuração
Um servidor persistente é também um acordo entre as pessoas que o usam. Declarar antecipadamente o horizonte do mundo — se e quando será reposto — evita a frustração de quem investiu semanas numa construção. Do mesmo modo, indicar as janelas de manutenção permite aos jogadores não serem apanhados a meio de uma expedição longa. São pormenores que não constam de nenhum ficheiro de configuração, mas que determinam a longevidade de um servidor mais do que qualquer parâmetro numérico.