Использует ли игровая индустрия автоматизированное тестирование визуальных частей игр / рендеринга? Как?

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

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

Это правда? Если да, то как можно протестировать рендеринг игр? Захватывать выходные данные и сравнивать изображения (это может быть надежно?)? Перехват данных с видеокарты на низком уровне? Захватывает информацию вершин (и т. Д.) На пути к графической карте? Кажется, что есть много возможностей; но я не могу найти информацию об этом :(

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

unit-testing testing game-development

— Дэнни Таппени
источник

Я бы сказал, что, вероятно, они просто используют хорошо протестированную графическую библиотеку (стороннюю или разработанную собственными силами). Когда они добираются до проектирования игрового уровня, они не проверяют, что каждый объект находится точно в координатах X, Y, Z, или если перспектива правильна, но более простые вещи как обеспечение того, чтобы объекты были там и не были заблокированы стенами и т. Д. А если графическая библиотека разрабатывается самостоятельно, тесты автоматизированы и являются более базовыми.

— SJuan76

@ SJuan76 Полагаю, если вы работаете над двигателем, вопрос касается тестирования двигателя

— Дэнни Таппени,

Не является ли этот вопрос несколько шире, чем тот, который был помечен как дубликат? ОП не упоминал C ++ или OpenGL. Игровая индустрия больше этого.

— toniedzwiedz

Вероятно, легче формально доказать, что код верен, учитывая, что графические API не содержат ошибок, чем проверять, выполняет ли оборудование свою работу. Поскольку драйверы AMD и NVidia являются проприетарными, я представляю, какой протокол используется для связи с видеокартой: 1) проприетарный, 2) может быть изменен и 3) варьируется от карты к карте. Кроме того, даже если данные, отправленные на видеокарту, верны, откуда вы знаете, что у видеокарты нет аппаратного недостатка?

— Довал

Я попытался открыть это снова, поскольку цель dupe была более конкретно посвящена стратегиям автоматического тестирования графики OpenGL. Это не моя специальность, но я доверяю отзывам других, которые очень хорошо знают игровую индустрию, поэтому я хочу дать ей еще один шанс. Ссылку на аналогичный вопрос смотрите здесь: programmers.stackexchange.com/questions/150688/…

— maple_shaft

Любая компания поступит по-разному, даже разные игры будут испытаны по-разному.

Возможно, недостаток информации о графике объясняется тем, что рендеринг действительно довольно «повторяющийся» (я не могу придумать лучшего слова, извините), и в типичной сложной сцене будет достаточно примитивных комбинаций, поэтому большинство людей обычно могут легко увидеть большинство глюков ( за исключением менее используемых шейдеров, но можно использовать специальный уровень / демонстрацию стресс-шейдеров). Помните, что люди были охотниками в течение тысяч лет :), поэтому, вероятно, мы созданы, чтобы видеть глюки.
Кроме того, свобода передвижения, присутствующая в большинстве игр, и рандомизация других элементов в типичной игре, которая делает ее более «реалистичной», обычно являются кошмаром для применения чисто автоматических тестов: на самом деле, тестер-человек найдет быстрее и больше ошибок, чем любой автоматический тест. Вы можете кодировать логику для записи времени, статистики и позиций / углов / других переменных, когда тестер играет ... так что даже на неавтоматизированных тестах у вас будет обратная связь, подобная автоматизированным тестам. Обычно полезно иметь возможность воспроизвести любую записанную сессию бета-тестера (и, как правило, это хорошая функция и для финальной игры).
Например, о статистике рендеринга вы можете получить: статистику подсчета вызовов для каждого из шейдеров (поскольку вы будете делать вызовы, достаточно сохранить несколько счетчиков), количество загрузок (то же самое вы будете контролировать, когда Обновлены буферы GPU), тайминги (не только fps, а также промежутки между каждым вызовом) и т. д. При необходимости (но я считаю, что это не рекомендуется, за исключением случаев поиска конкретной ошибки), вы можете получить статистику от самой видеокарты. (например, вы можете получить показатели заполнения и другие, используя запросы окклюзии).
Наконец, другая причина для использования бета-тестеров заключается в том, что разные графические карты будут, вероятно, работать по-разному ... вам может потребоваться ферма машин для тестирования o_O. Любимые бета-тестеры будут смягчать весь этот беспорядок.

Надеюсь, что это поможет!

Отказ от ответственности: я не бета-тестер, я разработчик XDDD.

— user1039663
источник

Я полностью согласен с тем, что люди созданы для того, чтобы видеть шаблоны, глюки, ... Мы действительно визуальные существа.

— Триларион,