Apakah Anda benar-benar menggunakan diagram untuk memodelkan game? [Tutup]


17

Maksud saya sebagian besar UML tetapi metode apa pun yang berfungsi layak. Jadi - apakah Anda benar-benar memodelkan game Anda dengan UML / diagram lain atau metode yang berbeda? Saya memiliki subjek di universitas saya tentang pemodelan dengan UML dan sepertinya lebih banyak upaya daripada manfaat yang sebenarnya, tetapi saya menyadari itu mungkin hanya karena saya tidak pernah membuat sistem TI yang sangat rumit. Jadi apakah itu sepadan dengan waktu dan jenis diagram / metode apa yang biasanya * terbaik?

* Tentu saja, berkali-kali alat konkret perlu dipilih untuk masalah konkret tetapi mungkin ada beberapa pola.

Sunting: Saya lupa satu hal penting - apakah Anda membuat diagram sebelum atau setelah menerapkan hal-hal? Yang saya maksud adalah - ketika seseorang mendesain dan mengimplementasikan sesuatu yang biasanya berubah pikiran atau sesuatu yang tidak terduga muncul dan seseorang harus membuat perubahan, terkadang yang besar - dan melakukannya dalam diagram yang sudah rumit tampaknya sama-sama tidak ada harapan seperti dalam kode itu sendiri.


5
Ini lebih merupakan pertanyaan terkait pemrograman pada umumnya, jadi lihatlah pertanyaan ini: programmers.stackexchange.com/questions/152997/…
congusbongus

3
Terima kasih untuk tautannya tetapi sebenarnya saya sengaja mengajukan pertanyaan ini di sini - Saya ingin melihat apakah gamedev serupa dalam aspek ini dengan bidang TI lainnya.
NPS

Jawaban:


21

Saya suka berpikir bahwa segala sesuatu di sekitar kita dapat diwakili, dengan satu atau lain cara, melalui diagram. Bahkan jika itu hanya diagram linier yang mewakili transisi antara keadaan suatu objek tertentu sepanjang waktu (seperti makhluk hidup, melalui sejumlah keadaan dari lahir hingga mati). Saya menggunakan diagram untuk meletakkan pemikiran dan ide saya untuk implementasi yang sebenarnya. Saya banyak berimprovisasi.

Oleh karena itu, diagram saya sebagian besar waktu pada tingkat yang sangat tinggi, dan terasa seperti peta pikiran .

Untuk memasukkan beberapa contoh, ini sebenarnya adalah peta warisan kelas (yang telah dipotong) dalam permainan saya di mana Objek Interaktif adalah tipe dasar.

Objek Interaktif adalah tipe dasar

Ini adalah FSM ( mesin Finite-state ) diagram untuk perangkap paku (orang-orang perangkap mengagumkan di mana Anda melangkah dan Woosh paku muncul dari tanah).

Diagram FSM untuk perangkap spike sederhana

Ini adalah diagram buku pegangan (dinamai demikian karena ini dimaksudkan untuk menjadi diagram kembali sering ) yang saya gambar baru-baru ini. Ini menguraikan komponen permainan, dan juga membantu mengumpulkan aset yang diperlukan, karena Anda dapat segera melihat apa yang dibutuhkan dan apa yang tidak. Saya merekomendasikan ini pada proyek kecil, karena mereka menjadi sangat besar pada yang besar. Mereka dapat diperluas lebih lanjut, sehingga dapat memperbaiki keadaan.

Gambaran umum game

Ketika saya pergi ke tingkat yang lebih rendah, biasanya karena saya perlu merencanakan aspek paling rumit dari arsitektur saya, dan saya biasanya berurusan dengan UML di sana. Saya tidak pernah berkonsentrasi untuk menghasilkan UML yang benar-benar bersih dan benar. Saya telah mengadopsi apa yang paling saya sukai tentang konvensi UML, dan mengubahnya menjadi UML mindmap-ish yang bagus. Ini sederhana dan melakukan pekerjaan untuk saya, tetapi saya tidak akan menggunakannya di lingkungan di mana UML yang sebenarnya diharapkan, karena alasan yang jelas.

