Apa pendekatan terbaik untuk merancang AssestManager yang akan menyimpan referensi grafik, suara, dll. Dari sebuah game?
Haruskah aset ini disimpan dalam pasangan Peta kunci / nilai? Yaitu saya meminta aset "latar belakang" dan Peta mengembalikan bitmap yang terkait? Apakah ada cara yang lebih baik?
Khususnya saya sedang menulis game Android / Java, tetapi jawabannya bisa umum.
Jawaban:
Itu tergantung pada ruang lingkup gim Anda. Manajer aset sangat penting untuk judul yang lebih besar, apalagi untuk game yang lebih kecil.
Untuk judul yang lebih besar Anda harus mengelola masalah seperti yang berikut:
Untuk judul yang lebih kecil hal-hal ini tidak terlalu menjadi masalah, kerangka kerja seperti XNA memiliki manajer aset di dalamnya - ada sedikit gunanya menciptakan kembali itu.
Jika Anda menemukan diri Anda membutuhkan manajer aset, sebenarnya tidak ada solusi satu ukuran untuk semua, tetapi saya telah menemukan bahwa peta hash dengan kunci sebagai hash * dari nama file (diturunkan dan separator semuanya 'diperbaiki') bekerja dengan baik untuk proyek yang saya kerjakan.
Biasanya tidak disarankan untuk nama file hardcode di aplikasi Anda, biasanya lebih baik memiliki format data lain (seperti xml) menggambarkan nama file ke 'ID'.
(Mencoba menghindari "jangan gunakan manajer aset" - diskusi di sini, karena saya menganggapnya offtopic.)
Peta kunci / nilai adalah pendekatan yang sangat berguna.
Kami memiliki satu implementasi ResourceManager di mana Pabrik untuk tipe Sumber Daya yang berbeda dapat mendaftar.
Metode "getResource" menggunakan templat untuk menemukan Pabrik yang benar untuk resourcetype yang diinginkan dan mengembalikan ResourceHandle spesifik (sekali lagi menggunakan templat untuk mengembalikan SpecificResourceHandle).
Sumber daya dihitung ulang oleh ResourceManager (di dalam ResourceHandle) dan dirilis ketika mereka tidak diperlukan lagi.
Addon pertama yang kami tulis adalah metode "reload (XYZ)", yang memungkinkan kami untuk mengubah sumber daya dari luar mesin yang sedang berjalan tanpa mengubah kode apa pun atau memuat ulang game. (Ini penting ketika seniman mengerjakan konsol;))
Sebagian besar waktu kita hanya memiliki instance dari ResourceManager, tetapi kadang-kadang kita membuat instance baru hanya untuk level atau peta. Dengan cara ini kita bisa memanggil "shutdown" pada levelResourceManager dan memastikan tidak ada yang bocor.
// very abbreviated!
// this code would never survive our coding guidelines ;)
ResourceManager* pRm = new ResourceManager;
pRm->initialize( );
pRm->registerFactory( new TextureFactory );
// [...]
TextureHandle tex = pRm->getResource<Texture>( "test.otx" ); // in real code we use some macro magic here to use CRCs for filenames
tex->storeToHardware( 0 ); // channel 0
pRm->releaseResource( pRm );
// [...]
pRm->shutdown(); // will log any leaked resourceKelas Manajer khusus hampir tidak pernah menjadi alat teknik yang tepat. Jika Anda hanya membutuhkan aset satu kali (seperti latar belakang atau peta), Anda hanya perlu memintanya sekali, dan membiarkannya mati secara normal ketika Anda selesai menggunakannya. Jika Anda perlu men-cache objek tertentu, Anda harus menggunakan pabrik yang pertama-tama memeriksa cache dan sebaliknya memuat sesuatu, memasukkannya ke dalam cache, dan kemudian mengembalikannya - dan pabrik itu dapat berupa fungsi statis mengakses variabel statis , bukan jenisnya sendiri.
Steve Yegge (di antara banyak, banyak lainnya) telah menulis cerita yang bagus tentang bagaimana kelas manajer yang tidak berguna, dengan pola tunggal, pada akhirnya. http://sites.google.com/site/steveyegge2/singleton-considered-stupid
Saya selalu berpikir bahwa manajer aset yang baik harus memiliki beberapa mode operasi. Mode-mode ini kemungkinan besar akan menjadi modul sumber terpisah yang mengikuti antarmuka umum. Dua mode dasar operasi adalah:
Anda membutuhkan alat yang dapat mengambil semua assest dari database bersama dan membuat dataset produksi.
Dalam tahun-tahun saya sebagai pengembang, saya belum pernah melihat yang seperti ini, meskipun saya hanya bekerja untuk beberapa perusahaan sehingga pandangan saya tidak benar-benar representatif.
Memperbarui
OK, beberapa suara negatif. Saya akan memperluas desain ini.
Pertama, Anda tidak benar-benar membutuhkan kelas pabrik karena jika Anda punya:
TextureHandle tex = pRm->getResource<Texture>( "test.otx" );Anda tahu tipenya, jadi lakukan saja:
TextureHandle tex = new TextureHandle ("test.otx");tapi kemudian, apa yang saya coba katakan di atas adalah bahwa Anda tidak akan menggunakan nama file eksplisit, tekstur untuk memuat akan ditentukan oleh model tekstur digunakan, sehingga Anda tidak benar-benar membutuhkan nama yang dapat dibaca manusia, itu bisa menjadi nilai integer 32 bit, yang jauh lebih mudah untuk ditangani oleh CPU. Jadi, dalam konstruktor untuk TextureHandle Anda akan memiliki:
if (texture already loaded)
update texture reference count
else
asset_stream = new AssetStream (resource_id)
asset_stream->ReadBytes
create texture
set texture ref count to 1AssetStream menggunakan parameter resource_id untuk menemukan lokasi data. Cara melakukannya tergantung pada lingkungan tempat Anda menjalankan:
Dalam Pengembangan: aliran mencari ID dalam database (menggunakan SQL misalnya) untuk mendapatkan nama file dan kemudian membuka file, file tersebut dapat di-cache secara lokal, atau ditarik dari server jika file lokal tidak ada atau kadaluarsa.
Dalam Rilis: aliran melihat ID dalam tabel kunci / nilai untuk mendapatkan offset / ukuran menjadi file besar yang dikemas (seperti file WAD Doom).
Apa yang saya suka lakukan untuk aset adalah mengatur manajer lumpuh . Terinspirasi oleh mesin Doom, benjolan adalah potongan data yang berisi aset, disimpan dalam file benjolan yang menyatakan nama, panjang, jenis benjolan (bitmap, suara, shader, dll.), Dan jenis konten (file, benjolan lain, di dalam file lump itu sendiri). Saat startup, benjolan ini dimasukkan ke dalam pohon biner, tetapi belum dimuat. Setiap peta (yang juga merupakan benjolan) memiliki daftar dependensi, yang hanyalah nama-nama benjolan yang perlu dikerjakan oleh peta. Benjolan ini, kecuali jika sudah dimuat, dimuat pada saat peta dimuat. Selain itu, gumpalan peta yang bersebelahan dengan peta dimuat, tidak pada saat yang bersamaan, tetapi saat mesin idle karena suatu alasan. Ini dapat membuat peta menjadi mulus, dan tidak ada layar pemuatan.
Metode saya sempurna untuk peta dunia terbuka, tetapi permainan berbasis level tidak akan mendapat manfaat dari kelancaran metode ini. Semoga ini membantu!