Автоматизированное тестирование игры

Вопрос

Как бы вы добавили в игру автоматическое тестирование?

Я считаю, что вы можете провести модульное тестирование многих функций игрового движка (сеть, создание объектов, управление памятью и т. Д.), Но можно ли автоматизировать тестирование самой игры?

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

Вступление

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

Возможные ответы

Моя идея такая:

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

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

Создайте сценарий, который следует по пути (проверяет поиск пути) и взаимодействует с различными объектами (сохраняет результат или ожидаемое поведение). Этот сценарий будет вашим автоматическим тестом. По прошествии определенного времени (скажем, одной недели) запустите сценарий вместе с модульными тестами вашего движка.

Ответов (10)

В Riot Games есть статья об использовании автоматического тестирования для League of Legends (LoL), многопользовательской онлайн-игры RTS.

По словам разработчиков, каждый день происходит множество изменений как в коде игры, так и в игровом балансе. Они создали тестовую среду Python, которая по сути является более простым игровым клиентом, который отправляет команды на сервер непрерывной интеграции, на котором запущен экземпляр игрового сервера LoL. Затем сервер отправляет тестовой среде результат команды, позволяя протестировать ответ.

Платформа предоставляет очередь событий, в которой записываются события, данные и эффект с определенного момента времени. В статье это называется «снимок».

В статье описан пример юниттеста для заклинания:


Подготовка
1. Дайте персонажу способность.
2. Создайте вражеского персонажа на средней полосе (место на карте).
3. Создайте крипа на средней линии. (В контексте LoL крипы - это слабые неконтролируемые персонажи, которые являются частью армии каждой команды. Они в основном являются каноническим кормом и источником опыта и золота для вражеской команды. Но если их не остановить, они могут сокрушить противника. team) 4. Телепортируйте персонажа на мидлейн.

Выполнить
1. Сделайте снимок всех переменных (например, текущую жизнь игрока, врага и обычных персонажей).
2. Сотвори заклинание.
3. Активируйте эффекты заклинания (например, некоторые заклинания срабатывают при попадании) на вражеского персонажа.
4. Сбросьте время восстановления заклинания, чтобы его можно было немедленно применить снова.
5. Сотвори заклинание.
6. Активируйте эффекты заклинания на крипа (в контексте LoL, большинство заклинаний имеют другие вычисления при использовании на крипах). 7. Сделайте еще один снимок.

Проверка.
Начиная с первого снимка, воспроизведите события и убедитесь , что ожидаемые результаты (с точки зрения разработчика игры) верны. Примеры событий, которые могут быть проверены: Урон находится в пределах диапазона урона заклинания (LoL использует случайные числа, чтобы дать дисперсию атакам), Урон правильно сопротивляется по сравнению с персонажем игрока и крипом, и заклинания читаются в пределах его эффективный диапазон.


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

Я написал статью по этой теме - http://download.springer.com/static/pdf/722/art%253A10.7603%252Fs40601-013-0010-4.pdf?auth66=1407852969_87bc2e71ad5228b36738f0237084ebe5&ext=.pdf

В другом ответе уже упоминалась статья из Power of Two Games Games From Within , но я предлагаю прочитать все (или почти все) там, поскольку все они действительно хорошо написаны и применимы непосредственно к разработке игр. Статья о Assert особенно хорошо. Вы также можете посетить их предыдущий веб-сайт Games From Within , где много написано о разработке через тестирование , то есть модульном тестировании, доведенном до крайности.

Ребята из Power of Two реализовали UnitCpp, довольно хорошо зарекомендовавший себя фреймворк для модульного тестирования. Лично я предпочитаю WinUnit .

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

Этот пост на Games From Within может быть актуальным / интересным.

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

Но мы можем проверить детерминированные значения. Например, в модульном тесте Гайбраш Трипвуд может двигаться к двери (поиск пути), открывать дверь (использовать команду), терпеть неудачу, потому что в его инвентаре нет ключа (обратная связь), выбирать ключ от двери (поиск пути + инвентарь). управление), а затем, наконец, открыв дверь.

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

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

Однажды я сделал что-то похожее на вашу идею, и это оказалось очень успешным, хотя я подозреваю, что на самом деле это скорее системный тест, чем модульный. Как вы предлагаете, ваш генератор случайных чисел должен иметь одно и то же значение и каждый раз генерировать идентичную последовательность. Игра работала с частотой 50 Гц, поэтому время не было проблемой. У меня была система, которая записывала щелчки мыши и их местоположение, и я использовал ее для создания вручную «сценария», который можно было воспроизвести для получения тех же результатов. Убрав временные задержки и отключив генерацию графики, час игрового процесса можно было бы воспроизвести за несколько секунд. Самая большая проблема заключалась в том, что изменения в дизайне игры делали скрипт недействительным.

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

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

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

Если вы используете XNA (эту идею, конечно, можно экстраполировать на другие фреймворки), вы можете использовать фреймворк внутриигрового модульного тестирования, который позволяет вам получить доступ к состоянию игры в модульном тесте. Одна из таких рамок - Scurvy.Test :-)

http://flea.sourceforge.net/gameTestServer.pdf

Это интересное обсуждение реализации полноценного функционального тестера в игре.

Термин «модульное тестирование» подразумевает, что тестируется «модуль». Это одно. Если вы проводите тестирование более высокого уровня (например, несколько систем одновременно), обычно это называется функциональным тестированием. Можно провести модульное тестирование большей части игры, но вы не можете тестировать ради удовольствия.

Детерминизм не нужен, пока ваши тесты могут быть нечеткими. Например, «получил ли персонаж травму» вместо «потерял ли персонаж 14,7 здоровья».