Czy rozwój oparty na testach jest opłacalny przy tworzeniu gier?

23

Jako, że mam certyfikat Scrum, mam skłonność do metodologii Agile podczas opracowywania systemu, a nawet używam płótna z frameworka Scrum do zarządzania moją codzienną pracą.

Poza tym zastanawiam się, czy TDD jest opcją w rozwoju gier, czy jest opłacalna?

Jeśli wierzę w to pytanie GD, TDD nie ma większego zastosowania w tworzeniu gier.
Dlaczego MVC i TDD nie są częściej wykorzystywane w architekturze gier?

Pochodzę z programowania przemysłowego, w którym duże projekty o dużych budżetach muszą działać bezbłędnie, ponieważ mogłoby to doprowadzić do katastrofalnych scenariuszy, gdyby kod nie został dokładnie przetestowany wewnątrz i na zewnątrz.

Ponadto przestrzeganie zasad Scruma zachęca do dotrzymywania terminów pracy, podczas gdy każda akcja w Scrumie jest ograniczona czasowo! Zgadzam się więc, gdy w powyższym pytaniu mówią, aby przestać próbować zbudować system i zacząć pisać grę. Jest to, co mówi Scrum, staraj się nie budować idealnego systemu, po pierwsze: spraw, aby działał do końca Sprint. Następnie w razie potrzeby popraw kod podczas pracy w drugim sprincie!

Rozumiem, że jeśli nie wszystkie działy odpowiedzialne za rozwój gry korzystają ze Scrum, Scrum staje się bezużyteczny. Zastanówmy się jednak przez chwilę, że wszystkie działy używają Scruma ... Myślę, że TDD dobrze byłoby napisać kod bez błędów, choć nie chcesz pisać „idealnego” systemu / gry.

Więc moje pytanie jest następujące:

Czy TDD jest opłacalne w rozwoju gier?

— Will Marcouiller
źródło

Jaka dyskusja z tego pytania zostanie dodana poza pytaniem, które podłączyłeś?

Przedstawiam strukturę zarządzania projektami Scrum w rozwoju oprogramowania Agile i spieram się o to, czego Scrum chce od programisty podczas Sprint, dzięki czemu TDD jest opłacalny jako opcja. Chcę uzyskać punkt widzenia innych na ten temat z punktu widzenia Scruma, nie tylko w aspekcie TDD lub MVC. Chcę zrozumieć, w jaki sposób TDD nie jest wykonalne, gdy spiera się z tej strony medalu, poza tym, że samo TDD uważa się za samodzielne podejście.

— Will Marcouiller,

@Czy TDD == Projektowanie z góry na dół czy projektowanie oparte na testach? Myślałem o Top Down i zamierzałem udzielić odpowiedzi na temat zarządzania w perspektywie długoterminowej, ale potem zobaczyłem, że inna odpowiedź interpretuje TDD w sposób, w jaki nie byłem ...

— James

@James: Test Driven Development.

— chaos

@James: Przepraszamy za zamieszanie! Nie wiedziałem o innym znaczeniu akronimu, ponieważ miałem na myśli Agile Software Development ze Scrumem.

— Will Marcouiller,

11

Jest to z pewnością opłacalne, chociaż wielu programistów gier tak naprawdę nie przyłączyło się do tego pomysłu lub nie rozumie, jak testować skomplikowane systemy. Przyznaję, że rzadko go używam, z wyjątkiem łatwych do przetestowania systemów niezwiązanych z rozgrywką.

Spodziewaj się, że użyjesz wielu próbnych obiektów. Ze względu na to, jak wiele systemów jest ze sobą powiązanych, trudno jest przetestować ich poszczególne elementy.

Ponadto wielu rzeczy nie można dokładnie przetestować. Jak testujesz, powiedzmy, układ cząsteczkowy? Jak sprawdzasz, czy twój system animacji działa poprawnie? Wiele rzeczy ma charakter wizualny i nie jest oczywiste (przynajmniej dla mnie), jak wykonać odpowiednie testy.

Istnieje jednak wiele rzeczy, które niekoniecznie są testami jednostkowymi w tradycyjnym znaczeniu tego słowa, ale istnieją jako „testy” dla określonych funkcji. Rzeczy takie jak poziomy testowe dla nawigacji AI są dość powszechne, ale niekoniecznie są najłatwiejszymi do zautomatyzowania.

