Apa saja pola desain pemrograman yang berguna dalam pengembangan game? [Tutup]

129

Saya memiliki beberapa buku tentang Pola Desain, dan telah membaca beberapa artikel, tetapi tidak dapat secara intuitif mengetahui pola desain pemrograman mana yang akan berguna dalam pengembangan game.

Sebagai contoh, saya memiliki buku berjudul ActionScript 3 dengan Pola Desain yang merinci beberapa pola desain seperti Pengendali Tampilan Model, Singleton, Pabrik, Perintah, dll.

Sebagai seseorang yang baru dalam hal ini, saya tidak dapat menemukan yang mana di antara ini akan berguna, atau bahkan jika salah satu dari ini adalah pola desain yang harus saya pelajari dan coba gunakan. Mungkin ada pola desain lain yang lebih khusus untuk pemrograman-pemrograman-game yang tidak saya sadari?

Jika Anda memiliki pengalaman menggunakan pola desain tertentu dalam pengembangan game, saya ingin mendengarnya. Alasan mengapa itu digunakan, contoh kode, atau sumber daya online semua akan sangat membantu juga jika Anda memilikinya. Saya saat ini paling tertarik dengan implementasi ActionScript 3 dan C ++, tetapi pasti dapat mengambil manfaat dari pengalaman dan contoh-contoh dari bahasa apa pun.

Terima kasih!

— jcurrie33
sumber

"Mungkin ada pola desain lain yang lebih khusus untuk pemrograman-pemrograman-game yang bahkan tidak kusadari?" - tidak, pola-pola ini bersifat umum, dan berlaku lebih banyak untuk memperluas kemampuan bahasa yang Anda gunakan. Mereka tidak ada hubungannya dengan masalah aplikasi Anda.

— Kylotan

3

@Kylotan Tampaknya dari sudut pandang saya yang terbatas bahwa karena setiap pola desain dimaksudkan untuk mengatasi masalah tertentu secara efektif, pada dasarnya beberapa pola desain akan lebih berguna daripada yang lain diberikan serangkaian masalah tertentu, yaitu dalam hal ini, masalah-masalah itu unik untuk pengembangan game. Tentunya ada beberapa pedoman, atau berdasarkan pengalaman Anda, pola desain tertentu yang lebih sering Anda gunakan daripada yang lain?

— jcurrie33

Sebelum ada yang pergi dan mempelajari 1000 pola desain yang berbeda, baca ini dan ini

— BlueRaja - Danny Pflughoeft

@ BlueRaja-DannyPflughoeft Tautan secon tidak valid. Bisakah Anda kirim ulang

— Emadpres

163

Sekarang untuk tanggapan yang kurang sopan, dengan beberapa saran. Jangan menganggap ini sebagai rekomendasi implementasi, lebih sebagai contoh kemungkinan penggunaan.

