Manajemen Aset, basis data atau sistem versi?

29

Saat mengembangkan aset untuk gim, (jerat, tekstur, suara, video) bagaimana Anda mengelolanya?

  1. Menyatukan mereka dengan kode sumber di dalam sistem versi? (memaksa, git, dll ...)
  2. Atau memiliki pusat cadangan, basis data yang didedikasikan untuk aset dan membuat editor selalu menyukainya? (PostgreSQL, MySQL, dll ...)
  3. Lain?

Apa pro dan kontra dari masing-masing, dan mengapa orang harus memilih yang lain?

assets version-control asset-management NocturnDragon
sumber
Pertanyaan bagus. Saya cukup tertarik mendengar bagaimana orang lain mendekati ini.
David McGraw
1
Untuk info tentang kontrol versi: gamedev.stackexchange.com/questions/480/… dan gamedev.stackexchange.com/questions/245/… Saya tidak berpikir ini duplikat karena ini khusus tentang aset
Sean James

Jawaban:

22

Bagi kebanyakan dari kita - terutama yang bekerja pada gim yang lebih kecil - Anda benar-benar harus memiliki aset dalam repositori yang sama dengan sumber Anda .

Saran bahwa aset termasuk dalam repositori terpisah hanya masuk akal untuk set aset yang sangat besar, atau untuk set aset yang agak besar ketika ada batas mesin / data yang jelas. Kecuali ada alasan teknis khusus untuk itu - itu saran yang buruk!

Anda ingin kontrol versi Anda berperilaku seperti kontrol versi . Anda ingin dapat memundurkan dan memajukan serta menggabungkan dan menggabungkan revisi dan masih membuat gim Anda bekerja. Dan kode dan aset Anda akan saling bergantung.

Sebagai contoh: Kode Anda mungkin berharap untuk dapat mengatur parameter pada shader, dan shader itu mungkin tergantung pada tekstur yang ada di sana. Atau mungkin format data level Anda mungkin bergantung pada versi tertentu dari kode permainan Anda.

Ini hampir pasti akan menjadi berantakan. Dan Anda memiliki hal-hal yang lebih baik untuk dilakukan daripada mencoba dan menjaganya tetap rapi.

Sekarang, seperti komentar Mike Wagner ( pada jawaban ini ) - Anda tidak ingin atau membutuhkan semua versi "dalam proses" aset Anda di bawah kontrol versi! Hanya versi final / yang berfungsi, seperti yang digunakan oleh kode Anda, yang akan dilakukan - sering kali inilah yang Anda ekspor dari alat Anda.

(Meskipun jika Anda benar-benar ingin mengontrol versi versi aset yang sedang dalam proses - itu bagus. Dan sangat cocok untuk repositori terpisah. Secara pribadi saya menemukan bahwa organisasi folder yang bagus dan sistem cadangan yang tepat sudah cukup.)

Yang dikatakan - kadang-kadang baik untuk memiliki opsi untuk hanya menempel "dalam proses" aset di bawah kontrol versi. Biasanya ini melibatkan memiliki pipa konten yang dapat menangani langkah-langkah 'ekspor' untuk Anda - misalnya: meratakan gambar multi-layer ke satu tekstur.

Andrew Russell
sumber
10

Sistem pembuatan versi.

Dengan pendekatan roll-your-own Anda akan secara efektif berakhir dengan menggulirkan sistem versi, jadi lebih baik menggunakan yang sudah ada sejak siklus desain / kode / tes bertahun-tahun.

Simpan aset dalam repositori terpisah dari sumber, untuk membuatnya lebih mudah untuk menjaga checkout / sinkronisasi waktu ke minimum dan mengambil keputusan yang berbeda tentang berapa banyak sejarah untuk mempertahankan (meskipun ruang disk murah, simpan semua jika memungkinkan. Tekstur individu tidak dapat berubah sebanyak itu sepanjang umur proyek).

Tandai file XML sebagai biner, alat penggabungan cenderung sangat buruk dalam menggabungkan markup bersarang dan seniman tidak akan melihat markup yang rusak jika alat berpikir tidak ada konflik.

Jika Anda bisa, atur sintaks atau bahkan membangun aset di setiap komit dan tolak komit dengan email kembali ke orang yang melakukan jika gagal; ini akan menghemat banyak waktu tim.

bayangan bulan
sumber
2
Menyetujui menjaga aset seni dan kode aset dalam repo yang terpisah. Anda juga mungkin menemukan bahwa para artis lebih enggan untuk memeriksa sesuatu daripada coders, dan tidak harus karena mereka menemukan sistem yang mengintimidasi. Mereka mungkin memiliki 30 garis besar konsep kasar dan tidak ingin menyerah sampai mereka mempersempitnya menjadi sesuatu yang mereka sukai. Faktor ini menjadi jalur produksi. Jika ada direktur teknis yang menggerakkan leher mereka untuk memeriksa segala sesuatu, mereka akan menghabiskan lebih banyak waktu di repo daripada menyelesaikan masalah.
Casey Wagner
1
Pada menandai file XML sebagai biner: Jika VCS Anda memungkinkan alat diff yang berbeda, minta untuk menggunakan sesuatu yang berspesialisasi dalam XML diffing untuk file XML. Ini dapat membantu menghindari markup rusak yang aneh.
Jeff
Beri +1 pada ini. :) Aset milik dalam repositori mereka sendiri - jika dalam repositori sama sekali. Mungkin menggunakan perangkat lunak repositori aset khusus? Khusus dibuat untuk tujuan itu, alih-alih mencoba menyesuaikannya dengan sistem kontrol versi yang dirancang terutama untuk konten tekstual.
jacmoe
8

Semuanya dalam satu repositori, jika Anda mampu membelinya dalam hal ukuran. Saya pernah mendengar tentang repositori Subversion di sekitar 1 TB. Kami saat ini sedikit di bawah 400 GB.

Juga, banyak seniman memeriksa semuanya, termasuk 30 garis besar konsep kasar; kami menggunakan pohon folder terpisah untuk "aset sumber" dan untuk "diekspor" - yang masuk ke skrip pembuatan aset. Jika artis Anda ditabrak bus besok, Anda harus dapat membuat seseorang melanjutkan pekerjaan pada asetnya pada hari berikutnya, hanya melihat melalui repositori (tidak ada arkeologi di mesin pribadinya). Sekali waktu ketika game adalah 2D dan sprite dipra-prerender dari adegan Max animasi yang kompleks, kami harus mengirimkan banyak unit dalam game RTS dengan sedikit jelek, dan tampilan yang sangat tidak konsisten (vs unit lainnya), bahkan meskipun itu masalah rendering ulang dengan pencahayaan yang sedikit berbeda dan pengaturan antialiasing - karena artis asli telah berhenti, dan kami tidak memiliki adegan Max aslinya. Mengenakan'

Tidak menandatangani
sumber
1
Suara positif