{"id":4008,"url":"\/distributions\/4008\/click?bit=1&hash=3e0e24714242dbbafe0bc5f0070ccccc83480de788b38ffe56426b16d15d7a5e","title":"\u0423\u0437\u043d\u0430\u043b\u0438, \u0447\u0435\u0433\u043e \u0436\u0434\u0443\u0442 \u043e\u0442 \u043d\u043e\u0443\u0442\u0431\u0443\u043a\u0430 \u043b\u044e\u0434\u0438 \u0440\u0430\u0437\u043d\u044b\u0445 \u043f\u0440\u043e\u0444\u0435\u0441\u0441\u0438\u0439","buttonText":"","imageUuid":"","isPaidAndBannersEnabled":false}

Используете ли вы автотесты при разработке игр?

Небольшой опрос о том, как обстоят в геймдеве дела с автотестами.

Используете ли вы автотесты для кода?
Да
Нет
Показать результаты
Переголосовать
Проголосовать
Используете ли вы автотесты для игровых ситуаций?
Да
Нет
Показать результаты
Переголосовать
Проголосовать
Используете ли вы автотесты для проверки размещения и наличия ассетов?
Да
Нет
Показать результаты
Переголосовать
Проголосовать
Если автотесты есть, как часто они запускаются?
Раз в день
Раз в неделю
Иногда
Перед релизом
Показать результаты
Переголосовать
Проголосовать

Пока у меня сложилось впечатление, что автотесты в ГД считаются чем-то чуждым.

Мне попалось вот это видео от разработчика Retro City Rampage, но то, о чем он говорит - запись ввода - это каменный век по меркам автоматизированного тестирования.

Разработчик использовал специальный режим для тестирования игры

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

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

0
63 комментария
Написать комментарий...
Andrey Apanasik

Про лёгкость написания тестов говорят обычно те, кто их никогда не писал. Даже обычные-то юнит тесты не всегда просто написать, что уж говорить про автоматизированное тестирование логики. Особенно, если речь про онлайн игру.

Ответить
Развернуть ветку
Stanislav

Мне вообще сама постановка вопроса (почему бы девелоперам не покрывать всё автотестами, тогда и багов в играх не будет) напоминает древний баян с письмом в NASA -- про почему бы им просто не заливать Ментос Колой, чтобы ракета быстро взлетала.

Ну или типичное детское "почему бы нам просто не напечатать больше денег, чтобы всем в мире их хватило".

Ответить
Развернуть ветку
16 комментариев
njunkie

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

Ответить
Развернуть ветку
1 комментарий
Andrey Apanasik
Ответить
Развернуть ветку
Алексей Алексеев

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

разве что на стадии некоего прототипа без лишних сущностей. но и там скорее речь будет про шустрого бота из talos principle как простую экономию времени (аналогия с цифровыми шахматами), нежели про привычные автотесты из it. иначе же — слишком много переплетенных механик и ассетов, чтобы лепить автоматизацию поверх этого и каждый раз грустно перезапускать после правки в коде/дизайне/геймдизайне/балансе/этсетера.

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

Ответить
Развернуть ветку
Stanislav
дока

Простите.

Ответить
Развернуть ветку
Stanislav

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

А имитировать поведение живого игрока -- а, вернее, множества разных живых игроков, потому что как ни крути, а играть каждый игрок будет по-разному -- задача сложная и глобальная. Использовать её для автотестов -- это примерно как решать проблему холодного синтеза для того, чтобы запитать лампочку в ночнике возле туалета и избавиться от постоянно садящейся батарейки.

Ответить
Развернуть ветку
Fenkreg
неоптимизированные аналоговые куски мяса перед экранами

Отлично, этим я и заменю термин "человек"

Ответить
Развернуть ветку
1 комментарий
Dmitry Namynnuz

То есть ты предлагаешь написать бота, который бы управлял игровым персонажем? И что ты таким образом сможешь проверить? Ну, положим, проблемы с коллизиями на уровне. Возможно, утечку памяти или ещё какие проблемы с ресурсами. Какие-то рандомные крэши. А логику-то ты как собрался проверять? Нужен гипервизор, который бы проверял состояние всей системы, с учётом большого числа переменных и степеней свобод. И само поведение будет максимально топорным и ритуализированным, побежали до точки, выполнили квест, получили награду. Это же будет делать тестеры в лице разработчиков или кого ещё. Только они будут отвлекаться «о, цветочек!» или нелинейно выполнять задачу. В итоге оверхэд никак не отобьётся.

Ответить
Развернуть ветку
sloa
Автор

