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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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