Builder: mengatur entitas berbasis komponen satu komponen pada satu waktu, berdasarkan data
Metode Pabrik: membuat NPC atau widget GUI berdasarkan string yang dibaca dari file
Prototipe: menyimpan satu karakter 'Elf' generik dengan properti awal dan membuat instance Elf dengan mengkloningnya.
Singleton: ruang ini sengaja dikosongkan.
Adaptor: memasukkan pustaka pihak ke-3 opsional dengan membungkusnya dalam lapisan yang terlihat seperti kode Anda yang ada. Sangat berguna dengan DLL.
Komposit: membuat grafik adegan dari objek yang dapat diulang, atau membuat GUI dari pohon Widget
Fasad: menyederhanakan perpustakaan pihak ke-3 yang kompleks dengan menyediakan antarmuka yang lebih sederhana untuk membuat hidup Anda lebih mudah nanti.
Kelas Terbang: menyimpan aspek bersama dari NPC (mis. Model, tekstur, animasi) secara terpisah dari aspek individu (mis. Posisi, kesehatan) dengan cara yang sebagian besar transparan
Proxy: Buat kelas kecil pada klien yang mewakili kelas yang lebih besar, lebih kompleks di server, dan meneruskan permintaan melalui jaringan.
Rantai tanggung jawab: menangani input sebagai rantai penangan, misalnya. tombol global (mis. untuk tangkapan layar), lalu GUI (mis. jika kotak teks terfokus atau menu di atas), maka permainan (mis. untuk memindahkan karakter)
Command: merangkum fungsionalitas game sebagai perintah yang dapat diketik ke dalam konsol, disimpan dan diputar ulang, atau bahkan dituliskan untuk membantu menguji game
Mediator: mengimplementasikan entitas game sebagai kelas mediator kecil yang beroperasi pada komponen yang berbeda (mis. Membaca dari komponen kesehatan untuk meneruskan data ke komponen AI)
Pengamat: minta representasi karakter yang dapat diajak mendengarkan peristiwa dari representasi logis, untuk mengubah presentasi visual bila perlu tanpa logika permainan yang perlu tahu apa pun tentang merender kode
Status: simpan NPC AI sebagai salah satu dari beberapa status, mis. Menyerang, Berkeliaran, Kabur. Masing-masing dapat memiliki metode pemutakhiran () sendiri dan data apa pun lainnya yang dibutuhkan (mis. Menyimpan karakter yang diserang atau melarikan diri dari, area tempat ia berkeliaran, dll.)
Strategi: beralih di antara heuristik yang berbeda untuk pencarian A * Anda, tergantung pada bidang apa Anda, atau mungkin bahkan menggunakan kerangka kerja A * yang sama untuk melakukan penelusuran jalan dan perencanaan yang lebih umum
Metode template: mengatur rutin 'pertempuran' umum, dengan berbagai fungsi kait untuk menangani setiap langkah, misalnya. amunisi pengurangan, hitung peluang hit, selesaikan hit atau miss, hitung kerusakan, dan setiap jenis skill serangan akan menerapkan metode dengan cara spesifik mereka sendiri

Beberapa pola ditinggalkan karena kurangnya inspirasi.

— Kylotan
sumber

Diskusi yang sangat mencerahkan tentang lajang dapat ditemukan di sini: misko.hevery.com/2008/08/25/root-cause-of-singletons

— Andrew Wang

+1 untuk pola Strategi. Saya telah menggunakannya untuk tujuan tepat yang disebutkan di atas (menghubungkan berbagai heuristik A *).

— Mike Strobel

1

terima kasih untuk jawaban ini, itu terdengar lebih seperti pola desain daripada "singleton" yang biasa saya dengar di mana-mana ...

— jokoon

Daftar contoh yang bagus. Terlepas dari penyalahgunaan kronis pola tunggal (negara global yang menyamar), ada kegunaan yang sah: Ketika itu mewakili sumber daya yang sebenarnya hanya Anda miliki (atau inginkan). Ini bisa berupa pembungkus perangkat keras (mis. Keyboard / mouse) atau pembungkus pustaka yang tidak reentrant (itu terjadi, dan tidak semua bahasa memiliki kata kunci sinkronisasi ajaib).

— charstar

11

Saya masih tidak akan menggunakan lajang untuk sumber daya perangkat keras - barang-barang yang menurut Anda hanya akan pernah Anda miliki cenderung untuk berlipat ganda nanti, sama seperti yang dilakukan kartu video dan monitor seperti tahun-tahun berikutnya. Demikian pula, di bawah beberapa API Anda perlu membaca 2 joystick untuk memahami 1 gamepad. Jadi saya katakan, jika Anda hanya membutuhkan satu saja, instantiate saja, jangan memaksakan pembatasan sewenang-wenang yang mungkin tidak diperlukan.

— Kylotan

59

Saya menulis buku tentang topik itu: Pola Pemrograman Game . Bab-bab yang ada di sana mungkin bermanfaat bagi Anda.

— murah hati
sumber

2