Да, примерно это. Выдать дизайнеру уровней пачку маркеров, отражающих задуманное поведение, пустить по ним болванчика, а дальше все как в обычных автотестах - регистрировать то что происходит и сравнивать с тем, что должно было произойти. Где надо умер, где не надо - не умер.
А что именно проверять - ну примерно всё. Что прыжок допрыгивает, а стрельба достреливает. Что звучат звуки, которые должны были звучать. Что в ассетах сцены не забыли что-нибудь временное удалить.
А дальше - тесты растут из багов. Лоханулись разок - заведите тест.
Ну и вообще возможность заранее узнать, сколько именно тестов ломает новое изменение в механике, может быть очень ценна с точки зрения планирования.
Нет, это не отменяет необходимость плейтеста, но зато можно узнать, что ты накосячил до того, как изменения попадут в общую ветку, а не после.

Ответить
Развернуть ветку
7 комментариев
Dr Stragehate
запись ввода - это каменный век по меркам автоматизированного тестирования.

Отчасти, чтобы на тестах была обычная человеческая реакция с ошибками и прочим, а не идеальное управление от ИИ

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

Черный ящик же - не все тесты должны знать правила игры

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

Т.е. ты фактически предлагаешь написать игровой ИИ. Ну-ка навскидку 10 игр, где ИИ играет хорошо и не попадает в нелепые ситуации, несвойственные людям?)

Ответить
Развернуть ветку
sloa
Автор

Проблема записанных тестов в том, что они очень хрупкие.

Ответить
Развернуть ветку
1 комментарий
Demian
Мне кажется, что игры просто созданы для автоматизированного тестирования

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

В целом, я вижу ситуацию так: геймплей всё равно нужно тестировать руками, поэтому смысл тестов уже отпадает, тк. количество часов, необходимое на ручное тестирование от этого всё равно не сильно уменьшается. Зато возни с тестами может быть намного больше

Ответить
Развернуть ветку
Andrey Sergeev

Очень обширный вопрос.
1. Unit тесты должны быть обязательными для онлайн проектов.
2. Большие онлайн проекты должны быть частично автоматизированы ботами, которые обвешаны маячками и логами.
3. Вся веб обвязка в виде магазинов, порталов и тд должна быть автоматизирована классическими средствами (Selenium)
4. Геймплей - только ручками. Тк тестирование на позитивный сценарий это макс 5% от тестирования функционала. Все прочее - это тестирование на негативный сценарий. А это врятли поддается автоматизации либо потащит за собой уйму трудочасов и тучу сотрудников.

Ответить
Развернуть ветку

Комментарий удален модератором

Развернуть ветку
Andrey Apanasik

Потому что за это не платят. Менеджеры частенько по рукам бьют, если ты заикнёшься про тесты или рефакторинг, ибо "а как же фичи?!".

Ответить
Развернуть ветку
4 комментария
Nikolay Goloshchapov

На твиче был чувак один, как ни зайду, пишет автотесты.

Ответить
Развернуть ветку
Дмитрий Духнич

Думаю, очень сложно их писать, вот и не пишут

Ответить
Развернуть ветку
Старый игродел

В gamedev все просто, пока по фану - это не баг, и наоборот. Поэтому формально потестить можно только часть систем.

Ответить
Развернуть ветку
U.N.Owen Was Natum

Всё же относительно игр нет лучше теста, чем обученный биоробот.

Ответить
Развернуть ветку
Ольга

Удалено

Ответить
Развернуть ветку
Константин Жуков

О, адепт автоматизированного тестирования. Привет. Вот тебе две задачки на автоматизацию.
1. Проверить генератор псевдорандома на соответствие заданному распределению.
2. Проверить, что некоторое событие происходит с вероятностью 0.01% при условии выполнения игроком определенной последовательности действий.

Ответить
Развернуть ветку
sloa
Автор

1. Взять сразу проверенный и не городить велосипедов.
2. Триггерить событие руками по специальному счётчику, если оно не выпало по рандому. Все равно игроки "честный" рандом не любят.
А дальше просто выполняем операцию 10000 раз и смотрим что все в порядке.

Ответить
Развернуть ветку
9 комментариев
Paer Quote

1. Это зачем xor или mersenne-twiester насиловать? При желании проблем нет - вопрос только в точности определения.
2. Тут вообще проблем никаких. С другой стороны Именно в геймдеве это может не иметь смысла, потому что более приятен и понятен для игроков псевдорандом (по типу шансов башей в доКе2 и т.п.).

Ответить
Развернуть ветку
1 комментарий
Paer Quote

Если честно - в шоке от результатов теста. Теперь понятно почему "кранчевание" от Rockstar на dtf не считается чем-то необычным.

Ответить
Развернуть ветку
Читать все 63 комментария
null