Является ли Test Driven Development жизнеспособным в разработке игр?

23

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

Кроме того, мне интересно, является ли TDD вариантом в разработке игр, если он жизнеспособен?

Если я верю этому вопросу GD, TDD не очень полезен в разработке игр.
Почему MVC & TDD больше не используются в игровой архитектуре?

Я пришел из промышленного программирования, где большие проекты с большими бюджетами должны работать безупречно, так как это может привести к катастрофическим сценариям, если код не был тщательно протестирован изнутри и снаружи.

Кроме того, соблюдение правил Scrum поощряет соблюдение сроков вашей работы, в то время как каждое действие в Scrum ограничено по времени! Итак, я согласен, когда в вопросе, связанном выше, они говорят, чтобы прекратить попытки построить систему и начать писать игру. Это вполне то, что говорит Scrum, постарайтесь сначала не создавать идеальную систему: заставить ее работать до конца Sprint. Затем, при необходимости, проведите рефакторинг кода во время работы во втором Sprint!

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

Итак, мой вопрос заключается в следующем:

В любом случае, является ли TDD жизнеспособным в разработке игр?

— Уилл Маркуиллер
источник

Что обсуждение этого вопроса добавит к тому, что вы связали?

Я представляю Scrum-инфраструктуру управления проектами в Agile-разработке программного обеспечения и рассуждаю о том, чего Scrum хочет от разработчика во время Sprint, и, следовательно, делает TDD жизнеспособным в качестве опции. Я хочу получить точку зрения других на эту тему с точки зрения Scrum, а не только с точки зрения TDD или MVC. Я хочу понять, как TDD нежизнеспособен, когда его аргументируют с этой стороны медали, кроме как просто рассматривать само TDD как самостоятельный подход.

— Уилл Маркуиллер

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

— Джеймс

@James: разработка через тестирование.

— хаос

@James: Простите за путаницу! Я не знал о другом значении аббревиатуры, так как имел в виду Agile Software Development со Scrum.

— Уилл Маркуиллер

11

Это, безусловно, жизнеспособно, хотя многие программисты игр еще не поняли эту идею и не понимают, как тестировать сложные системы. Я признаю себя, что использую его редко, за исключением систем, не связанных с геймплеем, которые легко тестировать.

Ожидайте использовать много фиктивных объектов. Из-за того, как много систем связаны между собой, сложно протестировать отдельные компоненты этого.

Плюс многое не может быть тщательно проверено. Как вы тест-драйв, скажем, системы частиц? Как вы проверяете, что ваша система анимации работает правильно? Многие вещи носят визуальный характер и не являются очевидными (по крайней мере, для меня) относительно того, как проводить надлежащее тестирование.

Однако есть много вещей, которые не обязательно являются модульными тестами в традиционном смысле этого слова, но существуют как «тесты» для определенных функций. Такие вещи, как тестовые уровни для навигации по ИИ, довольно распространены, но это не обязательно самые простые вещи для автоматизации.

Существуют определенные аспекты игр, которые могут (и, вероятно, должны) иметь написанные для них модульные тесты. Любая общая система «чтения файлов» должна быть протестирована. Может быть, есть некоторые тесты для инициализации аппаратных вещей (3D-поверхности и т. Д.). Возможно, имейте некоторые фиктивные серверы и протестируйте ваш код взаимодействия клиент / сервер. Такие вещи.

— тетрада
источник

9

Это отличные предложения для наличия автоматизированного тестирования, но совсем не для разработки, основанной на тестировании.

1

Интересное мнение, тетрадь! Спасибо за ваше зерно соли. Вы спрашиваете, как проверить визуальную анимацию? Трудно сказать, что касается 3D-систем, так как я еще никогда не писал ни одной игры, возможно, после того, как некоторые разработали несколько крошечных игр! Кроме того, в 2D я часто видел объекты, представленные матрицей, и матричные парсеры для рендеринга изображения на экране. Следовательно, я уверен, что после некоторого нажатия клавиш направления правильная информация, найденная в нужном месте в результирующей матрице, может быть началом. Я просто еще недостаточно знаю о визуальных компонентах игры, и я уверен, что в этом году! =)

— Уилл Маркуиллер

Я вернулся после некоторого кодирования, чтобы сказать, что я ответил на вопрос на этой неделе (мой первый на GD! =)), Который требовал знания концепций ООП. OP хотел переместить змею , на Keys.Down, Keys.Leftи т.д. То , чтобы сказать , что игра знает , где пользователь хочет, чтобы змея идти, и змея должна идти туда , где игра говорит его, хотя это только змея , которая знает , как двигаться в разных направлениях, следовательно, также его положение в игре. Сказав это, ИМХО, делает Snakeкласс тестируемым! (Продолжение следует ...)

— Уилл Маркуиллер

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

— Уилл Маркуиллер

