Teste Dayalı Geliştirme oyun geliştirmede uygulanabilir mi?

23

Scrum sertifikalı olarak, bir sistem geliştirirken Çevik metodolojilere yatkınlık yapıyorum ve günlük çalışmamı yönetmek için Scrum çerçevesinden bir tuval bile kullanıyorum.

Ayrıca TDD'nin oyun geliştirmede bir seçenek olup olmadığını merak ediyorum.

Eğer bu GD sorusuna inanırsam, TDD oyun geliştirmede pek kullanılmaz.
MVC ve TDD neden oyun mimarisinde daha fazla kullanılmıyor?

Büyük bütçeli büyük projelerin kusursuz çalışması gereken endüstriyel programlamadan geliyorum, çünkü kodun içte ve dışta ayrıntılı bir şekilde test edilmemesi halinde felaket senaryolara neden olabilir.

Ayrıca, Scrum kurallarına uymak, işinizin bitiş tarihlerini karşılamayı teşvik ederken, Scrum'daki her bir eylem zaman sınırlıdır! Bu yüzden, yukarıda verilen soruya ne zaman bir sistem kurmaya çalışmayı bırakıp oyunu yazmaya başladığını söylüyorlar. Scrum'ın söylediği gibi, mükemmel sistemi kurmamaya çalışın, ilk önce Sprint sonunda çalışsın. Ardından, gerekirse ikinci Sprint'te çalışırken kodu tekrar gözden geçirin!

Oyun gelişiminden sorumlu tüm bölümler Scrum kullanmazsa, Scrum'un işe yaramaz hale geldiğini anlıyorum. Ama bir anlığına bütün bölümlerin Scrum kullandığını düşünelim ... "Mükemmel" sistem / oyun yazmak istemeseniz de TDD'nin hatasız kod yazmakta iyi olacağını düşünüyorum.

Yani benim sorum şu:

Oyun geliştirme sürecinde TDD uygulanabilir mi?

— Marcouiller
kaynak

Bağladığınız sorunun ötesine eklenecek bu sorunun tartışması nedir?

Çevik yazılım geliştirmede Scrum proje yönetimi çerçevesini sunuyorum ve Scrum'ın bir Sprint sırasında geliştiriciden ne istediğini, dolayısıyla TDD'yi bir seçenek olarak uygun hale getirdiğimi savunuyorum. Konuyla ilgili diğerlerinin bakış açısını sadece TDD veya MVC yönü altında değil, Scrum bakış açısından görmek istiyorum. TDD'nin kendisini bağımsız bir yaklaşım olarak görmekten başka madalyanın bu tarafından tartışıldığı zaman TDD'nin nasıl uygulanabilir olmadığını anlamak istiyorum.

— Marcouiller

@ TDD == Yukarıdan Aşağıya Tasarım mı yoksa Test Odaklı Tasarım mı? Top Down'u düşünüyordum ve uzun vadede yönetilebilirlik cevabını verecektim ama sonra diğer cevabın TDD'yi benim olmadığı gibi yorumladığını gördüm ...

— James

@James: Test Odaklı Geliştirme.

— kaos

@James: Karışıklık için üzgünüm! Kısaltmanın diğer anlamını bilmiyordum, çünkü aklımdaki şey Scrum ile Çevik Yazılım Geliştirme idi.

— Marcouiller

11

Birçok oyun programcısı henüz bu fikirle ilgili bir fikir edinmedi ya da karmaşık sistemlerin nasıl test edileceği konusunda iyi bir anlayışa sahip olsa da kesinlikle uygulanabilir. Kendimi nadiren kullandığımı itiraf ediyorum, oyunla ilgili olmayan ve test edilmesi kolay sistemler dışında.

Çok fazla sahte nesne kullanmayı bekleyin. Bir çok sistemin birbirine ne kadar bağlı olması nedeniyle, bunun bileşenlerini tek tek test etmek zor.

Ayrıca pek çok şey tam olarak test edilemez. Bir parçacık sistemini nasıl test edersiniz? Animasyon sisteminizin doğru çalıştığını nasıl test edersiniz? Bir çok şey doğada görseldir ve uygun testlerin nasıl yapılacağına dair (en azından benim için) açık değildir.

Bununla birlikte, kelimenin geleneksel anlamıyla ünite testi gerektirmeyen, ancak belirli özellikler için "testler" olarak varolan pek çok şey vardır. AI navigasyonu için test seviyeleri gibi şeyler oldukça yaygındır, ancak otomatikleştirilmesi en kolay şeyler değildir.

