Apakah Test Driven Development layak dalam pengembangan game?

23

Sebagai yang bersertifikat Scrum, saya cenderung cenderung untuk metodologi Agile saat mengembangkan suatu sistem, dan bahkan menggunakan beberapa kanvas dari kerangka kerja Scrum untuk mengelola pekerjaan saya sehari-hari.

Selain itu, saya bertanya-tanya apakah TDD adalah opsi dalam pengembangan game, apakah itu layak?

Jika saya percaya pertanyaan GD ini, TDD tidak banyak digunakan dalam pengembangan game.
Mengapa MVC & TDD tidak dipekerjakan lebih banyak dalam arsitektur game?

Saya berasal dari pemrograman industri di mana proyek-proyek besar dengan anggaran besar perlu bekerja dengan sempurna, karena dapat menghasilkan skenario bencana jika kode tersebut tidak diuji secara hati-hati di dalam dan luar.

Plus, mengikuti aturan Scrum mendorong untuk memenuhi tanggal jatuh tempo pekerjaan Anda sementara setiap tindakan di Scrum adalah kotak waktu! Jadi, saya setuju ketika dalam pertanyaan yang ditautkan di atas mereka mengatakan berhenti berusaha membangun sistem, dan mulai menulis permainan. Inilah yang dikatakan Scrum, cobalah untuk tidak membangun sistem yang sempurna, pertama: membuatnya bekerja pada akhir Sprint. Kemudian, refactor kodenya sambil bekerja di Sprint kedua jika perlu!

Saya mengerti bahwa jika tidak semua departemen yang bertanggung jawab atas pengembangan game menggunakan Scrum, Scrum menjadi tidak berguna. Tapi mari kita pertimbangkan sejenak bahwa semua departemen menggunakan Scrum ... Saya pikir TDD akan baik untuk menulis kode bebas bug, meskipun Anda tidak ingin menulis sistem / permainan "sempurna".

Jadi pertanyaan saya adalah sebagai berikut:

Apakah TDD layak dalam pengembangan game?

architecture software-engineering methodology testing test-driven-development Will Marcouiller
sumber
Apa yang akan ditambahkan oleh diskusi dari pertanyaan ini di luar pertanyaan yang Anda tautkan?
Saya menyajikan kerangka kerja Scrum manajemen proyek dalam pengembangan perangkat lunak Agile dan berdebat tentang apa yang diinginkan Scrum dari pengembang selama Sprint, karenanya menjadikan TDD layak sebagai opsi. Saya ingin mendapatkan sudut pandang orang lain tentang subjek dari sudut pandang Scrum, tidak hanya di bawah aspek TDD atau MVC. Saya ingin memahami bagaimana TDD tidak layak ketika diperdebatkan dari sisi medali ini, selain hanya menganggap TDD itu sendiri sebagai pendekatan mandiri.
Will Marcouiller
@Apakah TDD == Desain Top Down atau Desain Berbasis Tes? Saya sedang memikirkan Top Down dan akan memberikan jawaban tentang pengelolaan dalam jangka panjang tetapi kemudian melihat jawaban yang lain menafsirkan TDD dengan cara yang tidak saya lakukan ...
James
@ James: Pengembangan Berbasis Tes.
chaos
@ James: Maaf atas kebingungannya! Saya tidak tahu tentang arti lain dari akronim, karena apa yang ada dalam pikiran saya adalah Agile Software Development with Scrum.
Will Marcouiller

Jawaban:

11

Ini tentu saja dapat dilakukan, meskipun banyak programmer game belum benar-benar memahami ide tersebut, atau memiliki pemahaman yang baik tentang cara menguji sistem yang rumit. Saya mengakui bahwa saya jarang menggunakannya, kecuali untuk sistem yang tidak berhubungan dengan gameplay yang mudah untuk diuji.

Berharap untuk menggunakan banyak benda tiruan. Karena betapa terikatnya banyak sistem, sulit untuk menguji komponen individu itu.

Ditambah banyak hal yang tidak dapat diuji secara menyeluruh. Bagaimana Anda menguji drive, katakanlah, sistem partikel? Bagaimana Anda menguji apakah sistem animasi Anda berfungsi dengan benar? Banyak hal bersifat visual, dan tidak jelas (setidaknya bagi saya) tentang cara melakukan pengujian yang tepat.

Namun, ada banyak hal yang belum tentu unit test dalam pengertian tradisional kata, tetapi yang ada sebagai "tes" untuk fitur tertentu. Hal-hal seperti level tes untuk navigasi AI sangat umum, tetapi tidak selalu hal termudah untuk diotomatisasi.