Istnieją pewne aspekty gier, które mogą (i prawdopodobnie powinny) mieć napisane dla nich testy jednostkowe. Należy przetestować każdy rodzaj ogólnego systemu „odczytu plików”. Może masz jakieś testy na inicjalizację sprzętu (powierzchnie 3D itp.). Może masz jakieś fałszywe serwery i przetestujesz kod interakcji klient / serwer. Rzeczy jak te.

— Tetrad
źródło

9

Są to świetne propozycje na obecność testów automatycznych, ale wcale nie wymagają programowania opartego na testach.

1

Ciekawa opinia, Tetrad! Dzięki za ziarno soli. Pytasz, jak przetestować animację wizualną? Trudno powiedzieć, jak w przypadku systemów 3D, ponieważ nigdy nie napisałem jeszcze żadnej gry, być może po opracowaniu kilku małych gier! Poza tym w 2D często widziałem obiekty reprezentowane przez macierz i parsery macierzy do renderowania obrazu na ekranie. Dlatego też upewnienie się, że po pewnym naciśnięciu klawisza kierunkowego, właściwa informacja znaleziona we właściwym miejscu w wynikowej macierzy może być początkiem, jak sądzę. Po prostu nie wiem jeszcze wystarczająco dużo o elementach wizualnych gry i na pewno to zrobię w tym roku! =)

— Czy Marcouiller

Wróciłem po kodowaniu, aby powiedzieć, że odpowiedziałem w tym tygodniu na pytanie (moje pierwsze na GD! =)), Które wymagało znajomości koncepcji OOP. PO chciała przenieść węża momencie Keys.Down, Keys.Leftitd To znaczy, że gra nie wie, gdzie użytkownik chce iść wąż i wąż musi iść gdzie gra informuje go, choć jest to tylko wąż, który wie, jak poruszać się w różnych kierunkach, stąd też jego pozycja w grze. Powiedziawszy to, IMHO sprawia, że Snakeklasa jest sprawdzalna! (

— Ciąg

Jest nie tylko testowalny, ale teraz jest dobrym kandydatem do TDD. Powiedzmy, że wąż jest inicjowany w pozycji Vector2.Zero, z prędkością 10.0fna osi X i Y w tej grze 2D. Pierwsze pytanie brzmi: czy jest ustawione w swojej domniemanej pozycji początkowej i jak to przetestować? Uważasz wtedy, że Positionnieruchomość zostanie publicznie wyeksponowana. Po drugie: jak to zrobić? Metody ruch powinien być dobry, więc można napisać test dla każdej metody kierunku MoveDown, MoveLefti tak dalej. Teraz idź i napisz deklarację metody i sprawdź, czy test narzeka. Następnie

— zrewiduj

po MoveDownwywołaniu metody! Ponieważ wiesz, że Positionnieruchomość jest dokładnie testowana, jest to członek, na który możesz liczyć! Tutaj możesz odgadnąć kontynuację! ;-) To znaczy, że elementów wizualnych zdecydowanie nie można przetestować, ale wąż powinien wyglądać jak wąż, wszystko w zależności od tego, jakiego węża chcesz w grze. Artysta rysujący węża powinien wykazać wystarczającą satysfakcję z rysowania węża, czego oczywiście nie należy testować za pomocą TDD! Ale jego pozycja względem innych obiektów może, a także klasa reprezentująca tego węża. W rzeczywistości TDD

— Will Marcouiller

11

Nie sądzę, aby TDD było odpowiednie jako podstawa do rozwoju gier. Zautomatyzowane testowanie jednostek jako część metodologii, oczywiście, ale zbyt wiele kluczowych problemów związanych z tworzeniem gier jest subiektywne i nie może być testowane maszynowo, aby testy były motorem rozwoju. Jak zamierzasz napisać skryptowy test sprawdzający, czy mechanika gry jest fajna? Czy poziom jest atrakcyjny wizualnie? Nawet czy ukończenie poziomu zajmuje typowemu graczowi około 15 minut? TDD pasuje do sytuacji, w których dojrzałość projektu można zmierzyć ilościowo pod względem zgodności ze specyfikacją, a to po prostu nie jest rozwój gry.

