Небольшой опрос о том, как обстоят в геймдеве дела с автотестами.
Пока у меня сложилось впечатление, что автотесты в ГД считаются чем-то чуждым.
Мне попалось вот это видео от разработчика Retro City Rampage, но то, о чем он говорит - запись ввода - это каменный век по меркам автоматизированного тестирования.
Мне кажется, что игры просто созданы для автоматизированного тестирования. Они уже сами по себе тестируют игрока на знание и понимание правил игры. От этого всего один шаг до того, чтобы использовать знание задуманных правил игры, закодированное тем или иным образом, для тестирования всей системы.
И игра сама по себе сочиняется как некий набор сценариев, которые должны происходить. И отсюда всего шаг до того, чтобы превратить эти сценарии в тесты, по которым потом можно будет проверять механики.
Про лёгкость написания тестов говорят обычно те, кто их никогда не писал. Даже обычные-то юнит тесты не всегда просто написать, что уж говорить про автоматизированное тестирование логики. Особенно, если речь про онлайн игру.
Мне вообще сама постановка вопроса (почему бы девелоперам не покрывать всё автотестами, тогда и багов в играх не будет) напоминает древний баян с письмом в NASA -- про почему бы им просто не заливать Ментос Колой, чтобы ракета быстро взлетала.
Ну или типичное детское "почему бы нам просто не напечатать больше денег, чтобы всем в мире их хватило".
В мире сейчас куча свободных фреймворков для тестирования, бери - не хочу. Про сложность обычно говорят те, кто неосилил. хех
не дока, но мне кажется, не очень-то вяжется типовая игра с условным селениумом или бехатом. дебаггинг да регрессия чрезвычайно далеки от вашего философского "игры тестируют игрока".
разве что на стадии некоего прототипа без лишних сущностей. но и там скорее речь будет про шустрого бота из talos principle как простую экономию времени (аналогия с цифровыми шахматами), нежели про привычные автотесты из it. иначе же — слишком много переплетенных механик и ассетов, чтобы лепить автоматизацию поверх этого и каждый раз грустно перезапускать после правки в коде/дизайне/геймдизайне/балансе/этсетера.
то есть, наверное, в сферическом мире для идеально продуманного инди это было бы всё еще лучше, чем обычный дешевый мануальщик, но то в сферическом.
Простите.
Большинство багов игры вылезает не из-за косяков механики ("пуля при попадании в голову не убивает"), а из-за косяков взаимодействия с этой механикой входных данных ("пуля при попадании в голову не убивает, если игрок стреляет лёжа, с левой руки и попадает снизу, под углом 37 градусов от шеи, в мочку правого уха"), потому что идеальные сферические сценарии, которые замечательно рисуются на графиках и моделируются математически, не соответствуют тому, что делают неоптимизированные аналоговые куски мяса перед экранами.
А имитировать поведение живого игрока -- а, вернее, множества разных живых игроков, потому что как ни крути, а играть каждый игрок будет по-разному -- задача сложная и глобальная. Использовать её для автотестов -- это примерно как решать проблему холодного синтеза для того, чтобы запитать лампочку в ночнике возле туалета и избавиться от постоянно садящейся батарейки.
Отлично, этим я и заменю термин "человек"
То есть ты предлагаешь написать бота, который бы управлял игровым персонажем? И что ты таким образом сможешь проверить? Ну, положим, проблемы с коллизиями на уровне. Возможно, утечку памяти или ещё какие проблемы с ресурсами. Какие-то рандомные крэши. А логику-то ты как собрался проверять? Нужен гипервизор, который бы проверял состояние всей системы, с учётом большого числа переменных и степеней свобод. И само поведение будет максимально топорным и ритуализированным, побежали до точки, выполнили квест, получили награду. Это же будет делать тестеры в лице разработчиков или кого ещё. Только они будут отвлекаться «о, цветочек!» или нелинейно выполнять задачу. В итоге оверхэд никак не отобьётся.
Да, примерно это. Выдать дизайнеру уровней пачку маркеров, отражающих задуманное поведение, пустить по ним болванчика, а дальше все как в обычных автотестах - регистрировать то что происходит и сравнивать с тем, что должно было произойти. Где надо умер, где не надо - не умер.
А что именно проверять - ну примерно всё. Что прыжок допрыгивает, а стрельба достреливает. Что звучат звуки, которые должны были звучать. Что в ассетах сцены не забыли что-нибудь временное удалить.
А дальше - тесты растут из багов. Лоханулись разок - заведите тест.
Ну и вообще возможность заранее узнать, сколько именно тестов ломает новое изменение в механике, может быть очень ценна с точки зрения планирования.
Нет, это не отменяет необходимость плейтеста, но зато можно узнать, что ты накосячил до того, как изменения попадут в общую ветку, а не после.
Отчасти, чтобы на тестах была обычная человеческая реакция с ошибками и прочим, а не идеальное управление от ИИ
использовать знание задуманных правил игры, закодированное тем или иным образом, для тестирования всей системыЧерный ящик же - не все тесты должны знать правила игры
И игра сама по себе сочиняется как некий набор сценариев, которые должны происходить. И отсюда всего шаг до того, чтобы превратить эти сценарии в тесты, по которым потом можно будет проверять механики.Т.е. ты фактически предлагаешь написать игровой ИИ. Ну-ка навскидку 10 игр, где ИИ играет хорошо и не попадает в нелепые ситуации, несвойственные людям?)
Проблема записанных тестов в том, что они очень хрупкие.
Игры хуже всего подходят для автоматизированного тестирования. Зависит от жанра, конечно. Но это ну никак не может быть проще, чем делать тесты на софт
В целом, я вижу ситуацию так: геймплей всё равно нужно тестировать руками, поэтому смысл тестов уже отпадает, тк. количество часов, необходимое на ручное тестирование от этого всё равно не сильно уменьшается. Зато возни с тестами может быть намного больше
Очень обширный вопрос.
1. Unit тесты должны быть обязательными для онлайн проектов.
2. Большие онлайн проекты должны быть частично автоматизированы ботами, которые обвешаны маячками и логами.
3. Вся веб обвязка в виде магазинов, порталов и тд должна быть автоматизирована классическими средствами (Selenium)
4. Геймплей - только ручками. Тк тестирование на позитивный сценарий это макс 5% от тестирования функционала. Все прочее - это тестирование на негативный сценарий. А это врятли поддается автоматизации либо потащит за собой уйму трудочасов и тучу сотрудников.
Комментарий удален модератором
Потому что за это не платят. Менеджеры частенько по рукам бьют, если ты заикнёшься про тесты или рефакторинг, ибо "а как же фичи?!".
На твиче был чувак один, как ни зайду, пишет автотесты.
Думаю, очень сложно их писать, вот и не пишут
В gamedev все просто, пока по фану - это не баг, и наоборот. Поэтому формально потестить можно только часть систем.
Всё же относительно игр нет лучше теста, чем обученный биоробот.
Удалено
О, адепт автоматизированного тестирования. Привет. Вот тебе две задачки на автоматизацию.
1. Проверить генератор псевдорандома на соответствие заданному распределению.
2. Проверить, что некоторое событие происходит с вероятностью 0.01% при условии выполнения игроком определенной последовательности действий.
1. Взять сразу проверенный и не городить велосипедов.
2. Триггерить событие руками по специальному счётчику, если оно не выпало по рандому. Все равно игроки "честный" рандом не любят.
А дальше просто выполняем операцию 10000 раз и смотрим что все в порядке.
1. Это зачем xor или mersenne-twiester насиловать? При желании проблем нет - вопрос только в точности определения.
2. Тут вообще проблем никаких. С другой стороны Именно в геймдеве это может не иметь смысла, потому что более приятен и понятен для игроков псевдорандом (по типу шансов башей в доКе2 и т.п.).
Если честно - в шоке от результатов теста. Теперь понятно почему "кранчевание" от Rockstar на dtf не считается чем-то необычным.