My<cod/>.net
Автоматизированное тестирование игры
Вопрос
Как бы вы добавили автоматическое тестирование в игру?
Я считаю, что вы можете юнит-тестировать многие функции игрового движка (сеть, создание объектов, управление памятью и т. д.), Но можно ли автоматизировать тестирование самой игры?
Я не говорю об элементах геймплея (например, Протоссы победили бы зергов на карте X), но я говорю о взаимодействии между игрой и движком.
Вступление
В разработке игр движок - это просто платформа для игры. Вы можете представить себе игровой движок как OS, а игру как программное обеспечение, которое будет работать OS. Игра может быть набором скриптов или реальной подпрограммой внутри игрового движка.
варианта ответа
Моя идея заключается в следующем:
Вам понадобится детерминированный двигатель. Это означает, что при наличии одного набора входных данных выход будет точно таким же. Это означало бы, что генератор случайных чисел будет засеян тем же самым входом.
Затем создайте голый уровень, который содержит несколько объектов, с которыми аватар/пользователь может взаимодействовать. Начните с малого, а затем добавляйте объекты на уровень по мере развития новых взаимодействий.
Создайте сценарий, который следует по пути (тестирует поиск путей) и взаимодействует с различными объектами (сохраняет результат или ожидаемое поведение). Этот сценарий будет вашим автоматическим тестом. Через некоторое время (скажем, через неделю) запустите скрипт вместе с модульными тестами вашего движка.
Значения настолько случайны в рамках игровых аспектов развития, что было бы надуманной идеей проверить абсолютные значения
Значения настолько случайны в рамках игровых аспектов развития, что было бы надуманной идеей проверить абсолютные значения
Но мы можем проверить детерминированные значения. Например, модульный тест может заставить Гайбруша Трипвуда двигаться к двери (поиск пути), открыть дверь (команда use), потерпеть неудачу, потому что у него нет ключа в инвентаре (обратная связь), выбрать ключ двери (поиск пути + управление запасами) и затем, наконец, открыть дверь.
Все эти пути детерминированы. С помощью этого модульного теста я могу рефакторировать диспетчер памяти, и если он каким-то образом нарушит рутину управления запасами, модульный тест завершится неудачей.
Это всего лишь одна идея для юнит-тестирования в играх. Я хотел бы знать другие идеи, следовательно, мотивацию для этого поста.
Однажды я сделал нечто подобное вашей идее, и это было очень успешно, хотя я подозреваю, что это скорее системный тест, чем модульный тест. Как вы предлагаете, ваш генератор случайных чисел должен быть заполнен одним и тем же значением и каждый раз должен производить идентичную последовательность. Игра шла на 50-ти циклах, так что выбор времени не был проблемой. У меня была система, которая записывала щелчки мыши и местоположение, и использовала ее для ручного создания 'script', который можно было воспроизвести, чтобы получить те же результаты. Удалив временные задержки и отключив графическую генерацию, можно было за несколько секунд воспроизвести час игрового процесса. Самая большая проблема заключалась в том, что изменения в игровом дизайне сделали бы сценарий недействительным.
Если ваша комната с голыми костями содержит логику, которая не зависит от общей игры, то она может работать очень хорошо. Движок может запуститься без какого-либо пользовательского интерфейса и запустить скрипт сразу после завершения инициализации. Тестирование на сбой по пути было бы простым, но более сложные тесты, такие как оставление символов в правильных позициях, были бы более сложными. Если запись скриптов достаточно проста, как это было в моей системе, то их можно очень легко обновить, а специальные скрипты для тестирования специализированного поведения можно настроить очень быстро. Моя система имела дополнительное преимущество, что ее можно было использовать во время тестирования игры, а также точную последовательность событий, записанных для облегчения исправления ошибок.
Riot Games имеет статью об использовании автоматизированного тестирования для League of Legends (LoL), многопользовательской онлайн-игры RTS.
По словам разработчиков, каждый день происходит много изменений как в игровом коде, так и в игровом балансе. Они построили тестовый фреймворк Python, который в основном является более простым игровым клиентом, который отправляет команды на сервер непрерывной интеграции, на котором работает экземпляр игрового сервера LoL. Затем сервер отправляет тестовой платформе результат выполнения команды, позволяя протестировать ответ.
Платформа предоставляет очередь событий, которая записывает события, данные и эффект с определенного момента времени. В статье это называется a "snapshot".
В статье описан пример unittest для заклинания:
Установка
1. Дайте персонажу такую возможность.
2. Создайте вражеского персонажа в мидлейне (локация на карте).
3. Породить ползучего в средней полосе. (В контексте LoL крипы-это слабые неконтролируемые персонажи, которые являются частью армии каждой команды. Они в основном являются каноническим кормом и источником опыта и золота для вражеской команды. Но если их не остановить, они могут сокрушить команду противника)
4. Телепортируйте персонажа на среднюю планету.
Выполнять
1. Сделайте снимок всех переменных (например, текущей жизни игрока, врага и обычных персонажей).
2. Произнесите заклинание.
3. Активируйте эффекты заклинания (например, есть некоторые заклинания, которые будут действовать при попадании) на вражеском персонаже.
4. Сбросьте время перезарядки заклинания, чтобы его можно было немедленно разыграть снова.
5. Произнесите заклинание.
6. Активируйте эффекты заклинания на ползучести (в контексте LoL большинство заклинаний имеют разные вычисления при использовании на ползучести).
7. Сделайте еще один снимок.
Проверить
Начиная с первого снимка, повторите события и подтвердите, что ожидаемые результаты (с точки зрения геймдизайнера) верны. Примеры событий, которые можно проверить: урон находится в пределах урона заклинания (LoL использует случайные числа, чтобы дать дисперсию атакам), урон правильно сопротивляется при сравнении с персонажем игрока и ползучестью, а заклинания разыгрываются в пределах его эффективного диапазона.
В статье показано, что видео теста может быть извлечено при просмотре тестового сервера из обычного игрового клиента.
http://flea.sourceforge.net/gameTestServer.pdf
Это интересная дискуссия о реализации полномасштабного функционального тестера в игре.
Термин "unit testing" подразумевает, что тестируется a "unit". Это одно дело. Если вы проводите тестирование более высокого уровня (например, сразу нескольких систем), обычно это называется функциональным тестированием. Можно провести юнит-тест большей части игры, однако вы не можете действительно тестировать для удовольствия.
Детерминизм не нужен, пока ваши тесты могут быть нечеткими. E.g. "did the character get hurt" в отличие от "потерял ли персонаж 14.7 хитпоинтов.
Если вы тестируете механизм рендеринга, я думаю, что вы можете отрисовывать определенные тестовые сцены, делать снимки экрана и сравнивать их с эталонными тестовыми рендерами. Таким образом, вы можете визуально обнаружить, если изменения в двигателе что-то нарушают. Вы можете написать аналогичный тест для звукового движка или даже анимации (сравнивая серию кадров).
Если вы хотите проверить логику игры или прогресс сцены, вы можете сделать это, Протестировав различные условия на переменных сценариев (предполагая, что вы используете сценарии для реализации большинства аспектов сцены и истории).
Если вы используете XNA (идея, конечно, может быть экстраполирована на другие фреймворки), вы можете использовать фреймворк внутриигрового юнит-теста, который позволяет вам получить доступ к состоянию игры в юнит-тесте. Одним из таких фреймворков является Scurvy.Test :-)
Это не совсем ответ на ваш вопрос, но я слушал подкаст на Pex от microsoft , который делает аналогичную вещь с решением, которое вы предлагаете, и когда я слушал его, я помню, что подумал, что было бы действительно интересно посмотреть, сможет ли он тестировать игры. Я не знаю, сможет ли это помочь вам конкретно, но, возможно, вы могли бы взглянуть на некоторые из идей, которые они используют, и применить их к вашему модульному тестированию.