Чи життєздатна тестова розробка при розробці ігор?

23

Як сертифікований Scrum, я, як правило, схильний до методів Agile при розробці системи, і навіть використовую деякі полотна в рамках Scrum для управління моєю щоденною роботою.

Крім того, мені цікаво, чи TDD є варіантом у розробці ігор, якщо він життєздатний?

Якщо я вірю в це питання GD, TDD не дуже корисний для розробки ігор.
Чому MVC & TDD більше не використовуються в ігровій архітектурі?

Я походжу з індустріального програмування, де великі проекти з великими бюджетами повинні працювати бездоганно, оскільки це може призвести до катастрофічних сценаріїв, якби код не був перевірений всередині і зовні.

Плюс дотримання правил Scrum заохочує дотримуватись термінів вашої роботи, тоді як кожна дія в Scrum є вичерпною! Отже, я згоден, коли у вищезазначеному питанні вони кажуть припинити спроби побудови системи та почати писати гру. Цілком те, що каже Scrum, спершу намагайтеся не будувати досконалу систему: змусьте її працювати до кінця Sprint. Потім, переробляючи код під час роботи у другому спринті, якщо це потрібно!

Я розумію, що якщо не всі відділи, відповідальні за розробку гри, використовують Scrum, Scrum стає марним. Але давайте на хвилину подумаємо, що всі відділи використовують Scrum ... Я думаю, що TDD було б добре написати код без помилок, хоча ви не хочете писати "ідеальну" систему / гру.

Отже, моє запитання таке:

Чи TDD життєздатний в ході розробки ігор?

— Буде Маркуйлер
джерело

Що обговорення цього питання буде додавати поза тим питанням, яке ви зв'язали?

Я представляю рамки управління проектами Scrum в розробці програмного забезпечення Agile і стверджую, чого Scrum хоче від розробника під час спринту, отже, роблячи TDD життєздатним як варіант. Я хочу отримати точку зору інших на цю тему з точки зору Scrum, а не тільки в аспекті TDD або MVC. Я хочу зрозуміти, як TDD не життєздатний, коли сперечаються з цієї сторони медалі, за винятком того, щоб просто розглядати TDD як окремий підхід.

— Буде Маркуйлер

@Will TDD == Дизайн зверху вниз або тестовий дизайн? Я думав, що Top Down і збирався дати відповідь про керованість у довгостроковій перспективі, але потім побачив, що інша відповідь інтерпретував TDD так, як я не був ...

— Джеймс,

@James: Тестова розробка.

— хаос

@James: Вибачте за плутанину! Я не знав про інше значення абревіатури, оскільки мав на увазі Agile Software Development з Scrum.

— Буде Маркуйлер

11

Це, безумовно, життєздатне, хоча багато ігрових програмістів ще не дуже зрозуміли, чи добре розуміють, як перевірити складні системи. Я визнаю себе, що я його рідко використовую, за винятком систем, не пов'язаних з ігровими процесами, які легко перевірити.

Розраховуйте використовувати багато макетних об'єктів. Через те, як пов’язано багато систем, важко перевірити окремі компоненти цього.

Плюс багато речей не можуть бути ретельно перевірені. Як ви протестуєте, скажімо, систему частинок? Як ви перевіряєте, що ваша система анімації працює правильно? Багато речей мають візуальний характер, і не очевидно (принаймні для мене), як зробити належне тестування.

Однак є багато речей, які не обов'язково є одиничними тестами в традиційному розумінні цього слова, але це існує як "тести" на конкретні особливості. Такі речі, як тестові рівні для AI навігації, є досить поширеними, але не обов'язково є найпростішими речами для автоматизації.

Існують певні аспекти ігор, які можуть (і, ймовірно, повинні) писати для них одиничні тести. Будь-яка загальна система "читання файлів" повинна бути протестована. Можливо, є кілька тестів на ініціалізацію апаратних речей (3d поверхонь тощо). Можливо, є кілька глузуючих серверів і тестуйте код взаємодії клієнт / сервер. Такі речі.

— Тетрад
джерело

9

Це чудові пропозиції щодо автоматизованого тестування, але зовсім не для тестових розробок.

1

Цікава думка, Тетраде! Дякую за ваше зерно солі. Ви запитуєте, як протестувати візуальну анімацію? Важко сказати, що стосується 3D-систем, оскільки я ніколи ще не писав жодної гри, можливо, після того, як деякі розробили кілька крихітних ігор! Крім того, у 2D я часто бачив об'єкти, представлені матрицею та матричними аналізаторами для відображення зображення на екрані. Отже, переконавшись, що після певного натискання клавіші, потрібна інформація, знайдена в потрібному місці в отриманій матриці, може стати початком. Я просто ще не знаю достатньо про візуальні компоненти гри, і я впевнений, що цього року! =)