Situasi lain ketika saya harus pergi ke level yang lebih rendah adalah ketika saya harus menggambarkan algoritma yang sebenarnya. Saya menggunakan apa yang saya sebut diagram alir . Ini adalah format yang terinspirasi oleh diagram yang digunakan dalam pengujian kotak putih .

Contoh untuk spike trap yang saya gambar sekarang akan terlihat seperti ini: Diagram alur spike trap lebih detail

Ini biasanya merupakan lapisan terakhir antara diagram dan implementasi algoritma aktual. Jika diperlukan, saya merinci diagram alir lebih lanjut (dengan instruksi yang dieksekusi ekstra), dan menyimpulkan atau memperkirakan kompleksitas, dan membuat kasus uji yang akurat. Saya juga lebih suka diagram daripada pseudocode.

Tidak terkait dengan pengembangan game, saya juga memiliki format yang bagus untuk menggambarkan layar dalam aplikasi multi-layar, fungsionalitas yang dapat dipicu pengguna di setiap layar, dan hubungan antara layar. Saya biasanya membangun ini sebelum memulai pengembangan aktual, dan mereka bertindak seperti peta selama proses pengembangan. Jika itu untuk klien, diagram layar bahkan lebih berguna! Ini membantu saya menjalani semua proyek, dari awal hingga awal, dan mempertimbangkan semua fungsi yang dibutuhkan. Karena itu, sangat berharga untuk memberikan perkiraan biaya dan waktu yang akurat.

Jadi ya, saya jelaskan diagram segalanya dan apa saja. Jika saya punya ide, saya bisa dan pasti akan menggambar diagram untuk itu. Jika saya entah bagaimana memulai proyek tanpa setidaknya diagram yang sangat luas untuk mendukung saya, saya merasa lumpuh.


4
Pada sidenote, apakah Anda menggunakan YEd untuk diagram? Saya merasa sangat berguna.
Kromster mengatakan mendukung Monica

4
Persis! Senang melihat pengguna yEd lain. Saya sudah sering menggunakannya dalam beberapa tahun terakhir, ini adalah favorit saya saat ini.

2
+1 untuk yed. Satu-satunya downside adalah, UML tidak intuitif sama sekali. Tetapi untuk setiap diagram lainnya sangat luar biasa untuk aplikasi gratis.
Sidar

2
Saya menggunakan YEd untuk merancang pohon perilaku saya untuk kompetisi AI AiGameDev.
Nick Caplinger

15

Tentu saja saya lakukan - baik struktural dan perilaku - aturan praktis saya adalah bahwa saya membuat diagram ketika biaya membuat diagram kurang dari mencoba mengingat apa yang saya pikirkan sebulan kemudian - atau ketika saya perlu menjelaskan dengan jelas diri saya kepada beberapa pengembang lain

Diagram kelas ketika hierarki warisan menjadi cukup kompleks

Diagram objek ketika hal-hal seperti instantiasi objek menjadi sesuatu yang berbatasan dengan penciptaan monster Frankenstein dari bagian yang berbeda - terutama berguna dalam kitchen sink vertex dan pengguna pixel shader, untuk memastikan semua bit yang diperlukan didorong melalui pipa

Sequence diagram ketika interaksi terperinci antara satu set objek menjadi kompleks - ini sangat berguna dalam memodelkan aliran render kompleks di mana informasi yang dikomputasi sebelumnya diperlukan di lokasi hilir yang hampir tidak terkait


Saya lupa satu hal penting - apakah Anda membuat diagram sebelum atau setelah menerapkan hal-hal? Yang saya maksud adalah - ketika seseorang mendesain dan mengimplementasikan sesuatu yang biasanya berubah pikiran atau sesuatu yang tidak terduga muncul dan seseorang harus membuat perubahan, terkadang yang besar - dan melakukannya dalam diagram yang sudah rumit tampaknya sama-sama tidak ada harapan seperti dalam kode itu sendiri.
NPS

6
ah ha - tergantung - cara mana saja yang berhasil untuk masalah yang dihadapi - kadang-kadang lebih mudah untuk mengutak-atik kode dan kemudian diagramnya, kadang-kadang lebih mudah untuk membuat diagram dan membangunnya - saya tidak memiliki aturan yang keras dan cepat untuk itu satu
Mark Mullin

