Mesin game dan desain berbasis data

Saya pernah mendengar tentang desain yang didorong oleh data dan telah lama meneliti tentang hal itu. Jadi, saya sudah membaca beberapa artikel untuk mendapatkan konsep.

Salah satu artikelnya adalah Data Driven Design yang ditulis oleh Kyle Wilson. Ketika ia menjelaskan, menurut saya kode aplikasi (yaitu kode untuk mengendalikan sumber daya seperti memori, jaringan ...) dan kode logika permainan harus dipisahkan, dan kode logika permainan harus didorong oleh sumber data eksternal. Pada titik ini, saya bisa membayangkan bahwa pengembang akan menulis semacam editor game yang menerima data eksternal tentang objek dalam game (seperti informasi karakter, informasi senjata, informasi peta ...). Desain skenario akan ditulis dengan bahasa khusus / alat yang ditulis oleh programmer untuk memungkinkan perancang game membuat interaksi di antara objek-objek game. Perancang gim akan menggunakan bahasa skrip yang ada / khusus untuk menulis skrip untuk gim, atau menyeret dan menjatuhkan alat untuk membuat dunia gim. Contoh pendekatan alat yang bisa saya pikirkan adalah World Editor, yang biasanya dikemas bersama dengan game Bliizard.

Namun, artikel lain menentang penggunaan Desain Berbasis Data, Kasus Terhadap Desain Berbasis Data . Penulis menyarankan untuk tidak membiarkan desain game didorong oleh data, karena akan membutuhkan lebih banyak waktu untuk mengembangkan game, karena desainer game memiliki beban pemrograman. Sebagai gantinya, akan ada programmer game untuk memprogram game secara bebas dari desain sketsa, dan diverifikasi oleh perancang game setelah pemrograman game selesai. Dia menyebut ini didorong oleh programmer. Apa yang saya pikirkan tentang metode ini mirip dengan cara yang biasa saya lakukan: Logika permainan adalah aplikasi itu sendiri, sebagaimana diterapkan pada ide di atas, aplikasi tersebut adalah editor permainan, dan permainan yang sebenarnya dirancang berdasarkan pada alat.

Bagi saya, metode pertama tampaknya lebih masuk akal, karena komponen game dapat digunakan kembali untuk banyak proyek. Dengan metode kedua yang menentang desain berbasis data, kode game hanya milik game itu. Inilah mengapa saya pikir Warcraft memiliki begitu banyak genre game di dalamnya, seperti Warcraft asli dan berbagai peta khusus, dan salah satu yang paling terkenal: DOTA yang sebenarnya mendefinisikan genre baru. Untuk alasan ini, saya mendengar orang menyebut Editor Dunia adalah mesin permainan. Benarkah ini seharusnya mesin permainan?

Jadi, setelah semua ini, saya hanya ingin memverifikasi apakah ada kesalahan dalam pemahaman saya tentang ide-ide ini (data driven, drive programmer, scripting dll ...)?

Membuat game Anda (atau produk perangkat lunak apa pun) yang didorong data hampir selalu bermanfaat. Satu-satunya masalah nyata adalah Anda mungkin menghabiskan sedikit lebih banyak waktu membangun sistem yang relevan di muka; itu akan membayar selama sisa karir Anda sebagai seorang programmer (bahkan jika Anda tidak menggunakan kembali sistem yang sama sepanjang waktu itu, Anda akan menggunakan kembali teknik yang Anda gunakan untuk membangunnya).

Tantangannya, dan di mana pemutusan dalam dua artikel yang Anda tautkan muncul, adalah apa yang Anda pilih untuk dimasukkan ke dalam data dan siapa yang Anda pilih untuk memberikan akses ke data itu. Pada dasarnya, desain dan pengembangan yang didorong oleh data berarti Anda memasukkan informasi ke dalam penyimpanan eksternal, memuat informasi itu pada waktu berjalan, dan menindaklanjutinya. Kode aplikasi Anda melakukan apa yang diminta oleh data eksternal, alih-alih Anda menulis kode aplikasi yang secara langsung melakukan apa yang Anda pikirkan hasil akhirnya. Itu bukan ide yang kompleks.

Anda tidak harus membangun "arsitektur berbasis komponen" yang kompleks (seperti isinya belakangan ini). Menempatkan konstanta untuk mengubah-ubah fisika (gaya gravitasi, koefisien restitusi) dalam file teks didorong oleh data. Skrip (dalam Lua atau yang lainnya) didorong oleh data. Menjelaskan data level Anda dalam XML. Yang seperti itu.

