Logika game yang sama pada dua pustaka grafis yang terpisah

Apa filosofi kode / struktur abstraksi / desain program yang memungkinkan game digunakan dengan grafis 2D dan 3D (secara terpisah) TANPA harus kode ulang logika Game?

Kita berbicara tentang mengambil kode yang sama, mengubah hal-hal minimum (misalnya, menukar nama file untuk aset 2D dengan nama file untuk aset 3D), dan mungkin memasukkan beberapa spesialisasi kelas dasar per generik / templat.

Untuk menempatkannya dalam konteks nyata di mana masuk akal: bayangkan permainan LAN-multipemain di mana ada satu klien 3D yang haus akan kinerja tinggi untuk para pemain dengan beberapa rig gamer yang sangat bagus, dan klien 2D yang lebih rendah hati untuk yang lama kotak berdebu yang seseorang temukan di loteng mereka. Tapi itu masih permainan yang sama - acara yang sama terdaftar (seseorang mengambil koin), protokol jaringan yang sama digunakan, dunia proporsional, dll.

Untuk memasukkannya ke dalam konteks MVC: Controllers adalah persis sama (menekan tombol "Atas" akan mengatur akselerasi pemain di 3,5 unit / detik), Views sama sekali berbeda (2D versus 3D), dan Modelnya sama kecuali untuk apa pun yang berhubungan langsung dengan grafik (pemeriksaan tabrakan untuk lingkungan dilakukan setiap 5 detik, dan itu menggunakan algoritma yang sama. Perhatikan bahwa ini berarti ada Z-koordinat untuk semua Objek Game dalam versi 2D, tapi itu hanya diabaikan atau ditampilkan kepada pengguna dengan cara lain, misalnya oleh bayangan yang ditampilkan lebih jauh ke kiri ketika pemain ada di udara).

Apa yang membuat topik ini sangat menarik adalah bahwa FORCE akan memaksa pengembang untuk memiliki gagasan yang sangat jelas tentang bagaimana datanya disusun dan bagaimana kontrol mengalir. Perhatikan bahwa ini tidak berarti menggunakan apa pun selain perpustakaan grafis seperti SDL, D3DX atau OpenGL. Tidak ada mesin game!

Karena ini adalah sebagian besar pertanyaan teoretis, saya akan mengabaikan bahasa pemrograman, tetapi jika Anda ingin memberikan contoh, Anda dapat menggunakan bahasa apa pun yang Anda suka, C ++ jika Anda ingin menghabiskan seluruh babi, atau bahkan Brainfuck jika Anda merasa hingga tantangan (Setiap jawaban konkret akan dihargai, serta yang abstrak!).

Saya pikir semua (?) Yang Anda butuhkan adalah lapisan abstraksi yang membungkus perpustakaan grafik Anda; Anda akan membutuhkan yang baru untuk setiap perpustakaan yang akan Anda gunakan, dan masing-masing harus memiliki API eksternal yang sama persis.

Pikirkan pelokalan string: alih-alih mengkodekan string "Inventaris" ke dalam gim Anda, Anda akan memanggil perpustakaan pelokalan (yang mungkin dibuat khusus), yang akan melakukan beberapa proses dan mengembalikan string yang tepat, tergantung pada konteks dari permainan.

Dengan cara yang sama, semua panggilan ke mesin grafis Anda akan dilakukan melalui bungkus Anda di sekitarnya.

Dalam melakukan ini, Anda membatasi / membatasi perintah apa yang dapat Anda berikan kepada mesin grafis Anda. Berikut ini beberapa yang penting:

1. Gambar (objek grafik) di (lokasi)
2. Ubah properti (alpha, rotasi, dll.) Dari (objek grafik)
3. Pindahkan (objek grafik) ke (lokasi)
4. Membangun peta (nama level / struktur data)

Dan beberapa lainnya, yang akan Anda temukan saat Anda mengerjakan proyek Anda.

Jika Anda menggunakan Bahasa Berorientasi Objek-Ketik-Berorientasi, Anda akan memanggil perintah di atas antarmuka yang semua pembungkus Anda akan menerapkan. Lebih disukai, ini akan menjadi satu - satunya metode yang tidak dilindungi / publik.

Sekarang, buat pembungkus baru untuk masing-masing pustaka grafik Anda, dan terapkan API . Ketika perintah untuk menggambar __ at __ diberikan kepada Anda, Anda harus menggunakan kode untuk membuat sprite atau model, dan menariknya ke lingkungan Anda. Ini mungkin memerlukan beberapa tipu daya, seperti menyimpan setiap sprite dalam hash agar dapat diakses kembali di lain waktu dengan simbol yang diberikan.

