게임 버전 라벨링에 대한 모범 사례가 있는지 아는 사람이 있습니까?
버전 관리 이외의 표준 이름이 있는지 확실하지 않지만 기본적으로 다음과 같습니다.
- 1.0
- 1.1
- 1.2
- 1.3.1 베타
게임 버전 라벨링에 대한 모범 사례가 있는지 아는 사람이 있습니까?
버전 관리 이외의 표준 이름이 있는지 확실하지 않지만 기본적으로 다음과 같습니다.
답변:
표준은 없지만 나에게 맞는 방식으로 수행해야하며 해당 빌드를 추적하는 데 필요한 모든 정보를 포함해야합니다. 본질적으로 다음과 같이 고장난 회사에서 일했습니다.
[주요 빌드 번호]. [마이너 빌드 번호]. [개정]. [패키지]
즉 버전 : 1.0.15.2
주요 빌드 번호 : 이것은 게임에서 주요 이정표를 나타냅니다. 베타에서 릴리스로 갈 때 릴리스에서 주요 업데이트로 증가합니다.
마이너 빌드 번호 : 기능 업데이트, 큰 버그 수정 등에 사용됩니다.
개정 : 기존 기능, 작은 버그 수정 등에 대한 사소한 변경
패키지 : 코드는 동일한 외부 라이브러리 변경 또는 자산 파일 업데이트를 유지합니다.
결합 된 변경 사항이 가장 중요한 변경 사항으로 롤오버됩니다. 예를 들어, 부 빌드 번호를 늘리면 개정 및 패키지가 모두 0으로 재설정됩니다.
카테고리가 정의되어 있지만 수정 버전과 최소 빌드 번호 사이에서 실제로 어떤 종류의 기능이 교차하는지에 대해서는 모호합니다. 그것은 당신에게 달려 있습니다. 각 증분 전에 구현해야 할 기능 목록을 작성하면 따라야 할 계획이 있지만 결국 각 범주에 맞는 것이 무엇인지 결정합니다.
Stack Overflow는 Versioning Style Guide 를 참조하는 How To Do Version Numbers 에 대한 논의 가 많았다 .
개요:
내가 아는 한 그것에 대한 표준 은 없습니다 . 실습은 회사, 팀 및 프로젝트에 따라 달라질 수 있습니다 . 모범 사례와 같은 것은 없습니다. 가장 중요한 것은 실제 관습이 아니라 모든 사람들이 그것을 지키고 있다는 사실입니다.
즉, 언급 한 계획은 출시 된 게임에서 매우 일반적입니다. 1.0은 일반적으로 골드 마스터이며 패치는 1.1, 1.2부터 시작합니다. 개인 또는 공개 베타와 같은 시험판 고객 버전에서도 사용됩니다.
개발중인 게임의 경우이 시스템이 거의 사용되지 않았습니다. 원자 변경 ID (예 : Perforce 변경 목록 번호)로 빌드를 참조하는 것이 훨씬 일반적입니다. 이는 모든 (코드 및 자산)이 동일한 저장소에 저장되고 지속적인 통합이 이루어지는 중간 규모 프로젝트에 특히 유용합니다. 이 경우 원자 변경 번호 와 버전 번호가 모두 중복되어 오류가 발생하기 쉽습니다. 일부 빌드는 품질 보증 후 알파, 베타, 출시 후보 등의 이정표로 승격되어 표시됩니다.
대규모 프로젝트의 경우 "게임 버전"이라는 간단한 개념은 더 이상 적용되지 않습니다. 여러 플랫폼, SKU, 언어, 단일 플레이어 모드, 멀티 플레이어 모드 등이 있습니다. 버전 관리는 정규직이됩니다 ( 데이터 관리자 라고도 함 )-Ubisoft 용어로, 다른 곳에서는 다르게 지칭 될 수 있음) 라벨링 방식은 실제 게임에 훨씬 더 복잡하고 의존적입니다.