A economia é dado, não código

O problema de balancear caçando constante

Num jogo de progressão, balancear é o trabalho que nunca termina. O primeiro negócio está barato demais? O quinto degrau demora tempo demais para se pagar? O gerente custa o equivalente a quantos toques na bola? Essas perguntas voltam toda semana, e a resposta muda conforme o resto do jogo muda.

O jeito natural de escrever isso é o jeito errado: espalhar os números pelo código, um custoBase aqui, um multiplicador ali, um caso especial acolá. Funciona até a primeira vez que alguém pergunta "por que o quarto negócio parece pior que o terceiro?", e a resposta exige ler cinco arquivos para reconstruir a conta.

Pior: quando os números moram no código, testar um ajuste significa editar código, e editar código para testar ajuste é como você acaba com um balanceamento que ninguém entende, feito de remendos que cada um resolveu um sintoma diferente.

A economia inteira numa tabela

A decisão foi tirar tudo do código e colocar num arquivo de dados: custo inicial de cada negócio, quanto o preço cresce por unidade comprada, quanto cada ciclo rende, quanto dura o ciclo, quanto custa o gerente e onde ficam os marcos que multiplicam a produção. Dez negócios, um registro cada.

Com isso, balancear virou editar a tabela e rodar o simulador. O simulador percorre a progressão inteira e mostra quanto tempo leva para chegar em cada degrau, quanto rende cada linha e onde a curva trava. Nenhuma dessas perguntas exige abrir o jogo, e nenhuma exige tocar em código.

A armadilha do valor sem aspas

Repare que os valores de dinheiro naquele trecho estão entre aspas. Isso não é descuido, é regra, e ela existe por um motivo específico e cruel.

O último negócio da escada custa na casa dos 10^10, e o gerente dele passa de 10^12. Números assim ainda cabem num float. Mas a escada cresce, e o dia em que um valor passar de 10^308 escrito sem aspas, o leitor de JSON o converte para Infinity antes de qualquer validação rodar. O arquivo é válido, o jogo carrega, e um negócio inteiro passa a custar infinito.

Validar na carga, não no primeiro uso

A tabela é conferida no momento em que o jogo a carrega, não na primeira vez que alguém usa um campo. Marco fora de ordem, duração fracionária, negócio sem gerente, identificador repetido: tudo isso barra ali, com mensagem dizendo qual registro está errado.

A alternativa, que é o padrão quando ninguém decide nada, seria descobrir o problema no meio da partida de um jogador, na forma de um número estranho na tela.

E aqui vale a regra que mais gerou discussão no projeto: todo validador precisa ser testado com um caso sabidamente ruim. A pior classe de defeito nesse tipo de código nunca foi código errado: foi guarda que parou de guardar em silêncio. Um validador com um erro de lógica não encontra problema nenhum, e um validador que não encontra nada devolve exatamente a mesma resposta de um validador feliz: "tudo certo". Por isso o validador da tabela é testado contra uma dúzia de tabelas propositalmente quebradas, cada uma de um jeito diferente.

O que essa separação custa

Ela custa indireção. Para entender de onde vem um número na tela, agora é preciso olhar dois lugares: a tabela e a fórmula que a consome. É um custo real, e quem chega novo no código sente.

O que ela salva é maior. Balancear deixou de ser mexer no jogo: virou mexer num arquivo que não roda nada. O simulador responde em segundos o que levaria horas de partida para descobrir. E a mesma tabela que alimenta o jogo alimenta as páginas de conteúdo deste site: a tabela dos dez negócios é gerada dos mesmos dados, então ela nunca fica desatualizada em relação ao jogo de verdade.

Essa última parte não estava no plano. Ela apareceu de graça, que é o que costuma acontecer quando o dado está separado da regra.