— chaos
źródło

3

Co masz na myśli mówiąc, że tworzenie gier nie jest zgodne ze specyfikacjami? Chodzi mi o to, że musisz wiedzieć, jaką grę piszesz, gdy chcesz ją napisać. Jako takie, specyfikacje, wymagania należy zapisać jako cechy lub tym podobne; weźmy przykład Backlogu Produktu w Scrumie. Znasz historie użytkowników, które będziesz musiał opracować w swojej grze, aby napisać oczekiwaną grę! Następnie, na przykład, być może będziesz musiał wykryć kolizje w grze walki, są to rzeczy do przetestowania! Niezależnie od tego, czy gra jest fajna, to więcej historii, niż programowania, IMHO.

— Will Marcouiller,

@Will Marcouiller: Nie chcę sugerować, że nie mamy specyfikacji lub nie możemy zmierzyć ich zgodności, ale że mniej tego, co ważne w projekcie, można znacznie sprecyzować niż w innych rodzajach rozwoju. Możesz napisać „gra powinna być fajna” w swojej specyfikacji, ale nie jest to specyfikacja o znaczeniu technicznym. Możesz i powinieneś przetestować to, co jest testowalne, ale TDD ma na celu to, że testowanie to nie tylko część procesu, to cała podstawa procesu, fundamentalne nastawienie, i nie widzę, żeby to jibingowało się dobrze subiektywne pole.

— chaos

2

@Will Marcouiller, ja bardzo, nie zgadzam się, że zabawa w grze sprowadza się do historii. Cała zabawa w grze sprowadza się do rozgrywki, fabuła to tylko bonus.

— AttackingHobo

1

@Will: Nie, mówi, że przyjemności, jaką użytkownik czerpie z gry, nie można określić za pomocą automatycznego testu i że gry zawierają duże ilości rzeczy, które można przetestować, wysyłając grę w ręce konsumenta.

— DeadMG

1

@DeadMG: To prawda, niż ktokolwiek by chciał, ale moja uwaga (niekoniecznie AttackingHobo) dotyczy faktu, że sam proces rozwoju musi obejmować testowanie przez projektantów i producentów oraz programistów i testerów, których nie da się określić ilościowo w jednostce test, który ma związek z jakością doświadczenia i dotyku oraz stylem i efektem estetycznym tworzonym przez grę. Powiedzieć ludziom, że robią TDD, gdy jest to tak ważna część rozwoju, to po prostu okłamać ich.

— chaos

6

Trudno jest dokładnie ustalić, o co pytasz, ponieważ tytuł dotyczy wyłącznie TDD, ale wydaje się, że Scrum stanowi integralną część pytania - i jak rozumiem, jedno nie wymaga drugiego.

Jeśli wierzę w to pytanie GD, TDD nie ma większego zastosowania w tworzeniu gier.

To jest poprawne. Nie sądzę, żebym kiedykolwiek słyszał o tym używanym w praktyce w branży gier. (Ale potem nigdy nie słyszałem o tym, że jest używany poza branżą gier - tylko przez osoby prywatne).

Pochodzę z programowania przemysłowego, w którym duże projekty o dużych budżetach muszą działać bezbłędnie, ponieważ mogłoby to doprowadzić do katastrofalnych scenariuszy, gdyby kod nie został dokładnie przetestowany wewnątrz i na zewnątrz.

Gry nie muszą działać bezbłędnie. Dlatego mniejszy nacisk kładziony jest na poprawność kodu. TDD nie gwarantuje poprawności kodu, ale niektórzy uważają, że zmniejsza to niepoprawność. Jeszcze nie widzę tego dowodu.

Ponadto przestrzeganie zasad Scruma zachęca do dotrzymywania terminów pracy, podczas gdy każda akcja w Scrumie jest ograniczona czasowo!

Nigdy nie widziałem metodologii, która nie zachęcałaby do terminów lub działań, które nie były ograniczone w czasie. Problem polega na tym, że bez względu na zastosowaną metodologię oszacowanie złożoności oprogramowania jest dość trudne. Nie jest to niemożliwe, ale dokładne oszacowanie nie ma wiele wspólnego z procesem. Jeśli moim zadaniem jest dodanie nowego panelu GUI lub naprawienie błędu animacji lub dodanie nowej statystyki do postaci, użycie Scruma wcale nie przyspieszy tego, a użycie TDD będzie spowolnić zadanie (z możliwą korzyścią późniejszego ograniczenia dalszych zadań konserwacyjnych). Z pewnością nie ułatwią oszacowania czasu trwania zadania.

