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

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

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

Итак, это чтение заставило меня задуматься, какие другие аспекты в тестировании программного обеспечения мы должны рассматривать как отличные или особенные, когда мы имеем дело с / тестированием игры? Кто-нибудь имеет опыт с этим или кто-то слышал что-то еще об этом?

Современные игры на самом деле представляют собой тонну креативного художественного контента, разработанного с использованием собственного или собственного игрового движка. Сам движок по большей части тестируется юнитами (рендеринг, геометрия, физика, AI-модули и т. Д.). Аналогично, простые тесты также могут быть прикреплены к отдельным частям разрабатываемого контента. Это означает, что тестирование юнитов и «белых ящиков» действительно осуществимо и успешно.

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

Добавьте к этому тот факт, что конечный вывод является чисто аудио-визуальным, и нет никакого детерминистического стандарта абсолютной правильности такого вывода. Чипы GPU действительно не должны выполнять точные вычисления, просто много вычислений, даже если некоторые не точны.

И, наконец, главная цель - Развлечения . Геймеры в порядке с глюками, если он работает на скорости более 60 FPS, выглядит потрясающе и имеет бесконечные часы развлекательного контента.

Это просто помещает традиционные идеи автоматического «черного ящика» в область «не так ощутимо и стоит» применительно к играм.

Тем не менее, в последнее время предпринимались попытки обучить NN играть в игры , что фактически является формой исследовательского самообучающегося обезьяньего тестирования.

Прошло много лет с тех пор, как я сделал gamedev, но помимо приятного ответа, есть некоторые вещи, которые я хочу добавить и детализировать.

Первое, что уже упоминалось, - это то, что выходные данные являются только визуальными и слуховыми, несмотря на жесткие «FPS-критические» ограничения и вычислительные / памяти бюджеты. Идеи правильности становятся расплывчатыми, когда вопросы больше похожи на: «Выглядит ли это хорошо? Работает ли он гладко, без заиканий? Звучит великолепно?» в то время как разработчики настраивают, настраивают и аппроксимируют, в то время как сотрудничество дизайнеров и разработчиков приводит к тому, что с каждой быстрой итерацией все выглядит и звучит несколько иначе.

Другое - тестеры могут быть потрясающими! Я никогда не находил более специализированную группу тестировщиков ни в одной другой области, так как они хотятпротестировать программное обеспечение. Они веселятся Они зависимы и спят рядом с компьютером, исследуя каждый закоулок вашей игры. Становится довольно легко обнаружить даже самые неясные сбои, когда люди на самом деле развлекаются, тщательно тестируя каждый уголок программного обеспечения, будучи практически зависимым от него. В моей нынешней отрасли с тестерами работать немного сложнее, поскольку многие из них являются профессионалами, связывающими свои средства к программному обеспечению, и поэтому они полагаются на несколько функций для выполнения своей работы и не обязательно заинтересованы в изнурении. каждый закоулок все время. Естественно, когда мы не можем так сильно полагаться на людей-тестировщиков, нам нужно больше автоматизированного тестирования.

Еще одно состоит в том, что кодовая база для игры обычно не поддерживается, не модифицируется и не расширяется годами. Не похоже, что разработчикам Super Mario, которые изначально разрабатывали его в сборке 6502, приходилось поддерживать что-то, похожее на этот оригинальный код, еще долго после того, как игра была выпущена. Doom 3, вероятно, использует ноль строк кода (или закрывает) из Doom 1. Если есть продолжающаяся франшиза, новые игры больше похожи на «продолжения», чем «обновления». Большинство игр просто поставляются и, возможно, выпускают некоторые патчи, DLC, а затем код готов. Это огромный контраст с моей индустрией VFX, где я работал над поддержкой кода, начиная с дней Amiga, которые портировались и поддерживались десятилетиями. Игры, как правило, не

Одна из причин этого недолговечного характера игровых кодовых баз заключается в том, что они так привязаны к аппаратному обеспечению. В сочетании с их ультрасовременным характером и критическими требованиями к FPS, они часто не могут быть разработаны таким образом, чтобы абстрагироваться от деталей оборудования, даже близко. Они часто написаны очень специально для целевого поколения оборудования, и обычно незадолго до этого PS3 заменяется PS4, который затем устаревает и заменяется PS5, и так далее, и все очень быстро. Аппаратные возможности играют такую ​​ключевую роль в дизайне и разработке игры, что, как правило, не стоит пытаться поддерживать большую часть того же кода, написанного для PSX, что и для PS4, например, большинство игровых франшиз, которые существуют в течение нескольких поколений, все еще пишут свои движки следующего поколения в основном с нуля для новейшего оборудования.

С короткоживущей кодовой базой приходит ограниченное время обслуживания (т. Е. Ограниченное время, в течение которого код должен быть модифицирован). С учетом ограниченного времени, необходимого для изменения кода, который не длится годами, когда объем движка с каждым обновлением увеличивается и увеличивается, а в сочетании с тем фактом, что игры не достигают критической важности, нет такой абсолютно Критически необходимо применить максимально исчерпывающее и комплексное тестирование. Это бесполезно для обеспечения целостности будущих изменений, если будущие изменения не будут сделаны, а аспект модульного тестирования и рефакторинга унаследованных кодовых баз, естественно, не имеет значения, если в первую очередь нет «унаследованного».

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

Тем не менее, интеграционное тестирование на самом высоком / самом грубом уровне имеет тенденцию быть более полезным. Например, во многих играх может использоваться способ записи того, как состояние игры меняется со временем для «повторов». Такие функции воспроизведения могут гарантировать, что игра является детерминированной, а также могут использоваться в качестве самостоятельной формы инструмента тестирования для воспроизведения игрового сеанса, записанного ранее кем-то другим.

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

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