Alguém sabe se existe uma prática recomendada para rotular versões de jogos.
Não tenho certeza se existe um nome padrão para ele além de versionamento, mas o que quero dizer é basicamente:
- 1.0
- 1.1
- 1.2
- 1.3.1 beta
Alguém sabe se existe uma prática recomendada para rotular versões de jogos.
Não tenho certeza se existe um nome padrão para ele além de versionamento, mas o que quero dizer é basicamente:
Respostas:
Não existe um padrão, mas você deve fazê-lo de uma maneira que faça sentido para você e contenha todas as informações necessárias para rastrear essa compilação. Eu trabalhei para uma empresa que basicamente a dividia assim:
[Número da versão principal]. [Número da versão secundária]. [Revisão]. [Pacote]
ie Versão: 1.0.15.2
Número principal da compilação : indica um marco importante no jogo, aumente isso ao passar do beta para o lançamento, do lançamento para as principais atualizações.
Número menor de compilação : usado para atualizações de recursos, grandes correções de bugs etc.
Revisão : Pequenas alterações nos recursos existentes, pequenas correções de bugs, etc.
Pacote : seu código permanece o mesmo, alterações na biblioteca externa ou atualização do arquivo de ativos.
As alterações combinadas passam para a alteração mais significativa. Por exemplo, se você estiver incrementando o número menor de compilação, a revisão e o pacote serão redefinidos para 0.
Mesmo que as categorias sejam definidas, ainda há ambiguidade para que tipo de recursos realmente se cruzam entre uma revisão e um número menor de compilação. Você decide. Se você fizer uma lista dos recursos que precisarão ser implementados antes de cada incremento, também terá um plano a seguir, mas no final é sua decisão o que se encaixa em cada categoria.
O Stack Overflow tem uma ótima discussão sobre isso chamada Como fazer números de versão , que faz referência ao Guia de estilo de versão .
Resumo:
Até onde eu sei, não existe um padrão para isso. A prática variará dependendo das empresas, equipes e projetos: não existe uma prática recomendada. O mais importante não é a convenção real, mas o fato de que todos aderem a ela.
Dito isto, o esquema que você mencionou é bastante comum para jogos lançados. A 1.0 será tipicamente o mestre de ouro e os patches começarão a partir daí: 1.1, 1.2 ... Também é usado em versões anteriores ao lançamento do cliente, como betas particulares ou abertas.
Para jogos em desenvolvimento, raramente vi esse sistema ser usado. É muito mais comum se referir a uma construção por seu ID de alteração atômica (por exemplo, número da lista de alterações Perforce). Isso é particularmente útil para um projeto de média escala, onde tudo (código e ativos) é armazenado no mesmo repositório e a integração contínua está em vigor. Nesse caso, ter um número de alteração atômica e um número de versão é redundante e propenso a erros. Algumas construções serão promovidas para um marco após o controle de qualidade: alfa, beta, candidato a lançamento e rotuladas como tal.
Para grandes projetos, o conceito simples de "versão do jogo" não se aplica mais. Você terá várias plataformas, SKUs, idiomas, modo single-player, modo multi-player, etc. O gerenciamento de versões se torna um trabalho em tempo integral (às vezes chamado de gerenciador de dados - essa é a terminologia da Ubisoft, provavelmente chamada de outra maneira). , o esquema de rotulagem é muito mais complexo e altamente dependente do jogo real.