Thực hành tốt nhất để ghi nhãn phiên bản trò chơi?


21

Có ai biết nếu có một thực hành tốt nhất để ghi nhãn phiên bản trò chơi.

Tôi không chắc có tên tiêu chuẩn cho nó ngoài phiên bản hay không nhưng ý tôi là về cơ bản:

  • 1
  • 1.1
  • 1.2
  • 1.3.1 beta

Câu trả lời:


18

Không có tiêu chuẩn, nhưng bạn nên làm theo cách có ý nghĩa với bạn và chứa tất cả thông tin bạn có thể cần để theo dõi bản dựng đó. Tôi đã làm việc cho một công ty về cơ bản đã phá vỡ nó như thế này:

[Số bản dựng chính]. [Số bản dựng nhỏ]. [Sửa đổi]. [Gói]

tức là phiên bản: 1.0.15.2

  • Số bản dựng chính : Điều này cho thấy một cột mốc quan trọng trong trò chơi, tăng số này khi đi từ bản beta sang bản phát hành, từ bản phát hành đến bản cập nhật lớn.

  • Số bản dựng nhỏ : Được sử dụng để cập nhật tính năng, sửa lỗi lớn, v.v.

  • Sửa đổi : Thay đổi nhỏ trên các tính năng hiện có, sửa lỗi nhỏ, v.v.

  • Gói : Mã của bạn giữ nguyên, thay đổi thư viện bên ngoài hoặc cập nhật tệp tài sản.

Thay đổi kết hợp cuộn qua để thay đổi đáng kể nhất. Ví dụ: nếu bạn tăng số bản dựng nhỏ, cả bản sửa đổi và gói đều được đặt lại về 0.

Mặc dù các danh mục đã được xác định, vẫn còn mơ hồ về loại tính năng nào thực sự giao thoa giữa sửa đổi và số bản dựng nhỏ. Tuỳ bạn. Nếu bạn lập danh sách các tính năng sẽ cần được triển khai trước mỗi lần tăng, bạn cũng sẽ có kế hoạch để thực hiện, nhưng cuối cùng, quyết định của bạn là phù hợp với từng danh mục.


1
Đó là thông tin tuyệt vời, ở mọi nơi tôi nhìn thấy nó chỉ nói về các số xây dựng nhỏ của quảng cáo chính mà không có lời giải thích thực sự nào về những gì rơi vào mỗi.
clifford.duke


10

Stack Overflow có một cuộc thảo luận tuyệt vời về vấn đề này được gọi là Cách thực hiện Số phiên bản , tham chiếu Hướng dẫn về Phong cách Phiên bản .

Tóm lược:

  • Phiên bản CHÍNH khi bạn thực hiện các thay đổi API không tương thích
  • Phiên bản MINOR khi bạn thêm chức năng theo cách tương thích ngược
  • Phiên bản PATCH khi bạn thực hiện sửa lỗi tương thích ngược
  • Các nhãn bổ sung cho phát hành trước và siêu dữ liệu xây dựng có sẵn dưới dạng các phần mở rộng cho định dạng MAJOR.MINOR.PATCH

6

Theo tôi biết, không có tiêu chuẩn cho điều đó. Thực tiễn sẽ thay đổi tùy thuộc vào các công ty, nhóm và dự án: không có cách nào tốt nhất. Điều quan trọng nhất không phải là quy ước thực tế, mà thực tế là mọi người đều gắn bó với nó.

Điều đó nói rằng, chương trình bạn đề cập là khá phổ biến cho các trò chơi phát hành. 1.0 thường sẽ là chủ vàng và các bản vá sẽ bắt đầu từ đó: 1.1, 1.2 ... Nó cũng được sử dụng trong các phiên bản khách hàng phát hành trước như betas riêng hoặc mở.

Đối với các trò chơi đang phát triển, tôi hiếm khi thấy hệ thống này được sử dụng. Thông thường hơn nhiều khi đề cập đến một bản dựng bằng ID thay đổi nguyên tử của nó (ví dụ: số thay đổi Perforce). Điều này đặc biệt hữu ích cho một dự án quy mô trung bình, nơi mọi thứ (mã & tài sản) được lưu trữ trên cùng một kho lưu trữ và tích hợp liên tục được thực hiện. Trong trường hợp này, việc có cả số thay đổi nguyên tử số phiên bản là dư thừa và dễ bị lỗi. Một số bản dựng sẽ được thăng cấp lên một cột mốc sau QA: alpha, beta, ứng cử viên phát hành và được dán nhãn như vậy.

Đối với các dự án lớn, khái niệm đơn giản về "phiên bản trò chơi" sẽ không áp dụng nữa. Bạn sẽ có một số nền tảng, SKU, ngôn ngữ, chế độ chơi đơn, chế độ nhiều người chơi, v.v. Quản lý phiên bản trở thành công việc toàn thời gian (đôi khi được gọi là trình quản lý dữ liệu - đây là thuật ngữ của Ubisoft, có thể được gọi khác ở nơi khác) , kế hoạch ghi nhãn sau đó phức tạp hơn nhiều và phụ thuộc nhiều vào trò chơi thực tế đang được thực hiện.


wow, nó trở thành một công việc trong chính nó? Tôi luôn nghĩ rằng các lãnh đạo của mỗi bộ phận sẽ quản lý phiên bản riêng của nó.
clifford.duke

2
@ChaoticLoki Bạn cần sự phối hợp hợp lý giữa các phòng ban để đảm bảo rằng, ví dụ, các nhà thiết kế cấp độ đang làm việc trên chương trình thực thi ổn định mới nhất. Hoặc các lập trình viên có thể tìm thấy ai đã làm hỏng một biến trong văn bản được bản địa hóa (như trong: "Trình dịch tiếng Ý đã sửa lỗi hộp thoại X, vô tình phá vỡ văn bản hướng dẫn Y cùng một lúc, nhưng chúng ta không thể quay lại phiên bản cũ vì exe isn 't tương thích. Arghhh! Trợ giúp? "). Và như vậy. Trong một đội ngũ lớn, bạn cần ai đó chăm sóc tất cả những điều này. Đó thực sự là một trong những công việc thử thách nhất trong ngành.
Laurent Couvidou
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.