Существуют ли методы автоматического тестирования игр?
Приветствуется особый опыт с соответствующей информацией о проекте, такой как платформа и тип игры, если это помогает с разъяснениями.
Существуют ли методы автоматического тестирования игр?
Приветствуется особый опыт с соответствующей информацией о проекте, такой как платформа и тип игры, если это помогает с разъяснениями.
Ответы:
Независимая игра от одного человека. Это была многопользовательская танковая игра с разрушаемым ландшафтом, и код разрушаемого ландшафта и столкновений оказался несколько ненадежным.
Я закончил тем, что подстроил некоторые простые глупые ИИ (под «тупыми» я подразумеваю «абсолютно идиотский» - они случайным образом выбирали «ехать к вражескому танку», «ехать от вражеского танка» и «ехать в случайном направлении»). ", при случайном стрельбе из основного оружия) и играя в игру с максимальной частотой кадров при записи нажатий клавиш. Я получил около 10-15x в реальном времени. Код был тщательно утвержден, поэтому, если что-то пойдет не так, он будет выгружать весь журнал нажатия клавиш на диск вместе с сообщением об ошибке и начальным случайным начальным числом. Затем я мог бы пойти и воспроизвести журнал нажатий клавиш, чтобы точно дублировать состояние, или просто отладить отчет об ошибке.
Я оставил его работающим постоянно в течение буквально месяцев. Вначале он редко получал час без сбоев - мне приходилось сидеть там и присматривать за ним в течение недели, убивая несколько непонятных ошибок в день. В конце концов он дошел до того, что он работал в течение недели между сбоями, что соответствует примерно 1500 часам игрока на аварию.
Это было неоценимо, и я от всей души рекомендую это.
Для MMO, над которым я работал (более 100 разработчиков, ориентированных на ПК), мы пытались добавить огромное разнообразие автоматизированного тестирования с переменным успехом. Вот что сработало:
Что не сработало:
Работа над стратегической игрой 4х с трехмерным боем (думаю, что Homeworld встречается с Мастерами Ориона), которая, к сожалению, так и не вышла на свет, поскольку у компании кончились средства.
Я всегда гарантировал, что вы можете играть в игру без людей, чтобы мы могли оставить игру на ночь.
Мы могли бы отключить 3-й бой (упрощенный до случайного результата), и мы оставили игровой механизм стратегии ИИ сам по себе. Это нашло множество ошибок и проблем. Не только ошибки-пробки, но и стратегии, когда (например) стратегии ИИ зашли бы в тупик и тратили тысячи ходов, не делая «правильных действий». Подобные ошибки было трудно обнаружить, просто «играя в игру».
На шутере от первого лица, над которым я работал (Descent 3 - linux / mac / windows, ~ 30 человек в команде в 1999 году), возможность демонстрации / воспроизведения демо оказалась чрезвычайно полезной. Я сделал выбор, чтобы вы могли воспроизводить демо так же быстро, как игра могла рендерить кадры, и это стало отличным способом проверить производительность после того, как что-то изменилось.
Он также использовал много кода вне системы рендеринга, так что это была хорошая проверка работоспособности. После внесения множества изменений я мог просто запустить демонстрационное воспроизведение 10 минут игры. Много раз это могло бы обнаружить ошибку в области, которую я бы даже не подумал проверить сам.
У нас был шутер с открытым миром (x360, PS3, PC), который использовал быстрый тестовый дым на сервере сборки - он загружал игру, проходил через интерфейс, запускал [аватар] вперед, снимал скриншот и выходил. Если cctray обнаружил чистый выход, сборка прошла успешно.
Мы запускали его примерно в течение последнего года проекта, и его команда составляла ~ 100 разработчиков.
Он был эффективен при обнаружении ошибок показа, но было легко создать сборку, которая прошла бы самый дымный, но провалила большинство «реальных» уровней, или не работала в многопользовательской игре, и не дурачила ИИ, поэтому она не была идеальной. Это определенно стоило сделать.
Я слышал, что с тех пор, как я ушел, они начали проводить более широкую серию тестов дыма, разрабатываемых на нескольких компьютерах. По всей видимости, поддержка дымовых тестов - это проблема, и есть небольшая команда, которая занимается только поддержанием серверов сборки и программного обеспечения, поэтому я не могу сказать, был ли это успех или нет.
Мой опыт работы с Automated Testing во время разработки Crysis 2 доступен здесь: http://yetanothergameprogrammingblog.blogspot.com/2010/06/aaa-automated-testing.html
Резюме:
Разработка игр на самом деле является одним из тех случаев, когда модульное тестирование, кажется, имеет некоторый смысл для меня, потому что взаимодействия между дискретными системами очень распространены. Проектирование по контракту, конечно, является частью этого, и его следует планировать с самого первого дня разработки, но я не понимаю, почему его нельзя было реализовать позже, если предположить, что для этого есть необходимые средства.
Сложной частью является, конечно, интеграционное тестирование. Многие игры можно протестировать, просто выполнив демо-цикл или что-то в этом роде, но концептуально эти вещи довольно легко отлаживать - где я бы больше хотел тратить свое время на выявление ошибок, которые могут произойти, когда игрок что-то делает, с учетом того, что ошибка, которую игрок никогда не видит, явно менее важна, чем ошибка, которую делает игрок.
Что довольно сложно, очевидно. Тактика, которая работает с другими приложениями (фаззинг, ожидаемый проход / ожидаемый сбой и т. Д.), Не работает здесь так хорошо. В системах со скриптами кажется, что создание тестового набора скриптов для симуляции игрока - это путь, по которому нужно идти (см. Ответ JZig). Но тестирование специально для вещей, с которыми может столкнуться игрок, кажется мне лучшим местом для сосредоточения вашего времени как на людях, так и на автоматизированных тестах.