Perencanaan game dan desain perangkat lunak? Saya merasa bahwa UML tidak nyaman

Di universitas saya, mereka selalu menekankan dan gembar-gembor tentang desain dan hal-hal UML, di mana saya merasa itu tidak akan bekerja dengan baik dengan desain struktur game. Sekarang, saya hanya ingin saran profesional tentang bagaimana saya harus mulai merancang game saya? Ceritanya adalah saya memiliki beberapa keterampilan dalam pemrograman dan telah melakukan banyak permainan kecil seperti membuat beberapa platformer 2D bekerja sampai batas tertentu. Masalah yang saya temukan tentang program saya adalah kualitas desain yang buruk. Setelah pengkodean sebentar, hal-hal mulai memecah karena perencanaan yang buruk (Ketika saya menambahkan fitur baru, itu cenderung membuat saya harus mengkode ulang seluruh program). Namun, untuk merencanakan semuanya tanpa cacat desain tunggal agak terlalu ideal. Karena itu, ada saran untuk bagaimana saya harus merencanakan permainan saya? Bagaimana saya harus memasukkannya ke dalam gambar yang terlihat, sehingga saya dan teman-teman saya dapat melihat desainnya?

Saya berencana untuk mulai membuat kode permainan dengan teman saya. Ini akan menjadi kerja tim pertama saya, jadi saran profesional apa pun akan menyenangkan. Apakah ada alternatif lain selain UML?

Pertanyaan lain adalah bagaimana "prototyping" biasanya terlihat?

Saya hanya ingin saran profesional tentang bagaimana saya harus mulai merancang game saya?

Desain game adalah spesifikasi gameplay, aset, sistem penilaian, dll - ini tidak spesifik untuk perangkat lunak. Karena itu, UML adalah alat yang salah untuk tugas itu.

Ketika datang untuk merancang kode untuk mengimplementasikan sistem ini, UML adalah alat yang baik untuk tugas tersebut, memberikan tim Anda mengetahuinya, dan tetap berpegang pada jenis diagram yang lebih umum. Biasanya, ketika mencoba mendesain fitur, Anda akan tahu apakah Anda perlu menggunakan deskripsi atau diagram. Jika Anda perlu menggunakan diagram, UML memberi Anda cara menggambar standar, yang merupakan hal yang baik.

Setelah pengkodean sebentar, hal-hal mulai memecah karena perencanaan yang buruk (Ketika saya menambahkan fitur baru, itu cenderung membuat saya harus mengkode ulang seluruh program).

Itu umumnya masalah dengan cara Anda memprogram, daripada bagaimana Anda merencanakan. Perangkat lunak yang baik biasanya mudah diperluas dan digunakan kembali. Jika Anda tetap berpegang pada praktik pemrograman yang baik, masalah ini akan berkurang. Tetapi perencanaan yang lebih baik juga akan membantu, dan Anda tidak perlu diagram yang rumit untuk ini. Hanya memiliki daftar fitur berarti bahwa ketika Anda membuat kode satu hal, Anda memiliki fitur lain dalam pikiran dan dapat menganggapnya sebagai kode Anda.

Karena itu, ada saran untuk bagaimana saya harus merencanakan permainan saya? Bagaimana saya harus memasukkannya ke dalam gambar yang terlihat, sehingga saya dan teman-teman saya dapat melihat desainnya?

Sepertinya Anda mencampur 2 masalah di sini, desain game, dan desain kode.

Saya sarankan pertama-tama menulis desain game dasar, menentukan fitur yang Anda butuhkan, grafik dan suara yang Anda butuhkan, bagaimana game dimenangkan dan hilang, dll. Cari 'dokumen desain' jika Anda memerlukan bantuan di sana.

Dari sana, Anda akan memiliki gagasan tentang fitur-fitur yang perlu Anda kode. Anda dapat melihat setiap fitur secara bergantian dan mencoba memikirkan cara menerapkannya. Diagram dapat membantu menunjukkan hubungan antara berbagai kelas dan objek dalam gim Anda, tetapi keterampilan mengetahui objek mana yang perlu ada adalah sesuatu yang harus Anda pelajari melalui latihan dan / atau bacaan lebih lanjut.

Juga, coba kerjakan proyek yang lebih kecil, kurang ambisius. Itu akan membuat Anda terbiasa menulis kode kerja yang baik, tanpa perlu perencanaan atau penulisan ulang yang luas.

Tidak memahami sesuatu membuatnya mudah untuk diberhentikan. UML adalah alat teknik yang digunakan untuk mengkomunikasikan ide-ide yang Anda miliki secara terstruktur. Game adalah sistem yang dapat direkayasa seperti yang lainnya. Jika ada, kompleksitas dan dinamika permainan membuat representasi visual dari bagian-bagian itu dan interaksinya sangat berharga.