@ Mark: bit itu harus menjadi bagian dari jawaban;)
Kromster mengatakan mendukung Monica

8

Diagram adalah cara yang bagus untuk berkomunikasi, mendokumentasikan dan membantu desain Anda , dan desain adalah bagian terpenting dari pengembangan perangkat lunak. UML memiliki banyak fitur tetapi Anda tidak dimaksudkan untuk menggunakannya semuanya pada saat yang sama, hanya yang bermanfaat.

Saat bernavigasi di kota baru, apakah Anda benar-benar berhenti dan melihat peta, bukan hanya melanjutkan dan mengikuti rambu? Itulah yang dimaksud dengan desain vs coding. Ketika hal-hal yang tidak dikenal, ketika masalahnya kompleks, ketika Anda merasa bingung, saat itulah memikirkan desain paling membantu, dan lebih baik melakukannya lebih awal daripada nanti. Jauh lebih mudah untuk mengubah desain Anda sebelum menerapkan apa pun .

Diagram adalah cara yang bagus untuk memvisualisasikan masalah dan membantu desain Anda, terutama untuk pemikir visual (yang sebagian besar dari kita di gamedev saya bayangkan). Banyak masalah menjadi sepele, cacat menjadi jelas, ketika itu jelas dipetakan pada diagram. Beberapa masalah yang mungkin Anda temukan dalam diagram:

  • Terlalu banyak koneksi ke satu komponen? Anda mungkin memiliki benda dewa yang sulit dipertahankan
  • Terlalu banyak interkoneksi? Mungkin modularitas dapat ditingkatkan, untuk membuat arsitektur kurang rapuh
  • Terlalu banyak jalur antara dua komponen? Mungkin Anda memiliki kopling ketat
  • Untuk aplikasi berkinerja tinggi seperti game, apakah ada terlalu banyak komponen yang terlibat dalam jalur panas atau loop dalam? Ini dapat memengaruhi kinerja Anda
  • Namun sebagian besar waktu, diagram akan menunjukkan ketidakkonsistenan antara desain yang Anda bayangkan, dan implementasi yang sebenarnya

Selain itu, diagram sangat bagus untuk mengomunikasikan dan mendokumentasikan desain Anda, baik kepada orang-orang non-teknis atau orang-orang yang baru dalam proyek Anda - dan ingat, dalam waktu 6 bulan Anda juga praktis baru dalam proyek ini!

Cara Anda menggunakan UML harus didorong dari pertimbangan ini. Membuat diagram untuk kepentingan Anda sendiri? Gunakan notasi apa pun yang paling nyaman bagi Anda. Berkolaborasi dengan pengembang lain? Cobalah untuk memasukkan rincian panggilan API, jenis pesan, arah dependensi. Membahas arsitektur? Kotak hitam dan koneksi sederhana akan cukup. Lagipula tidak ada yang menggunakan set lengkap fitur UML , plus itu sangat berguna sebagai set notasi standar yang dipahami banyak orang - sedangkan orat-oret serbet saya mungkin tidak dapat dipahami oleh Anda dan sebaliknya.

Adapun saya sendiri, saya menggunakan diagram setiap saat - gambar notepad sederhana untuk proyek pribadi, diagram UML sederhana di tempat kerja. Diagram UML ini adalah apa yang saya anggap terlalu kompleks, dan yang tidak pernah saya buat karena biaya produksi dan pemeliharaannya melebihi manfaatnya, tetapi tentu saja YMMV.


Satu pertanyaan besar untuk Anda - IIUC, Anda mencoba untuk tetap menggunakan diagram sederhana (selalu). Tetapi diagram biasanya diperlukan ketika aplikasi menjadi rumit. Bagaimana Anda membuat diagram kecil dan sederhana ketika memodelkan sistem yang luas dan kompleks?
NPS

@NPS Itu tergantung pada tujuan / target audiens, dan dalam pengalaman saya Anda masih dapat menggunakan diagram sederhana untuk memodelkan sistem yang kompleks. Biasanya yang Anda miliki adalah banyak diagram sederhana yang berbeda untuk orang yang berbeda, atau menunjukkan aspek yang berbeda dari sistem - itulah sebabnya mengapa ada berbagai jenis diagram dalam UML. Sistem kompleks biasanya kompleks dalam arti bahwa mereka memiliki banyak aspek atau lapisan, yang semuanya sederhana dalam isolasi. Sistem yang benar-benar rumit sangat jarang, karena cenderung sangat sulit dipahami oleh para ahli terbaik.
congusbongus

