Quản lý tài sản, cơ sở dữ liệu hay hệ thống phiên bản?

29

Trong khi phát triển tài sản cho trò chơi, (lưới, kết cấu, âm thanh, video) bạn có quản lý chúng không?

Giữ chúng cùng với mã nguồn bên trong hệ thống phiên bản? (perforce, git, v.v.)
Hoặc có một cơ sở dữ liệu trung tâm dự phòng dành riêng cho các tài sản và có các biên tập viên luôn làm việc thích nó? (PostgreSQL, MySQL, v.v ...)
Khác?

Các ưu và nhược điểm của mỗi loại là gì, và tại sao người ta nên chọn nó hơn cái kia?

assets version-control asset-management

— NocturnDragon
nguồn

Câu hỏi hay. Tôi khá thích thú khi nghe người khác tiếp cận điều này như thế nào.

— David McGraw

1

Để biết thông tin về kiểm soát phiên bản: gamedev.stackexchange.com/questions/480/ , và gamedev.stackexchange.com/questions/245/, Tôi không nghĩ đây là một bản sao vì nó đặc biệt là về tài sản

— Sean James

22

Đối với nhiều người trong chúng ta - đặc biệt là làm việc trên các trò chơi nhỏ hơn - bạn hoàn toàn nên có tài sản trong cùng một kho lưu trữ với nguồn của mình .

Đề xuất rằng các tài sản thuộc về một kho lưu trữ riêng biệt chỉ có ý nghĩa đối với các bộ tài sản rất lớn hoặc cho các bộ tài sản có phần lớn khi có ranh giới dữ liệu / công cụ được xác định rõ ràng. Trừ khi có một lý do kỹ thuật cụ thể cho nó - đó là lời khuyên tồi!

Bạn muốn kiểm soát phiên bản của bạn hoạt động như kiểm soát phiên bản . Bạn muốn có thể tua lại và tua nhanh và phân nhánh và hợp nhất các phiên bản mà vẫn giúp trò chơi của bạn hoạt động. Và mã và tài sản của bạn sẽ phụ thuộc vào nhau.

Ví dụ: Mã của bạn có thể mong đợi có thể đặt tham số trên trình đổ bóng và trình tạo bóng đó có thể phụ thuộc vào kết cấu ở đó. Hoặc có thể định dạng dữ liệu của các cấp của bạn có thể phụ thuộc vào một phiên bản cụ thể của mã trò chơi của bạn.

Nó gần như chắc chắn sẽ nhận được lộn xộn. Và bạn có những điều tốt hơn để làm hơn là cố gắng và giữ cho nó gọn gàng.

Bây giờ, như Mike Wagner đã nhận xét ( về câu trả lời này ) - bạn không muốn hoặc không cần tất cả các phiên bản "đang thực hiện" của tài sản của mình dưới sự kiểm soát phiên bản! Chỉ phiên bản cuối cùng / hoạt động, như được sử dụng bởi mã của bạn, sẽ làm - thường đây là những gì bạn xuất từ công cụ của mình.

(Mặc dù nếu bạn muốn kiểm soát phiên bản các phiên bản đang xử lý của tài sản - điều đó tốt. Và rất phù hợp với một kho lưu trữ riêng. Cá nhân tôi thấy rằng tổ chức thư mục tốt và hệ thống sao lưu phù hợp là đủ.)

Điều đó đang được nói - đôi khi thật tuyệt khi có tùy chọn chỉ dán các tài sản "đang tiến hành" dưới sự kiểm soát phiên bản. Thông thường, điều này liên quan đến việc có một đường dẫn nội dung có thể xử lý bất kỳ bước 'xuất' nào cho bạn - ví dụ: làm phẳng hình ảnh nhiều lớp thành một kết cấu.

— Andrew Russell
nguồn

10

Hệ thống phiên bản.

Với cách tiếp cận theo cách riêng của bạn, bạn sẽ kết thúc một hệ thống tạo phiên bản một cách hiệu quả, vì vậy tốt hơn là sử dụng một hệ thống đã có nhiều chu kỳ thiết kế / mã / thử nghiệm.

