Кто-нибудь знает, есть ли лучшая практика для маркировки версий игр.
Я не уверен, есть ли для него стандартное имя, кроме версии, но я имею в виду:
- 1,0
- 1,1
- 1.2
- 1.3.1 бета
Кто-нибудь знает, есть ли лучшая практика для маркировки версий игр.
Я не уверен, есть ли для него стандартное имя, кроме версии, но я имею в виду:
Ответы:
Стандартов нет, но вы должны делать это так, чтобы это имело смысл для вас и содержало всю информацию, которая вам может понадобиться для отслеживания этой сборки. Я работал в компании, которая, по сути, сломала его так:
[Основной номер сборки]. [Малый номер сборки]. [Редакция]. [Пакет]
т.е. версия: 1.0.15.2
Основной номер сборки : это указывает на важную веху в игре, увеличивайте ее при переходе от бета-версии к выпуску, от выпуска к основным обновлениям.
Малый номер сборки : используется для обновления функций, исправления крупных ошибок и т. Д.
Редакция : Незначительные изменения существующих функций, небольшие исправления ошибок и т. Д.
Пакет : Ваш код остается тем же, изменения внешней библиотеки или обновления файла актива.
Объединенные изменения переносятся на наиболее значительные изменения. Например, если вы увеличиваете младший номер сборки, ревизия и пакет оба сбрасываются в 0.
Несмотря на то, что категории определены, все еще существует неопределенность в отношении того, какие функции фактически пересекаются между редакцией и второстепенным номером сборки. Тебе решать. Если вы составите списки функций, которые необходимо будет реализовать перед каждым шагом, у вас также будет план, которым вы будете следовать, но в конце концов вы решите, что вписывается в каждую категорию.
Переполнение стека имеет отличную дискуссию по этому вопросу под названием « Как сделать номера версий» , которое ссылается на Руководство по стилю управления версиями .
Резюме:
Насколько я знаю, для этого нет стандарта. Практика будет варьироваться в зависимости от компаний, команд и проектов: нет такой вещи, как лучшая практика.Самое главное не фактическое соглашение, но факт, что все придерживаются этого.
Тем не менее, упомянутая схема довольно распространена для выпущенных игр. 1.0, как правило, будет золотым мастером, и с этого момента начнутся патчи: 1.1, 1.2 ... Он также используется в предварительных версиях для клиентов, таких как закрытые или открытые бета-версии.
Для игр в разработке я редко видел, чтобы эта система использовалась. Гораздо чаще встречается ссылка на сборку по ее атомарному идентификатору изменения (например, по номеру списка изменений Perforce). Это особенно полезно для проекта среднего масштаба, в котором все (код и ресурсы) хранятся в одном и том же хранилище, и существует постоянная интеграция. В этом случае, имеющие как атомный номер изменения и номер версии является излишним и подвержен ошибкам.Некоторые сборки будут повышены до уровня после QA: альфа, бета, релиз-кандидат и помечены как таковые.
Для больших проектов простая концепция «игровой версии» больше не применима. У вас будет несколько платформ, SKU, языки, однопользовательский режим, многопользовательский режим и т. Д. Управление версиями становится тогда работой на полный рабочий день (иногда ее называют менеджером данных - это терминология Ubisoft, вероятно, в других местах называемая по-другому) тогда схема маркировки намного сложнее и сильно зависит от реальной игры.