Sedangkan untuk membangun peta, cara yang paling efisien adalah dengan pra-membangun setiap peta untuk setiap mesin grafis sebelumnya dan melakukan pencarian. Atau Anda bisa menyimpan peta di struktur data kustom Anda sendiri dan kemudian menggunakan pembungkus Anda untuk membangun peta dari struktur data itu.

Semoga ini bisa membantu Anda memulai =]

Membangun arsitektur gim Anda dengan paradigma yang cukup dekat dengan MVC untuk memungkinkan abstraksi kode tampilan yang lengkap mungkin akan cukup sulit untuk setiap proyek besar. Namun, sepertinya penghalang terbesar untuk membuat game yang mendukung klien 2D dan 3D adalah merancang game di mana kedua klien sama-sama mampu.

Penting untuk memulai desain gim Anda dengan maksud penuh untuk menciptakan dan mendukung kedua klien, dan mungkin akan lebih aman untuk membatasi semua fungsi gim dengan apa yang masuk akal bagi klien 2D.

Sebagai contoh jebakan, jika Anda tidak merancang ke set fungsi terbatas Anda dapat membuat level di mana informasi atau objek penting hanya terlihat dari sudut tertentu. Meskipun itu akan baik-baik saja untuk klien 3D yang memiliki 360 derajat kebebasan melihat kecuali jika klien 2D Anda secara eksplisit mendukung sudut pandang yang memiliki visibilitas pada masing-masing objek penting tersebut, Anda akan mengganggu pengguna klien.

Akan lebih baik untuk menetapkan jumlah sudut tampilan tertentu untuk klien 2D (8 atau 16 atau lebih) dan mengembangkan semua konten agar sesuai dengan batasan-batasan tersebut. Sayangnya, jika Anda memiliki level dan objek yang dirancang agar dapat dilihat hanya dari satu set sudut tertentu, itu bisa terlihat sangat aneh dari dalam klien 3D.

Menurut pendapat saya itu akan menjadi upaya pilihan yang buruk desain game memungkinkan untuk klien 2D dan 3D yang dimaksudkan untuk memiliki kemampuan yang sama. Saya pikir ini akan menjadi penggunaan sumber daya yang lebih baik untuk merancang opsi gameplay asimetris, dan memungkinkan setiap klien untuk bermain dengan kekuatannya. Sebagai contoh jika klien 2D terutama berfokus pada perspektif level strategis pada dunia game, dengan klien 3D digunakan untuk gameplay level taktis.

Saya pikir Anda sudah menjawab pertanyaan Anda sendiri:

Untuk meletakkannya dalam konteks MVC: Pengontrol adalah sama persis (menekan tombol "Atas" akan mengatur akselerasi pemain di 3,5 unit / detik), Views sama sekali berbeda (2D versus 3D), dan Modelnya sama kecuali untuk sesuatu yang berhubungan langsung dengan grafik.

Jadi, dengan memberikan abstraksi yang memadai antara input, logika game, dll, dan grafik, Anda akan menyelesaikan masalah.

Ini pada dasarnya adalah titik dari model MVC, terutama karena berkaitan dengan aplikasi desktop dan web: mungkin ada banyak klien yang mengakses dan memanipulasi data yang sama (misalnya antarmuka web, klien seluler, dan klien desktop untuk email).

Tetap sederhana jika Anda menginginkannya sederhana: - Tulis logika permainan untuk memindahkan objek. Jangan menyimpan data apa pun pada mereka yang terkait dengan rendering. - Tulis penyaji yang diberi kesempatan untuk melihat status data permainan dan menggambarnya.

Anda dapat menggunakan teknik pemrograman yang lebih atau kurang rumit untuk ini. Satu-satunya hal yang Anda butuhkan adalah cara untuk mendapatkan "ekstra" data yang harus Anda render untuk setiap objek game. Cara paling sederhana adalah tidak memiliki data tambahan yang dibutuhkan! Jika objek game adalah "Wizard", gambarkan Wizard.

Jika Anda membutuhkan metode yang lebih rumit, pertimbangkan polimorfisme, pola memento, tabel hash, void * pointer, dll. Jangan terlalu merekayasa itu (sebagian besar metode ini direkayasa berlebihan).