Apa yang harus dimuat dalam grafik adegan game?

10

Maukah Anda membantu saya untuk menjelaskan, apa sebenarnya yang seharusnya terkandung dalam grafik adegan game? Lihat daftar berikut, silakan:

  • Aktor Game? (jelas ya, semua objek yang berubah status harus menjadi bagian utama dari Grafik Pemandangan)
  • Ojbects permainan statis sederhana?(Maksud saya menempatkan tempat di latar belakang yang tidak mendapatkan animasi, mereka juga tidak bertabrakan)
  • Pemicu Game ?
  • Lampu Game ?
  • Kamera Game ?
  • Peluru Senjata ?
  • Ledakan Game dan Efek Khusus?

Jenis objek yang dipertimbangkan di atas. Sekarang untuk cakupan grafik adegan:

  • Haruskah grafik adegan berisi seluruh peta level permainan sejak level dimulai, atau haruskah itu hanya berisi bagian peta yang terlihat? Jika yang kedua benar, itu artinya grafik adegan akan terus diperbarui, dengan menambahkan / menghapus objek permainan, saat pemain bergerak. Namun, hanya berisi peta yang terlihat jelas akan lebih cepat untuk dilalui dan diperbarui.
Bunkai.Satori
sumber
@Josh: terima kasih telah mengedit dan memperbaiki Pertanyaan saya.
Bunkai.Satori

Jawaban:

4

Saya pikir sedikit membaca tentang apa yang dilakukan teknologi grafik adegan lain akan menghasilkan banyak manfaat bagi Anda.

Latar Belakang
Sebagai contoh, lihat deskripsi Ogre3D. Ini adalah mesin grafik berbasis adegan adegan yang open source. Saya akan menyarankan melihat tutorial dan melihat bagaimana node adegan sedang digunakan (Catatan: Saya tidak memberitahu Anda untuk belajar cara menggunakan Ogre, melainkan fitur apa yang ada dalam node adegan dan manajer adegan Ogre)

Dokumentasi SceneNode:
http://www.ogre3d.org/docs/api/1.9/class_ogre_1_1_scene_node.html

Dokumentasi SceneManager: http://www.ogre3d.org/docs/api/1.9/class_ogre_1_1_scene_manager.html

Hal lain yang patut dilihat adalah tautan berikut:
http://sgl.sourceforge.net/#features

Ini adalah solusi grafik adegan berbasis OpenGL dan halaman fitur di sana menunjukkan semua node yang dapat dikandungnya.

Node yang Disarankan
Saya berpendapat bahwa grafik adegan harus diabstraksi sejauh mungkin dari logika permainan sehingga Anda tidak memiliki masalah ketergantungan. Untuk setiap poin Anda, saya akan mengatakan yang berikut:

Aktor Game
Saya mungkin akan mengatakan tidak. Mirip dengan Ogre, saya akan memiliki kelas Entity dasar (yang akan berisi logika objek spesifik) dan SceneNode dasar dengan pointer anggota Entity untuk mendapatkan informasi yang sesuai untuk merender objek (Posisi, Orientasi, dll)

EDIT: Saya tidak mengatakan untuk tidak memasukkan aktor permainan Anda dalam grafik adegan di sini (jika tidak, tidak akan muncul: P) Saya mengatakan untuk memiliki node adegan dengan referensi ke kelas aktor permainan logis, jadi Anda sudah masih mendapatkan kopling longgar dari rendering dan pembaruan objek game.

Gim statis sederhana ojbects
Ya

Pemicu Game?
Tidak, ini kedengarannya seperti logika khusus game bagi saya.

Lampu Game?
Iya

Kamera Game?
Iya

Peluru Senjata?
Tidak sepenuhnya yakin tentang yang ini, tapi saya mungkin akan mengatakan ya, tetapi Anda mungkin ingin semua peluru sebagai anak-anak ke simpul adegan orangtua "BulletCollection", hanya agar Anda dapat men-cache posisi itu dan Anda tidak perlu melintasi grafik adegan banyak untuk menghapus dan menambahkan peluru ke render.

Ledakan Game dan Efek Khusus?
Tidak yakin, saya akan membiarkan orang lain menjawabnya.

Cakupan Grafik Adegan
Jika Anda memiliki level yang relatif kecil, Anda harus dapat menyimpan seluruh level dalam grafik adegan dan kemudian mengoptimalkan visibilitas menggunakan Oktree (biasanya untuk lingkungan luar) atau pohon BSP (biasanya untuk lingkungan dalam ruangan).

Jika Anda memiliki level yang jauh lebih besar dan Anda tidak ingin melakukan pemuatan level apa pun, di sinilah streaming akan ikut bermain, tapi itu masalah lain sepenuhnya. Saya akan mulai dengan level kecil dan secara bertahap melihat seberapa besar Anda dapat membuatnya tanpa mempengaruhi kinerja.

Kesimpulan
Bagi saya grafik adegan adalah untuk bagian Render dari loop game. Anda tidak boleh memasangkan rendering Anda dan pembaruan logika Anda terlalu dekat, jika tidak, Anda akan mengalami masalah ketergantungan yang mengganggu.