после MoveDownвызова метода! Так как вы знаете, что Positionнедвижимость тщательно проверена, вы можете рассчитывать на это! Вы можете угадать продолжение здесь! ;-) То есть визуальные компоненты определенно не могут быть протестированы, но змея должна выглядеть как змея, все в зависимости от того, какую змею вы хотите в игре. Художник, рисующий змею, должен быть достаточно удовлетворен ее / ее рисунком змеи, что, конечно, не должно быть проверено с помощью TDD! Но его положение относительно других объектов может и класса, представляющего эту змею, тоже. На самом деле, TDD

— Уилл Маркуиллер

11

Я не думаю, что TDD как таковой уместен в качестве основы для разработки игр. Конечно, автоматическое модульное тестирование является частью методологии, но слишком многие ключевые проблемы разработки игр носят субъективный характер и не подлежат машинному тестированию для тестирования, чтобы быть движущей силой разработки. Как вы собираетесь написать скриптовый тест на то, является ли игровой механик забавным? Что за уровень визуально привлекательный? Даже если для прохождения уровня у типичного игрока требуется около 15 минут? TDD подходит для ситуаций, когда зрелость проекта может быть количественно измерена с точки зрения его соответствия спецификации, и это просто не разработка игры.

— хаос
источник

3

Что вы имеете в виду, когда говорите, что разработка игр не соответствует спецификациям? Я хочу сказать, что вы должны знать, какую игру вы пишете, когда хотите ее написать. Как таковые, спецификации, требования должны быть написаны как функции или тому подобное; давайте возьмем пример продукта Backlog в Scrum. Вы знаете пользовательские истории, которые вам придется разрабатывать в своей игре, чтобы написать ожидаемую игру! Тогда, для другого примера, вам, возможно, потребуется обнаружить столкновения в файтинге, это проверяемые вещи! ИМХО, будет ли игра увлекательной - это скорее история или программирование.

— Уилл Маркуиллер

@Will Marcouiller: Я не имею в виду, что у нас нет спецификаций или мы не можем измерить их соответствие, но что менее важно то, что важно в проекте, можно указать более содержательно, чем в других видах разработки. Вы можете написать «игра должна быть веселой» в вашей спецификации, но это не спецификация с техническим смыслом. Вы можете и должны тестировать то, что можно тестировать, но смысл TDD в том, что тестирование - это не просто часть процесса, это вся основа процесса, фундаментальный настрой, и я не вижу, чтобы это хорошо сочеталось с субъективное поле.

— хаос

2

@ Уилл Маркуиллер, я совершенно не согласен с тем, что удовольствие от игры сводится к истории. Все веселье в игре сводится к игровому процессу, история - это просто бонус.

— AttackingHobo

1

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

— DeadMG

1

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

— хаос

6

Немного сложно понять, что именно вы спрашиваете, поскольку заголовок посвящен исключительно TDD, но вы, кажется, делаете Scrum неотъемлемой частью вопроса - и, насколько я понимаю, один не требует другого.

Если я верю этому вопросу GD, TDD не очень полезен в разработке игр.

Это правильно. Я не думаю, что когда-либо слышал об этом на практике в игровой индустрии. (Но тогда я никогда не слышал об этом, используемом вне игровой индустрии - просто частными лицами.)

Я пришел из промышленного программирования, где большие проекты с большими бюджетами должны работать безупречно, так как это может привести к катастрофическим сценариям, если код не был тщательно протестирован изнутри и снаружи.

Игры не должны работать без нареканий. Так что правильности кода гораздо меньше. TDD не гарантирует правильность кода, но некоторые люди считают, что это уменьшает неправильность кода. Я еще не видел доказательств этого.

Кроме того, соблюдение правил Scrum поощряет соблюдение сроков вашей работы, в то время как каждое действие в Scrum ограничено по времени!

Я никогда не видел методологию, которая не поощряла бы соблюдение сроков или действий, которые не были бы ограничены по времени. Проблема в том, что независимо от того, какую методологию вы используете, оценить сложность программного обеспечения довольно сложно. Это не невозможно, но точная оценка не имеет ничего общего с процессом. Если моя задача состоит в том, чтобы добавить новую панель графического интерфейса пользователя, или исправить ошибку с анимацией, или добавить новую статистику для персонажей, то использование Scrum совсем не ускорит это, и использование TDD будет происходить замедлить выполнение задачи (при возможном выигрыше от сокращения дополнительных задач по обслуживанию позже). Они, конечно, не помогут оценить продолжительность задачи.

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

Если доказано, что TDD пишет лучший код, чем другие методы, тогда да.

Есть ли доказательства этого? Тот факт, что промышленность может использовать его, не является доказательством. Промышленность хорошо известна производством плохого кода, который доставляется поздно. Отсутствие примеров крупных проектов TDD, которые потерпели неудачу или запустились с опозданием, может быть просто потому, что это новый подход, и мало кто фактически закончил такой проект. (А те, которые опаздывают ... могут все еще бежать.)

В любом случае, является ли TDD жизнеспособным в разработке игр?

Жизнеспособное? Конечно. Выгодно? Это еще предстоит доказать.

— Kylotan
источник

1