+1 Saya berharap ada orang yang menautkannya dan saya melihat penulis memilikinya! Deskripsi pola komponen di sana sangat membantu, dan saya suka Anda mencoba menggunakan contoh kode lengkap untuk menunjukkan.

— CodexArcanum

2

Ya - saya ingat pernah membaca tautan Anda beberapa tahun yang lalu. Anda harus menyelesaikan artikel-artikel itu!

— onedayitwillmake

2

Sekarang buku sudah selesai :)

— dusan

1

Sumber luar biasa yang membantu saya menerjemahkan pengetahuan pemrograman saya yang ada ke pemrograman untuk game. Terima kasih telah menulisnya!

Penjelasan tentang pola pemrograman game ini benar-benar membantu saya memahami - pola desain - sehingga tidak ada buku pola desain perangkat lunak yang melakukannya! Ini sebagian adalah kekuatan pengembangan game (contoh nyata dalam bahasa yang berbicara kepada saya dan memungkinkan saya untuk meningkatkan pengembangan saya secara keseluruhan), tetapi sebagian besar karena tulisannya sangat bagus.

— Kzqai

19

Satu hal yang Brandon Eich punya akal sehat untuk dibesarkan dalam Coders at Work adalah bahwa pola adalah peretasan dan penyelesaian masalah: [Pola] menunjukkan semacam cacat dalam bahasa. Pola-pola ini tidak gratis. Tidak ada makan siang gratis. Jadi kita harus mencari evolusi dalam bahasa yang menambahkan bit yang tepat.

Sebagai programmer game daripada desainer kompiler, kami jarang mendapatkan opsi untuk mengembangkan bahasa yang kami gunakan, tetapi kami dapat belajar untuk mengembangkan gaya kami sendiri agar lebih sesuai dengan bahasa dan persyaratan kami. Pola adalah beberapa di antaranya, tetapi tidak menggunakan pola adalah bagian lain, terutama karena seperti yang dikatakan Brandon, pola jarang berjalan tanpa kinerja yang menonjol atau memori atau biaya kelincahan kode. MVC bukan pola yang bagus untuk banyak hal dalam game. Singleton adalah solusi untuk aturan inisialisasi statis C ++ lumpuh, dan Anda mungkin tidak boleh melakukan itu pula. Factory menyederhanakan pembuatan objek yang rumit - mungkin objek Anda seharusnya lebih sederhana untuk memulai. Pola yang populer adalah alat untuk digunakan ketika kita membutuhkannya untuk mengelola sesuatu yang kompleks, bukan alat yang harus kita rindukan untuk membangun sesuatu yang rumit pada awalnya.

Kode (permainan) yang bagus mungkin menggunakan pola, atau mungkin juga tidak. Jika memang menggunakan pola, baik - mereka adalah alat komunikasi yang bagus untuk menjelaskan struktur kode ke programmer lain di tingkat tinggi, bahasa-independen. Jika Anda berpikir kode lebih baik tanpa menggunakan pola, jangan menyalahkan diri Anda sendiri - mungkin itu.

— pengguna744
sumber

4

Ya, salah satu hal yang dijelaskan dalam buku asli (tetapi sering diabaikan) adalah bahwa jika ditulis untuk C daripada C ++ / Smalltalk, mereka mungkin telah memasukkan pola "Warisan", dan dengan cara yang sama, beberapa bahasa mungkin mengandung beberapa pola GoF yang sudah ada.

— Kylotan

13

Hal lain yang sering diabaikan dalam buku asli (buku asli asli oleh Alexander, bukan GoF) adalah bahwa pola adalah alat untuk komunikasi , bukan implementasi . Mereka membiarkan desainer berkomunikasi tentang implementasi pada tingkat yang lebih tinggi, dan diidentifikasi karena mereka berulang, tidak harus karena mereka harus digunakan jika memungkinkan.

1