8

Saya akan mengatakan ada dua jenis diagram. Diagram dan coretan formal.

Mengenai diagram formal, saya melakukannya ketika saya bekerja dengan programmer lain, tetapi saya jarang melakukannya ketika saya pemrograman sendiri.

Namun, itu tidak berarti saya duduk dan kode apa pun yang terlintas dalam pikiran. Menurut pendapat saya, hal terpenting ketika pemrograman (atau sebenarnya apa pun dalam hidup) adalah berpikir dulu dan lakukan nanti .

Pengkodean adalah tugas yang sangat mekanis. Anda mengetik dan kata-kata muncul di layar. Idenya adalah bahwa pada saat Anda memulai pengkodean, Anda seharusnya sudah menyelesaikan masalah yang ada. Membuat coretan adalah cara yang bagus untuk menyortir pemikiran Anda, dan bahkan memaksa diri Anda untuk berpikir bahwa Anda perlu melakukan bagian pengkodean dengan benar. Coretan tidak dimaksudkan untuk disimpan untuk referensi di masa mendatang, hanya agar Anda dapat memahami proses pemikiran Anda dengan mudah.

Jangan khawatir jika Anda terlalu banyak berpikir. Saya pikir keseimbangan yang baik terjadi ketika Anda mendedikasikan 90% dari waktu Anda berpikir dan 10% coding. Saya telah bertemu beberapa programmer "senior" yang hidup dengan "kita tidak punya waktu untuk berpikir, hanya melakukan". Tetapi bahkan jika mereka menyebut kode mereka "selesai" lebih awal daripada mereka yang meluangkan waktu untuk berpikir tentang apa yang mereka lakukan, mereka (atau jiwa-jiwa sial yang tertinggal sesudahnya) kemudian menghabiskan waktu berjam-jam memperbaiki dan menambal sesuatu yang seharusnya dibangun dengan benar dari awal.

Yang terbaik adalah berpikir itu gratis! Anda tidak harus duduk di komputer untuk berpikir. Anda dapat memikirkan kode tersebut saat makan, bepergian, berolahraga ... Sebenarnya, ide-ide terbaik datang ketika Anda tidak mengharapkannya, jadi jagalah pikiran Anda selalu terbuka, dan mulailah coding ketika Anda benar-benar tahu apa yang Anda akan kode.

Inilah artikel terkait yang kebetulan saya setujui.

Sunting : Mengenai format dan jenis diagram yang sebenarnya, saya sarankan Anda menggunakan freestyle, dan benar-benar tulisan tangan alih-alih menggunakan alat yang dipaket sebelumnya. Ingatlah bahwa intinya adalah untuk membantu Anda dalam proses berpikir Anda, jadi silakan menggambar apa pun yang Anda suka. Semantik adalah apa pun yang Anda inginkan, dan mereka mungkin berbeda di antara diagram, dan bahkan di antara berbagai bagian diagram.

Ada tiga manfaat utama dengan diagram gaya bebas / tulisan tangan di atas alat yang dikemas:

  1. Anda tidak dipaksa untuk mengikuti jenis diagram yang didukung oleh alat apa pun yang Anda pilih. Terkadang mapminds akan berfungsi, terkadang sesuatu yang lebih seperti UML akan baik-baik saja, sementara di lain waktu diagram logika akan berfungsi. Di lain waktu, diagram yang benar-benar khusus adalah yang berfungsi, dan tidak ada alat yang dapat memberi Anda semua fleksibilitas diagram gaya bebas (cobalah meninju lubang melalui kertas dan melanjutkan di sisi belakang kertas, dalam paket favorit Anda, dan lihat apa yang terjadi)

  2. Anda akan menghabiskan lebih banyak waktu untuk membuat diagram daripada menggunakan alat ini. Apa pun alatnya, pena dan kertas selalu lebih cepat dalam pembuatan diagram daripada keyboard dan mouse melalui menu untuk menemukan elemen spesifik yang Anda cari.

  3. Anda tidak perlu komputer untuk menulis tulisan tangan. Sebagian besar waktu saya melakukan desain yang kompleks, saya melakukannya di perpustakaan, kafe, atau bahkan di dalam pesawat terbang. Juga, ide-ide bagus selalu muncul pada saat yang paling tidak tepat, jadi pastikan untuk selalu membawa sesuatu untuk ditulis, dan sesuatu untuk ditulis.


