Bagaimana cara mendesain mesin game dalam bahasa berorientasi objek? [Tutup]

Setiap kali saya mencoba dan menulis permainan dalam bahasa berorientasi objek apa pun, masalah pertama yang selalu saya hadapi (setelah memikirkan jenis permainan apa yang akan ditulis) adalah bagaimana merancang mesin. Bahkan jika saya menggunakan pustaka atau kerangka kerja yang ada seperti SDL, saya masih harus membuat keputusan tertentu untuk setiap game, seperti apakah akan menggunakan mesin negara untuk mengelola menu, kelas seperti apa yang digunakan untuk memuat sumber daya, dll.

Apa desain yang bagus dan bagaimana penerapannya? Apa saja kompromi yang harus dibuat dan pro / kontra mereka?

Saya ragu seseorang akan dapat mengatakan 'Anda harus melakukan ini dan itu dan ini dan slot ini dengan yang menggunakan pola X'.

Namun, beberapa sumber daya yang berguna:
Enginuity - serangkaian artikel pembuatan mesin di Gamedev.net.
Game Coding Complete - Saya memiliki buku ini, dan ia membahas setiap (well, hampir) aspek pemrograman game dengan baik. Itu juga memiliki mesin yang dibangun di seluruh buku.
Arsitektur Mesin Game - Ini adalah buku bagus untuk desain mesin.
C4 Engine Layout - Diambil dari komentar saya, tetapi ini menunjukkan cara tingkat tinggi untuk menyatukan setiap bagian dari mesin.

Ini mungkin sedikit terlalu banyak untuk apa yang Anda butuhkan, tetapi Anda tidak bisa tahu terlalu banyak tentang sesuatu, dan saya yakin Anda akan mendapatkan rencana yang baik dari mereka.

EDIT: Saya lupa artikel Gamedev telah diarsipkan sejak situs baru, diperbaiki :)

Sebagai contoh, inilah bagaimana proyek roguelike saya saat ini terstruktur (di Jawa). Ini menggunakan mesin grafis 2D sehingga banyak kode rendering sudah diurus untuk saya. Kritik disambut.

class Game
Kelas ini mengatur mesin negara yang mengelola kondisi permainan saat ini. (dalam menu vs. memulai gim baru vs. memainkan gim yang disimpan)

interface State
Setiap kelas State berisi dua loop: loop untuk memperbarui logika dan loop untuk rendering. Mereka juga berisi kode untuk memanggil Gamekelas dan meminta perubahan ke status yang berbeda.

class ResourceManager
Satu singleton yang diinisialisasi oleh Gamekelas yang memuat semua sumber daya yang dibutuhkan dan memungkinkan akses ke sana. Saya tidak suka desain ini karena membuatnya sulit untuk memuat / membongkar sumber daya pada tingkat yang berbeda, misalnya. Saya mungkin akan mendesain ini secara berbeda jika saya memulai dari awal.

class Map
Peta berisi larik ubin dan daftar semua makhluk dan item di peta. Ini kelas yang cukup mendasar.

class Creature
Makhluk mengandung informasi tentang diri mereka sendiri termasuk perhitungan gerakan (mengharuskan mereka untuk tahu di mana Peta mereka berada, dan untuk dapat menanyakannya untuk mencari tahu tentang hambatan). Memutuskan apakah akan melakukan ini, atau meminta semacam manajer mengaturnya untuk semua makhluk adalah sesuatu yang aku perjuangkan.

interface AITask
Makhluk dapat memiliki daftar AITasks, yang dieksekusi setiap kali loop logika makhluk dijalankan. AITask memiliki loop logika sendiri yang mengeluarkan perintah ke makhluk, dan kondisi terminasi yang menentukan apakah tugas itu berhasil diselesaikan atau tidak.

interface UIElement
Saya menerapkan UI saya sendiri untuk mesin ini. Setiap UIElement memiliki loop render dan loop logika. Mereka juga memiliki loop untuk memproses input keyboard / mouse. Semua elemen dapat memiliki sejumlah elemen anak, yang diberikan setelah orang tua mereka, dan mengambil alih input keyboard / mouse. Ini memungkinkan Anda memiliki menu dengan submenu, misalnya.

