Apa pendekatan berorientasi objek yang benar untuk desain kelas dalam pengembangan game?

Saya sedang mengembangkan game 2D berbasis sprite untuk Windows 7 Phone, menggunakan XNA. Pelatihan dan tutorial yang tersedia sangat membantu, tetapi masalah yang saya hadapi adalah bahwa masing-masing dari mereka mendekati desain kelas mereka secara berbeda, dan kode ini tidak diperhitungkan dengan baik. Akibatnya, sulit bagi saya untuk mendapatkan pemahaman yang baik tentang tanggung jawab mana yang harus saya berikan kepada kelas tertentu.

Sebagai contoh, saya dapat memiliki kelas sprite dasar BaseSpriteyang tahu cara menggambar itu sendiri, memeriksa tabrakan, dll. Saya kemudian dapat memiliki AnimatedSpritekelas yang akan tahu cara menavigasi sprite sheet, ExplodingSpritekelas, dan sebagainya. Teknik ini ditunjukkan dalam contoh Space Invaders dalam materi Windows 7 Phone Jumpstart Session 2 .

Atau, saya bisa menempatkan sebagian besar render dan menjalankan tanggung jawab gim di GameScreenkelas; kelas itu dan kelas turunannya berperilaku lebih seperti formulir atau halaman web dalam hal tanggung jawab mereka. Kelas sprite adalah wadah yang lebih sederhana dengan logika yang jauh lebih sedikit.

Ini adalah teknik yang digunakan dalam game Alien Sprite pada Windows 7 Phone Training Kit dan contoh-contoh manajer permainan lainnya.

Apa pendekatan berorientasi objek yang benar untuk desain kelas dalam pengembangan game?

Saya memang menggunakan pendekatan yang lebih berorientasi komponen, di mana Anda akan memiliki kelas Sprite yang memiliki komponen seperti Visual, Collision, Animation, Input, dll. Dengan pendekatan ini saya tidak memiliki hierarki kelas yang mendalam (yang baik) .

Untuk beberapa info tentang Desain Berorientasi Komponen lihat di sini .

Dalam permainan, pola Komponen adalah solusi umum.

The Principles SOLID berlaku sebagai banyak untuk desain kode permainan untuk profesi lain - setidaknya sampai Anda datang ke mengoptimalkan, jadi saya akan menggunakan contoh pertama Anda sebagai titik awal.

Saya akan melangkah lebih jauh, karena BaseSprite terdengar seperti itu memiliki kecenderungan untuk menjadi megaclass. Prinsip Tanggung Jawab Tunggal menyatakan bahwa tabrakan, render, dan navigasi semua harus ditangani oleh komponen, bukan entri individual dalam hierarki kelas. Kelas induk dari semua komponen ini seharusnya hanya menangani mendorong posisi dunia di antara mereka.

Untuk beberapa proyek terakhir saya lebih condong ke arah pendekatan gaya MVC.

Awalnya kami tidak yakin apakah ini akan berhasil, tetapi itu bekerja dengan sempurna.

Model

Objek data. Hanya data murni. Tidak ada perilaku, tidak ada render.

Manajer data. Hanya menangani "daftar" objek data. (Dapat juga ditingkatkan untuk mendukung pooling.)

Melihat

Kami menyebutnya penyaji. Untuk setiap tipe objek data ada penyaji. Ketika dipanggil dengan manajer, itu akan membuat semua objek dalam daftar itu.

Pengendali

Sama seperti penyaji, tetapi mengontrol perilaku.

Contoh

ShipManager memiliki daftar Kapal. ShipController akan memindahkan Kapal sesuai dengan statusnya. ShipRenderer akan merender Kapal sesuai dengan negara mereka.

Mengapa

Dengan cara ini pandangan dan logika dipisahkan secara ketat. Itu membuat porting ke platform baru cukup mudah. Mengoptimalkan tata letak data di dalam XxxManager juga sangat mudah.