Oyunların kendileri için yazılmış birim testlerini yapabilecek (ve muhtemelen de etmesi gerekir) bazı yönleri vardır. Her türlü genel "dosya okuma" sistemi test edilmelidir. Belki donanımların başlatılması için bazı testler (3d yüzeyler, vb.) Vardır. Belki bazı sahte sunucular var ve müşteri / sunucu etkileşim kodunuzu test edin. Bunun gibi şeyler.

— dörtlü
kaynak

9

Bunlar otomatik testlerin mevcudiyeti için harika tekliflerdir, ancak test odaklı bir gelişim için kesinlikle değildir.

1

İlginç görüş, Tetrad! Tuzunuz için teşekkürler. Görsel animasyonun nasıl test edileceğini soruyorsunuz? 3D sistemlerde olduğu gibi söylemek zor, çünkü belki de bir kaç küçük oyun geliştirdikten sonra, tek bir oyun yazmadım. Ayrıca, 2B'de, sık sık matrisle temsil edilen nesneleri ve matris ayrıştırıcıları görüntüyü ekranda göstermek için gördüm. Bu nedenle, bazı yön tuşlarına basıldıktan sonra, elde edilen matristeki doğru yerde doğru bilginin bulunmasının bir başlangıç olabileceğinden emin olmak sanırım. Sadece bir oyunun görsel bileşenleri hakkında henüz yeterince bilgim yok ve bu yıl kesinlikle olacak! =)

— Marcouiller

Bazı hafta kodlamadan sonra geri döndüm, bu hafta OOP kavramları hakkında bilgi gerektiren bir soruyu cevapladığımı (GD'ye ilk benim!) Yazdım. OP Keys.Down, bir yılanı Keys.Left, vb. Üzerine taşımak istedi. Oyunun, kullanıcının yılanı nereye götürmek istediğini bildiğini ve yılanın, oyunun onu söylediği yere gitmesi gerektiğini, ancak bunun sadece yılan olduğunu bilmek Farklı yönlerde hareket etmek, dolayısıyla oyundaki konumundan da geçmek. Bunu söyledikten sonra IMHO, Snakesınıfı test edilebilir bir hale getiriyor ! (Devam edecek ...)

— Will Marcouiller

Sadece test edilebilir olmakla kalmayıp, aynı zamanda TDD için iyi bir aday. Diyelim ki yılan bu 2D oyunda hem X hem de Y ekseninde Vector2.Zerobir hızda pozisyonda başlatılmış 10.0f. İlk soru: Sözde ilk konumunda mı ve nasıl test edilmeli? O zaman, Positionmülkün halka açık hale getirileceğini düşünüyorsunuz . İkincisi: nasıl hareket ettirilir? Her yöne yöntemi için bir test yazmak yüzden Hareket yöntemleri, iyi olmalı MoveDown, MoveLeftböylece ve. Şimdi gidip yöntem bildiriminizi yazın ve testin şikayet edip etmediğine bakın. Ardından, yılanın konumunu tekrar

— doğrulayın

Bir MoveDownyöntem çağrısından sonra ! Bunu bildiğimiz için Positionmülk iyice test edilir, yani sen sayabilirsiniz hangi üyesidir! Burada devamı tahmin edebilirsiniz! ;-) Bu, görsel bileşenlerin kesinlikle test edilemeyeceği, ancak yılanın, oyunda ne tür bir yılan istediğine bağlı olarak, bir yılan gibi görünmesi gerektiğidir. Yılanı çizen sanatçı, elbette TDD ile test edilmeyen yılan çiziminden yeterince memnuniyet duymalı! Ancak diğer nesnelere göre konumu ve bu yılanı temsil eden sınıf da olabilir. Aslında, TDD

— Will Marcouiller

11

TDD'nin oyun geliştirme için bir temel olarak uygun olduğunu sanmıyorum. Metodolojinin bir parçası olarak otomatik birim testi, oyun geliştirmenin temel kaygılarının birçoğu özneldir ve geliştirmenin itici gücü olmak için test edilebilir değildir . Bir oyun tamircisinin eğlenceli olup olmadığı konusunda senaryo sınavını nasıl yazacaksınız? Bir seviye görsel olarak çekici olduğunu? Hatta bir seviye tamamlamak için yaklaşık 15 dakika tipik bir oyuncu alır? TDD, bir projenin olgunluğunun bir şartnameye uygunluğu açısından niceliksel olarak ölçülebildiği ve sadece oyun gelişimi olmadığı durumlar için uygundur.

— kaos
kaynak

3