— Буде Маркуйлер

Я повернувся після кодування, щоб сказати, що на цьому тижні я відповів на запитання (моє перше в GD! =)), Яке вимагало знань про концепції OOP. OP хотів перемістити змію , на Keys.Down, Keys.Leftі т.д. Те , щоб сказати , що гра знає , де користувач хоче, щоб змія йти, і змія повинна йти туди , де гра говорить його, хоча це тільки змія , яка знає , як рухатися в різних напрямках, отже, і своє положення в грі. Розповівши про це, IMHO робить Snakeклас тестируемим! (Буде продовжено ...)

— Буде Маркуйлер

Він не тільки перевіряється, але тепер є гарним кандидатом на TDD. Скажімо, змія ініціалізується в положенні Vector2.Zero, зі швидкістю 10.0fпо осі X і Y в цій 2D грі. Перше питання: чи він розміщений у передбачуваному початковому положенні та як його перевірити? Тоді ви думаєте, що Positionмайно має бути відкрито. Друге: як змусити його рухатись? Методи руху повинні бути хорошими, так що ви пишете тест для кожного методу напрямки MoveDown, MoveLeftі так далі. Тепер перейдіть і напишіть свою декларацію про метод і подивіться, чи скаржиться тест. Потім підтвердіть позицію змії

— Will Marcouiller

після MoveDownвиклику методу! Оскільки ви знаєте, що Positionвластивість ретельно перевірено, це член, на який ви можете розраховувати! Ви можете здогадатися про продовження тут! ;-) Тобто, візуальні компоненти точно не можна перевірити, але змія повинна виглядати як змія, все залежно від того, яку змію ви хочете в грі. Художник, який малює змію, повинен довести достатню задоволеність своїм малюнком змії, що, звичайно, не перевіряється через TDD! Але його положення щодо інших об'єктів може, і клас, який представляє цю змію, теж. Насправді TDD

— Will Marcouiller

11

Я не думаю, що TDD як така є підходящою основою для розвитку ігор. Безперечно, автоматичне тестування блоків як частина методології, але занадто багато ключових проблем розвитку ігор є суб'єктивними та не піддаються машинному тестуванню, щоб тестувати, щоб бути рушієм розвитку. Як ви збираєтесь написати тест на сценарій, чи цікавий ігровий механік? Який рівень є візуально привабливим? Навіть на те, що рівень займає типового гравця близько 15 хвилин? TDD підходить для ситуацій, коли зрілість проекту можна кількісно виміряти з точки зору його відповідності специфікації, а це просто не є розвитком гри.

— хаос
джерело

3

Що ви маєте на увазі, коли говорите, що розробка ігор не відповідає специфікаціям? Моя думка, ви повинні знати, яку гру ви пишете, коли хочете написати її. Як такі, специфікації, вимоги повинні бути записані як ознаки або подібне; давайте візьмемо приклад "Блокування продукту" в Scrum. Ви знаєте історії користувачів, які вам доведеться розвивати у своїй грі, щоб ви писали очікувану гру! Тоді, для іншого прикладу, можливо, вам потрібно буде виявити зіткнення в бойовій грі, це перевірені речі! Незалежно від того, чи гра весела, це більше історія чи ніж програмування, IMHO.

— Буде Маркуйлер

@Will Marcouiller: Я не маю на увазі, що ми не маємо специфікацій або не можемо виміряти їх відповідність, але що менше того, що важливо про проект, може бути змістовно визначено, ніж в інших видах розробок. Ви можете записати "гра повинна бути веселою" у свою специфікацію, але це не специфікація з технічним значенням. Ви можете і повинні перевірити те, що можна перевірити, але суть TDD полягає в тому, що тестування - це не просто частина процесу, це вся основа процесу, фундаментальний менталітет, і я не бачу, що це добре працює з високо суб'єктивне поле.

— хаос

2

@Will Marcouiller, я дуже, дуже не погоджуюся, що задоволення від гри зводиться до історії. Вся забава в грі зводиться до ігрового процесу, історія - лише бонус.

— Атака

1

@Will: Ні, він говорить, що насолоду, яку користувач отримує від гри, не можна визначити за допомогою автоматизованого тесту, і що в іграх є велика кількість речей, які можна перевірити, лише відправивши гру в руки споживача.

— DeadMG

1

