Perlu perencanaan sebelum memasukkan kode?

Saya selalu berpikir bahwa perencanaan itu penting untuk sebuah permainan. Tetapi saya tidak tahu pada titik mana. Beberapa mengatakan kepada saya untuk kode daripada perencanaan tetapi saya merasa itu masih penting karena ketika Anda akan berada dalam kode Anda akan tahu apa yang harus dilakukan selanjutnya dengan lebih mudah. Saat ini saya sedang mengerjakan sebuah game yang akan memiliki banyak konten sehingga saya memutuskan untuk memulai dokumen desain yang memperkenalkan konten mereka dan pada level sisi saya sedang melakukan pembuktian konsep untuk memeriksa apakah itu dapat dilakukan. Bagian-bagian dari masing-masing bukti konsep kemudian dapat digunakan nanti dalam permainan nyata.

EDIT: Saya bekerja sendiri di proyek ini.

Jadi pertanyaan saya adalah: Perlu perencanaan sebelum memasukkan kode? Saya masih tertarik untuk mengetahui apa yang orang lain katakan tentang ini. Karena saya masih mendapatkan beberapa poeple mengatakan saya harus kode alih-alih berpikir .. jadi apa pendapat Anda tentang ini?

Anda mengatakan dua hal cerdas dalam pertanyaan Anda:

1. "kode alih-alih berpikir" - ada filosofi lengkap yang menjelaskan hal ini: http://gettingreal.37signals.com/toc.php
2. "bukti konsep untuk memeriksa apakah itu bisa dilakukan" - Saya telah melihat dan memiliki banyak ide yang ternyata tidak mungkin atau sangat sulit dibuat ketika hampir selesai. Terkadang Anda tidak dapat memprediksinya, karena lingkungan pemrograman Anda (bahasa, perpustakaan, kinerja perangkat keras) membatasi Anda.

Itu sebabnya saya katakan:

• desain, tetapi jangan membuat dokumen desain besar jika Anda tidak mencari kolaborator atau investor, kecuali itu menyenangkan bagi Anda dan Anda menganggapnya sebagai istirahat dari pemrograman;
• selalu ingat apa yang ingin Anda capai; setiap modul harus memiliki input dan output yang dirancang; dengan begitu Anda dapat dengan mudah menguji modul, dan tidak memiliki perasaan berkeliaran dalam kabut;
• ingat bahwa Anda mendesain sebagian besar waktu, karena mengetik kode hanya membutuhkan sekitar 5% dari waktu Anda (setidaknya mengetik kode akhir);
• pemrograman bukanlah ilmu teoretis, alih-alih memeriksa apakah sesuatu akan bekerja pada selembar kertas, Anda bisa menuliskannya dan mencobanya; produk akhir sebagian besar tentang membuat input pengguna sangat mudah, GUI terlihat bagus dan berurusan dengan kasus-kasus khusus - tes kotor dari sebuah ide dapat dilakukan secara langsung;
• buat daftar agenda jika Anda takut lupa ide-ide Anda
• bicarakan dengan teman-teman Anda tentang ide-ide Anda, karena mereka akan kurang antusias dan mungkin memiliki lebih banyak pengalaman di bidang; pernah saya memiliki ide untuk menjaga parameter unit (dalam permainan strategis) rahasia, tetapi teman saya mengatakan itu adalah ide yang buruk, karena dia memainkan game seperti ini dan itu adalah pengalaman pengguna yang mengerikan.

Ya, tapi hanya sedikit .

Untuk pemrograman game, terutama pemrograman gameplay, sangat penting untuk memiliki kasus penggunaan yang baik sebelum menulis kode apa pun. Misalnya apa yang seharusnya dilakukan pemain, ke mana ia harus pergi dan bagaimana, bagaimana ia berinteraksi dengan dunia, dll. Ini bisa berupa papan cerita yang dibuat sketsa di atas kertas, atau keluar dari diskusi dengan rekan ... Ini adalah bagian dari desain game , dan akan bodoh untuk memulai pengkodean tanpa gagasan kasar tentang bagaimana game itu seharusnya dimainkan.

Tapi game harus dibuat berulang-ulang . Anda tidak dapat membuat spek besar untuk gim Anda dan berharap ini akan menyenangkan untuk dimainkan. Anda perlu uji coba secara teratur untuk mencari tahu apa yang berhasil, dan apa yang tidak, dan terus mengulanginya. Semakin cepat eksekusi yang dapat dieksekusi, desain game tercepat dapat diuji, yang terbaik didapatkan pada akhirnya. Jadi selalu lebih baik untuk mulai mengkode ASAP, dari desain game yang sangat non-formal, lihat apa yang keluar, dan teruskan.

Satu hal yang pasti, saat Anda melakukan pengkodean sendiri, Anda tidak memerlukan dokumen atau metodologi desain perangkat lunak mewah, kode sumbernya adalah desain.

Ada yang bilang Anda harus kode bukannya berpikir? Nah untuk kode Anda perlu tahu apa yang ingin Anda buat, untuk mengetahui apa yang ingin Anda buat, pertama-tama Anda perlu memikirkan apa yang ingin Anda miliki, ergo yang perlu Anda pikirkan sebelum Anda membuat kode;).