Oyun geliştirmenin teknik özelliklere uygun olmadığını söylerken ne demek istiyorsun? Demek istediğim, yazmak istediğinizde ne tür bir oyun yazdığınızı bilmeniz gerektiğidir. Bu nedenle, şartnameler, şartlar özellikler veya benzeri olarak yazılmalıdır; Scrum'da bir Ürün İş Listesi örneği alalım. Beklediğiniz oyunu yazmak için oyununuzda geliştirmeniz gereken kullanıcı hikayelerini biliyorsunuz! O zaman, başka bir örnek için, bir dövüş oyunundaki çarpışmaları tespit etmeniz gerekebilir, bunlar test edilebilir şeyler! Oyunun eğlenceli olup olmadığı hikaye ya da programlamanın ötesinde, IMHO.

— Marcouiller

@Will Marcouiller: Bence o daha az proje hakkında önemli olanın özelliklere sahip olmayan veya onlarla uyumu ölçemez ama ima etmek anlamına gelmez edebilir anlamlı gelişme diğer tür daha belirtilebilir. Spesifikasyonunuza "oyun eğlenceli olmalı" yazabilirsiniz, ancak bu teknik anlamı olan bir özellik değildir. Test edilebilir olanı test edebilirsiniz ve etmelisiniz, ancak TDD'nin amacı testin sadece sürecin bir parçası olmadığı, sürecin tüm temeli, temel bir zihniyet olduğunu ve bunun çok iyi bir şekilde titreştiğini görmüyorum. öznel alan.

— kaos

2

@ Marcouiller, çok, çok, ben oyunun eğlencesinin hikayeye indiği konusunda hemfikirim. Oyunda tüm eğlence oyun aşağı gelir, hikaye sadece bir bonus.

— Saldırı

1

@Will: Hayır, bir kullanıcının bir oyundan elde ettiği eğlencenin, otomatik testle belirlenemediğini ve oyunların yalnızca oyunu tüketicinin ellerine göndererek test edilebilecek çok sayıda şeye sahip olduğunu söylüyor.

— DeadMG

1

