Saat membuat prototipe cepat, apakah lebih baik menggunakan bahasa yang akan Anda gunakan pada akhirnya?


23

Saya telah bekerja dengan SFML (C ++) dan Flash (AS3) dan biasanya membuat prototipe untuk beberapa ide yang saya miliki.

Apakah lebih baik menggunakan bahasa yang akan Anda gunakan pada akhirnya (biasanya C ++) atau menggunakan sesuatu yang sederhana dan cepat (AS3, Python, dll) untuk membuatnya bekerja dan kemudian mulai dari awal ketika Anda mulai pada produk utama?

Jawaban:


31

Ini sangat tergantung pada apa tujuan Anda.

Jika Anda mencoba untuk membuktikan gameplay, kecepatan iterasi mungkin adalah tujuan Anda yang paling penting dan oleh karena itu Anda harus memilih bahasa dan lingkungan yang sesuai dengan itu.

Jika Anda mencoba membuktikan teknologi (menggunakan middleware atau lainnya), maka tujuan Anda juga termasuk memilih bahasa apa yang akan digunakan.


6
Satu hal yang perlu ditambahkan, menggunakan bahasa selain bahasa target akhir akan mencegah prototipe Anda menjadi kode produksi. Anda mungkin ingin mempertimbangkan hal itu ketika memikirkan politik perusahaan Anda.
jessecurry

1
@ jessecurry, saya suka bagaimana Anda mengatakan "tolong cegah." Saya telah melihat prototip kode Ruby menjadi hidup dalam beberapa hari bersama dengan menginstal dukungan ruby ​​di server hosting.
gradbot

Kecuali jika Anda ingin membuktikan kinerja, pilihan bahasa juga tidak masalah untuk membuktikan teknologi. Yaitu untuk menjawab pertanyaan "Apakah ini bekerja sama sekali", prototipe skrip cepat dapat memberikan semua jawaban yang Anda butuhkan.
Rachel Blum

@ Rachel Ya tentu saja, itulah sebabnya saya membuka seluruh pertanyaan dengan "itu tergantung".
Tetrad

14

Ide pembuatan prototipe adalah untuk mendapatkan versi kerja yang cepat dan kotor dari ide Anda dan kemudian membuang prototipe untuk menciptakan arsitektur yang solid untuk produk akhir Anda.

Penting untuk mengakui bahwa suatu Prototipe tidak dimaksudkan untuk (dan tidak boleh pernah) di refactored menjadi suatu produk, jadi tidak perlu untuk menuliskannya dalam bahasa yang sama dengan yang Anda inginkan untuk menulis permainan terakhir Anda. Lebih baik memilih bahasa pemrograman yang memungkinkan untuk pengembangan cepat, seperti Flash seperti yang Anda sebutkan.

Prototipe pada dasarnya tidak dirancang untuk menjadi kode yang tahan lama. Prototipe dirancang untuk dibuang. Mereka satu kali. Tidak tepat untuk merekayasa berlebihan prototipe. Sebuah prototipe seperti sebuah kota di film barat. Semuanya fasad. Tidak ada apa-apa di belakangnya. Anda tidak dapat pindah dan membesarkan keluarga di salah satu rumah itu.

Jika Anda ingin membangun sesuatu yang mungkin ingin Anda gunakan lebih lanjut, ini bukan Prototipe melainkan Tracer Bullet seperti Andy Hunt dan Dave Thomas menyebutnya dalam buku The Pragmatic Programmer .


4

Saran umum dengan prototipe adalah menggunakan sesuatu yang benar-benar dibuang. Tujuan prototipe saat mengembangkan gim adalah memastikan bahwa Anda sedang bersenang-senang. Apakah mekanik permainan utama yang diandalkan oleh perangkat lunak Anda benar-benar membuat permainan yang menyenangkan? Itu pertanyaan penting, dan yang ingin Anda jawab secepatnya. Gunakan segala cara yang diperlukan untuk mendapatkan jawaban itu.


1

Saya pikir jawabannya di sini agak tergantung pada seberapa nyaman Anda dalam berbagai bahasa, dan pada kebutuhan teknis produk akhir. Dengan banyak game beranggaran kecil hari ini, sebenarnya tidak ada kebutuhan untuk kode dalam C ++ - Anda tidak akan pernah membutuhkan kecepatan yang diberikannya kepada Anda.

Pengalaman saya adalah bahwa jika Anda kesulitan untuk mendapatkan prototipe untuk bekerja, Anda telah membuat segala macam kompromi dalam kualitas kode Anda untuk sampai ke sana. Saya suka membuang prototipe itu dan mengkode ulangnya; dengan pelajaran yang telah saya pelajari dari mereka, mengkode apa yang saya inginkan lagi (terlepas dari bahasa yang ada di dalamnya) akan sangat cepat & memiliki kualitas kode yang jauh lebih tinggi.

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.