Ada aspek-aspek tertentu dari permainan yang dapat (dan mungkin harus) memiliki tes unit tertulis untuk mereka. Segala jenis sistem "pembacaan file" generik harus diuji. Mungkin ada beberapa tes untuk inisialisasi hal-hal perangkat keras (permukaan 3d, dll). Mungkin ada beberapa server tiruan dan uji kode interaksi klien / server Anda. Hal-hal seperti itu.

Tetrad
sumber
9
Ini adalah proposal bagus untuk keberadaan pengujian otomatis, tetapi tidak sama sekali untuk pengembangan yang digerakkan oleh pengujian.
1
Pendapat menarik, Tetrad! Terima kasih untuk sebutir garam Anda. Anda bertanya bagaimana cara menguji animasi visual? Sulit dikatakan mengenai sistem 3D, karena saya belum pernah menulis satu game pun, mungkin setelah beberapa mengembangkan beberapa game kecil! Selain itu, dalam 2D, saya sering melihat objek diwakili oleh matriks, dan pengurai matriks untuk membuat gambar di layar. Oleh karena itu, memastikan bahwa setelah beberapa penekanan tombol arah, informasi yang tepat ditemukan di tempat yang tepat dalam matriks yang dihasilkan bisa menjadi awal, saya kira. Saya hanya belum cukup tahu tentang komponen visual permainan, dan saya yakin akan tahun ini! =)
Will Marcouiller
Saya kembali setelah beberapa pengkodean untuk mengatakan bahwa saya telah menjawab pertanyaan minggu ini (pertama saya di GD! =)) Yang membutuhkan pengetahuan tentang konsep OOP. OP ingin memindahkan ular ke atas Keys.Down, Keys.Leftdll. Itu untuk mengatakan bahwa permainan tahu ke mana pengguna ingin ular pergi, dan ular harus pergi ke tempat permainan mengatakannya, meskipun itu hanya ular yang tahu caranya untuk bergerak ke arah yang berbeda, maka posisinya juga dalam permainan. Setelah mengatakan ini, IMHO, menjadikan Snakekelas yang dapat diuji! (Bersambung ...)
Will Marcouiller
Tidak hanya itu diuji, tetapi sekarang adalah kandidat yang baik untuk TDD. Katakanlah ular diinisialisasi pada posisi Vector2.Zero, dengan kecepatan 10.0fpada kedua sumbu X dan Y dalam game 2D ini. Pertanyaan pertama adalah: Apakah diposisikan pada posisi awal yang seharusnya dan bagaimana cara mengujinya? Kemudian, Anda berpikir bahwa Positionproperti tersebut akan terbuka untuk umum. Kedua: bagaimana membuatnya bergerak? Metode gerakan harus baik, jadi Anda menulis tes untuk setiap metode arah MoveDown, MoveLeftdan seterusnya. Sekarang, pergi dan tulis deklarasi metode Anda dan lihat apakah tesnya mengeluh. Kemudian, verifikasi kembali posisi ular itu
Will Marcouiller
setelah MoveDownpanggilan metode! Karena Anda tahu bahwa Positionproperti tersebut diuji secara menyeluruh, itu adalah anggota yang dapat Anda andalkan! Anda bisa menebak kelanjutannya di sini! ;-) Artinya komponen visual pasti tidak dapat diuji, tetapi ular harus terlihat seperti ular, semua tergantung dari jenis ular yang Anda inginkan dalam permainan. Artis yang menggambar ular harus membuktikan kepuasan yang cukup dengan gambar ular itu, yang tidak dapat diuji melalui TDD, tentu saja! Tapi posisinya relatif terhadap objek lain bisa, dan kelas yang mewakili ular ini juga. Bahkan, TDD
Will Marcouiller
11

Saya tidak berpikir TDD, dengan demikian, cocok sebagai dasar untuk pengembangan game. Pengujian unit otomatis sebagai bagian dari metodologi, tentu saja, tetapi terlalu banyak perhatian utama pengembangan game bersifat subjektif dan tidak dapat diuji mesin untuk pengujian sebagai pendorong pengembangan. Bagaimana Anda akan menulis tes skrip untuk mengetahui apakah seorang mekanik permainan itu menyenangkan? Level itu menarik secara visual? Bahkan level itu membutuhkan pemain biasa sekitar 15 menit untuk menyelesaikan? TDD cocok dengan situasi di mana kematangan proyek dapat diukur secara kuantitatif dalam hal kepatuhannya terhadap spesifikasi, dan itu bukan pengembangan game.