@DeadMG: Bu herkesin istediğinden daha doğru, ama benim açımdan (mutlaka AttackingHobo'nun değil) geliştirme sürecinin kendisinin bir birimde ölçülemeyen tasarımcılar, üreticiler ve geliştiriciler ve testçiler tarafından yapılan testleri içermesi gerektiği gerçeği var. Test, oyunun yarattığı tecrübe ve his ve tarz ve estetik etki kalitesi ile ilgilidir. İnsanlara TDD yaptıklarını söylemek, gelişimin bu kadar önemli bir parçası olduğunda, sadece onlara yalan söylemek demektir.

— kaos

6

Tam olarak ne istediğinizi çözmeniz biraz zor çünkü ünvan tamamen TDD ile ilgili. Fakat Scrum'ı sorunun da ayrılmaz bir parçası yapıyor gibi görünüyorsunuz - ve anladığım kadarıyla biri diğerine ihtiyaç duymuyor.

Eğer bu GD sorusuna inanırsam, TDD oyun geliştirmede pek kullanılmaz.

Bu doğru. Oyun endüstrisinde pratikte kullanıldığını hiç duymadığımı sanmıyorum. (Ama o zaman oyun endüstrisi dışında da kullanıldığını hiç duymadım - sadece bireyler tarafından.)

Büyük bütçeli büyük projelerin kusursuz çalışması gereken endüstriyel programlamadan geliyorum, çünkü kodun içte ve dışta ayrıntılı bir şekilde test edilmemesi halinde felaket senaryolara neden olabilir.

Oyunların kusursuz çalışması gerekmez. Dolayısıyla kod doğruluğuna çok daha az önem verilir. TDD kod doğruluğunu garanti etmiyor, ancak bazı kişiler yanlışlığı azalttığını düşünüyor. Henüz bunun kanıtını görmedim.

Ayrıca, Scrum kurallarına uymak, işinizin bitiş tarihlerini karşılamayı teşvik ederken, Scrum'daki her bir eylem zaman sınırlıdır!

Son buluşma tarihlerini teşvik etmeyen ya da zaman çizelgesi olmayan eylemlerde bulunma yöntemlerini hiç görmedim. Sorun, hangi metodolojiyi kullanırsanız kullanın, yazılım karmaşıklığını tahmin etmek oldukça zordur. İmkansız değil, ancak doğru bir şekilde tahmin etmek, süreçle ilgili değil. Görevim yeni bir GUI paneli eklemek veya animasyonla ilgili bir hatayı düzeltmek veya karakterlere yeni bir istatistik eklemekse, Scrum kullanımı bunu hızlandıracak ve TDD kullanımı devam etmeyecektir. Görevi yavaşlatmak (daha sonraki bakım görevlerini azaltma olasılığına bağlı olarak). Görev sürelerini tahmin etmeyi kesinlikle kolaylaştırmayacaklar.

TDD'nin hatasız kod yazmanın iyi olacağını düşünüyorum, ancak "mükemmel" bir sistem / oyun yazmak istemezsiniz.

TDD'nin diğer yöntemlerden daha iyi kod yazdığı kanıtlanırsa, evet.

Bunun kanıtı var mı? Sanayinin kullanabileceği gerçeği kanıt değildir. Endüstri, geç teslim edilen zayıf kodların üretilmesi ile tanınır. Başarısız veya geç kalmış ana TDD projelerinin örneklerinin olmayışı, bunun yeni bir yaklaşım olduğu ve çok az insanın henüz böyle bir projeyi bitirdiği için olabilir. (Ve geç kalanlar hala çalışıyor olabilirler.)

Oyun geliştirme sürecinde TDD uygulanabilir mi?

Mantıklı mı? Tabii ki. Faydalı? Bu henüz kanıtlanmadı.

— Kylotan
kaynak

1

Ne yazık ki, TDD ve Scrum hala yanlış anlaşılmaktadır. Ve bu, ne hata düzeltmelerinin hızlandırılmasında ne de yardımcı olacak mevcut projeler için geçerlidir. Scrum, bir oyun gibi göründüğü gibi karmaşık sistemler geliştirmek için bir çerçevedir. Scrum, Sprint'ten diğerine hata düzeltmeyi teşvik etmemekte ve böylece hiçbir zaman birikmemelerini sağlamıştır. TDD sizi kullanıcının tarafına yerleştirir. Kullanıcı olarak, kodunuzu kullanacak meslektaş programcılarını kastediyorum. Kodunuzu diğerleri için kullanımı kolay hale getirmek için nasıl kullanılması gerektiğini düşünmeye zorlar. Bu nedenle, deneyim başına daha iyi tasarıma yol açar. Bütün bunların söylediği, konuyla ilgili ilginç görüşleriniz var.

— Marcouiller

1

Böcekleri birikmemeye zorlamak sadece özelliklerin kaymasına neden olur - sihirli bir şekilde daha fazla zaman üretemezsiniz. Anladığım kadarıyla Scrum'un zaten böceklere özgü belirli bir metodu olmadığı. TDD, diğer kişilerin kodunuzu nasıl kullanacakları hakkında düşünmeye zorlama konusunda, bunu yapmanın tek yolu bu değil. Bu nedenle mutlaka daha iyi değil ve mutlaka mutlaka zamanın en etkili kullanımı değil.

— Kylotan

1

Bilginize, Noel Llopis indie oyunlarında TDD kullanıyor ve eski şirketi High Moon Studios da kullanıyordu. Bir alıntı yapmadım, üzgünüm.

— tenpn

Okumak için ilginç bazı iyi noktaların var! Katkınız için teşekkürler. Bununla birlikte, TDD'nin XP gibi bir başka yaklaşım olduğunu da eklemek isterim (aşırı programlama). Ve evet, Scrum, böceklere özgü herhangi bir özel yöntem sağlamaz ve daha doğrusu Takımın (geliştiricilerin) kendi kendine organizasyonuna yatırım yapar. Scrum size işleri nasıl yapacağınızı söylemez, sadece yapılması gerekenleri söyler. Yapılması gerekenleri gözden geçirmek Takımın taahhüdüdür. Scrum, yalnızca kendi kendine organize olan çapraz fonksiyonel Takımlara bahis yapar. Özelliklerin nasıl geliştirilip test edileceğine karar veren Takım, vb.

— Will Marcouiller

(devam ...) Bu hafta GD konulu derslerle ilgili ilk sorumu cevapladım. OP, sprite'ın yön tuşlarına basıldığında nasıl hareket ettirileceğini bilmek istedi. OOP konseptleri konusunda rahat olduğumda, ilk oyunumu XNA kullanarak geliştirmek için belki de sınıfları kullanmam gerektiğini düşündüm. Bu, Spacecraftsınıfımın yöntem ve özelliklerle tamamen test edilebilir bir sınıf haline geldiğini söyledi . Bu, IMHO'nun TDD kullanılarak tamamen test edilebilecek türden bir şey. Diyelim ki bir uzay aracına ihtiyacınız var, o zaman bir seferde bir testi başarmak için neye ihtiyacınız olduğuna dair testleri yazıyorsunuz.

— Marcouiller

4

fakir ingilizcem için üzgünüm ve önyargılı bakış açım için üzgünüm: bir oyun tasarımcısı değilim ama bir kodlayıcıyım.

Bu tartışmada bazı yanlış anlaşılmaların olduğunu düşünüyorum. TDD hakkında daha genel olarak BDD denilen bir biçimde konuşacağım. Davranış odaklı gelişim, projeyi test etmenin bir yolu değildir (testler yan etkiler gibi bir şeydir). BDD, tüm üretim sırasında refactor ve yazılım tasarımını yapmanın bir yolunu tasarlamanın bir yoludur (KISS olarak bazı sloganlara bakın, "kaliteyi" "," erken test et, sık test et ") ve tek bir aşamada değil. BDD, şelale işlemi gibi bazı klasik yazılım işlemlerinin veya yazılım yapmak için başka bir yinelemeli yöntemin zıttıdır.

Diğer bir nokta, otomatik testlerin bilgisayarlı bir makine tarafından otomatik olarak test edilebilecek özelliklere yönelik olmasıdır. Oyunlarda eğlence için bir test yoktur ve grafiksel bir kullanıcı arayüzünün kullanılabilirliği için bir test yoktur. eğlence veya kullanılabilirlik, etkileşim tasarımcısı, dünya ve seviye gibi yazılım geliştirme amaçlı değil, diğer işler için materyallerdir. d. aynı şekilde sanatsal kısımlar (modelleme, dokulama, vb.) bilgisayarları yaratıcılık aracı olarak kullanan sanatçıya yöneliktir - açıkçası bu işler kod yazan kişi tarafından da yapılabilir, ama mesele bu değil. fizik test edilebilir, optimizasyon algoritmaları test edilebilir, tekil nesne davranışları test edilebilir (daha önce belirtildiği gibi alay, taslak ve kukla ile)

Son düşünce, yani, sadece oyun tasarımının değil, aynı zamanda bütün yazı kodunun bir sanat olduğu.

— nkint
kaynak

4

İşte TDD ve gamedev'in oldukça iyi bir şekilde karıştığını düşünen birinden bir örnek vaka incelemesi:

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

Kuşkusuz, bu Pygame'de küçük bir proje, ancak grafiksel bir oyunda hangi parçaların test edilebileceği ve hangilerinin yapamayacağı fikrini veriyor. Bu senaryoda TDD ile neler yapılabileceğine şaşırdım.

— Brandon
kaynak

1

Aynı projeyi yapan bir kontrol grubuyla (çok yüksek seviyeli bir dilde mevcut önemsiz bir arcade oyununu klonlamak) kıyaslama yapmadan TDD'nin etkili olup olmadığı hakkında hiçbir şey söylemez. Sadece TDD kullandığı yazıyor.

3

Hayır, Test Odaklı Gelişme, Oyun Geliştirme için uygun değildir. Test etmek istediğiniz bazı bölümler için testler yazabileceğinizden emin olun, ancak Oyun Geliştirme süreci, ilerlemeye başlamadan önce kesin özelliklere sahip olmayı gerektiren Test Odaklı Geliştirme'den tamamen farklıdır.

Oyun başlatıldığında nadiren kesin özelliklere sahiptir. Ve yaparlarsa, gelişme sürecinde daima değişir ve gelişirler.

Oyun tasarımı bir sanattır, sanatın ne zaman iyi veya tam olduğunu bilmek için özel testleriniz olamaz.

— AttackingHobo
kaynak

Oyunun kendisini, işlevsel analizi veya benzerlerini analiz ederken eğlenceli faktörün dikkate alınması gerektiğini düşünmüyor musunuz? Birlikte oyunu oynamak için eğlenceli hale getirecek bir dizi özellik ayarlayabilirsiniz ve bu özellik daha sonra test edilebilir! Sadece konu ve ortaya çıktığınız tartışmalar hakkında derinlemesine gitmek için farklı görüşler öne sürmeye çalışıyorum. Katkınız için teşekkürler! =)

— Marcouiller

3

Küçük geliştirmeler yapmak ve ne kadar eğlenceli oynayacaklarını görmek çok fazla gelişmedir. % 100 taşa ayarlanmadıkça bunları test edemezsiniz. Ve yapıldıktan sonra bir sistemi test etmek TDD değil, test etmek, ancak testlerle yapılan bir Geliştirme değil.

— Saldırı

2

Gerçek dünyadaki projelerin çoğunun başladığı zaman kesin özellikleri olduğunu düşünüyorsanız, muhtemelen pek çok gerçek dünya projesinde çalışmadınız.

— BlueRaja - Danny Pflughoeft 16:11 te