Namun, hanya dengan memiliki terminologi dapat membantu Anda bernalar tentang masalah dan mengenali kapan pendekatan semacam itu merupakan solusi yang baik. Pola-pola terbaik biasanya disempurnakan dari waktu ke waktu oleh pekerja terampil dan berpengalaman, dan pekerja yang kurang terampil tidak akan menemukan pola yang sama sendiri tanpa ada contoh-contoh terkodifikasi ini.

— Kylotan

Saya setuju bahwa memiliki terminologi itu bagus, dan bagian dari definisi suatu pola adalah bahwa itu adalah solusi berulang yang baik untuk beberapa masalah. Sayangnya pekerja yang kurang terampil cenderung menemukan sebagian besar Singleton, dan menerapkannya pada setiap masalah, bahkan ketika belum ada masalah.

Terima kasih atas tanggapan ini; Saya merasa lega membaca bahwa pola desain dibuat untuk menyelesaikan masalah yang diciptakan oleh desain perangkat lunak. Saya berpikir bahwa struktur dari seluruh perangkat lunak besar harus dipikirkan sejak awal hingga akhir sebelum benar-benar mulai mengkodekan apa pun. Anda tidak dapat selalu mengimplementasikan fungsionalitas satu per satu, kadang-kadang Anda harus memikirkan setiap fitur tertentu, dan memeriksa apakah itu tidak akan mengacaukan struktur global perangkat lunak atau hanya menghalangi cara perangkat lunak itu dianggap untuk bertingkah. Membagi tugas ke beberapa programmer terkadang dapat menciptakan kontradiksi ...

— jokoon

7

Tentu saja, seperti yang dikatakan orang lain, semua pola berguna dalam keadaan yang tepat, dan bagian dari belajar bagaimana menggunakannya adalah belajar kapan menggunakannya. Namun, buku yang luar biasa Inti Teknik dan Algoritma dalam Pemrograman Game oleh Daniel Sanchez-Crespo Dalmau, daftar enam pola pemrograman dan enam pola kegunaan yang sangat berguna dalam pemrograman game.

Pemrograman:

Singleton: Saya tidak membenci yang ini seperti kebanyakan orang; dapat digunakan untuk hal-hal seperti pemutar pemain tunggal atau pembaca keyboard.
Pabrik: Memungkinkan Anda membuat dan menghancurkan objek secara efisien.
Strategi: Memungkinkan Anda mengubah strategi AI dengan elegan.
Indeks Spasial: Membantu melakukan kueri pada set data spasial.
Komposit: Menyiapkan benda pusaka yang berguna.
Kelas Terbang: Membebaskan ingatan dengan menggeneralisasikan hal-hal seperti musuh yang identik.

Kegunaan:

Shield: Melindungi dari aktivasi aksi dramatis yang tidak disengaja.
Status: Isyarat visual tentang status dunia / UI.
Pembatalan Mode Otomatis: Membuat game berfungsi lebih baik.
Magnetisme: Pemilihan otomatis dan unit mudah.
Fokus: Menghilangkan elemen UI yang mengganggu.
Kemajuan: Bermanfaat secara universal.

Buku itu, tentu saja, menjelaskan lebih rinci tentang masing-masing dari ini.

— Gregory Avery-Weir
sumber

Terima kasih atas masukannya! Saya tidak mengetahui buku itu, tetapi akan memeriksanya sekarang sebagai hasil dari posting Anda. Terima kasih lagi!

— jcurrie33

2

Singleton untuk pembaca keyboard adalah persis situasi di mana saya harus bertanya - Dapatkah Anda benar-benar tidak hanya menjadikannya penunjuk global yang ditetapkan di awal fungsi utama Anda? Pernahkah Anda benar-benar secara tidak sengaja membuat dua pembaca papan ketik?

Tolong jangan membenci singleton. Itu melakukan dua hal dengan buruk. Akses dan arity global. Seringkali pengembang berpikir akses global == singleton. Ada beberapa masalah yang sangat dibutuhkan daripada seorang singleton sejati, dan mungkin beberapa masalah yang lebih elegan ketika diselesaikan dengan singleton.