Anda dapat mengendarai hampir semua komponen perangkat lunak dengan data, dan Anda dapat memilih mana yang ingin Anda gunakan. Waktu pengembang mahal; waktu programmer terutama begitu. Jika Anda dapat menghemat waktu Anda atau programmer lain dengan menempatkan perilaku dan data di penyimpanan eksternal dan tidak memerlukan game untuk dikompilasi ulang untuk setiap perubahan kecil, Anda harus melakukannya. Anda akan menghemat uang dan menyelesaikan sesuatu dengan lebih cepat.

Selain itu, Anda menjalankan risiko besar dalam mencoba membuat "desain desainer" dan membuat programer "membuat desain itu menjadi kenyataan," memaksa seorang programmer untuk tetap ada dalam loop iterasi untuk pekerjaan seorang desainer: Anda menjalankan risiko membuat programmer merasa seperti dia hanya kode monyet, membuat sedikit perubahan sepele untuk desain terus-menerus. Ini dapat secara besar-besaran menurunkan moral bagi sebagian besar programmer, yang ingin bekerja pada tantangan teknis yang menarik dan tidak menjadi proksi desainer.

Untuk pertanyaan spesifik Anda:

Benarkah ini seharusnya mesin permainan?

"Mesin game" tidak benar-benar memiliki definisi tetap. Umumnya itu adalah kumpulan teknologi dasar yang digunakan untuk membuat game, biasanya didukung oleh banyak alat terkait (dan dengan demikian cukup didorong data). Tetapi itu cukup bervariasi dari konteks ke konteks.

Jadi, setelah semua ini, saya hanya ingin memverifikasi apakah ada kesalahan dalam pemahaman saya tentang ide-ide ini (data driven, drive programmer, scripting dll ...)?

Anda tampaknya kurang lebih berada di jalur yang benar, meskipun Anda mungkin terlalu rumit apa data didorong desain dan pengembangan dengan menggabungkannya dengan sistem berbasis komponen.

Sebagai penulis posting kedua, saya ingin mengklarifikasi beberapa poin.

1. Seperti yang disarankan Josh Petrie, penataan kode Anda untuk menggunakan data alih-alih hanya pengodean keras semuanya selalu menang. Saya tidak menyarankan sebaliknya. Saya menunjukkan bahwa mendorong segala sesuatu pada perancang bukanlah ide yang baik. Istilah "desain berbasis data" memiliki arti yang berbeda bagi orang yang berbeda, jadi saya mungkin seharusnya lebih spesifik ketika saya menulis artikel aslinya.
2. Di setiap tempat saya bekerja, kami membuat struktur data yang dapat diubah dalam engine. Untuk melakukan perubahan, kita tidak perlu mengkompilasi ulang game. Kami dapat mengubah nomor secara dinamis saat runtime. Struktur data sering disimpan dalam kode, tetapi tergantung pada siapa yang mengubahnya, mereka dapat dengan mudah diambil dari "file data".
3. Sebagian besar lingkungan pengembangan mendukung beberapa bentuk edit dan melanjutkan atau memuat ulang modul untuk C / C ++.
4. Sebagian besar studio pengembangan game memiliki pemrogram gameplay. Pekerjaan mereka seringkali untuk bekerja dengan desainer dalam menciptakan pengalaman yang menyenangkan. Perhatian utama mereka bukanlah tantangan teknis tetapi lebih pada bersenang-senang dari kode. Saya telah bekerja sebagai programmer gameplay selama bertahun-tahun, dan saya menemukan ini lebih menarik daripada hanya mencoba memecahkan tantangan teknis. Tanggung jawab saya beragam, tetapi saya merasa pekerjaan saya paling memuaskan ketika saya bertanggung jawab atas implementasi dan saya bekerja dengan para perancang untuk membuat sesuatu yang keren. Masalah dengan desainer pengkodean atau scripting adalah bahwa programmer sering harus memilah bug, yang merupakan salah satu hal paling tidak menyenangkan yang dapat Anda lakukan sebagai programmer.
5. Apa yang paling cocok untuk sebuah studio tergantung pada gimnya. Jika Anda memiliki waktu yang lama untuk membuat game, dan Anda ingin memberikan kaki permainan Anda untuk komunitas mod dan menciptakan sesuatu yang besar dalam ruang lingkup, maka membuat game yang sepenuhnya didorong oleh data masuk akal. Banyak game yang tidak memiliki tujuan itu. Mereka harus membuat game baru dalam dua tahun, dan kecuali mereka memiliki franchise hit, itu mungkin jenis game yang berbeda dari pekerjaan mereka sebelumnya.
6. Apa yang dilakukan "perancang" dapat bervariasi dari satu studio ke studio lainnya. Saya pernah mendengar tentang studio pengembangan yang mempekerjakan pemrogram gameplay dari studio lain, menyebut mereka desainer, dan meminta mereka menuliskan perilaku permainan. Ini mengesampingkan masalah memiliki orang yang tidak terlatih dalam pemrograman coding / scripting.
7. Harus selalu ada penggambaran antara kode logika game dan kode engine. Selain itu, Anda biasanya ingin memiliki semacam editor visual untuk penempatan objek. Saya tidak pernah bekerja di studio di mana lokasi musuh dikodekan dengan keras. Mereka ditempatkan di editor. Izinkan saya mengajukan sebuah contoh tentang apa yang saya bicarakan. Katakanlah perancang menganggap musuh. Apakah perancang selain naskah perilaku tipe musuh baru ini? Itulah yang saya anggap desain berdasarkan data (dalam hal apa yang ditulis Tim Moss tentang hal itu). Dalam cara saya usulkan, programmer bekerja dengan desainer, mereka membuat musuh yang menyenangkan bersama-sama mungkin dengan parameter tweakable, dan kemudian mereka ditempatkan di level.
8. Kode asli yang ditulis oleh seorang programmer akan mengeksekusi lebih cepat pada saat runtime daripada sebuah skrip yang ditulis oleh seorang programmer, yang akan mengeksekusi lebih cepat daripada sebuah skrip yang ditulis oleh seseorang dengan pengetahuan teknis yang kurang. Kinerja ini mungkin penting atau tidak tergantung pada jenis permainan apa yang Anda buat dan apa yang Anda lakukan, tetapi itu adalah sesuatu yang perlu dipertimbangkan.
9. Anda dapat membagikan kode gim antar gim terlepas dari metode apa yang Anda pilih. Saya tidak begitu yakin apa yang Anda maksud dengan poin ini. Bahkan jika Anda tidak menggunakan bahasa scripting atau alat visual untuk mendefinisikan beberapa perilaku, Anda harus merancang kode gameplay Anda menjadi komponen yang dapat digunakan kembali sebanyak yang Anda bisa. Akan selalu ada hal-hal yang tidak berlaku untuk permainan Anda berikutnya, tetapi setiap tempat saya pernah bekerja, ketika kami memulai permainan berikutnya, kami mulai dengan basis kode dari sebelumnya - bahkan jika itu bukan sekuel. Kami kemudian menyimpan hal-hal yang masuk akal dan menghapus hal-hal khusus game.