К сожалению, TDD и Scrum все еще не поняты. И это верно для существующих проектов, которые не помогут ускорить исправление ошибок или что-либо еще. Scrum - это основа для разработки сложных систем, как кажется в игре. Scrum поощряет исправление ошибок от Sprint к другому, чтобы они никогда не накапливались. TDD разместит вас на стороне пользователя. Под пользователем я подразумеваю коллег-программистов, которые будут использовать ваш код. Это заставляет вас задуматься о том, как его использовать, чтобы сделать ваш код простым в использовании для других. Следовательно, это приводит к лучшему дизайну, за опыт. Тем не менее, вы получили интересные взгляды на эту тему.

— Уилл Маркуиллер

1

Принуждение к ошибкам не накапливать просто приводит к сбою функций - вы не можете волшебным образом тратить больше времени. Насколько я понимаю, в Scrum нет какого-либо конкретного метода, специфичного для ошибок. Что касается TDD, заставляющего вас думать о том, как другие люди будут использовать ваш код, это не единственный способ сделать это. Поэтому это не обязательно лучше, и, конечно, не обязательно самое эффективное использование времени.

— Kylotan

1

К вашему сведению, Ноэль Ллопис использует TDD для своих инди-игр, и его старая компания High Moon Studios широко его использует. У меня нет цитаты, извините.

— 10

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

— Уилл Маркуиллер,

(продолжить ...) Я ответил на мой первый вопрос на этой неделе о занятиях здесь на GD. ОП хотел узнать, как заставить свой спрайт перемещаться при нажатии клавиш. Освоив концепции ООП, я понял, что, возможно, мне следует использовать классы для разработки моей первой игры с использованием XNA. Тем не менее, мой Spacecraftкласс становится полностью тестируемым классом с методами и свойствами. Это тот тип вещей, который, IMHO, может быть полностью протестирован с использованием TDD. Допустим, вам нужен космический корабль, а затем вы пишете тесты для того, что вам нужно для выполнения одного теста за раз.

— Уилл Маркуиллер

4

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

Я думаю, что есть некоторые недоразумения в этой дискуссии. я буду говорить о TDD в более общем виде, так называемый BDD. Разработка, основанная на поведении, не является способом тестирования проекта (тесты - это что-то вроде побочных эффектов). BDD - это способ дизайна , способ создания рефакторинга и разработки программного обеспечения на протяжении всего производства (см. Некоторые девизы, такие как «KISS», «держать качество в», «тестировать заранее, часто тестировать»), а не в одиночной фазе. BDD является противоположностью некоторого классического программного процесса, такого как процесс водопада, или некоторой другой итерационной методологии создания программного обеспечения.

Другое дело, что автоматические тесты предназначены для тех функций, которые могут быть автоматически протестированы вычислительной машиной. в играх нет теста на забаву, и нет теста на удобство использования графического интерфейса пользователя. Веселье или удобство использования - это материалы для других работ, а не для разработки программного обеспечения, такие как дизайнер взаимодействия, мир и уровень d. Точно так же, как художественные элементы (моделирование, текстурирование и т. д.) предназначены для художника, который использует компьютеры в качестве инструмента для творчества - очевидно, что эти работы могут выполняться тем же человеком, который пишет код, но это не главное. физика может быть проверена, алгоритмы оптимизации могут быть проверены, поведение отдельных объектов может быть проверено (с макетами, заглушками и пустышками, как упоминалось ранее)

последнее, что я думаю, это то, что не только игровой дизайн, но и весь код написания - это искусство.

— nkint
источник

4

Вот пример того, кто считает, что TDD и gamedev хорошо сочетаются:

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

Следует признать, что это небольшой проект в Pygame, но он дает представление о том, какие части можно протестировать в графической игре, а какие нет. Я был удивлен тем, как много можно сделать с TDD в этом сценарии.

— Brandon
источник

1

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

3

Нет, Test Driven Development не подходит для разработки игр. Конечно, вы можете написать тесты для некоторых частей, которые вы хотите протестировать, но процесс разработки игр полностью отличается от разработки, основанной на тестировании, которая требует точных спецификаций до начала процесса.

Игры редко имеют точные спецификации при запуске. И если они это делают, они всегда меняются и развиваются в процессе разработки.

Гейм-дизайн - это искусство, у вас не может быть конкретных тестов, чтобы знать, когда искусство хорошо или полно.

— AttackingHobo
источник

Не думаете ли вы, что этот весёлый фактор следует учитывать при анализе самой игры, функциональном анализе или тому подобном? Вы можете настроить набор функций, которые вместе сделают игру увлекательной, и эти функции станут тестируемыми! Я только пытаюсь выдвинуть различные мнения, чтобы углубиться в тему и аргументы, которые вы приводите. Спасибо за ваш вклад! =)

— Уилл Маркуиллер

3

Большая часть разработки сводится к настройке мелких вещей и просмотру, как весело играть. Вы не можете проверить эти вещи, если они не на 100% установлены в камне. И тестирование системы после того, как это сделано, - это не TDD, это тестирование, но не разработка, которая определяется тестированием.

— AttackingHobo

2

Если вы думаете, что большинство реальных проектов имеют точные спецификации при запуске, то вы, вероятно, не работали над многими реальными проектами.

— BlueRaja - Дэнни Пфлугхофт