— deft_code

7

Sistem entitas adalah jenis pola yang bagus. Ini bukan pola desain karena itu bukan OOP. Namun Anda dapat mencampurnya dengan OOP.

Beberapa tautan bagus (mulai dari atas untuk intro):

— Wernight
sumber

3

"Ini bukan pola desain karena itu tidak kaku [sic] OOP." Pola desain tidak ada hubungannya dengan OOP; jika ada, OOP itu sendiri adalah pola desain. Pola desain muncul tidak hanya di luar OOP, tetapi di luar pengembangan perangkat lunak sepenuhnya.

Ada OOP design patternsyang biasanya menunjukkan hubungan dan interaksi antara kelas / objek. Dan ada banyak pola desain lainnya. OOP adalah seperangkat konsep, bukan pola yang sesungguhnya. Design patternadalah sebuah konsep juga.

— topright

6

Alih-alih berbicara tentang semantik, bukankah seharusnya Anda menilai kegunaan dari respons yang saya berikan?

— Wernight

6

Mereka semua. Kecuali Singleton. [/kesembronoan]

— Kylotan
sumber

Bisakah Anda menyebutkan satu atau dua pola desain yang sering Anda gunakan dalam pengembangan game, dan untuk alasan apa? Sebagai pemula sehubungan dengan pola desain, "semuanya" bukanlah respons yang sangat membantu. Terima kasih sudah merespons.

— jcurrie33

5

Bertanya, "Pola apa yang Anda gunakan?" seperti bertanya "nama variabel apa yang telah Anda gunakan?" Itu datang ke gaya pribadi dan persyaratan dan domain. Pada titik tertentu, Anda mungkin akan menggunakan pola apa pun yang pernah dinamai. Anda mungkin akan menggunakan lebih banyak lagi yang belum disebutkan namanya, dan mungkin bahkan menciptakan beberapa yang baru.

@ jcurrie33: maaf, saya tidak bisa menahan diri untuk tidak menggali lebih dulu di lajang. ;)

— Kylotan

6

Tidak benar-benar tentang pola, tetapi tentang prinsip-prinsip dasar di belakangnya. Dalam "Pola Desain: Elemen Reusable Object-Oriented Software" (1995) , geng empat (Gamma, Erich; Richard Helm, Ralph Johnson, dan John Vlissides) merekomendasikan hanya dua prinsip untuk desain berorientasi objek: (1) program untuk antarmuka dan bukan untuk implementasi dan (2) mendukung komposisi objek daripada warisan kelas.

2 prinsip ini sangat membantu dalam banyak tugas pengembangan game. Sebagai contoh, banyak programmer game telah menggunakan hierarki kelas yang dalam untuk mewakili entitas game. Ada pendekatan lain berdasarkan komposisi - objek permainan berbasis komponen. Artikel tentang pendekatan ini. Lebih banyak tautan . Ini adalah contoh pola dekorator .

— topright
sumber

Komponen seperti yang digunakan dalam desain game lebih seperti pola strategi stateful - yang secara alami dinyatakan sebagai penutupan di luar C / C ++ / Java / C #, dan sebagai objek komponen di dalamnya. Pola dekorator lebih seperti proxy; kepemilikan dan aliran datanya berlawanan dengan yang biasanya kita maksud ketika kita berbicara tentang sistem komponen dalam game.

Komponen juga perlu berbicara satu sama lain, membawa pola seperti Mediator, Observer, dan Composer. "Komponen-Berbasis Game" adalah pola desain komposit dengan sendirinya.

— CodexArcanum

@ CodexArcanum, Pengamat, secara pasti, tetapi tidak selalu Mediator (Rantai Tanggung Jawab dapat digunakan sebagai gantinya). Ini adalah Komposer hanya jika GameObject (terdiri dari GameObjectComponent) adalah GameObjectComponent itu sendiri (tidak perlu).

