Memisahkan fisika dan logika game dari kode UI


12

Saya sedang mengerjakan game puzzle sederhana berbasis blok.

Bermain game terdiri dari cukup banyak blok bergerak di sekitar area permainan, jadi ini adalah simulasi fisika sepele. Implementasi saya, bagaimanapun, menurut saya jauh dari ideal dan saya bertanya-tanya apakah Anda bisa memberi saya petunjuk tentang bagaimana melakukannya dengan lebih baik.

Saya telah membagi kode menjadi dua area: Logika permainan dan UI, seperti yang saya lakukan dengan banyak permainan puzzle:

  • Logika permainan bertanggung jawab untuk aturan umum permainan (misalnya sistem aturan formal dalam catur)
  • UI menampilkan area permainan dan potongan-potongan (misalnya papan catur dan potongan-potongan) dan bertanggung jawab untuk animasi (misalnya gerakan animasi potongan-potongan catur)

Logika permainan mewakili kondisi permainan sebagai kisi-kisi logis, di mana setiap unit memiliki lebar / tinggi satu sel pada kisi. Jadi untuk kisi dengan lebar 6, Anda dapat memindahkan blok dengan lebar 2 empat kali sampai bertabrakan dengan batas.

UI mengambil kotak ini, dan menggambarnya dengan mengubah ukuran logis menjadi ukuran piksel (yaitu, mengalikannya dengan konstanta). Namun, karena gim ini hampir tidak memiliki logika gim, lapisan logika gim saya [1] tidak memiliki banyak hal selain deteksi tabrakan. Begini cara kerjanya:

  1. Pemain mulai menyeret sepotong
  2. UI meminta logika game untuk area pergerakan legal dari bagian itu dan membiarkan pemain menyeretnya di dalam area itu
  3. Pemain melepaskan sepotong
  4. UI mengambil potongan ke kisi (sehingga berada pada posisi logis yang valid)
  5. UI memberi tahu logika game posisi logis baru (melalui metode mutator, yang saya lebih suka hindari)

Saya tidak cukup senang dengan itu:

  • Saya menulis unit test untuk lapisan logika permainan saya, tetapi bukan UI, dan ternyata semua kode rumitnya ada di UI: Menghentikan potongan agar tidak bertabrakan dengan orang lain atau batas dan menjentikkannya ke grid.
  • Saya tidak suka fakta bahwa UI memberi tahu logika permainan tentang keadaan baru, saya lebih suka memanggil movePieceLeft()metode atau sesuatu seperti itu, seperti dalam permainan saya yang lain, tapi saya tidak jauh dengan pendekatan itu, karena logika permainan tidak tahu apa-apa tentang menyeret dan memotret yang mungkin dilakukan di UI.

Saya pikir hal terbaik untuk dilakukan adalah menyingkirkan lapisan logika permainan saya dan menerapkan lapisan fisika sebagai gantinya. Saya punya beberapa pertanyaan tentang itu:

  1. Apakah layer fisika seperti itu biasa, atau apakah lebih tipikal jika layer logika game melakukan ini?
  2. Apakah snapping to grid dan piece dragging code milik UI atau layer physics?
  3. Apakah lapisan fisika seperti itu biasanya bekerja dengan ukuran piksel atau dengan beberapa jenis unit logis, seperti lapisan logika permainan saya?
  4. Saya pernah melihat pendeteksian tabrakan berbasis peristiwa dalam basis kode game, yaitu, pemain hanya akan menyeretnya, UI akan menerjemahkannya dengan patuh dan memberi tahu sistem fisika, dan sistem fisika akan memanggil metode onCollision () pada potongan setelah tabrakan terdeteksi. Apa yang lebih umum? Pendekatan ini atau meminta area pergerakan hukum terlebih dahulu?

[1] layer mungkin bukan kata yang tepat untuk apa yang saya maksud, tetapi subsistem terdengar berlebihan dan kelas salah arah, karena setiap layer dapat terdiri dari beberapa kelas.


Apakah jawaban saya membantu, memerlukan informasi lebih lanjut?
Will Marcouiller

Tolong, pilih baik-baik saja dan terima jawabannya jika ini membantu atau memberi tahu tentang masalah Anda dalam mengimplementasikan arsitektur atau semacamnya, tetapi tetap beri tahu kami tentang situasi Anda sehingga kami dapat bantuan yang lebih baik. =)
Will Marcouiller

Jawaban:


3

Saya akan mencoba mencoba menjawab pertanyaan ini karena saya bisa mengerti apa yang Anda tanyakan, meskipun saya tidak punya banyak pengalaman pengembangan game karena saya masih hanya belajar.