@DeadMG: Це правдивіше, ніж хто б хотів, але моя думка (не обов'язково AttackingHobo's) передбачає той факт, що сам процес розробки повинен включати тестування розробниками та виробниками, розробниками та тестерами, які не можна оцінити в одиниці тест, що стосується якості досвіду та почуття, стилю та естетичного ефекту, який створює гра. Сказати людям, що вони роблять TDD, коли це така важлива частина розвитку, в основному просто брехати їм.

— хаос

6

Зробити те, про що ви запитуєте, трохи складно, оскільки заголовок стосується лише TDD, але, здається, ви також робите Scrum невід’ємною частиною питання - і як я це розумію, іншого не вимагає.

Якщо я вірю в це питання GD, TDD не дуже корисний для розробки ігор.

Це правильно. Я не думаю, що я коли-небудь чув про це, що використовується на практиці в ігровій індустрії. (Але тоді я ніколи не чув, щоб його використовували і поза індустрією ігор - лише окремими особами.)

Я походжу з індустріального програмування, де великі проекти з великими бюджетами повинні працювати бездоганно, оскільки це може призвести до катастрофічних сценаріїв, якби код не був перевірений всередині і зовні.

Ігри не повинні працювати бездоганно. Тож набагато менше акцентів на правильності коду. TDD не гарантує правильність коду, але деякі люди вважають, що це зменшує некоректність. Я ще не бачу доказів цього.

Плюс дотримання правил Scrum заохочує дотримуватись термінів вашої роботи, тоді як кожна дія в Scrum є вичерпною!

Я ніколи не бачив методології, яка не заохочувала зустріти дати або проводити дії, які не були визначені часом. Проблема полягає в тому, що незалежно від методології, яку ви використовуєте, оцінка складності програмного забезпечення є досить важкою. Це не неможливо, але точно оцінити це не має великого відношення до процесу. Якщо моє завдання - додати нову панель GUI, або виправити помилку з анімацією, або додати нову статистику до символів, тоді використання Scrum зовсім не прискорить це, і використання TDD переходить уповільнити завдання (за можливої користі згодом зменшити подальші завдання з технічного обслуговування). Вони, звичайно, не збираються полегшити оцінку тривалості завдання.

Я думаю, що TDD було б добре написати код без помилок, хоча ви не хочете писати «ідеальну» систему / гру.

Якщо TDD доведено писати кращий код, ніж інші методи, то так.

Чи є докази цього? Те, що промисловість може використовувати це, не є доказом. Промисловість відома тим, що виробляє поганий код, який доставляється пізно. Відсутність прикладів великих проектів TDD, які провалилися чи запізнилися, може бути лише тому, що це новий підхід, і мало хто ще закінчив такий проект. (А ті, які працюють пізно ..., можливо, все ще працюють.)

Чи TDD життєздатний в ході розробки ігор?

Життєздатний? Звичайно. Вигідний? Це ще не доведено.

— Kylotan
джерело

1

На жаль, TDD та Scrum досі не зрозуміли. І це стосується вже існуючих проектів, які не допоможуть прискорити виправлення помилок або ще. Scrum - це основа для розробки складних систем, як виглядає гра. Scrum заохочує виправлення помилок із спринту до іншого, щоб вони ніколи не накопичувалися. TDD розміщує вас на стороні користувача. Під користувачем я маю на увазі колег-програмістів, які будуть використовувати ваш код. Це змушує задуматися, як його використовувати, щоб зробити свій код легким у використанні для інших. Отже, це призводить до кращого дизайну, за досвідом. Все сказане, у вас цікаві погляди на цю тему.

— Буде Маркуйлер

1

Примушування помилок не накопичуватися просто спричиняє ковзання функцій - ви не можете чарівно виробляти більше часу. Я розумію, що Scrum так чи інакше не має певного методу, характерного для помилок. Що стосується TDD, що змушує вас думати про те, як інші люди будуть використовувати ваш код, це не єдиний спосіб зробити це. Тому це не обов'язково краще, і, звичайно, не найефективніше використання часу.

— Килотан

1

FYI, Ноель Льопіс використовує TDD для своїх інді-ігор, а його стара компанія High Moon Studios широко використовувала його. Цитування не маю, вибачте.

— tenpn

У вас є кілька цікавих моментів, цікавих для читання! Дякуємо за ваш внесок. Тим не менш, я хотів би додати, що TDD - це ще один підхід, як і XP (екстремальне програмування). І так, Scrum не надає конкретного методу, характерного для помилок, а скоріше інвестує в самоорганізацію Команди (розробників). Scrum не говорить вам, як робити справи, він лише говорить, що потрібно зробити. Це зобов'язання Команди пройти все, що потрібно зробити. Scrum ставить лише на самоорганізовані міжфункціональні команди. Це команда, яка вирішує, як слід розробити та протестувати функції тощо