— topright

6

The Pola Template anehnya berulang dapat benar-benar berguna untuk menghindari metode virtual dan hukuman kinerja yang dapat berasal dari panggilan fungsi virtual.

Ini bisa menjadi pola yang tepat ketika Anda tidak benar-benar perlu memiliki wadah tipe kelas dasar yang memiliki antarmuka yang Anda cari, tetapi Anda ingin memiliki perilaku dan antarmuka yang sama bernama.

Sebagai contoh, Anda dapat menggunakan ini ketika mengkompilasi kelas untuk beberapa platform atau mesin (dx vs opengl) di mana varian jenis diketahui pada waktu kompilasi.

— Rick
sumber

Saya selalu benci bahwa lapisan abstraksi adalah virtual. Ini tidak seperti Anda akan membutuhkan dua lapisan ab osilasi. Jauh lebih baik menggunakan CRTP.

— deft_code

Mungkin saya hanya tua, tetapi saya bahkan tidak akan menggunakan CRTP untuk DX / OpenGL atau antarmuka platform. Terlalu lambat untuk dikompilasi - Saya hanya menggunakan typedefs. CRTP bagus ketika Anda ingin berbagi antarmuka dan implementasi antar kelas tetapi tidak memiliki hubungan lain, tidak ketika Anda hanya ingin memilih satu struct atau yang lainnya.

4

Sebuah pola desain yang saya kembangkan selama bertahun-tahun, dan yang telah sangat berguna bagi saya, adalah sesuatu yang saya sebut sebagai "set definisi yang ditengahi"; bagaimana meringkasnya dalam istilah GOF tampaknya kontroversial, tetapi pertanyaan ini saya tulis tentang hal itu di StackOverflow masuk ke beberapa detail tentang hal itu.

Konsep inti adalah bahwa beberapa properti model, seperti spesies makhluk, diatur sehingga setiap nilai yang mungkin untuk properti memiliki objek definisi yang sesuai - satu objek bersama per nilai - yang menentukan perilakunya, dan ini diakses melalui broker pusat (yang, GOF-bijaksana, mungkin merupakan Registry, Pabrik, atau keduanya). Dalam penggunaan saya, mereka juga umumnya diakses melalui kunci skalar, untuk memfasilitasi pengikatan yang lemah untuk keperluan morfisme runtime.

— chaos
sumber

Saya tidak melihat bagaimana ini adalah singleton sama sekali dan ketika membahas pola kelas terbang kata "registri" berlebihan. Ini hanya kelas terbang.

Pemahaman saya dari utas SO adalah bahwa orang mengidentifikasi Singleton sebagai bagian darinya karena definisi yang ditetapkan sebagai kelas. Sejauh Registry berjalan, saya tidak melihat bagaimana itu bisa berlebihan ketika dapat diganti atau dikombinasikan dengan Factory.

— kekacauan

-1, sejauh pola tentang komunikasi cepat, ini mungkin kegagalan terbesar yang pernah saya lihat. Saya benar-benar tidak bisa menganggap serius uraian ini.

Astaga, maafkan aku karena tidak cukup membuat kue untukmu. Apakah Anda akan memilih jawaban "Sistem Entitas" juga karena itu tidak langsung dirangkum dalam istilah GOF?

— kekacauan

1

Sejumlah "pemotong kue", atau setidaknya kejelasan semantik, adalah pola apa yang harus bermanfaat. Istilah-istilah seperti "kelas terbang" dan "singleton" seperti yang umumnya dipahami saling eksklusif. Yang pertama adalah tentang berbagi data secara otomatis antara beberapa instance; yang kedua adalah tentang memiliki persis satu contoh. Saya tidak mengatakan pilihan desain Anda tidak berguna atau bahkan buruk, tetapi menjejalkan nama pola "cukup dekat" hanya akan membingungkan semua orang. (Tolong jangan mengambil downvotes secara pribadi, terutama pada CW.)