kekacauan
sumber
3
Apa maksud Anda ketika Anda mengatakan bahwa pengembangan game tidak memenuhi spesifikasi? Maksud saya adalah Anda harus tahu jenis permainan apa yang Anda tulis saat Anda ingin menulis satu. Dengan demikian, spesifikasi, persyaratan harus ditulis sebagai fitur atau sejenisnya; mari kita ambil contoh Product Backlog di Scrum. Anda tahu cerita pengguna yang harus Anda kembangkan di game Anda sehingga Anda menulis game yang diharapkan! Kemudian, untuk contoh lain, Anda mungkin perlu mendeteksi tabrakan dalam game pertempuran, ini adalah hal yang dapat diuji! Apakah permainan itu menyenangkan lebih dari cerita atau pemrograman, IMHO.
Will Marcouiller
@ Will Marcouiller: Saya tidak bermaksud mengatakan bahwa kita tidak memiliki spesifikasi atau tidak dapat mengukur kepatuhan terhadapnya, tetapi hal yang kurang penting dari proyek dapat ditentukan secara bermakna daripada jenis pengembangan lainnya. Anda dapat menulis "game seharusnya menyenangkan" ke dalam spek Anda, tetapi itu bukan spesifikasi dengan makna teknis. Anda dapat dan harus menguji untuk apa yang dapat diuji, tetapi titik TDD adalah bahwa pengujian bukan hanya bagian dari proses, itu adalah seluruh dasar dari proses, pola pikir mendasar, dan saya tidak melihat bahwa cocok dengan sangat baik dengan sangat bidang subjektif.
kekacauan
2
@ Akan Marcouiller, saya sangat, sangat, tidak setuju bahwa kesenangan dari permainan turun ke cerita. Semua kesenangan dalam permainan datang ke gameplay, cerita hanyalah bonus.
AttackingHobo
1
@ Will: Tidak, dia mengatakan bahwa kenikmatan yang diperoleh pengguna dari sebuah game tidak dapat ditentukan melalui tes otomatis, dan bahwa game memiliki sejumlah besar hal yang hanya dapat diuji dengan mengirimkan game ke tangan konsumen.
DeadMG
1
@DeadMG: Itu lebih benar daripada yang diinginkan siapa pun, tetapi poin saya (belum tentu AttackingHobo) melibatkan fakta bahwa proses pengembangan itu sendiri harus menggabungkan pengujian, oleh desainer dan produsen dan pengembang dan penguji, yang tidak dapat diukur dalam satu unit Tes, itu berkaitan dengan kualitas pengalaman dan rasa dan gaya dan efek estetika yang diciptakan permainan. Memberitahu orang-orang bahwa mereka melakukan TDD ketika itu bagian penting dari pengembangan pada dasarnya hanya untuk berbohong kepada mereka.
kekacauan
6

Agak sulit untuk mengetahui persis apa yang Anda minta karena judulnya murni tentang TDD tetapi Anda tampaknya menjadikan Scrum bagian integral dari pertanyaan juga - dan seperti yang saya pahami, yang satu tidak memerlukan yang lain.

Jika saya percaya pertanyaan GD ini, TDD tidak banyak digunakan dalam pengembangan game.

Itu betul. Saya tidak berpikir saya pernah mendengarnya digunakan dalam praktik di industri game. (Tetapi kemudian saya tidak pernah mendengar tentang itu digunakan di luar industri game - hanya oleh individu.)

Saya berasal dari pemrograman industri di mana proyek-proyek besar dengan anggaran besar perlu bekerja dengan sempurna, karena dapat menghasilkan skenario bencana jika kode tersebut tidak diuji secara hati-hati di dalam dan luar.

Game tidak perlu bekerja dengan sempurna. Jadi ada jauh lebih sedikit penekanan pada kebenaran kode. TDD tidak menjamin kebenaran kode, tetapi beberapa orang merasa mengurangi kesalahan. Saya belum melihat buktinya.

Plus, mengikuti aturan Scrum mendorong untuk memenuhi tanggal jatuh tempo pekerjaan Anda sementara setiap tindakan di Scrum adalah kotak waktu!

Saya belum pernah melihat metodologi yang tidak mendorong tanggal jatuh tempo rapat, atau memiliki tindakan yang tidak sesuai waktu. Masalahnya adalah apa pun metodologi yang Anda gunakan, memperkirakan kompleksitas perangkat lunak cukup sulit. Bukan tidak mungkin, tetapi memperkirakannya secara akurat tidak banyak hubungannya dengan proses. Jika tugas saya adalah menambahkan panel GUI baru, atau untuk memperbaiki bug dengan animasi, atau menambahkan statistik baru ke karakter, maka penggunaan Scrum tidak akan mempercepat itu sama sekali, dan penggunaan TDD akan meningkat untuk memperlambat tugas (pada kemungkinan manfaat mengurangi tugas pemeliharaan lebih lanjut nanti). Mereka tentu tidak akan membuatnya lebih mudah untuk memperkirakan durasi tugas.

