🌽🎲🎮

Tenho já há algum tempo algumas ideias para utilização de versionamento semântico em jogos analógicos, mas não com sua funcionalidade original. No lugar de usar o sistema e versões como controle de desenvolvimento, acredito que há como utilizá-lo para progressão de personagens ou mesmo para progressão de itens.

O que é versionamento semântico?

Você já deve saber instintivamente o que é sem conhecer o termo. Imagine que está procurando um software para baixar, e encontra as versões 5.3.2 e 5.2.7. Qual delas você baixa? Provavelmente disse a primeira, pois é a mais recente.

O versionamento semântico é uma série de guidelines para controle de versões em software, sobretudo aqueles cuja API (interface de programação) é pública, ou seja, que pode ser utilizada em outros projetos de software.

Essencialmente, são três números: MAIOR.MENOR.PATCH - pelos nomes deve ser fácil entender o que significam, mas há certas regras, como por exemplo:

• A primeira versão deve ter o valor MAIOR como zero (0.Y.Z), já que o software ainda é instável;
• A versão MENOR significa mudanças graduais que não quebram compatibilidade com versões anteriores;
• A versão MAIOR significa que houve mudanças que comprometem compatibilidade, portanto toda vez que aumentar, os valores MENOR e PATCH devem ser zerados;
• É possível denotar versões de pré-lançamento utilizando indicadores adicionais: 1.0.0-alpha.2.

Como usar isso?

Algumas ideias saltam à mente quando paramos para analisar que os números vão de 0 a 9, assim como um d10. Imaginemos que o personagem seria definido de alguma forma pelo versionamento semântico (mais sobre essa ideia adiante) e utilizemos os valores para rolagens.

Progressão de personagens e itens

• É possível traçar um sistema de progressão dinâmico e constante para personagens em jogos narrativos. Assim como em Pathfinder 2E (e outros jogos, como Dragon Age) a recompensa em pontos de experiência depende da magnitude do feito dos personagens (pequeno, médio ou grande), podemos usar isso no versionamento semântico.
  • Uma abordagem seria simplesmente distribuir pontos de experiência (ou evolução, atualização, dependendo do cenário) de apenas um dígito para cada feito dos personagens. Esses pontos seriam imediatamente somados ao PATCH, e se ele passar de 9 ele é zerado, a MENOR é aumentada em 1 e o processo continua.
    
    Ex.: considerando a versão 4.5.7
    O personagem recebe 5XP, o que leva sua versão para 4.6.2: três pontos levam-no a 4.6.0 e os restantes são incrementados ao PATCH.
    
    Esta abordagem também permite facilmente dividir os bônus de progressão (poderes, habilidades, etc.) dependendo do que foi atualizado. Contudo, como o tempo que leva-se para completar 10 atualizações em cada valor sobe exponencialmente, devemos lidar com um pouco de balanceamento:
    
    Aumentar o PATCH pode significar alguns pontos de vida ou bônus em algo já existente. MENOR permitiria que o jogador escolha novas características da "classe", possivelmente liberando possibilidades avançadas de acordo com o valor atingido (uma habilidade conseguida no "nível" 7 poderia ser melhor do que a do 3).
    
    Como o valor MAIOR será o mais demorado a atualizar, ele pode representar um marco importante para o personagem. Atualizou tudo e aumentou a MAIOR? Parabéns, você assume a narrativa para dizer algo incrível que acontece com seu personagem, ou algo do tipo. Isso permite que a MAIOR possa ser aumentada "manualmente" se fizer sentido na história, mesmo que o personagem ainda precisasse de "atualizações".

Três níveis de sucesso

• Esta ideia assume um sistema roll-under (rolar igual ou abaixo do valor). Como há três números, seria possível associar cada um deles a um nível de sucesso: nenhum sucesso é uma falha, sucesso em apenas um dos valores seria um sucesso com custo, sucesso em dois seria um sucesso normal e sucesso em três seria um sucesso vantajoso.
  
  Ex.: considerando a versão 4.5.3
  Rolagem: 6-7-8 (falha)
  Rolagem: 4-6-4 (sucesso com custo)
  Rolagem: 5-3-3 (sucesso normal)
  Rolagem: 3.2.1 (sucesso vantajoso)
  
  • Seria possível também utilizar o resultado da falha para determinar sua gravidade: verifique o maior número rolado no dado (afinal, é roll-under e números altos tendem a não ser bons). Se foi a rolagem do PATCH, é uma falha mínima. Se for a MENOR, uma falha moderada. Claro, se for a MAIOR, uma falha grave
• Igualmente, podemos usar a informação de qual valor falhou para determinar o custo de um sucesso, considerando também o maior resultado no dado: o PATCH indica um custo mínimo, a MENOR um custo moderado e a MAIOR um custo alto.
  
  Ex.: considerando a versão 4.5.3
  Rolagem: 3-3-6 (sucesso com custo mínimo)
  Rolagem: 3-6-2 (sucesso com custo moderado)
  Rolagem: 8-3-2 (sucesso com custo alto)
  
  
  • Um dos problemas com esta abordagem é quando os números são zerados, tornando a chance de sucesso naquele dado apenas 10% até a próxima atualização. Uma possível solução é que os itens utilizados pelos personagens podem de certa forma acoplar-se ao versionamento, fornecendo um valor de build (compilação do código, no uso original).
    
    Ex.: considerando a versão 5.0.0
    Já que o personagem acaba de atualizar, ele poderia considerar sua arma (build 56) para considerar sua versão como sendo 5.0.0-build.56. O que isso faria? Ele poderia considerar os valores MENOR e PATCH como 5 e 6, respectivamente. Extrapolando, o equipamento do personagem sempre poderia ser comparado com MENOR e PATCH, e valeria o maior número. Isso requer um potencial sistema de evolução para equipamentos e balanceamento, então fica apenas como ideia vaga.

Versões de teste

• Pegando carona no exemplo anterior, poderiam haver builds alpha e beta (e quem sabe gamma, delta, etc.) que seriam experimentais antes da atualização de fato. Algumas possíveis aplicações:
  • Ao atualizar (progredir) o personagem pode declarar que está numa "build beta" e escolher certas habilidades de progressão para experimentá-las e trocá-las como achar melhor até achar o que lhe apetece. Contudo ele não progride enquanto estiver em beta.
  • Para resolver o problema anterior de quando os valores são zerados, o jogador poderia entrar em fase beta sempre que um deles fosse zerado: closed beta para o PATCH e open beta para o MENOR (eu quis usar essa nomenclatura em algum lugar, sorry). Isto permitiria que ele utilizasse o valor anterior à atualização até que aqueles valores atualizem novamente.
    
    Ex.: considerando a versão 4.9.3 atualizada para 5.0.0-open.beta
    O jogador poderia continuar utilizando 9 e 3 para MENOR e PATCH até que ele progredisse novamente. Digamos que ele ganhe 12 XP em alguma ocasião, trazendo sua versão para 5.1.2, e dali em diante precisaria utilizar estes novos valores.

Por questões de temática, a meu ver uma ambientação tecnológica caberia com essa abordagem, mas quem não há maneiras de utilizar o conceito em outros estilos?