3
dan "coretan" itu mungkin hanya ada dalam pikiran Anda, atau tidak mengikuti konvensi diagram formal apa pun. Dan jangan takut untuk menyesuaikan desain saat Anda mengikuti dan mendapatkan wawasan baru. Tentu saja jika Anda bekerja untuk orang lain dan mereka semata-mata bertanggung jawab untuk desain Anda tidak dapat melakukan itu (meskipun Anda mungkin dapat membuat saran dan permintaan), tetapi jika Anda sendiri lanjutkan dan bereksperimen. Saya sering duduk dan mulai melakukan hal-hal, menemukan desain berevolusi dari apa yang saya lakukan sampai saya punya cukup ide untuk memformalkannya dalam diagram atau dokumen.
jwenting

0

Mungkin layak untuk menunjukkan beberapa pembicaraan diagram desain dari Game Developers Conference 2013. Ini adalah beberapa contoh yang sangat praktis dan telah teruji di jalan - dan tampaknya mereka telah dipresentasikan di banyak konferensi sepanjang tahun.

(Jawaban lain telah melakukan pekerjaan yang mengagumkan untuk menunjukkan mengapa dan bagaimana diagram yang berfokus pada desain dapat sangat membantu dalam perencanaan, pembangunan, pertumbuhan, dan pemeliharaan basis kode, jadi saya akan meninggalkan aspek itu sendirian, dan percaya sumber daya ini mungkin berguna kepada siapa pun yang mengunjungi pertanyaan.)

Joris Dormans dan Ernest Adams membahas desain game Machination / sistem diagram keseimbangan. (Ini paywalled GDC Vault dari GDC EU 2012; sampel dari GDC 2013 di wiki Dormans.) Daripada mencoba untuk parafrase, inilah cara wiki menjelaskan sistem:

Machination adalah kerangka teori dan representasi interaktif, dinamis, grafis yang menggambarkan game sebagai sistem dinamis dan berfokus pada loop umpan balik tertutup di dalamnya. Tujuannya adalah untuk menemukan cara untuk mengekspresikan dan menyelidiki struktur game yang berulang (secara berulang). Machination menawarkan lensa baru pada praktik desain dan keseimbangan permainan yang intuitif dan halus.

Noah Falstein memberikan ceramah yang disebut "The Arcane Art of Puzzle Dependency Diagram" (video GDC Vault paywalled ). Saya tidak dapat menemukan tautan yang tidak berbayar di sini, tetapi berbagai orang telah mendiskusikan atau memposting catatan mereka secara online.

Kedua pembicaraan membahas ketika mereka membuat dan bagaimana mereka mempertahankan diagram ini, sampai taraf tertentu.


0

Anda mungkin harus memeriksa artikel ini tentang menggunakan tata bahasa abstrak sederhana untuk menggambarkan lingkaran permainan Anda, bagaimana hal itu dapat membantu Anda mengidentifikasi masalah desain, dan betapa mudahnya untuk beralih di tingkat itu.

http://www.gamasutra.com/blogs/JoshuaStarner/20130205/186060/Applying_Abstract_Models_to_Game_Design.php

Saya juga bisa mengarahkan Anda ke pekerjaan saya sendiri pada subjek, lebih didasarkan pada ekonomi dari loop gameplay, menggunakan sumber daya abstrak untuk melacak hal-hal seperti peluang, keberuntungan atau persiapan:

http://www.stephanebura.com/diagrams/

Jika Anda menganggap pendekatan ini bermanfaat, Anda harus melihat pada Machination Joris Dormans ', alat untuk membuat diagram seperti itu dan menjalankan simulasi mereka:

http://www.jorisdormans.nl/machinations/

Seluruh prosesnya dijelaskan dalam bukunya:

http://www.amazon.com/Game-Mechanics-Advanced-Design-Voices/dp/0321820274/

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.