Kiểm soát nguồn để lưu trữ mọi thứ của dự án trò chơi?

Có phải thông thường để quản lý không chỉ mã nguồn, mà tất cả các tài sản, kết cấu, nghệ thuật, tệp tài liệu, vv trong kho git để kiểm soát phiên bản? Ví dụ, tôi muốn lấy lại phiên bản cũ của kết cấu. Nếu thực tế rất tệ, bạn sử dụng công cụ nào để kiểm soát phiên bản tài sản và các công cụ khác?

Tôi muốn nói rằng đó là một thực hành rất tốt. Kiểm soát nguồn nên được sử dụng cho nguồn và tài sản. Bạn có thể nghĩ về nó giống như một bản sao lưu, bạn muốn có thể khôi phục từ kiểm soát nguồn mọi thứ cần thiết để xây dựng trò chơi của bạn.

Tôi đã liên kết một câu hỏi về việc lưu trữ tài sản trong một kho lưu trữ. Có một số kho lưu trữ hoạt động tốt hơn những kho khác để lưu trữ nghệ thuật. Họ sẽ cho phép bạn "khác biệt" nghệ thuật và xem những gì đã thay đổi. Những người khác sẽ chỉ coi các tài sản là dữ liệu nhị phân, vì vậy bạn sẽ phải kiểm tra xem nó có gì khác biệt. Điều này cũng có nghĩa là bạn sẽ phải tải lên toàn bộ tài sản khi nó thay đổi, vì kho lưu trữ sẽ không thể "biết" (phân tích) những gì đã thay đổi giữa các phiên bản.

Tôi lưu trữ mọi thứ trong kho lưu trữ. Khi tôi có máy tính xách tay mới, tôi có thể kiểm tra kho lưu trữ của mình và xây dựng trò chơi của mình mà không cần phải sao chép bất kỳ tài sản nào từ bất kỳ nơi nào khác. Điều đó có nghĩa là tôi cũng lưu trữ thư viện, tài sản và kiểm soát nguồn của bên thứ 3 trong kho lưu trữ của mình.

Git không tuyệt vời cho các tệp không phải là văn bản. Nhân bản một git repo yêu cầu tải xuống tất cả các phiên bản lịch sử của một tệp, trừ khi sử dụng phần mở rộng tệp lớn (không chuẩn, thường không được GUI hỗ trợ) hoặc các lệnh đặc biệt (yêu cầu phải là một git guru để làm). Điều tương tự cũng xảy ra với hầu hết các hệ thống DVCS. Đối với một kết cấu, mô hình hoặc clip âm thanh, điều này có nghĩa là kéo nhiều bản sao của một tệp rất lớn. 1GB tài sản có thể dễ dàng là 200GB dữ liệu sửa đổi lịch sử và git khiến bạn tải xuống tất cả khi bạn sao chép một repo mới và tải xuống tất cả các phiên bản trung gian khi lấy bản mới nhất. Điều này trở thành một nút cổ chai lớn khi bạn không thể chịu đựng được sự chậm trễ sản xuất.

Subversion, Perforce, v.v. là những lựa chọn tốt hơn cho tài sản, vì chúng chỉ yêu cầu tải xuống bản sửa đổi mong muốn (mới nhất, thường là). Bạn chỉ có thể sử dụng chúng cho tài sản và sử dụng git cho mã hoặc cũng có thể sử dụng chúng cho nguồn. Perforce có một số tính năng cho phép nó hoạt động như một DVCS rất cục mịch và tốt hơn chức năng SVN (mặc dù nhiều conplex hơn) theo kinh nghiệm của tôi, tuy nhiên chi phí có nghĩa là bạn sẽ sử dụng Subversion.

Hầu hết các chuyên gia nội dung ít có nhu cầu về DVCS và một số gặp rắc rối với ngay cả những điều cơ bản của VCS cổ điển. Đừng yên ngựa với git. Hoặc Mercurial, DARCS, v.v.

Đó là một thực tế tốt, ngay cả khi là một nghệ sĩ khi bạn đang làm việc trong một dự án, có xu hướng có một số hình thức kiểm soát phiên bản, tham nhũng tệp hoặc lỗi xảy ra, không có nghệ sĩ kiểm soát nguồn có xu hướng sửa đổi tiết kiệm dù sao đó chỉ là một mớ hỗn độn.

Ví dụ trong thế giới thực mà bạn có thể thấy đây là các dự án phim mở được thực hiện với Blender (Big Buck Bunny, Durian, v.v.)

Đường ống nghệ thuật cho trò chơi ít nhiều giống nhau, ngoại trừ có thể có một bước xây dựng để chính các tài sản thực hiện một số chuyển đổi từ dữ liệu lớn sang định dạng cụ thể của động cơ, chẳng hạn như nén kết cấu và chuyển đổi định dạng mô hình.

Một số công cụ, như GitHub thậm chí còn cung cấp các công cụ so sánh hình ảnh đẹp và giống nhau, tốt hơn rất nhiều so với việc so sánh một blob nhị phân.

Vì kho lưu trữ tài sản có thể rất lớn, nên sở thích của tôi là giữ một kho lưu trữ tài sản riêng biệt, là một mô hình con trong kho lưu trữ dự án. Bạn không muốn kéo xuống hàng gigabyte tài sản khi tất cả những gì bạn muốn là phân nhánh nguồn chẳng hạn.