Poin penting pertama yang harus dibuat adalah bahwa tidak ada jawaban 'baik' untuk pertanyaan ini.

Hal yang paling dekat dengan jawaban yang benar akan menjadi sesuatu seperti: Itu sangat tergantung pada jenis permainan, platform target, kendala (waktu) dll.

Yang mengatakan ada beberapa artikel yang sangat bagus di luar sana yang akan menunjukkan kepada Anda bagaimana orang lain telah mencoba untuk menjawab masalah ini (karena saya telah mencoba mencari info tentang ini di masa lalu).
Seperti bebek komunis menyebutkan Enginuity artikel tentang permainan dev membantu saya memahami beberapa bagian arsitektur permainan.

Desain saya saat ini adalah hibrida dari Quake3 / Doom3 dan sedikit perpustakaan kelas .NET :)

Saya memiliki dua perpustakaan (statis atau dinamis tergantung pada bagaimana Anda ingin membangun / mengirim) FrameworkdanLibrary .

Perpustakaan berisi semua kelas pembantu yang ada untuk membantu produksi perangkat lunak game tetapi tidak terbatas pada produk jenis ini. yaitu ia memiliki implementasi daftar tertaut yang dioptimalkan untuk kode game tetapi dapat digunakan oleh apa pun yang membutuhkan layanan dari daftar tertaut.

Kerangka kerja adalah nyali dari 'mesin' jika Anda ingin menyebutnya begitu. Banyak dari ini mengikuti filosofi desain Quake3 (hanya dengan cara yang lebih berorientasi objek). Ini berisi CLI , manajemen waktu, kode spesifik OS, dan akhirnya lapisan jaringan dll.

Keduanya kemudian dikaitkan dengan aplikasi aktual yang sedang diproduksi. ItuGame jika Anda suka, yang berisi kode permainan tertentu. Dengan cara yang hampir sama, Quake3 memuat DLL tergantung pada 'mod' yang dimainkan.

Untuk memberi Anda gambaran tentang struktur di sini adalah uraian singkat folder dan konten untuk setiap lib:

• Kerangka
  • IO (kelas manajemen file spesialis, kelas Pencetakan Teks (misalnya ke CLI), dan pencatatan dll)
  • Jaringan
    • Klien (kelas yang mewakili apa yang Kerangka anggap sebagai 'orang yang bermain / terhubung ke game')
    • Server (kelas untuk mengelola koneksi ke dalam kerangka kerja dan mengelola pemain)
  • Peron (Keyboard / mouse / pengontrol yang menangani kelas, rutinitas spesifik OS seperti getTime ())
  • Sistem (kelas tingkat sangat rendah seperti kelas kesalahan untuk membantu pencetakan pesan kesalahan, kelas waktu, dan CLI itu sendiri.)
  • Perender (cukup jelas)
  • dll.

• Perpustakaan
  
  • Koleksi (kelas yang mewakili koleksi data, daftar / hashtables yang ditautkan, dll.)
  • Matematika (kelas pembantu matematika dasar seperti Vektor dan matriks)
  • dll.

HTH! Harus memberi Anda beberapa petunjuk ...

Hal-hal yang perlu dipertimbangkan

• Bahasa berorientasi objek memiliki masalah karena mereka biasanya tidak memiliki fungsi kelas pertama atau tidak semua data adalah objek (seperti integer atau float di Java). Pola desain mengatasi masalah ini dengan beberapa pola. Ini umumnya lebih cepat untuk kode dan lebih mudah untuk tetap menggunakan bahasa yang dapat melakukannya (objek kelas satu); misalnya Python (yang juga memungkinkan desain berorientasi objek), Anda akan memiliki kecepatan yang lebih lambat.
• Event Calculus, untuk AI setidaknya
• Logika hoare, gunakan prasyarat dan kondisi akhir untuk setidaknya menguji kode Anda
• Agen, lihat entitas Gempa
• Database Relasional, cara ampuh untuk menyimpan data

Desain yang bagus

• membuat diagram ER
• buat itu benar
• buat database Anda, objek atau struktur data darinya

Data adalah kunci pemrograman. Jika Anda menginginkan data Anda bagus, algoritma biasanya muncul dari mereka (jika Anda tidak menghitung beberapa algoritma numerik, seperti penentu komputasi).