Diagram UML adalah pandangan yang berbeda dari model sistem yang sedang dibahas. Saya mulai dengan menggunakan kasing untuk seseorang yang duduk di depan program saya dan memulainya. Dalam kasus permainan ada dua jenis pengguna: desainer dan pemain. Saya menulis use case untuk masing-masing hal yang saya bisa lihat sedang mereka kerjakan. Lalu saya membuat beberapa kartu CRC untuk mencari tahu layanan apa yang perlu saya sediakan. Lalu saya membuat diagram kelas untuk antarmuka yang akan menyediakan layanan ini dan hubungan mereka. Ini didasarkan pada kartu CRC. Berikutnya adalah diagram dinamis untuk acara-acara seperti inisialisasi yang membutuhkan perencanaan dan orkestrasi. Kemudian diagram statis yang lebih rinci menunjukkan kelas yang mengimplementasikan antarmuka.

Semua sementara saya menulis kode dan membuat prototipe dan mengembangkannya ke arah menyediakan layanan untuk mendukung memenuhi persyaratan permainan saya. Tidak ada yang dibangun yang tidak mendukung pengguna melalui kasus penggunaan. Saya menulis beberapa elemen diagram yang tidak berguna, tetapi antara pengkodean antarmuka dan diagram, saya menulis sangat sedikit kode yang tidak berguna. Diagram memberi saya kepercayaan diri bahwa saya memahami cara kelas yang saya tulis cocok dengan keseluruhan sistem.

Poin yang saya coba sampaikan adalah bahwa program sepele dapat ditulis tanpa rencana, tetapi permainan sama sekali tidak sepele. Beberapa waktu yang lalu, ketika OOP masih baru, ada banyak eksperimen dan beberapa praktik terbaik muncul. Komunitas pengembangan perangkat lunak sepakat bahwa kami membutuhkan bahasa untuk menulis dan menganalisis desain perangkat lunak. UML adalah bahasa yang kami kembangkan. Kita semua tahu dan memahaminya, jadi jika Anda ingin menggunakan solusi orang lain untuk masalah Anda (buku, diskusi online, artikel, katalog pola, dll.) Dan tidak menemukan kembali roda Anda harus belajar membaca notasi standar. Sebagai bonus, ketika Anda memaksakan diri untuk memikirkan sistem Anda dalam bahasa lain, Anda mempelajari hal-hal yang tidak terduga.

Ada banyak metodologi berbeda, tetapi mereka semua mengidentifikasi masalah dan menggambarkan satu solusi secara sistematis. Ini rekayasa. UML sangat besar dan kompleks, tetapi tidak ada model yang menggunakan setiap konstruk. Itu seperti pisau tentara Swiss. Anda harus mengetahuinya dan mencari cara menggunakannya untuk mendukung proses rekayasa Anda. Yang penting bukanlah proses atau metodologi mana tetapi Anda memilikinya. Kalau tidak, Anda akan tenggelam dalam kompleksitas.

Saya juga mengerjakan beberapa proyek game independen dengan seorang teman (tim 2-orang). Sebagai seseorang yang berada dalam situasi yang serupa dengan Anda, saya dapat menawarkan beberapa informasi menarik yang menurut saya bermanfaat.

1. Jika ide Anda kasar, coba implementasikan satu per satu dalam proyek prototipe super kecil. Sebagai contoh, saya membuat game platform 2D sekarang, dan mendapatkan lompatan pemain yang tepat sangat penting bagi saya. Jadi, saya membuat proyek baru di mana hanya 2 hal yang terjadi adalah a) Menggambar pemain di layar, dan b) Mendeteksi input, dan menggambar ulang lompatan [karakter bahkan tidak bisa bergerak ke kiri atau ke kanan]
2. Beberapa orang mungkin tidak menyukai saran ini, tetapi pikirkan tentang menulis manual game terlebih dahulu (untuk menjelaskan konsep, kontrol, tujuan). Ini dapat melakukan 2 hal untuk Anda - menghasilkan dokumen yang sangat dibutuhkan, tetapi juga menguraikan subsistem permainan Anda dan detail yang diperlukan untuk pemain. Jika Anda tahu sebelumnya apa yang perlu diketahui pemain, maka Anda tahu sebelumnya apa yang perlu Anda lakukan.
3. Tulis kode dalam ukuran yang cukup kecil (alias termodulasi) potongan yang ) sehingga potongan-potongan yang diperhitungkan dapat dipindahkan, atau disusun dengan lebih baik tanpa merasa seolah-olah Anda sedang berusaha mengeluarkan semua spaghetti ukuran sedang dari sepiring pasta.

Semoga Anda menemukan setidaknya satu informasi bermanfaat di sana, dan semoga berhasil!