Ray Dey
sumber
+1 - Terima kasih atas jawaban terperinci dan berharga. Pengetahuan saya tentang SceneGraphs berasal dari buku Game Coding Lengkap ( amazon.com/Game-Coding-Complete-Third-McShaffry/dp/1584506806/… ). Tautan Anda sangat membantu, terutama kelas SceneNode dari Ogre. Mengacu pada Kesimpulan Anda , apakah Anda melihat Grafik Adegan sebagai cara terbaik untuk memperbarui Transformasi objek yang terhubung dalam game? Baik, jawaban Anda dan Josh sangat baik. Saya pikir, yang ini memiliki lebih banyak informasi di dalamnya, jadi saya menandai yang ini sebagai Jawaban yang Diterima .
Bunkai.Satori
@Bunkai Jika Anda berpikir objek permainan Anda memiliki metode Pembaruan () di mana mereka memperbarui vektor mereka untuk posisi, orientasi, dll, maka semua adegan adegan Anda harus lakukan adalah membuat mesh dan mengubahnya menggunakan GetPosition () dan GetOrientation () dan render ke layar. Ini benar-benar memisahkan logika aktor Anda dari kode rendering mereka yang benar-benar harus Anda perjuangkan.
Ray Dey
9

Kecenderungan saya adalah menyarankan untuk meletakkan lebih sedikit barang dalam grafik adegan. Lihat khususnya artikel ini oleh Tom Forsyth: " Grafik Adegan - Just Say No. "

Inti dari artikel Forsyth adalah bahwa Anda seharusnya tidak mencoba menjejalkan banyak hal yang tidak terkait ke dalam satu struktur data master besar. Ini sangat mirip dengan ide-ide yang saya sentuh dalam jawaban ini sehubungan dengan mendapatkan segala sesuatu di dalam game dari GameObjectdan kemudian mendorong semuanya dalam satu daftar heterogen besar (artinya, itu buruk).

Relatif sedikit objek di dunia yang benar-benar memperlihatkan hubungan orangtua-anak yang kuat sebagaimana layaknya struktur pohon. Contoh kanonik dari cangkir kopi di atas meja biasanya digunakan di sini - tentu saja, Anda dapat menganggapnya sebagai 'anak' dari meja ... setidaknya sampai ia terlempar. Lalu apakah itu benar-benar masih anak dari tabel? Ini berarti 'pohon' Anda bisa berakhir cukup dangkal dan agak merosot ke daftar.

Jadi saya sarankan Anda menggunakan beberapa struktur data untuk banyak hal, karena paling masuk akal untuk hal-hal itu. Geometri dan lampu statis, misalnya, tampak seperti hal yang masuk akal untuk dimasukkan ke dalam grafik adegan. Bahkan jika objek yang diwakili tidak memiliki hubungan orangtua-anak alami, fakta bahwa mereka statis berarti Anda dapat memberi mereka hubungan struktural orangtua-anak mengetahui bahwa mereka tidak pernah berubah.

Aktor gim ... Saya tidak begitu yakin tentang itu. Apa pun yang cenderung bergerak, pada kenyataannya, berarti Anda biasanya perlu menyimpannya di dekat akar grafik atau menggantinya secara terus-menerus (yang merupakan tugas dan tidak super efisien).

Peluru, pemicu, efek khusus dan objek sementara lainnya yang akan saya simpan di tempat lain. Tidak ada yang merender atau memiliki representasi visual (pemicu biasanya volume pembatas tak terlihat, peluru biasanya hanya ray-cast) harus dalam grafik render. Anda harus berusaha keras untuk memisahkan lapisan render dan logika .

Untuk apa nilainya, saya tidak pernah menggunakan grafik adegan seperti pohon di salah satu penyaji yang saya buat untuk penggunaan non-akademik (jelas saya telah membuat grafik adegan seperti pohon sebelumnya, yang merupakan cara saya sampai pada kesimpulan bahwa saya sekarang saya mencoba membuat Anda setuju).

Saya menggunakan metode partisi spasial yang sesuai dengan gaya permainan (quad-tree, octree, BSP, dan lain-lain) untuk mengelompokkan / menyisihkan entitas logis dalam game yang harus (a) memproses frame ini dan (b) ditampilkan bingkai ini. Saya kemudian akhirnya memberi makan set objek dari daftar (b) ke dalam sistem yang memetakan objek logis untuk membuat deskripsi dan mengurutkan deskripsi tersebut ke dalam ember berdasarkan properti (misalnya, apa pun yang menggunakan transparansi akan dimasukkan ke dalam ember untuk "barang" yang harus dirender kembali ke depan). Lalu saya membuat setiap ember secara berurutan, dan untuk setiap ember memberikan setiap uraian secara berurutan. Saya kira Anda dapat menyebut ini "pohon," tetapi ini tidak menunjukkan keadaan umum / mengubah metode propagasi yang dilakukan oleh grafik adegan berorientasi pohon tradisional. YYMV,

Komunitas
sumber
+1 untuk jawaban yang sangat bagus. Saya telah membaca artikel yang direkomendasikan. Pada dasarnya, saya ingin menggunakan Grafik Pemandangan untuk memperbarui posisi benda terkait (misalnya: satu set tentara di atas kapal. Saat kapal bergerak, tentara bergerak dengannya, dan senjata di tangan mereka juga bergerak). Oleh karena itu, saya berencana untuk memiliki kelas antarmuka: CGameObject, dan semua objek yang akan dimasukkan ke dalam Grafik Pemandangan seharusnya menjadi bagiannya. Terima kasih banyak atas saran Anda.
Bunkai.Satori