Quelqu'un sait-il s'il existe une meilleure pratique pour l'étiquetage des versions de jeux?
Je ne sais pas s'il existe un nom standard autre que le versioning, mais ce que je veux dire est essentiellement:
Il n'y a pas de norme, mais vous devez le faire d'une manière qui vous convient et qui contient toutes les informations dont vous pourriez avoir besoin pour suivre cette construction. J'ai travaillé pour une entreprise qui l'a essentiellement ventilé comme ceci:
[Numéro de build majeur]. [Numéro de build mineur]. [Révision]. [Package]
ie Version: 1.0.15.2
Numéro de build majeur : cela indique un jalon majeur dans le jeu, incrémentez-le lorsque vous passez de la version bêta à la version, de la version aux mises à jour majeures.
Numéro de build mineur : utilisé pour les mises à jour de fonctionnalités, les grandes corrections de bugs, etc.
Révision : modifications mineures sur les fonctionnalités existantes, petites corrections de bugs, etc.
Package : votre code reste le même, les modifications de la bibliothèque externe ou la mise à jour du fichier d'actif.
Les modifications combinées passent au changement le plus significatif. Par exemple, si vous incrémentez le numéro de build mineur, la révision et le package sont tous les deux réinitialisés à 0.
Même si les catégories sont définies, il existe toujours une ambiguïté quant au type de fonctionnalités qui se croisent réellement entre une révision et un numéro de version mineur. C'est à vous. Si vous faites des listes des fonctionnalités qui devront être implémentées avant chaque incrément, vous aurez également un plan à suivre, mais à la fin, c'est à vous de décider ce qui rentre dans chaque catégorie.
Stack Overflow a une grande discussion à ce sujet appelée Comment faire des numéros de version , qui fait référence au Guide de style de version .
Sommaire:
la source
Pour autant que je sache, il n'y a pas de norme pour cela. La pratique variera selon les entreprises, les équipes et les projets: il n'y a pas de meilleure pratique. La chose la plus importante n'est pas la convention proprement dite, mais le fait que tout le monde s'y tient.
Cela dit, le schéma que vous avez mentionné est assez courant pour les jeux sortis. 1.0 sera typiquement le maître d'or, et les correctifs commenceront à partir de là: 1.1, 1.2 ... Il est également utilisé dans les versions client pré-version telles que les bêtas privées ou ouvertes.
Pour les jeux en développement, j'ai rarement vu ce système utilisé. Il est beaucoup plus courant de faire référence à une construction par son ID de changement atomique (par exemple le numéro de liste de modifications Perforce). Cela est particulièrement utile pour un projet de taille moyenne où tout (code et ressources) est stocké sur le même référentiel et une intégration continue est en place. Dans ce cas, avoir à la fois un numéro de modification atomique et un numéro de version est redondant et sujet aux erreurs. Certaines versions seront promues à un jalon après QA: alpha, bêta, version candidate et étiquetées comme telles.
Pour les grands projets, le concept simple de "version jeu" ne s'applique plus. Vous aurez plusieurs plates-formes, SKU, langues, mode solo, mode multi-joueurs, etc. La gestion des versions devient alors un travail à temps plein (parfois appelé gestionnaire de données - c'est la terminologie d'Ubisoft, probablement appelée différemment ailleurs) , le schéma d'étiquetage est alors beaucoup plus complexe et très dépendant du jeu réellement réalisé.
la source