Seperti yang saya lihat, Anda harus memisahkan kode GUI dari logika game dan objek domain Anda, yaitu potongan puzzle. Ini memang tiga lapisan terpisah - dan ya, layeradalah istilah yang tepat menurut saya. Hal ini sering digunakan untuk menjelaskan konsep-konsep memisahkan setiap tingkat objek dari suatu sistem menjadi subsistem yang independen satu sama lain.

Dalam hal pemrograman berorientasi objek, setiap objek harus kelas. Jadi, setiap potongan puzzle Anda harus terdiri dari satu kelas untuk masing-masing, dan juga papan permainan. Papan permainan harus berisi potongan X puzzle tergantung pada ukuran dan kapasitas gerakan yang ingin Anda berikan kepada pemain.

Jadi, inilah pemikiran saya tentang topik ini - Saya harap ini akan membantu:

  1. Lapisan GUI: Lapisan ini harus berisi metode hanya untuk menampilkan potongan-potongan di papan permainan untuk memungkinkan interaksi antara permainan itu sendiri dan pemain;
  2. Lapisan Game Controller: Bertanggung jawab atas input pemain. Itu adalah lapisan yang harus memberitahu sepotong untuk bergerak ke arah yang berbeda, dan tanyakan papan permainan apakah akan ada tabrakan saat bergerak dan sebagainya;
  3. Lapisan Bisnis: Lapisan ini akan berisi semua kelas bisnis Anda, yaitu, potongan-potongan gim Anda dan objek papan gim yang berisi potongan-potongan puzzle.

Dalam arsitektur ini, Anda akan meminta layer GUI menampilkan pemain dari kondisi permainan, lokasi setiap potongan puzzle. Lapisan GUI kemudian akan bertanggung jawab untuk mendapatkan input pemain dan meneruskannya ke lapisan Game Controller yang mendasarinya, yang kemudian akan bertanggung jawab untuk deteksi tabrakan. Jika tidak ada, maka bagian tersebut dapat dipesan untuk bergerak ke arah input itu. Untuk melakukannya, Anda cukup memanggil bagian ini MoveLeft,MoveRight, dll. metode untuk membuat potongan bergerak. Anda mungkin juga membiarkan papan permainan tahu bagian mana yang ingin Anda pindahkan, dan kemudian ia memesan sendiri gerakan itu, dan bagian itu kemudian bergerak ke arah yang diminta. Arsitektur ini membuatnya mudah untuk menguji setiap bagian kode ke dalam lapisan yang berbeda, dan kemudian memungkinkan Anda untuk pengujian unit, pengujian integrasi dan pengujian fungsional.

Saya tahu ini mungkin tampak sedikit membingungkan untuk dilihat, dan terima kasih Tuhan jika tidak! Jika Anda memerlukan perincian dan bantuan lebih lanjut, silakan bertanya, saya akan dengan senang hati membantu yang terbaik yang saya bisa meskipun saya pemula dalam pengembangan game.

Terima kasih sudah membaca! =)


2
Yang terdengar sangat mirip dengan Model View Controller.
Tenpn

Sejujurnya, setiap deskripsi antarmuka abstrak dari implementasi yang mendasarinya akan terdengar seperti Model View Controller. Tapi itu karena terminologi dan teknik yang digunakan adalah sama (memisahkan dari detail implementasi, dan memisahkan antarmuka pengguna dari implementasi). Tetapi mengasumsikan lingkungan yang sangat sederhana. Ada beberapa lapisan di sini, dan ada pengontrol di setiap lapisan. Memisahkan tampilan dari model tidak cukup di sini, Anda juga harus memisahkan kontrol interaksi pengguna dari kontrol game.
MrCranky

Saya bertanya-tanya apa yang begitu rumit di sini, karena kita memindahkan kepingan puzzle ke papan permainan yang dibatasi. Kontrol diperoleh dari GUI, yang faktanya adalah cara yang baik, dan pingsan ke lapisan abstraksi, yaitu, pengontrol game. Kontroler permainan memeriksa tabrakan saat bergerak, lalu memberi tahu bagian untuk bergerak jika tidak ada tabrakan yang terdeteksi. Potongan puzzle kemudian bergerak dengan baik ke arah yang diminta dan mengungkapkan posisi barunya melalui Positionfungsi pengambil properti, sehingga pengendali permainan sekarang meminta GUI untuk menampilkan bagian yang dipindahkan ini ke posisi yang baru.
Will Marcouiller

heh, saya ngeblog tentang "MVC" dalam pengembangan game beberapa bulan lalu. Ya, ini adalah konsep gateway yang bagus untuk mereka yang belum tahu tentang pengembangan game: codecube.net/2010/08/xna-for-the-everyday-developer
Joel Martinez

1
Maaf untuk menerima terlambat, sayangnya saya terganggu dari proyek untuk sementara waktu. Saya sangat suka pendekatan pengontrol, saya akan mengadopsinya!
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.