Apakah Desain Berbasis Domain bagus untuk permainan?

Saya baru saja membaca tentang model Domain dan itu memberi saya pencerahan karena saya telah mengembangkan game yang memiliki kelas yang hanya menyimpan data (beberapa perilaku / metode). Saya menugaskan pekerjaan menangani kelas-kelas ini kepada para manajer ... dan sekarang manajer saya tampaknya terlihat seperti objek Dewa. Objek permainan saya yang seharusnya menangani logika hanyalah model domain anemia.

Pola desain saya saat ini adalah di Singleton dan saya ingin melakukan pengodean ulang untuk menyelesaikan masalah ini. Saya belum pernah melihat DDD di game (sampai sekarang) tetapi apakah ini pendekatan yang baik? Saya hanya seorang programmer pemula (cenderung ke game dev't) jadi saya ingin belajar lebih banyak tentang arsitektur yang baik sebelum game terlalu membengkak untuk mendesain ulang.

Saya belum pernah mendengar desain berbasis domain sebelum posting Anda. Melihat sekilas pada beberapa referensi - di sini dan di sini - tampaknya menunjukkan bahwa itu hanya nama yang bagus untuk metode pemrograman berorientasi objek tradisional tahun 90-an yang saya ajarkan di universitas, di mana Anda mencoba dan menulis kelas untuk setiap kata benda yang muncul dalam situasi yang Anda coba model dengan perangkat lunak, sehingga struktur perangkat lunak tampaknya mengikuti struktur konsep dunia nyata.

Dengan demikian, jawaban saya untuk ini adalah bahwa itu tidak "baik". Ini biasanya merupakan titik awal yang masuk akal tetapi terbukti tidak memadai saat Anda melanjutkan. Anda jarang memiliki satu domain tetapi beberapa domain berbeda dalam satu perangkat lunak - misalnya, Anda mungkin memiliki domain game (dunia, karakter, item), domain renderer (shader, jerat, bahan-bahan), domain input (sistem file, jaringan, keyboard dan mouse), dan masalah muncul ketika domain tumpang tindih dan saling mempengaruhi. Seringkali dalam perjalanan menggabungkan 2 domain bersama, Anda menyadari bahwa sebenarnya ada ketergantungan di sana yang membutuhkan perubahan, yang berarti salah satu representasi Anda menjadi lebih menjadi beban daripada bantuan.

Contoh samar mungkin adalah perpustakaan matematika di konsol dan karakter dalam game Anda. Perpustakaan matematika Anda akan ingin memiliki daftar data yang besar dan kemudian 1 instruksi untuk dilakukan pada daftar itu, untuk berjalan secara efisien. Karakter dalam gim Anda masing-masing akan memiliki set data verteks sendiri untuk rendering dan animasi, dll. Sekarang, bagaimana Anda mendapatkan daftar panjang semua data verteks dari masing-masing karakter Anda untuk dapat menanganinya dalam sekali jalan? Anda bisa melakukan operasi penyalinan lambat, atau sebaliknya Anda bisa memperbaiki karakter Anda sehingga data mereka lebih dapat diproses oleh perpustakaan matematika - tetapi kemudian salah satu domain Anda mogok untuk memilih yang lain.

Secara pribadi saya sangat waspada terhadap label yang menyerupai "Apapun-Didorong-Desain". Perangkat lunak terlalu luas dan terlalu rumit untuk membuatnya menjadi pendekatan satu ukuran untuk semua. Sebaliknya, ketika mencoba menulis perangkat lunak terbaik yang saya bisa, saya mencoba dan kembali pada prinsip-prinsip SOLID . Ini memberi Anda ide bagus tentang seberapa baik kode Anda, tanpa menjanjikan obat mujarab dari metode yang dapat Anda ikuti dan secara ajaib sampai pada kode yang baik. Sayangnya, tanpa metodologi terlampir seperti itu, dibutuhkan banyak pengalaman sebelum Anda belajar bagaimana menyesuaikan diri dengan pedoman ini, yang mungkin mengapa begitu banyak orang menyukai metodologi ini.

Mengenai masalah Anda memiliki kelas anemia dan objek manajer, ini biasanya adalah sesuatu yang dibahas dalam pelajaran orientasi objek pengantar dan tidak benar-benar mengharuskan Anda mematuhi metodologi khusus untuk 'memperbaikinya'. (Anda mungkin ingin mengambil buku tentang pemrograman berorientasi objek jika Anda baru saja memulai.) Kelas adalah gabungan dari keadaan dan perilaku, di mana perilaku memodifikasi keadaan itu, dan ini disebut enkapsulasi. Secara umum Anda mencoba dan merangkum sebanyak mungkin, yang berarti bahwa negara harus dimanipulasi oleh objek itu sendiri (dan hanya objek itu). Hanya untuk perilaku yang tidak dapat dimodelkan dalam kelas yang akan Anda delegasikan ke kelas eksternal, seperti manajer, itulah sebabnya keberadaan kelas manajer sering dianggap sebagai tanda kode berorientasi objek yang ditulis dengan buruk.

Pola desain saya saat ini adalah di Singleton dan saya ingin melakukan pengodean ulang untuk menyelesaikan masalah ini.

Saya tidak tahu apa yang Anda maksud dengan kalimat itu. Pola desain adalah cara yang terkenal untuk menulis sebagian kecil dari program Anda. Anda tidak akan memiliki pola desain 'saat ini', juga tidak akan membentuk sisa program Anda. Untuk pemula, pola-pola ini berguna untuk membuat Anda berada di jalur yang benar, sedangkan bagi para ahli mereka lebih merupakan cara untuk berkomunikasi tentang situasi kode umum. Namun satu hal penting: lajang hampir selalu merupakan ide yang buruk, dan Anda harus menghindarinya kapan pun memungkinkan. Anda dapat menemukan banyak pendapat tentang lajang di situs ini dan di Stack Overflow, tetapi di sini ada satu pertanyaan praktis dengan jawaban yang membantu Anda menghindari membutuhkannya.

Paradigma

Pada saat jawaban ini ditulis, jawaban yang diposkan di sini semuanya salah.

Alih-alih bertanya apakah Domain-Driven Design baik untuk game. Anda harus bertanya apakah "Pemodelan Domain" cocok untuk gim.

Apakah pemodelan domain baik untuk game?

Jawabannya adalah: kadang-kadang sangat menakjubkan. Namun, jika Anda membuat game real-time seperti platformer atau FPS atau apa pun (banyak jenis game) maka tidak ada. Ini belum tentu cocok untuk sistem tersebut. Namun, mungkin ada sistem di mana game-game di mana menerapkan pola model domain efektif.

Seperti yang disebutkan orang lain di sini, kerangka kerja komponen-entitas cenderung sangat populer, dan untuk alasan yang baik. Namun, dalam budaya pengembangan game tampaknya ada kekurangan arsitektur berlapis. Sekali lagi, ini untuk alasan yang baik karena sebagian besar permainan yang orang akan kembangkan hanya bermutasi pada entitas dan membiarkan konsekuensi yang muncul menjadi permainan.

SEMUA PERANGKAT LUNAK BUKAN PERANGKAT LUNAK YANG ANDA MENULIS. Beberapa sangat berbeda dari yang lain.

Beberapa contoh domain di mana pemodelan domain berfungsi dengan baik adalah permainan kartu, permainan papan, dan jenis sistem lainnya yang dikendalikan oleh peristiwa.

Game yang dijalankan pada laju bingkai X dengan gerakan dll ditentukan oleh delta waktu sebagai konsep domain inti mungkin tidak cocok. Dalam hal ini, "domain" kami seringkali sangat sederhana sehingga tidak perlu untuk pemodelan domain. Deteksi tabrakan, pemijahan entitas baru, pengaruh kekuatan pada entitas yang ada, dll. Cenderung mencakup sebagian besar permainan.

Namun, ketika segala sesuatunya menjadi rumit, Anda mulai melihat pengembang menerapkan model domain dalam entitas mereka untuk menangani jenis perilaku dan perhitungan tertentu.

Pola model domain dalam arsitektur game

Mesin game Anda (misalnya, Unity3D) seringkali berorientasi komponen-entitas. Di platformer, Anda mungkin memiliki entitas untuk karakter Anda dan kondisinya terus-menerus bermutasi untuk memperbarui posisi dll.

Namun, dalam permainan yang lebih digerakkan oleh peristiwa, lebih mungkin bahwa peran kerangka kerja entitas-komponen lebih hanya ada sebagai Antarmuka Pengguna. Anda berakhir dengan arsitektur berlapis.

UI membuat status permainan kepada pengguna. Pengguna berinteraksi dengan UI, memicu perintah di lapisan layanan. Lapisan layanan berinteraksi dengan objek domain. Objek domain mengangkat peristiwa domain. Pendengar acara mendengar kejadian dan memicu perubahan di UI.

UI> Lapisan Layanan> Model Domain

Singkatnya, berakhir dengan model-view-controller dengan implementasi lapisan layanan.

Menggunakan arsitektur ini, Anda memiliki inti game yang sepenuhnya dapat diuji unit (Jarang terjadi dalam budaya pengembangan game, dan ini menunjukkan) dengan antarmuka yang digerakkan oleh peristiwa.

Ok sekarang, apa itu DDD?

Desain Berbasis Domain secara khusus adalah budaya / gerakan penekanan pada pola analitik yang digunakan untuk mempelajari tentang domain, sehingga Anda benar-benar membangun hal yang benar, dan kemudian pola implementasi yang memberdayakan Anda untuk menerapkan lapisan model yang mewakili konsep dalam model domain menggunakan idiom bahasa Anda. DDD keluar dari komunitas yang bekerja dengan domain rumit dan selalu mencari cara untuk mengelola kompleksitas tinggi dalam aplikasi mereka dengan berfokus pada pemodelan domain.

DDD tidak melakukannya dengan baik jika tujuan Anda hanya memulai pengkodean, bermain-main dengan sistem dan kemudian mencari tahu apa yang ingin Anda bangun nanti, dll. Asumsi bahwa ada lebih atau kurang sebuah domain yang ada. Jadi, jika Anda tidak tahu akan seperti apa permainan Anda .. Lalu, itu tidak akan berhasil.

Tidak, saya tidak berpikir DDD, atau arsitektur "kata kunci" lainnya sangat bagus untuk gim. Dengan kemungkinan pengecualian "sistem komponen", yang tampaknya sangat populer di sini.

Ketika saya mendengar pertanyaan dan diskusi seperti ini, saya teringat akan situs ini . Merenungkan berbagai arsitektur kata-kata biasanya akan membuat Anda kurang baik daripada benar-benar merancang dan membuat kode aplikasi Anda sendiri.

Ya, tetapi Anda harus beradaptasi.

Saat menggunakan DDD Anda akan mendapatkan modularitas dan tanggung jawab tunggal dari setiap domain. Tetapi hal lain hanya membuat segalanya menjadi kompleks.

Lihat jawaban saya di sini