Saya pikir TDD akan baik untuk menulis kode bebas bug, meskipun Anda tidak ingin menulis sistem / permainan "sempurna".

Jika TDD terbukti menulis kode yang lebih baik daripada metode lain, maka ya.

Apakah ada buktinya? Fakta bahwa industri mungkin menggunakannya bukanlah bukti. Industri terkenal karena menghasilkan kode yang buruk yang dikirimkan terlambat. Tidak adanya contoh proyek TDD besar yang gagal atau terlambat mungkin hanya karena ini merupakan pendekatan baru dan sedikit orang yang benar-benar menyelesaikan proyek semacam itu. (Dan yang terlambat ... mungkin masih berjalan.)

Apakah TDD layak dalam pengembangan game?

Giat? Tentu saja. Bermanfaat? Itu belum terbukti.

Kylotan
sumber
1
Sayangnya, TDD dan Scrum masih disalahpahami. Dan ini berlaku untuk proyek yang ada yang tidak akan membantu mempercepat perbaikan bug atau lainnya. Scrum adalah kerangka kerja untuk mengembangkan sistem yang kompleks, seperti permainan tampaknya. Scrum mendorong perbaikan bug dari Sprint ke Sprint lain agar tidak pernah menumpuk. TDD menempatkan Anda di sisi pengguna. Menurut pengguna, maksud saya programmer rekan yang akan menggunakan kode Anda. Ini memaksa Anda untuk berpikir bagaimana seharusnya digunakan untuk membuat kode Anda mudah digunakan untuk orang lain. Oleh karena itu, ini mengarah pada desain yang lebih baik, per pengalaman. Itu semua mengatakan, Anda mendapat pandangan menarik tentang subjek.
Will Marcouiller
1
Memaksa bug untuk tidak menumpuk hanya menyebabkan fitur tergelincir - Anda tidak dapat secara ajaib menghasilkan lebih banyak waktu. Pemahaman saya adalah bahwa Scrum tidak memiliki metode khusus khusus untuk bug. Adapun TDD memaksa Anda untuk berpikir tentang bagaimana orang lain akan menggunakan kode Anda, itu bukan satu-satunya cara untuk melakukannya. Oleh karena itu belum tentu lebih baik, dan tentu saja bukan penggunaan waktu yang paling efektif.
Kylotan
1
FYI, Noel Llopis menggunakan TDD untuk game indie-nya, dan perusahaan lamanya High Moon Studios menggunakannya secara luas. Belum ada kutipan, maaf.
tenpn
Anda punya beberapa poin bagus yang menarik untuk dibaca! Terima kasih atas kontribusi Anda. Meskipun demikian, saya ingin menambahkan bahwa TDD adalah pendekatan lain seperti XP (pemrograman ekstrim). Dan ya, Scrum tidak menyediakan metode khusus khusus untuk bug, dan lebih baik berinvestasi pada pengaturan sendiri dari Tim (pengembang). Scrum tidak memberi tahu Anda bagaimana melakukan sesuatu, itu hanya mengatakan apa yang harus dilakukan. Merupakan komitmen Tim untuk menjalani apa yang harus dilakukan. Scrum hanya bertaruh pada Tim lintas fungsi yang diatur sendiri. Adalah Tim yang memutuskan bagaimana fitur harus dikembangkan dan diuji, dll
Will Marcouiller
(lanjutkan ...) Saya telah menjawab pertanyaan pertama saya minggu ini tentang kelas di GD. OP ingin mengetahui cara membuat sprite bergerak pada penekanan tombol arah. Menjadi nyaman dengan konsep OOP, saya menemukan bahwa saya mungkin harus menggunakan kelas untuk mengembangkan game pertama saya menggunakan XNA. Yang mengatakan, Spacecraftkelas saya menjadi kelas yang sepenuhnya dapat diuji dengan metode dan properti. Ini adalah jenis hal yang benar-benar dapat, IMHO, diuji sepenuhnya menggunakan TDD. Katakanlah Anda membutuhkan pesawat ruang angkasa, kemudian Anda menulis tes untuk apa yang Anda butuhkan untuk menyelesaikan satu tes pada suatu waktu.
Will Marcouiller
4

maaf untuk bahasa Inggris saya yang buruk dan maaf untuk sudut pandang saya yang bias: saya bukan seorang desainer game tetapi seorang pembuat kode.