Pada akhirnya, tidak ada jawaban benar atau salah. Ini adalah pertanyaan tentang bagaimana Anda dan rekan kerja Anda merasa nyaman bekerja. Ketika saya menulis blog itu beberapa waktu lalu, ada banyak pembicaraan tentang bagaimana semua pekerjaan harus didorong kepada para desainer, dan saya ingin menulis tentang berapa banyak perusahaan game yang sukses yang saya tahu menemukan keseimbangan yang berbeda.

Juga, sebagai catatan tambahan, entri blog saya berusia 5 tahun. Sepertinya lebih banyak studio yang bergerak ke arah bahasa scripting dan yang lainnya akhir-akhir ini tetapi sedang menciptakan alat yang matang untuk men-debug mereka, yang merupakan keluhan utama saya. Ketika saya menulis ini, saya rasa Unreal Kismet tidak ada, yang belum saya gunakan, tetapi sepertinya mereka mencoba untuk menyederhanakan skrip dan ternyata memiliki debugger. (Tidak tahu seberapa baik kerjanya)

Untuk gim berskala lebih kecil, saya pasti tidak berpikir Anda ingin mencoba dan menggunakan bahasa scripting atau fungsi serupa ke dalam teknologi Anda, tetapi jika Anda memiliki tim besar dan banyak waktu untuk mencurahkan teknologi, dimungkinkan untuk melakukan ini investasi yang tepat dan waktu mungkin masuk akal tergantung pada cara tim pengembangan Anda suka bekerja. Secara pribadi, saya mungkin akan berpegang teguh pada C ++ selama mungkin karena bagi saya, ini adalah yang termudah dan tercepat karena saya sering harus mencoba dan mengatasi "fitur" seperti pengumpulan sampah.

Anda harus melihat Mesin Tek BitSquid . Itu dibangun menggunakan konsep DOD. Blog Niklas Frykholm sangat menarik. Ada banyak artikel tentang bagaimana mesin ini dirancang.

Di GDC 2011, Niklas telah membuat presentasi tentang Data Driven Renderer .