Myślę, że TDD dobrze byłoby napisać kod wolny od błędów, choć nie chcesz pisać „idealnego” systemu / gry.

Jeśli udowodniono, że TDD pisze lepszy kod niż inne metody, to tak.

Czy jest na to dowód? Fakt, że przemysł może z niego skorzystać, nie jest dowodem. Przemysł jest dobrze znany z wytwarzania słabego kodu, który jest dostarczany z opóźnieniem. Brak przykładów dużych projektów TDD, które zawiodły lub się spóźniły, może wynikać z tego, że jest to nowe podejście i niewiele osób faktycznie zakończyło taki projekt. (A te, które spóźniają się ... mogą nadal działać.)

Czy TDD jest opłacalne w rozwoju gier?

Wykonalny? Oczywiście. Korzystny? To jeszcze nie zostało udowodnione.

— Kylotan
źródło

1

Niestety TDD i Scrum są nadal źle rozumiane. Dotyczy to istniejących projektów, które ani nie pomogą przyspieszyć naprawiania błędów. Scrum jest strukturą do tworzenia złożonych systemów, jak się wydaje na grę. Scrum zachęca do naprawy błędów między sprintem, aby nigdy się nie kumulowały. TDD stawia cię po stronie użytkownika. Przez użytkownika rozumiem kolegów programistów, którzy będą używać Twojego kodu. Zmusza Cię do zastanowienia się, jak należy go wykorzystać, aby ułatwić korzystanie z kodu innym osobom. W związku z tym prowadzi to do lepszego projektowania na doświadczenie. To powiedziawszy, masz ciekawe poglądy na ten temat.

— Will Marcouiller,

1

Zmuszanie do gromadzenia się błędów powoduje poślizg funkcji - nie można magicznie wydłużyć czasu. Rozumiem, że Scrum i tak nie ma żadnej konkretnej metody specyficznej dla błędów. Jeśli chodzi o TDD zmuszające do myślenia o tym, jak inne osoby będą używać Twojego kodu, nie jest to jedyny sposób, aby to zrobić. Dlatego niekoniecznie jest to lepsze, a na pewno niekoniecznie najbardziej efektywne wykorzystanie czasu.

— Kylotan

1

Do Twojej wiadomości, Noel Llopis używa TDD do swoich niezależnych gier, a jego stara firma High Moon Studios korzystała z niego w szerokim zakresie. Przepraszam, nie mam cytatu.

— tenpn

Masz kilka dobrych punktów do przeczytania! Dziękuję za Twój wkład. Niemniej jednak chciałbym dodać, że TDD to kolejne podejście, podobnie jak XP (programowanie ekstremalne). I tak, Scrum nie zapewnia żadnej konkretnej metody specyficznej dla błędów, a raczej inwestuje w samoorganizację Zespołu (programistów). Scrum nie mówi ci, jak to robić, mówi tylko, co należy zrobić. Zespół zobowiązuje się do przejścia przez to, co należy zrobić. Scrum stawia tylko na samoorganizujące się zespoły wielofunkcyjne. Zespół decyduje o tym, jak należy opracowywać i testować funkcje itp.

— Will Marcouiller,

(kontynuuj ...) W tym tygodniu odpowiedziałem na moje pierwsze pytanie dotyczące zajęć na GD. OP chciał dowiedzieć się, jak sprawić, by jego duszek poruszał się po naciskaniu klawiszy kierunkowych. Czując się dobrze z koncepcjami OOP, doszedłem do wniosku, że być może powinienem wykorzystać klasy do opracowania mojej pierwszej gry przy użyciu XNA. To powiedziawszy, moja Spacecraftklasa staje się w pełni testowalną klasą z metodami i właściwościami. Tego rodzaju rzeczy absolutnie można, IMHO, w pełni przetestować przy użyciu TDD. Powiedzmy, że potrzebujesz statku kosmicznego, a następnie piszesz testy tego, czego potrzebujesz, aby wykonać jeden test na raz.

— Will Marcouiller,