— Will Marcouiller

(продовження ...) Я відповів на своє перше запитання цього тижня про заняття тут, на GD. ОП хотіла дізнатись, як змусити його спрайт рухатися при натисканні клавіш. Будучи комфортним з концепціями OOP, я зрозумів, що, можливо, я повинен використовувати класи для розробки своєї першої гри за допомогою XNA. Однак, мій Spacecraftклас стає повністю перевіреним класом із методами та властивостями. Це такий тип речей, який абсолютно можна, IMHO, повністю перевірити за допомогою TDD. Скажімо, вам потрібен космічний корабель, тоді ви пишете тести на те, що вам потрібно для виконання одного тесту за один раз.

— Буде Маркуйлер

4

вибачте за мою погану англійську мову і вибачте за мою необ’єктивну точку зору: я не ігровий конструктор, а кодер.

Я думаю, що в цій дискусії є непорозуміння. я розповім про TDD в більш загальній формі, так званому BDD. Розвиток поведінки - це не спосіб перевірити проект (тести - це щось на зразок побічних ефектів). BDD - це спосіб проектування , спосіб робити рефактор та розробку програмного забезпечення протягом усього виробництва (див. Девізи, як KISS, "зберігай якість", "тестуй рано, тестуй часто"), а не в одній фазі. BDD - це протилежність класичному процесу програмного забезпечення, наприклад, процес водоспаду або інша ітеративна методологія виготовлення програмного забезпечення.

Ще один момент полягає в тому, що автоматичні тести - це ті функції, які можна було б перевірити автоматично за допомогою обчислювальної машини. немає тесту на розваги в іграх, і немає тесту на зручність використання графічного інтерфейсу користувача. розваги або зручність використання - це матеріали для інших робіт, а не для розробки програмного забезпечення, наприклад, дизайнера взаємодії, світу та рівня d. так само, як художні частини (моделювання, текстурування тощо) призначені для художника, який використовує комп’ютери як інструмент для творчості - очевидно, що ці завдання може виконувати та сама людина, яка пише код, але це не в тому. фізика може бути протестована, алгоритми оптимізації можуть бути протестовані, поведінка поодиноких об'єктів може бути протестована (з макетами, заглушками та манекеном, як згадувалося раніше)

Остання думка полягає в тому, що, імхо, полягає в тому, що не тільки ігровий дизайн, але і весь код написання - це мистецтво.

— нькінт
джерело

4

Ось тематичний приклад того, хто вважає, що TDD та gamedev досить добре поєднуються:

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

Справді, це невеликий проект у Pygame, але він дає уявлення про те, які частини можна перевірити за допомогою графічної гри, а які не можуть. Мене здивувало, скільки можна зробити з TDD за цим сценарієм.

— Брендон
джерело

1

Без порівняння з контрольною групою, яка зробила той самий проект (клонуйте існуючу тривіальну аркадну гру мовою дуже високого рівня), вона нічого не говорить про те, чи є TDD ефективним чи ні. Це просто говорить, що він використовував TDD.

3

Ні, розробка тестових програм не підходить для розробки ігор. Впевнені, що ви можете написати тести для деяких частин, які ви хочете протестувати, але процес розробки ігор повністю відрізняється від тестової керованої розробки, яка вимагає точних специфікацій, перш ніж почати прогрес.

Ігри рідко мають точні технічні характеристики при запуску. І якщо це відбувається, вони завжди змінюються і розвиваються в процесі розвитку.

Дизайн гри - це мистецтво, ви не можете провести конкретні тести, щоб знати, коли мистецтво добре чи завершено.

— Нападник Хобо
джерело

Ви не вважаєте, що фактором веселощів слід вважати те, що аналізується сама гра, функціональний аналіз тощо? Ви можете налаштувати набір функцій, які разом зроблять гру цікавою для гри, і ці функції потім перевіряються! Я лише намагаюся висловити різні думки вперед, щоб поглибити тему та аргументи, які ви придумуєте. Дякуємо за ваш внесок! =)

— Буде Маркуйлер

3

Багато розробок зводиться до налаштування дрібниць і бачення, як їм весело грати. Ви не можете перевірити ці речі, якщо вони не встановлені на камені на 100%. І тестування системи після її завершення - це не TDD, це тестування, але не розробка, яка керується тестуванням.

— Атака

2

Якщо ви думаєте, що більшість реальних проектів мають точні специфікації, коли вони починаються, то ви, мабуть, не працювали над багатьма реальними проектами.

— BlueRaja - Danny Pflughoeft