Game Noel Llopis dari dalam blog menyentuh ini baru-baru ini di posting "Remote Game Editing" . Paragraf pembuka:
Saya sudah lama menjadi penggemar runtime game minimal. Apa pun yang dapat dilakukan secara offline atau dalam alat yang terpisah, harus keluar dari runtime. Itu membuat arsitektur dan kode gim sangat ramping dan sederhana .
(Artikel ini adalah bacaan yang sangat direkomendasikan, seperti halnya sebagian besar barang Noel, apakah Anda setuju 100% atau tidak.)
Saya percaya kuncinya di sini adalah menjaga kompleksitas di luar mesin. Anda masih dapat memiliki fleksibilitas, tetapi fleksibilitas dalam pipa konten. Dan Anda mendapatkan kinerja yang lebih baik dengan tidak menghabiskan waktu untuk mengubah dan memindahkan data.
Kinerja yang lebih baik dapat diterjemahkan ke dalam waktu iterasi yang lebih rendah, anehnya, meskipun kehilangan beberapa kemampuan pengeditan di dalam mesin: lebih mudah untuk mencoba sesuatu jika Anda dapat memuat permainan dalam satu detik.
Mengadopsi beberapa prinsip " filosofi unix " akan membantu Anda menjaga rantai alat tetap fleksibel: pipa modular kecil.
Filosofi pribadi saya: memanggang data sebanyak mungkin offline, tetapi menyediakan dukungan mesin untuk menerima data yang dipanggang baru setiap saat. (Perhatikan bahwa data baru ini tidak perlu ikut bermain sampai titik nyaman: tombol "segarkan" ditekan, level berikutnya dimulai, Anda beralih ke area baru, apa pun. Kuncinya adalah menemukan sweet spot yang meminimalkan waktu iterasi dengan kompleksitas kode minimum dan upaya pengkodean.)
Di perusahaan kami, sebagian besar alat yang kami hadapi seniman / perancang berfokus pada masalah UI: kemudahan manipulasi aset tunggal atau kumpulannya, dll. Terkadang itu hanya alat pihak ke-3 seperti Photoshop atau 3DS Max. Alat-alat ini mengekspor ke format perantara (sering xml yang merujuk sumber data biner, tetapi tidak selalu). Format perantara diambil oleh alat "data make" backend, yang membuatnya menjadi sesuatu yang berguna dan pemuatan cepat untuk platform target.
Portabilitas dicapai dengan menambahkan alat data backend tambahan, atau memperluas alat data backend yang ada, yang memiliki keuntungan tambahan karena tidak terlihat oleh pembuat konten.
Sekarang, dengan membuat data inkremental yang tepat, Anda dapat memiliki perubahan dalam format terpanggang dalam hitungan detik; mesin Anda dapat laba-laba, atau alat dapat laba-laba, dan kemudian ini akan muncul di sistem sumber daya Anda, siap untuk dimuat ulang saat nyaman.
Alat - terutama data backend membuat alat - seringkali lebih sembrono dan buggier daripada kode mesin. Ini OK, karena lebih mudah untuk refactor / menulis ulang, memperluas, dan menguji; Anda memiliki spesifikasi untuk perilakunya dan cukup mudah untuk mengujinya dibandingkan dengan beberapa kode mesin.
Pendapat saya tentang pertanyaan Anda:
Haruskah mesin mampu memuat berbagai format gambar? Sebuah loader TGA saja cukup mudah untuk menyerahkan kode.
(Selain itu: bahkan jika Anda menggunakan decoder TGA di dalam mesin, jangan handcode itu. Anda hanya meminta masalah - ada banyak seluk-beluk dengan sebagian besar format gambar, dan banyak alat yang tidak mematuhi persis ke format yang mungkin tidak ditentukan secara spesifik. Anda sebaiknya mencari kode pustaka yang sudah teruji untuk pemrosesan gambar.)
Saya ingin alat ini dikonversi dari TGA ke apa pun format tekstur internal Anda, ditambah metadata.
Bagaimana dengan format audio? Apakah layak hanya mendukung memuat file wav? Bagaimana dengan file musik ambient yang seringkali besar.
Kami menggunakan tiga format di sini: musik yang dilacak (.xm), ADPCM (.wav), dan Speex (.spx). Ini sebagian besar karena kita menggunakan perangkat genggam, dan format ini sangat ringan untuk didekodekan.
Haruskah mesin mampu menghasilkan parsing dan atlas TTF dinamis? Pengepakan tekstur.
Atlasing adalah masalah yang sulit: lihat jawaban pertanyaan terakhir Anda . Hampir selalu layak dilakukan secara offline.
Plus, Anda dapat membuat metadata per-karakter menjadi struct yang dipanggang dengan kode hampir nol.
Sebagai penutup, Anda dapat membersihkan dan mengemas saluran pipa ini dengan game Anda, untuk komunitas mod. Anda selalu dapat menambahkan lebih banyak format sumber. Dan tidak ada yang mencegah Anda menjembatani kesenjangan antara alat pembuatan konten dan mesin dalam kasus tertentu; semoga kode pembuatan data dan kode laba-laba / transfer Anda dapat di refactored ke perpustakaan yang pada akhirnya dapat digunakan secara langsung oleh alat pembuat konten dalam beberapa kasus. Tapi saya tidak akan menjadikan itu tujuan pertama saya, tentu saja ... Sadarilah bahwa itu akan menjadi tujuan akhirnya dan biarkan yang sedikit mempengaruhi desain Anda, dan pergi untuk buah rendah menggantung dulu.
Sebagai pembaruan, Anda mungkin ingin mempertimbangkan untuk menggunakan Format File KTX untuk tekstur. Ini memiliki keuntungan sebagai sebagian besar "membaca structdan pergi" untuk sebagian besar pengguna GL (dan dari komentar Anda sepertinya Anda menargetkan GL) sambil tetap fleksibel dan terdefinisi dengan baik.
Overhead header KTX mungkin agak tinggi untuk data yang sepenuhnya dipanggang, tergantung pada target Anda, dan Anda mungkin ingin melupakan dukungan swap endian, tergantung pada usecase Anda ... tapi itu pasti setidaknya layak dilihat sebagai pertimbangan desain.