Saya pikir ada beberapa kesalahpahaman dalam diskusi ini. saya akan berbicara tentang TDD dalam bentuk yang lebih umum, yang disebut BDD. Pengembangan yang didorong oleh perilaku bukanlah cara untuk menguji proyek (tes adalah sesuatu seperti efek samping). BDD adalah cara untuk mendesain , cara untuk melakukan refactor dan desain perangkat lunak selama semua produksi (lihat beberapa moto sebagai KISS, "jaga kualitas dalam", "tes awal, tes sering") dan bukan dalam fase sendirian. BDD adalah kebalikan dari beberapa proses perangkat lunak klasik seperti proses air terjun atau metodologi berulang lainnya untuk membuat perangkat lunak.

Poin lain adalah bahwa pengujian otomatis untuk fitur yang dapat diuji secara otomatis oleh mesin komputasi. tidak ada tes untuk bersenang-senang dalam game, dan tidak ada tes untuk kegunaan antarmuka pengguna grafis. kesenangan atau kegunaan adalah bahan untuk pekerjaan lain dan bukan untuk pengembangan perangkat lunak seperti perancang interaksi, dunia dan tingkat d. dengan cara yang sama seperti bagian artistik (pemodelan, texturing, dll) untuk artis yang menggunakan komputer sebagai alat untuk kreativitas - jelas pekerjaan itu dapat dilakukan oleh orang yang sama yang menulis kode, tetapi ini bukan intinya. fisika dapat diuji, algoritma optimisasi dapat diuji, perilaku objek tunggal dapat diuji (dengan mengolok-olok, bertopik dan boneka seperti yang disebutkan sebelumnya)

pemikiran terakhir adalah bahwa, imho, adalah bahwa tidak hanya desain game tetapi seluruh kode penulisan adalah seni.

nkint
sumber
4

Berikut ini adalah studi kasus dari seseorang yang berpikir TDD dan gamedev mencampur dengan cukup baik:

http://powertwenty.com/kpd/downloads/TestDrivenDevelopmentInPython.pdf

Diakui, ini adalah proyek kecil di Pygame, tetapi memberikan gagasan bagian mana yang dapat diuji dengan permainan grafis dan mana yang tidak. Saya terkejut pada seberapa banyak yang bisa dilakukan dengan TDD dalam skenario ini.

Brandon
sumber
1
Tanpa perbandingan dengan kelompok kontrol yang melakukan proyek yang sama (mengkloning game arcade sepele yang ada dalam bahasa tingkat yang sangat tinggi), ia tidak mengatakan apa-apa tentang apakah TDD efektif atau tidak. Itu hanya mengatakan dia menggunakan TDD.
3

Tidak, Pengembangan Test Driven tidak cocok untuk Pengembangan Game. Tentu Anda dapat menulis tes untuk beberapa bagian yang ingin Anda uji, tetapi proses Pengembangan Game benar-benar berbeda dari Pengembangan yang Didorong Tes yang memerlukan spesifikasi yang tepat sebelum kemajuan dimulai.

Game jarang memiliki spesifikasi yang tepat ketika dimulai. Dan jika mereka melakukannya, mereka selalu berubah dan berkembang selama proses pengembangan.

Desain game adalah seni, Anda tidak dapat memiliki tes khusus untuk mengetahui kapan seni itu baik atau lengkap.

SerangHobo
sumber
Tidakkah Anda berpikir bahwa faktor menyenangkan harus dipertimbangkan ketika menganalisis permainan itu sendiri, analisis fungsional atau sejenisnya? Anda dapat mengatur serangkaian fitur yang bersama-sama akan membuat game ini menyenangkan untuk dimainkan, dan fitur-fitur ini kemudian dapat diuji! Saya hanya mencoba mengemukakan pendapat yang berbeda untuk lebih mendalam tentang topik dan argumen yang Anda kemukakan. Terima kasih atas kontribusi Anda! =)
Will Marcouiller
3
Banyak perkembangan datang ke tweak hal-hal kecil dan melihat betapa menyenangkannya mereka bermain. Anda tidak dapat menguji hal-hal itu kecuali jika 100% dibuat dari batu. Dan pengujian sistem setelah dilakukan bukan TDD, ini pengujian, tetapi bukan Pengembangan yang didorong oleh pengujian.
AttackingHobo
2
Jika Anda berpikir sebagian besar proyek dunia nyata memiliki spesifikasi yang tepat ketika mereka mulai, maka Anda mungkin belum bekerja di banyak proyek dunia nyata.
BlueRaja - Danny Pflughoeft