Saya sedang dalam tahap perencanaan untuk mesin gim internal yang akan mulai saya buat, yang akan digunakan untuk semua gim saya yang akan datang. Tapi saya sedikit kesulitan dengan bagaimana seharusnya dibangun.
Pilihannya ada pada: framework atau library.
Tujuan dasar saya adalah menyembunyikan detail mesin sebanyak mungkin untuk menjaga pengembangan game tingkat tinggi pada skrip dan file konfigurasi sebanyak mungkin. Tetapi juga untuk menggunakan kembali mesin inti untuk alat apa pun yang mungkin kita kembangkan di masa depan.
Kerangka kerja dapat membuat hal-hal bagus dan mudah untuk pengembangan, tetapi kemudian Anda terkunci. Perpustakaan bagus jika Anda hanya tertarik pada subsistem tertentu. Tapi kita perlu merekatkan semuanya dalam game demi game.
Yah ada juga yang lain, membangun mesin sebagai exe mandiri yang menangani semua sumber daya game, dan semua subsistem. Logika gim (dan hal dinamis per gim lainnya) dilakukan secara eksklusif pada skrip dengan file konfigurasi untuk mengonfigurasi setiap subsistem engine internal.
Yang mana akan memberi saya lebih banyak fleksibilitas di masa depan.
Terima kasih.
Sunting: Terima kasih semuanya, saya kira saya melihat ini dalam perspektif yang salah. Kami tidak dapat benar-benar merencanakan sesuatu seperti ini tanpa sepengetahuan apriori tentang apa yang dibutuhkan gim, tebak inilah sebabnya tidak ada yang namanya mesin umum untuk semua genre.
Saya akan fokus dulu pada game yang tepat kemudian secara iteratif menganalisis pada akhir setiap game bagaimana membuat abstraksi yang layak untuk perpustakaan atau kerangka kerja tergantung pada alur kerja saya (atau mungkin tim masa depan).
sumber
Jawaban:
Jangan khawatir tentang masa depan. Khawatir tentang game Anda saat ini, sekarang. Kalau tidak, Anda tidak akan sampai ke mana pun karena Anda mengkhawatirkan detailnya.
Anda harus berkonsentrasi untuk membangun game terlebih dahulu dan kemudian, jika game itu cukup sukses, Anda dapat mengekstraknya menjadi sesuatu yang dapat digunakan kembali untuk game berikutnya. Ini akan membuat Anda tidak terkunci pada sesuatu yang lain dan memberi Anda kendali penuh atas proyek Anda.
sumber
Bangun kerangka kerja.
Saya memiliki pengalaman dengan membangun keduanya. Saya lebih suka menggunakan perpustakaan di atas kerangka kerja. Kerangka kerja terasa sangat membatasi dan "suka memerintah" . Jadi ketika saya membangun game pertama saya, saya ingin membangun sebuah mesin yang terdiri dari banyak perpustakaan yang dapat dengan mudah digunakan kembali dalam proyek lain.
Itu adalah bencana. Saya menghabiskan setengah waktu untuk menulis kode lem di antara berbagai perpustakaan saya. Perpustakaan saya juga cenderung membengkak dengan abstraksi ekstra, sehingga menjadi tugas besar untuk menambahkan fitur ke perpustakaan / komponen.
Sekarang, bagaimanapun mesin saya dibuat dengan permainan yang saya tulis dalam pikiran. Saya masih tetap membuka mata untuk abstraksi yang memungkinkan saya untuk menggunakannya kembali atau fitur baru yang saya tambahkan di permainan nanti. Saya jauh lebih bahagia dan produktif.
Bagi saya titik baliknya adalah memutuskan untuk tidak menerbitkan mesin saya. Saya mungkin masih menerbitkannya, tetapi untuk sekarang mengetahui bahwa saya tidak perlu membenarkan peretasan khusus gim saya kepada pengguna lain telah memungkinkan saya membuat mesin yang lebih cocok untuk gim saya.
sumber
Saya melihat ini terlalu sering.
Mengapa membangun mesin, untuk digunakan di game masa depan, ketika Anda tidak tahu game apa yang dibutuhkan?
Mengapa tidak membangun game terlebih dahulu, lalu yang lain, dan yang lain, menggunakan kembali sesering mungkin.
Kemudian Anda memiliki pustaka kode, mungkin tidak terorganisir, tetapi semua terbukti bermanfaat.
Kemudian Anda bisa mengaturnya.
Dan untuk 'framework vs library', saya akan mendasarkannya pada seberapa lelah Anda menulis game loop berulang-ulang dan sebagainya. ;)
Kerangka kerja tidak harus mengunci Anda. Lihat XNA.
sumber
Tetap sederhana.
Jika Anda tidak yakin ke arah mana harus pergi - lakukan saja apa yang dibutuhkan game Anda. Cobalah untuk menulis perpustakaan kecil dan dasar untuk hal-hal yang Anda rasa mungkin dapat digunakan di masa depan. Lihatlah pengembangan perangkat lunak berbasis data. Saya sarankan melihat ke dalam sistem entitas berbasis komponen. Jangan mendasarkan kode di sekitar hal-hal yang unik seperti pemain. Seorang pemain hanyalah obyek lain, sama seperti benda lainnya. Entitas memiliki komponen, mungkin daftar komponen.
Dengan menulis pustaka kecil yang berisi interaksi satu sama lain, Anda dapat melanjutkan dan menentukan mana yang akan digunakan kembali untuk gim berikutnya. Secara pribadi saya memiliki hal-hal seperti perpustakaan "wadah" untuk tipe penyimpanan data. Saya memiliki perpustakaan matematika untuk hal-hal seperti itu. Ada beberapa hal seperti ini yang bisa Anda pilah dan tulis sebagai modul. Kamera, efek, input, entitas, gerakan, fisika, render, penanganan sumber daya, threading, daftarnya terus berlanjut.
Menulis komponen kecil yang berdiri sendiri sering kali meningkatkan keterbacaan dan kemungkinan debugging kode Anda.
Mike Acton dan insomniac games (www.insomniacgames.com) telah menulis banyak topik dan diskusi mengenai pengembangan game, khususnya yang didorong oleh data. Carilah mereka dan lihat informasi seperti apa yang terlalu rumit dan yang menurut Anda menarik dan dapat dipahami. Mereka adalah pengembang hebat dengan banyak pengalaman.
sumber
Saya pikir Anda melakukan generalisasi prematur. Jangan terlalu banyak terjebak pada pertanyaan penggunaan masa depan sekarang. Pilih jawaban dan jalankan dengannya, belajarlah darinya. Balikkan koin jika Anda tidak memiliki preferensi.
Mulailah dengan membangun game. Saat Anda membangun gim kedua Anda, Anda akan memiliki gagasan yang lebih baik bagian mana yang dapat digunakan kembali dan dapat diubah menjadi fungsi perpustakaan yang kuat. Ketika Anda membangun game ketiga Anda, Anda akan memiliki ide yang lebih baik struktur apa yang dapat digunakan kembali dan dapat diubah menjadi kerangka kerja yang kuat.
sumber
Dalam hal fleksibilitas, saya pikir Anda menjawab pertanyaan Anda sendiri: "Kerangka kerja dapat membuat hal-hal bagus dan mudah untuk pengembangan, tetapi kemudian Anda terkunci ." Ini tidak berarti kerangka kerja harus tidak fleksibel; setiap game, misalnya, memiliki loop game. Kerangka XNA Microsoft adalah 99% perpustakaan, tapi permainan Anda memperpanjang kelas permainan yang hanya menyediakan beberapa fungsi kosong untuk hal-hal yang dijamin untuk berada di setiap pertandingan:
LoadContent,Update,Draw. Ini adalah contoh utama dari kerangka kerja non-restriktif.Orang mungkin mengatakan kerangka kerja tidak lebih dari perpustakaan yang dikombinasikan dengan kelas template yang terhubung ke perpustakaan, setidaknya ini adalah pengalaman saya.
Saya cenderung lebih suka perpustakaan daripada kerangka kerja. jMonkeyEngine , misalnya, bagus tapi ini kerangka kerja dan sebagai hasilnya saya perhatikan ia menerima banyak kritik. SDL , di sisi lain, sangat populer; itu hanya perpustakaan. Ini memberikan apa yang Anda butuhkan tetapi keluar dari cara Anda untuk melakukan apa pun yang Anda inginkan dengannya.
Dengan perpustakaan, tidak perlu banyak perekat yang harus dilakukan berdasarkan game-by-game - terutama jika Anda menulis bagian dari perpustakaan Anda untuk mendukung setiap bagian dari loop game; penghitung / penghitung Frame-Per-Detik, misalnya, akan mencegah bagian yang biasanya ditulis ulang itu perlu diciptakan kembali dengan setiap gim.
Selain itu, perpustakaan dapat bersifat umum atau spesifik seperti yang Anda inginkan. Jika Anda membuat game balap dan Anda ingin perpustakaan Anda memiliki fitur khusus balap, itu tidak masalah. Ini adalah kreasi Anda dan Anda bisa memilih secara tepat seberapa fleksibel yang Anda inginkan. Ini akan sangat layak dalam situasi di mana Anda berada dalam kontrak jangka panjang dengan Nascar untuk mengembangkan banyak game balap, misalnya. Anda tidak perlu menginginkan kerangka kerja yang berpotensi mengikat Anda menjadi game balapan-dalam-lingkaran klasik ketika Nascar muncul dan meminta permainan offroad, tetapi Anda menginginkan perpustakaan khusus game balapan karena Anda tahu Nascar tidak akan meminta seorang penembak.
Ini juga tip untuk pengembangan: jika Anda menulis perpustakaan di samping permainan, Anda pasti akan secara tidak sengaja menggabungkan perpustakaan ke permainan, atau membuatnya terlalu tidak fleksibel, tidak peduli berapa banyak perencanaan yang Anda lakukan. Anda akan mengetahuinya segera setelah Anda mencoba membuat permainan yang berbeda dengannya, dan Anda akan menghabiskan waktu untuk memisahkannya; ini tidak selalu merupakan hal yang buruk dan Anda mungkin secara sadar memutuskan untuk melakukan ini, karena Anda akan memiliki lebih banyak waktu luang setelah game pertama Anda dirilis. Tetapi jika Anda membidik perpustakaan bintang sejak awal, cobalah membuat dua game yang sama sekali berbeda pada saat yang sama, dan ekstrak potongan-potongan serupa ke perpustakaan Anda. Anda akan mendapatkan kopling BANYAK lebih sedikit, itu akan jauh lebih fleksibel, dan game ketiga Anda mungkin masih akan mengungkapkan beberapa kelemahan tetapi perpustakaan Anda pada akhirnya akan jauh lebih baik. Namun, jelas jauh lebih sulit dan lebih memakan waktu untuk dilakukan.
sumber