4

przepraszam za mój słaby angielski i przepraszam za mój stronniczy punkt widzenia: nie jestem projektantem gier, ale programistą.

Myślę, że w tej dyskusji są pewne nieporozumienia. porozmawiam o TDD w bardziej ogólnej formie, tzw. BDD. Rozwój oparty na zachowaniach nie jest sposobem testowania projektu (testy są czymś w rodzaju efektów ubocznych). BDD to sposób na projektowanie , sposób na refaktoryzację i projektowanie oprogramowania podczas całej produkcji (patrz niektóre motta jako KISS, „zachowaj jakość”, „testuj wcześnie, testuj często”), a nie w pojedynczej fazie. BDD jest przeciwieństwem klasycznego procesu oprogramowania, takiego jak proces kaskadowy lub inna iteracyjna metodologia tworzenia oprogramowania.

Inną kwestią jest to, że testy automatyczne dotyczą funkcji, które mogą być testowane automatycznie przez maszynę obliczeniową. nie ma testu zabawy w grach i nie ma testu użyteczności graficznego interfejsu użytkownika. zabawa lub użyteczność to materiały do innych zadań, a nie do tworzenia oprogramowania, takich jak projektant interakcji, świat i poziom d. w ten sam sposób, w jaki części artystyczne (modelowanie, teksturowanie itp.) są przeznaczone dla artystów, którzy używają komputerów jako narzędzia kreatywności - oczywiście te prace mogą być wykonywane przez tę samą osobę, która pisze kod, ale nie o to chodzi. fizyka może być testowana, algorytmy optymalizacji mogą być testowane, pojedyncze zachowania obiektów mogą być testowane (z próbkami, skrótami i manekinami, jak wspomniano wcześniej)

ostatnia myśl jest taka, że imho to nie tylko projektowanie gier, ale cały pisanie kodu to sztuka.

— nkint
źródło

4

Oto studium przypadku kogoś, kto uważa, że TDD i gamedev całkiem dobrze się mieszają:

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

Wprawdzie jest to niewielki projekt w Pygame, ale daje wyobrażenie, które części można przetestować za pomocą gry graficznej, a które nie. Byłem zaskoczony, jak wiele można zrobić z TDD w tym scenariuszu.

— Brandon
źródło

1

Bez porównania z grupą kontrolną, która wykonała ten sam projekt (sklonowała istniejącą trywialną grę zręcznościową w języku bardzo wysokiego poziomu), nie mówi nic o tym, czy TDD jest skuteczne, czy nie. Mówi tylko, że użył TDD.

3

Nie, programowanie oparte na testach nie nadaje się do tworzenia gier. Na pewno możesz napisać testy dla części, które chcesz przetestować, ale proces tworzenia gry jest zupełnie inny niż testowanie oparte na testach, które wymaga dokładnych specyfikacji przed rozpoczęciem postępu.

Gry rzadko mają dokładną specyfikację po uruchomieniu. A jeśli tak, zawsze zmieniają się i ewoluują podczas procesu rozwoju.

Projektowanie gier jest sztuką, nie możesz mieć konkretnych testów, aby wiedzieć, kiedy sztuka jest dobra lub kompletna.

— AttackingHobo
źródło

Czy nie uważasz, że przy analizie samej gry, analizie funkcjonalnej itp. Należy brać pod uwagę czynnik zabawy? Możesz ustawić zestaw funkcji, które razem sprawią, że gra będzie przyjemna, a te funkcje będą testowalne! Staram się tylko przedstawić różne opinie, aby pogłębić temat i argumenty, które wysunąłeś. Dziękuję za Twój wkład! =)

— Czy Marcouiller

3

Dużo rozwoju sprowadza się do ulepszania drobiazgów i sprawdzania, jak dobrze się bawią. Nie możesz przetestować tych rzeczy, chyba że są w 100% osadzone w kamieniu. A testowanie systemu po jego zakończeniu nie jest TDD, jest testowaniem, ale nie Programowaniem opartym na testowaniu.

— AttackingHobo

2

Jeśli uważasz, że większość rzeczywistych projektów ma dokładne specyfikacje na początku, prawdopodobnie nie pracowałaś nad wieloma rzeczywistymi projektami.

— BlueRaja - Danny Pflughoeft