Saya pikir ada beberapa takeaways berharga dari UML yang tidak dapat Anda tolak. di sisi lain, perlu diingat bahwa UML dibangun untuk proses bisnis , Anda tahu, sistem pemodelan yang memiliki banyak orang berinteraksi dengannya, semua dengan berbagai keinginan, kebutuhan, dan keinginan. UML mencoba memastikan Anda tidak meninggalkan apa pun atau kewalahan oleh detail.

UML adalah "cara standar untuk memvisualisasikan arsitektur sistem"

UML menjelaskan

• kegiatan
• aktor
• proses bisnis
• skema basis data
• komponen (logis)
• pernyataan bahasa pemrograman
• komponen perangkat lunak yang dapat digunakan kembali

Tetapi jika Anda membuat game sederhana, apakah Anda benar-benar perlu memodelkan semua ini?

• Aktor: Pemain.

Berapa banyak yang bisa membantu?

Memodelkan beberapa hal lain, sangat membantu. Misalnya jika Anda membuat MMO kecil, Anda pasti ingin skema basis data yang dirancang dengan baik.

Jadi, sementara kesimpulan dari UML sangat bagus (tahu apa yang Anda lakukan, tulis persyaratan, dan sketsa diagram alur di mana pun dibutuhkan), dan elemen-elemennya sangat berguna, saya cenderung merasakan proses UML lengkap adalah sedikit lubang putaran pasak persegi untuk game.

UML bukan satu hal itu adalah kumpulan hal-hal yang beberapa di antaranya memiliki nilai yang lain tidak begitu banyak. gaya lama Use Cases (setidaknya apa yang kita sebut use case) menyatakan

• nama
• Persyaratan
• prasyarat
• pemicu
• tindakan
• tindakan alternatif
• pengecualian

bisa sangat berguna. meskipun apa yang Anda temukan untuk "Gunakan Kasus" jika Anda melakukan pencarian web (gambar) lebih untuk perangkat lunak umum.

Saya juga akan memberikan kredit ke diagram Kelas. ini menunjukkan bahwa Anda dapat menunjukkan hubungan antara semua objek Anda, dan Anda tahu tata letak arsitektur Anda.

apa yang turun adalah bahwa set fitur Anda harus semuanya direncanakan, dan terkunci int (disewa dalam pengaturan kebutuhan / keinginan) sebelum pemodelan, dan pembuatan diagram bahkan dimulai. semua ini harus ada dalam Brief / Treatment / Script Anda (kadang-kadang disebut sebagai pitch, dokumen fitur, dan cerita). kemudian dari sana Anda akan melakukan hal-hal dokumen teknologi Anda yang memiliki model, dan diagram.

ada perusahaan yang menggunakan UML, tetapi ini biasanya perusahaan yang memiliki tim desain dan implementasi yang terpisah. perusahaan yang akan membuat semua dokumentasi mereka, dan kemudian memberikannya kepada tim kode-monyet untuk membuat prototipe / alpha. itu mengatakan bahwa jika Anda dapat memodelkan game Anda secara akurat, Anda harus dapat memberikannya kepada tim yang sama sekali berbeda dan meminta mereka memprogramnya meskipun ini lebih merupakan mimpi pipa daripada akurasi.

Mereka akan mengajarkan Anda tentang UML di universitas Anda untuk membantu Anda mengkomunikasikan ide-ide Anda ke seluruh tim Anda, dan menunjukkan kepada para dosen bahwa Anda memiliki pengetahuan yang baik tentang prinsip-prinsip rekayasa perangkat lunak dasar.

Seperti diskusi apa pun tentang bahasa, alat, atau desain - biasanya tergantung pada bagaimana Anda menggunakannya. Pilih alat / bahasa / desain terbaik untuk pekerjaan itu dan buat cadangan pilihan Anda dengan alasan kuat. Saya akui UML tidak begitu fleksibel untuk produksi game, meskipun saya dapat mengatakan bahwa kami telah menggunakannya secara efektif untuk memodelkan fitur engine seperti komunikasi jaringan dan pengaturan waktu, manajemen tugas paralel, dan kasus penggunaan. Tidak ada yang lebih buruk daripada menjelaskan hal yang sama kepada 5 anggota tim yang berbeda 10 kali berbeda karena mereka tidak mengerti. Ini dokumentasinya, bacalah.

Bergantung pada seberapa solid desain Anda, dan seberapa disiplin tim Anda, bisa sangat produktif untuk dapat memodelkan konstruksi Anda sendiri di sekitar konstruksi yang belum dimulai, dan tahu persis bagaimana mereka akan beroperasi karena dokumentasi.

Meskipun demikian, Anda mungkin akan mendengar (dan menyadari dengan keras) bahwa ini adalah DOKUMEN HIDUP, dan kecuali jika ditinjau dan diperbarui secara berkala, mereka akan menjadi usang dengan cepat dan secara efektif tidak berguna.