Dan serius, Anda mungkin tidak memerlukan rencana terperinci di awal, tetapi memiliki garis besar dan / atau tonggak selalu bermanfaat - juga untuk sikap Anda, ketika Anda mencoret hal-hal yang sudah selesai, Anda akan lebih didorong untuk melakukan lebih banyak kerja.

Baik coding dan perencanaan diperlukan. Paket pertama, lalu kode, tetapi jangan merencanakan semuanya sekaligus. Rencanakan inti, kodekan, perbarui paket Anda sesuai kebutuhan, lalu rencanakan fitur yang menambah pemutaran, grafik, suara, sprite, dll. Ini akan membuat permainan yang Anda buat terlihat lebih baik dan secara keseluruhan merasa lebih baik. Anda dapat menjalankan siklus seperti itu lebih dari sekali, jelas, dan saya menyarankan Anda membuat keputusan yang akan mendukung peningkatan jika diperlukan.

Anda harus tahu ke mana Anda akan pergi sebelum menulis kode dan menulis / menggambar bisa menjadi cara yang baik untuk mewujudkan apa yang ingin Anda capai. Saya katakan menggambar karena menggambar diagram, sketsa, dll. Mungkin juga banyak membantu Anda. Anda tidak perlu membuat dokumen yang luar biasa yang dibuat dengan Word atau apa pun, cukup ambil pensil dan selembar kertas (banyak potongan kertas?) Dan gambar, tulis semua yang mungkin Anda pikirkan.

Bagi saya, ini adalah praktik yang baik untuk menggunakan pensil dan kertas, itu membantu mewujudkan ide-ide Anda dan juga menentukan di mana Anda ingin pergi untuk mencegah pergi ke mana pun, memperbaiki tujuan Anda. Ini bekerja untuk semua yang membutuhkan refleksi. Dan sudah jelas dalam banyak domain untuk menuliskan sesuatu sebelum melakukan pekerjaan yang sebenarnya.

Lakukan apa pun yang bekerja untuk Anda. Secara pribadi, saya merencanakan hal-hal kecil, tetapi tidak memiliki dokumen desain adalah rencana yang sangat rinci sebelum saya mulai mengkodekan apa pun. Lakukan apa pun yang paling produktif untuk Anda, terutama karena Anda bekerja sendiri.

(Saya menganggap pertanyaan dibuat dari sudut pandang desain-kode / arsitektur, bukan desain-game, meskipun jawabannya setidaknya sampai taraf tertentu berlaku untuk keduanya.)

Seperti yang sudah dikatakan, Anda perlu keduanya, dan Anda harus menyeimbangkannya. Overdesigning dan underdesigning aliran / struktur kode Anda dapat menyebabkan masalah. Sulit untuk mengatakan apa keseimbangan yang tepat, tetapi secara umum saya menemukan bahwa saya harus memiliki setidaknya ide yang tidak jelas bagaimana sisa kode akan bergabung dengan apa yang saya pemrograman saat ini, dan berpikir tentang masalah yang mungkin terjadi, kalau tidak saya cenderung "kode sendiri ke jalan buntu" - masuk ke situasi di mana saya menyadari "oke, sekarang berkat bagaimana saya memecahkan masalah ini, saya menciptakan masalah baru yang membuat seluruh solusi saya sebelumnya (atau bahkan lebih, dalam kasus terburuk ) sia-sia".

Secara umum, menurut pendapat saya, Anda dapat secara kasar menilai apakah Anda memiliki keseimbangan yang tepat dengan memikirkan skenario "bagaimana jika" seperti dalam "bagaimana jika saya nanti (ketika semuanya sepenuhnya dilaksanakan dalam paradigma yang sama seperti yang saya gunakan sekarang) cari tahu bagian A itu perlu bekerja sedikit berbeda yang berarti saya harus benar - benar mengerjakan ulang bagian B yang menghubungkannya mengakomodasi perubahan? " Jika perubahan arsitektur dalam satu bagian tidak mengharuskan Anda untuk mengubah lebih dari satu atau dua bagian lainnya, dan perubahan tersebut tidak mengalir (artinya pada gilirannya Anda harus mengubah juga bagian selanjutnya yang menghubungkan ke bagian B, dan kemudian bagian yang menghubungkan ke mereka, dll.), kode ini dikelompokkan secara relatif baik.

Tapi sungguh, ini adalah sesuatu yang akan Anda rasakan setelah mendapatkan beberapa pengalaman. Ini adalah sebagian mengapa semua orang memberikan saran gamedevs awal untuk pertama kode sesuatu yang dikenal dan mudah (Breakout / Tetris / Snake) dan untuk melakukannya sepenuhnya, dengan semua menu, suara, efek, semuanya untuk membuatnya sepenuhnya selesai permainan - lebih baik untuk mengacaukan proyek yang lebih kecil, dan melakukannya (baik dengan cara yang baik atau buruk) justru akan membantu Anda untuk merasakan seberapa jauh efek dari berbagai rentang keputusan arsitektur.