Прямой эфир
Небольшой опрос о том, как обстоят в геймдеве дела с автотестами.
Пока у меня сложилось впечатление, что автотесты в ГД считаются чем-то чуждым.
Мне попалось вот это видео от разработчика Retro City Rampage, но то, о чем он говорит - запись ввода - это каменный век по меркам автоматизированного тестирования.
Мне кажется, что игры просто созданы для автоматизированного тестирования. Они уже сами по себе тестируют игрока на знание и понимание правил игры. От этого всего один шаг до того, чтобы использовать знание задуманных правил игры, закодированное тем или иным образом, для тестирования всей системы.
И игра сама по себе сочиняется как некий набор сценариев, которые должны происходить. И отсюда всего шаг до того, чтобы превратить эти сценарии в тесты, по которым потом можно будет проверять механики.
Про лёгкость написания тестов говорят обычно те, кто их никогда не писал. Даже обычные-то юнит тесты не всегда просто написать, что уж говорить про автоматизированное тестирование логики. Особенно, если речь про онлайн игру.
Мне вообще сама постановка вопроса (почему бы девелоперам не покрывать всё автотестами, тогда и багов в играх не будет) напоминает древний баян с письмом в NASA -- про почему бы им просто не заливать Ментос Колой, чтобы ракета быстро взлетала.
Ну или типичное детское "почему бы нам просто не напечатать больше денег, чтобы всем в мире их хватило".
Нигде это не стандарт. Тесты делают там, где компания может выделить время и русурсы на это. Это явно не про инди.
Плюс, время тестировщиков стоит дешевле, объективно. Поэтому даже крупным компаниям проще платить тестерам, чем тратить время разработчиков на тесты =/
Вообще то в крупных компаниях есть отдельная позиция инженера-тестировщика-автоматизатора, где прайс за труд на уровне разраба, сам таким работаю🙂
Угук. Поэтому ты можешь проавтотестить, там, клиент-серверное соединение, или правильную трансформацию данных адаптером -- то есть, убедиться, что в модулях правильно работают не только конкретные функции, но интерфейсы для связности.
https://twitter.com/themalaru/status/1056328104031989761
А ты вот для этого хотя бы словами тест-кейс опиши :)
Разместить объект на пути поезда.
Сразу же поехали.
Что значит "на пути поезда"? Поезд -- это большой трёхмерный объект. Как и любой живой объект в игре. Какая конкретно часть объекта должна столкнуться с какой конкретно частью поезда? Это же всё приведёт к разному эффекту.
Пустить поезд -- в каком направлении, с какой скоростью, по какой тракетории?
Что должно случиться, если мы при размещении объекта разместим лошадь наполовину в поезде, наполовину вне него, "разрезанную" пополам стеной -- что, в принципе, тоже подходит под описание кейса?
А теперь скажи мне, сколько такая проверка займет руками и как часто будет проводиться.
Вечность. И проводиться будет совсем нечасто.
Поэтому и вылезти вот такое может вообще где угодно, как видишь :)
Поиск экзотических багов не является целью автоматизированного тестирования. Целью является предотвращение багов там, где их можно ожидать. Мы знаем, что игрок застрял в двери? Проверим все двери на застревание.
Мы знаем, что лошадь может зацепить поездом? Сделаем тест на это тоже. Потому что где-то на другом конце офиса сидит сотрудник, который пропустил эту историю, и вскоре снова добавит в игру кривую дверь. Или кривую лошадь.
Ну, у тестов, с точки зрения проекта, есть четыре цели: спецификация, документация, страховка и локализация.
Спецификация: до начала разработки мы создаём тест, который объясняет, как оно должно работать.
Условный геймдиз рисует уровень, по которому будет бегать условный супер Марио и отдает его кодерам. И они твикают код до тех пор, пока он не начнет работать как надо.
Документация: тесты должны объяснять, как проект работает, или должен работать. То есть каждую новую механику имеет смысл оформить в виде демонстрационной камеры, в которой она демонстрируется и проверяется.
Страховка: то есть тесты должны вовремя сообщить нам что что-то сломалось. В идеале - до внесения изменений. Поэтому имеет смысл оформлять найденные и типичные баги и проблемы отдельными тестами, чтобы они не вылезли снова.
Ну и наконец локализация. Если тесты показывают что что-то сломалось, они должны также показывать, что и где надо чинить. Тут лучше смотреть по структуре проекта.
Плюс интеграция. Большие готовые игровые сценарии тоже надо проверять хотя бы на позитивный сценарий.
Я думал о том, что можно сделать дерево с несколькими исходами, позитивными и негативными, и сделать алгоритм, который пройдет по нему до каждой конечной точки по очереди.
Ну да, действительно. Там же ИИ встроен, который за вас все тесты напишет.
не дока, но мне кажется, не очень-то вяжется типовая игра с условным селениумом или бехатом. дебаггинг да регрессия чрезвычайно далеки от вашего философского "игры тестируют игрока".
разве что на стадии некоего прототипа без лишних сущностей. но и там скорее речь будет про шустрого бота из talos principle как простую экономию времени (аналогия с цифровыми шахматами), нежели про привычные автотесты из it. иначе же — слишком много переплетенных механик и ассетов, чтобы лепить автоматизацию поверх этого и каждый раз грустно перезапускать после правки в коде/дизайне/геймдизайне/балансе/этсетера.
то есть, наверное, в сферическом мире для идеально продуманного инди это было бы всё еще лучше, чем обычный дешевый мануальщик, но то в сферическом.
Большинство багов игры вылезает не из-за косяков механики ("пуля при попадании в голову не убивает"), а из-за косяков взаимодействия с этой механикой входных данных ("пуля при попадании в голову не убивает, если игрок стреляет лёжа, с левой руки и попадает снизу, под углом 37 градусов от шеи, в мочку правого уха"), потому что идеальные сферические сценарии, которые замечательно рисуются на графиках и моделируются математически, не соответствуют тому, что делают неоптимизированные аналоговые куски мяса перед экранами.
А имитировать поведение живого игрока -- а, вернее, множества разных живых игроков, потому что как ни крути, а играть каждый игрок будет по-разному -- задача сложная и глобальная. Использовать её для автотестов -- это примерно как решать проблему холодного синтеза для того, чтобы запитать лампочку в ночнике возле туалета и избавиться от постоянно садящейся батарейки.
То есть ты предлагаешь написать бота, который бы управлял игровым персонажем? И что ты таким образом сможешь проверить? Ну, положим, проблемы с коллизиями на уровне. Возможно, утечку памяти или ещё какие проблемы с ресурсами. Какие-то рандомные крэши. А логику-то ты как собрался проверять? Нужен гипервизор, который бы проверял состояние всей системы, с учётом большого числа переменных и степеней свобод. И само поведение будет максимально топорным и ритуализированным, побежали до точки, выполнили квест, получили награду. Это же будет делать тестеры в лице разработчиков или кого ещё. Только они будут отвлекаться «о, цветочек!» или нелинейно выполнять задачу. В итоге оверхэд никак не отобьётся.
Да, примерно это. Выдать дизайнеру уровней пачку маркеров, отражающих задуманное поведение, пустить по ним болванчика, а дальше все как в обычных автотестах - регистрировать то что происходит и сравнивать с тем, что должно было произойти. Где надо умер, где не надо - не умер.
А что именно проверять - ну примерно всё. Что прыжок допрыгивает, а стрельба достреливает. Что звучат звуки, которые должны были звучать. Что в ассетах сцены не забыли что-нибудь временное удалить.
А дальше - тесты растут из багов. Лоханулись разок - заведите тест.
Ну и вообще возможность заранее узнать, сколько именно тестов ломает новое изменение в механике, может быть очень ценна с точки зрения планирования.
Нет, это не отменяет необходимость плейтеста, но зато можно узнать, что ты накосячил до того, как изменения попадут в общую ветку, а не после.
А что именно проверять - ну примерно всё. Что прыжок допрыгивает, а стрельба достреливает. Что звучат звуки, которые должны были звучать. Что в ассетах сцены не забыли что-нибудь временное удалить.
Это сработает ровно для того, что называется смоук-тестами. То есть, для того, что девелопер и сам проверит, поклацав после внедрения. Но как только дело дойдет даже до самых банальных граничных случаев, которые любой тестер в первую очередь проверит, тут-то автотестам и опаньки.
То есть, вот самое банальное, с чем я, как игрок, сто тыщ раз сталкивался. Баги с зонами перехода в платформерах. Ситуация-то per se очень простая -- дошел до определенного места, перешел на определенную локацию. Ботик добежит до зоны перехода, пройдет через неё, убедится, что всё ок и тест будет пройден. Человек добежит до зоны перехода и зайдет в неё с прыжка, с двойного прыжка, с голландского угла, ̶с̶ ̶г̶о̶л̶л̶а̶н̶д̶с̶к̶о̶г̶о̶ ̶ш̶т̶у̶р̶в̶а̶л̶а̶ с переката, с переката на три пикселя до, с переката на три пикселя после, с переката на три с половиной пикселя до, с переката на три с половиной пикселя после, толкая перед собой ящик, волоча за собой ящик, прыгая с этого ящика, прыгая с этого ящика под другим углом, швыряя ящик перед собой и сталкиваясь с ним в момент перехода...
Если в дело вступает физика, то ситуация вообще превращается в ад кромешный, потому что ты еще и никак начальные условия не детерминируешь -- у тебя каждый раз тест будет проходиться в разном окружении, а результаты каждый раз надо будет сравнивать с эталоном.
Практически в любой игре (исключая те, что вообще не тестили) то, что поддаётся тестированию и так нормально работает -- если ты делаешь то, что задумал автор так, как задумал автор , то всё приведёт к результату, который задумал автор . А если ты делаешь что-то не так, как задумал автор , то автор и тесты для такого варианта не продумал, с очевидностью.
это уже где как заведено. автоматизаторы вообще довольно-таки ценятся.
хотя легкое консервативное пренебрежение от остальных кнопкодавов в духе "где вы, где мы", вероятно, сквозит повсеместно. но есть вероятность, что это в основном в снг так, у нас софт-скиллы не то чтобы в почете.
Я смутно подозреваю, что автоматизаторы как раз и ценятся, потому что воспринимаются как технические кадры, которые имеют специальные знания о технологии, с мудрёными фреймворками работают и код -- это вам не по экрану мышкой кнопать!
В то время, как специальные знания хорошего тестировщика (которые ведут к нахождению багов) зачастую к мудрёным фреймворкам и написанию кода для автоматизации ни малейшего отношения не имеют.
Автоматизаторы ценятся из-за практики continuous integration and delivery, которая сейчас в моде.
https://ru.m.wikipedia.org/wiki/Непрерывная_интеграция
запись ввода - это каменный век по меркам автоматизированного тестирования.
Отчасти, чтобы на тестах была обычная человеческая реакция с ошибками и прочим, а не идеальное управление от ИИ
использовать знание задуманных правил игры, закодированное тем или иным образом, для тестирования всей системы
Черный ящик же - не все тесты должны знать правила игры
И игра сама по себе сочиняется как некий набор сценариев, которые должны происходить. И отсюда всего шаг до того, чтобы превратить эти сценарии в тесты, по которым потом можно будет проверять механики.
Т.е. ты фактически предлагаешь написать игровой ИИ. Ну-ка навскидку 10 игр, где ИИ играет хорошо и не попадает в нелепые ситуации, несвойственные людям?)
Ну так и твои тесты тоже не очень устойчивы. Придется проверять, что тест по-прежнему проверяет то, что он должен проверять (т.е. выполняет ли он кейс). А разработка такого теста будет много сложней
Мне кажется, что игры просто созданы для автоматизированного тестирования
Игры хуже всего подходят для автоматизированного тестирования. Зависит от жанра, конечно. Но это ну никак не может быть проще, чем делать тесты на софт
В целом, я вижу ситуацию так: геймплей всё равно нужно тестировать руками, поэтому смысл тестов уже отпадает, тк. количество часов, необходимое на ручное тестирование от этого всё равно не сильно уменьшается. Зато возни с тестами может быть намного больше
Очень обширный вопрос.
1. Unit тесты должны быть обязательными для онлайн проектов.
2. Большие онлайн проекты должны быть частично автоматизированы ботами, которые обвешаны маячками и логами.
3. Вся веб обвязка в виде магазинов, порталов и тд должна быть автоматизирована классическими средствами (Selenium)
4. Геймплей - только ручками. Тк тестирование на позитивный сценарий это макс 5% от тестирования функционала. Все прочее - это тестирование на негативный сценарий. А это врятли поддается автоматизации либо потащит за собой уйму трудочасов и тучу сотрудников.
Комментарий удален
Потому что за это не платят. Менеджеры частенько по рукам бьют, если ты заикнёшься про тесты или рефакторинг, ибо "а как же фичи?!".
Комментарий удален
Проходили-проходили и что-то не прошли.
Один корень надо побыстрее выпускать продукт и накручивать на него фичи, чтобы конверсия побыстрее шла.
Девелоперы при этом могут себя успокаивать тем, что ну вот выпустим релизную версию и уж точно сядем работать над техническим долгом. Хотя на самом деле выпустят они релизную версию и будут дальше панически фичи наляпывать, потому что пока релизились, у конкурентов уже тоже что-то вышло, и наши фичи, оказывается, уже не прорывное ноу-хау, а значит опять надо побыстрее выпускать новый продукт и накручивать на него фичи, чтобы конверсия не прекратилась...
В gamedev все просто, пока по фану - это не баг, и наоборот. Поэтому формально потестить можно только часть систем.
О, адепт автоматизированного тестирования. Привет. Вот тебе две задачки на автоматизацию.
1. Проверить генератор псевдорандома на соответствие заданному распределению.
2. Проверить, что некоторое событие происходит с вероятностью 0.01% при условии выполнения игроком определенной последовательности действий.
1. Взять сразу проверенный и не городить велосипедов.
2. Триггерить событие руками по специальному счётчику, если оно не выпало по рандому. Все равно игроки "честный" рандом не любят.
А дальше просто выполняем операцию 10000 раз и смотрим что все в порядке.
> 1. Взять сразу проверенный и не городить велосипедов.
Хорошо бы, но нет. Способ задания распределений у ГД столько же, сколько этих самых ГД. Так что обвязку вокруг генератора с равномерным распределением писать приходится в каждом отдельном случае. И это НЕ тестируется. Ни автоматически, никак. И это у меня еще максимально упрощенный и абстрагированный пример целого класса задач, которые приходится решать.
> 2. Триггерить событие руками по специальному счётчику, если оно не выпало по рандому.
Нет. Таким способом данный функционал не проверяется.
> Все равно игроки "честный" рандом не любят.
Вы это по собственному опыту или из каментов на гохе знаете? Потому, что как раз именно рандом игроки и любят больше всего, просто они об этом не знают и это не тот рандом, о котором они наивно рассуждают в тредиках. А вот не любят они как раз плохой дизайн, когда рандом используется максимально тупым способом (например классический "корейский рандом").
В разработке скольки выпущенных игр вы участвовали?
Из комментов Сида Мейера и том, как он добавлял рандом в Цивилизацию. Или вы о гемблерах а не геймерах? Эти может быть и любят.
И нет, я не участвую в разработке игр, иначе бы я тоже тут в комментах писал "Автотесты? Зачем? Что за глупость? У нас есть Паша, он всё проверяет".
И почитайте что-нибудь про deterministic rng, у меня есть чувство, что ваш ответ где-то там.
Смотрел. Не оседлал. Он писал игру вокруг автотестов по сути. Забавный подход, возможно работает для мелких мобильных казуалок, но что-то крупнее так не пишется. И да, это тот случай, когда плохие тесты хуже, чем отсутствие оных. Так что это не пример годного промышленного подхода, а пример странного эксперимента со странными же выводами, типа тетриса на брейнфаке.
Да, игрострой - это промышленность. Как кино, театр и прочий энтертейнмент.
Это звучит иронично, потому как промышленная разработка ПО начинается и заканчивается приемочными тестами. Их согласуют в начале, по ним принимают в конце, и код действительно пишется вокруг них, и никто не считает это экспериментом на брейнфаке. Потому что от этого зависят деньги.
1. Это зачем xor или mersenne-twiester насиловать? При желании проблем нет - вопрос только в точности определения.
2. Тут вообще проблем никаких. С другой стороны Именно в геймдеве это может не иметь смысла, потому что более приятен и понятен для игроков псевдорандом (по типу шансов башей в доКе2 и т.п.).
> 1. Это зачем xor или mersenne-twiester насиловать? При желании проблем нет - вопрос только в точности определения.
Возможно я слишком сократил описание, речь не о системном/библиотечном вызове функций семейства rand(), а о надстройках в коде игры, использующих эти вызовы для формирования распределений нужных геймдизайнерам. И нет, это НЕ тестируется.
> 2. Тут вообще проблем никаких.
Вообще никаких проблем - это написать "проблем никаких" и на этом закончить, ага. А вот если пойти чуть дальше, то сразу начинаются проблемы.
Если честно - в шоке от результатов теста. Теперь понятно почему "кранчевание" от Rockstar на dtf не считается чем-то необычным.
Прямой эфир