Giữ các tài sản trong một kho lưu trữ riêng biệt từ nguồn, để dễ dàng giữ thời gian kiểm tra / đồng bộ hóa ở mức tối thiểu và đưa ra các quyết định khác nhau về việc giữ lại bao nhiêu lịch sử (mặc dù dung lượng đĩa rẻ, giữ lại tất cả bất cứ khi nào khả thi. 't thay đổi nhiều trong suốt cuộc đời của một dự án).

Đánh dấu các tệp XML là nhị phân, các công cụ hợp nhất có xu hướng rất tệ trong việc hợp nhất đánh dấu lồng nhau và các nghệ sĩ không thể phát hiện ra đánh dấu bị hỏng nếu công cụ cho rằng không có xung đột.

Nếu bạn có thể, hãy sắp xếp kiểm tra cú pháp hoặc thậm chí xây dựng tài sản trên mỗi cam kết và từ chối cam kết với một email gửi lại cho người cam kết nếu thất bại; điều này sẽ tiết kiệm rất nhiều thời gian của đội.

— bóng của mặt trăng
nguồn

2

Đồng ý giữ các tài sản nghệ thuật và tài sản mã trong các repos riêng biệt. Bạn cũng có thể thấy rằng các nghệ sĩ không muốn kiểm tra một cái gì đó hơn các lập trình viên, và không nhất thiết là vì họ thấy hệ thống đáng sợ. Họ có thể có 30 phác thảo sơ bộ về một khái niệm và không muốn gửi cho đến khi họ thu hẹp nó thành một cái gì đó họ thích. Yếu tố này vào đường ống sản xuất. Nếu có một giám đốc kỹ thuật thở dốc để kiểm tra mọi thứ, họ sẽ dành nhiều thời gian hơn cho repo hơn là xử lý mọi thứ.

— Casey Wagner

1

Về việc đánh dấu các tệp XML là nhị phân: Nếu VCS của bạn cho phép các công cụ tìm khác biệt, hãy yêu cầu nó sử dụng một cái gì đó chuyên về khác biệt XML cho các tệp XML. Điều này có thể giúp tránh đánh dấu bị hỏng kỳ lạ.

— Jeff

+1 về điều này. :) Tài sản thuộc về kho lưu trữ của riêng họ - nếu trong kho lưu trữ. Có thể sử dụng một phần mềm lưu trữ tài sản chuyên dụng? Cụ thể được tạo ra cho mục đích đó, thay vì cố gắng làm cho nó phù hợp với các hệ thống kiểm soát phiên bản được thiết kế cho nội dung chủ yếu là văn bản.

— jacmoe

8

Tất cả mọi thứ trong một kho lưu trữ, nếu bạn có thể đủ khả năng về kích thước. Tôi đã nghe nói về kho Subversion trong vùng lân cận 1 TB. Chúng tôi hiện đang ở mức dưới 400 GB.

Ngoài ra, các nghệ sĩ kiểm tra nhiều thứ, bao gồm 30 phác thảo sơ bộ của một khái niệm; chúng tôi sử dụng các cây thư mục riêng cho "tài sản nguồn" và "xuất khẩu" - những cây đi vào tập lệnh xây dựng tài sản. Nếu nghệ sĩ của bạn bị xe buýt đâm vào ngày mai, bạn cần có người tiếp tục làm việc với tài sản của mình vào ngày hôm sau, chỉ xem qua kho lưu trữ (không có khảo cổ trên máy cá nhân của anh ấy). Ngày xưa khi các trò chơi là 2D và các họa tiết được tạo ra từ các cảnh hoạt hình Max phức tạp, chúng tôi đã phải gửi một loạt các đơn vị trong một trò chơi RTS với một chút nhảm nhí và trông rất không nhất quán (so với các đơn vị còn lại), thậm chí mặc dù đó là vấn đề tái hiện với các cài đặt ánh sáng và khử răng cưa hơi khác nhau - vì nghệ sĩ gốc đã bỏ cuộc và chúng tôi không có cảnh Max gốc của anh ấy. Đừng '

— Unsigner
nguồn

1

Upvote khi đề cập đến "yếu tố xe buýt")

— Kromster nói hỗ trợ Monica