Ошибки в компьютерных играх
Представьте себе: вот вы ждете новую часть вашей любимой игры и, наконец, она выходит. Специально под это дело вы обновили свой ПК: установили новейшие ЦП и ГП, увеличили объем оперативки и даже заменили жесткий диск на SSD. Теперь игра должна запускаться у вас гладко, как шелк, с первого же экрана загрузки и до самого конца.
Вот вы скачиваете себе ранее оплаченный предзаказ. Завершается установка, вы запускаете игру. Все идет хорошо: игра «летает» с частотой кадров 60 FPS. Или, во всяком случае, так говорит вам счетчик кадров в оверлее вашего ГП. Но что-то идет не так. Вы водите мышкой туда-сюда и замечаете, что игра… фризится.
Как это возможно? Какие еще фризы при 60 FPS?
Это может казаться смешным до тех пор, пока не столкнешься с этим сам. Если вы встречались с такими фризами, то наверняка уже успели их возненавидеть.
Это не лаги. Не низкий фреймрейт. Это статтеринг. При высоких FPS и идеальной сверхбыстрой конфигурации.
Что это такое, откуда взялось и есть ли способ от него избавиться? Сейчас разберемся.
Со времен появления первых аркадных автоматов в 70-ых годах видеоигры работают на 60 FPS. Обычно предполагается, что игра должна работать с той же скоростью, что и дисплей. Только после популяризации 3D-игр нам пришлось столкнуться и принять более низкую частоту кадров. Еще в 90-х годах, когда «3D-карты» (которые теперь называют «графическими процессорами») начали заменять программный рендеринг, люди спокойно играли с частотой 20 кадров в секунду, а 35 FPS считалась уже частотой для серьезных соревнований по сети.
Теперь же мы располагаем сверхбыстрыми машинами, которые, конечно же, могут летать на 60 FPS. Тем не менее… похоже, что недовольных производительностью теперь стало больше, чем когда-либо. Как это возможно?
Дело не в том, что игры работают недостаточно быстро. А в том, что они фризятся даже с высокой производительностью.
Если вы пробежитесь по игровым форумам, то, вероятно, встретите в заголовках тем что-то вроде такого:
ПК-геймеры часто жалуются, что игры страдают от статтеринга даже при отсутствии проблем с частотой кадров.
Можно предположить, что это единичные случаи, но такие допущения развеивает статистика поиска в Google:
За последние 5 лет статтеринг стал (относительно) большей проблемой, чем производительность.
(Обратите внимание, что это относительные значения. Дело не в том, что люди ищут информацию о статтеринге чаще, чем о фреймрейте в целом. В то время, как количество поисковых запросов о частоте кадров остается прежним, поисковые запросы о статтеринге появляются все чаще, особенно в последнее время.)
Ситуация на сегодняшний день
Со временем стали появляться все более сложные графические процессоры, и они неизбежно становились все более и более «асинхронными». Это означает, что когда ЦП дает команду ГП отрисовать что-то на экране, ГП просто сохраняет эту команду в буфере, чтобы ЦП мог продолжать свои дела, пока ГП выполняет рендеринг. В конечном итоге это приводит к ситуации, когда ЦП сообщает графическому процессору, когда наступает конец кадра, а графический процессор, сохраняя это среди своих данных, на самом деле не считает это чем-то приоритетным — ведь он все еще обрабатывает некоторые из ранее выданных команд. Он покажет кадр на экране только тогда, когда выполнит все, чем его загрузили до этого.
Итак, когда игра пытается вычислить время, вычитая временные метки в начале двух последовательных кадров, релевантность этого, откровенно говоря… весьма сомнительна. Поэтому вернемся к нашему примеру. Там у нас были такие кадры:
Шесть последовательных кадров с точной синхронизацией. Верхний ряд — правильный, нижний — с эффектом статтеринга.
В первых двух кадрах время кадра составляет 16,67 мс (или 1/60 секунды), и камера перемещается на одинаковую величину в верхнем и нижнем случаях, поэтому деревья синхронизированы. В третьем кадре (внизу, со статтерингом) игра увидела, что время кадра составляет 24,8 мс (то есть, больше 1/60 секунды) и оттого думает, что частота кадров упала, и бросается нагонять пропущенное… только для того, чтобы обнаружить, что на следующем кадре время составляет всего 10,7 мс, отчего камера замедляется, и теперь деревья снова более или менее синхронизированы.
Что же происходит? Измеряемое игрой время кадра колеблется из-за различных факторов — особенно в загруженной многозадачной системе, такой как ПК. Поэтому в некоторые моменты времени игра полагает, что частота упала с 60 FPS, и генерирует кадры анимации, рассчитанные на более низкую частоту кадров. Но из-за асинхронного характера работы ГП она всегда так или иначе возвращается к тем же 60 кадрам в секунду.
Это и есть статтеринг — анимация, сгенерированная для переменной частоты кадров (сердцебиения), отображающаяся с фактической правильной фиксированной частотой кадров.
Так что по существу можно считать, что никакой проблемы нет — все идет гладко, просто игра этого не знает.
Это подводит нас к тому, о чем мы говорили в начале статьи. Когда мы, наконец, выяснили причину проблемы (хотя мы знаем, что это иллюзия проблемы — ведь на самом деле проблемы нет, не так ли?), мы можем применить следующую волшебную пилюлю.
Что это за пилюля? В Serious Engine она обозначается как sim_fSyncRate = 60. Проще говоря, это означает вот что: «полностью игнорировать все эти махинации с синхронизацией и делать вид, что мы всегда измеряем стабильные 60 кадров в секунду». И это заставляет все работать гладко — только потому, что с самого начала все работало гладко! Единственная причина, по которой появлялся статтеринг, — это неправильное время, используемое для анимации.
И что же, на этом все?
Управление питанием и температурой VS сложность рендеринга
Мы также должны принять во внимание тот факт, что современные ЦП и ГП не работают с фиксированной частотой, но у обоих есть системы, которые регулируют их скорость вверх и вниз в зависимости от нагрузки и текущей температуры. Таким образом, игра не может просто предположить, что они будут иметь одинаковую скорость от кадра к кадру. С другой стороны, операционная система и драйверы не могут ожидать, что игра будет выполнять одинаковый объем работы в каждом кадре. Сложные системы связи между двумя сторонами должны быть спроектированы таким образом, чтобы все это принималось во внимание.
Ошибка 3. Отсутствие бюджета на локализации
Понятно, что в условиях ограниченного бюджета на разработку локализация — это последнее, на что компания будет планировать тратить деньги.
Но если игра будет выпускаться на иностранные рынки, то первое впечатление от игры будет именно от перевода, а только потом от сюжета и геймплея.
Нанять фрилансера-переводчика, который за пару ночей забацает перевод проекта с английского на какой-нибудь французский или русский? Для инди-игр это крайне распространенная схема. Вот только в абсолютном большинстве случаев она не работает.
Возьмем, к примеру, малоизвестную инди-игрушку «A room beyond». Оригинал игры был на немецком, но локализацию на английский сделали на профессиональной студии. Правда, с другими языками получилась полная лажа. Вот какие отзывы получала игра:
Ошибки были почти в каждой строке диалогов. Французский, испанский, итальянский — везде были проблемы. Скорее всего, студия отдала перевод текста какому-нибудь студенту или фрилансеру, расценив, что французскую версию все равно никто покупать не будет. И только после того, как локализацию разгромно раскритиковали, они сделали нормальный перевод с помощью профессионалов.
Мы, кстати, здесь не рассматриваем пиратские переводы игр. Потому что упоротых переводов без бюджета с помощью фанатов или переиздателей просто куча.
Этот мем даже не нуждается в представлении — он уже легенда.
Ошибка 1. Встраивать текст непосредственно в код игры или в текстуры
Косяк, который чаще всего случается с инди-играми и проектами, в которых принимает участие небольшое количество разработчиков.
С помощью такого нехитрого способа получается сэкономить немного времени и усилий, но локализовать такие проекты просто до ужаса сложно и неудобно.
Возьмем, к примеру, визуальную новеллу «Бесконечное лето». Она написана на движке Ren’Py. Для геймплея этого вполне достаточно, но вот диалоги реализованы именно в коде игры.
Их нельзя выделить отдельно от кода. И, соответственно, нельзя отдельно экспортировать и перевести. (Если это не так, напишите нам, пожалуйста. Мы не специалисты по Ren’Py).
Встраивание диалогов в текст — это не слишком большая проблема для игр вроде «Бесконечного лета». Но вот некоторые игры идут дальше и встраивают текст непосредственно в текстуры. Чтобы для локализации пришлось менять не строчку текста или кода, а текстуры полностью.
В некоторых случаях так делают вывески в играх. Вместо того, чтобы играться с начертанием и программированием, куда проще сразу сделать текстуру с надписью «Shop».
К примеру, в игре «Test Drive Unlimited» от Atari все дорожные знаки были отрисованы в текстурах. Над их заменой в локализациях решили вообще не заморачиваться — слишком много усилий это требовало. Их оставили как есть.
Правда, и это еще не предел. Создатели игры «Night in the woods» и вовсе запихнули в текстуры сами тексты диалогов. Прикол в том, что шрифт в игре анимирован и каждая буква в игре имеет три начертания. Но вместо анимации текста они использовали борды с буквами. Официального перевода игры так и не вышло — издатели в принципе не собирались переводить ее на другие языки. Фанатский перевод же потребовал просто кучу времени — в том числе и из-за того, что пришлось доставать тексты из текстур.
Посмотрите сами: за секунду анимация одной буквы меняется несколько раз. А с учетом подвязки текста к текстурам локализация превращается в тот еще квест.
Ошибка 4. Локализовать только текст, но не обращать внимание на культурные особенности других стран
Локализация игры — это не только перевод текстов и диалогов. Хотя кого мы обманываем, многие издатели считают именно так.
При локализации игр нужно уделить отдельное внимание ее адаптации культурным особенностям страны, для рынка которой она выпускается. Ведь менталитет, к примеру, Китая или Саудовской Аравии очень сильно отличается от менталитета Франции или США.
Настолько сильно, что даже одна фраза или шутка может привести к полному запрету продаж игры на территории отдельных стран.
К примеру, в файтере Kakuto Chojin одного из героев зовут Асад. Бой с ним ведется на ринге, оформленном в арабском стиле, а в музыкальной теме слышно пение муллы, где проскакивает фраза «Allah Akbar». Локализаторы оставили семпл без изменений, и исламское сообщество посчитало это за оскорбление. Во всех исламских странах игра была запрещена. Так из-за одной фразы компания потеряла довольно большой и перспективный рынок сбыта.
Иногда команды локализаторов вообще стараются убрать спорные моменты, которые даже примерно могут вызвать недовольство на конкретном рынке. Так в игре Fallout 3 был полностью убран кусок квеста, при прохождении которого в городе Мегатонна можно было взорвать атомную бомбу. Локализаторы оставили только варианты «Обезвредить бомбу» и «Оставить в покое».
Десятилетие поиска причин статтеринга
Пациент точно жив. Просто часто фризится.
Впервые автор столкнулся с этой проблемой где-то в 2003 году во время работы над Serious Sam 2. Люди стали сообщать о случаях, когда во время тестирования на пустом уровне движения экрана и мыши оказывались не плавными. Это сопровождалось очень специфическим паттерном на графике частоты кадров, который команда разработки назвала «сердцебиением».
Первой мыслью было то, что где-то в коде закралась ошибка, но никто не смог ее найти. Казалось, что проблема появлялась и исчезала случайным образом — при перезапуске игры, перезагрузке компьютера… но стоило изменить какой-либо параметр производительности, и она исчезала. Затем можно было поменять параметр обратно, и все продолжало работать идеально. Проблема-призрак.
Очевидно, проблема была не только в «Сэме». При запуске других игр она возникала точно так же, наводя на мысли, что тут что-то с драйверами. Но появление статтеринга не зависело от производителя вашего графического процессора. Оно имело место даже при разных API (OpenGL, DirectX 9, DirectX 11…). Единственное, что оставалось общим, так это что статтеринг появлялся то тут, то там на некоторых машинах и игровых сценах.
С выпуском новых игр эта проблема продолжала то появляться, то исчезать. Раньше это затрагивало лишь некоторых пользователей, и все ограничивалось просьбами со стороны техподдержки изменить кое-какие параметры производительности — что иногда помогало, а иногда нет, никогда не угадаешь.
Затем внезапно, в один прекрасный зимний день в начале 2013 года, ребята из Croteam обнаружили еще один пример этой проблемы, который на тот момент можно было относительно последовательно воспроизводить — на этот раз на одном из уровней в «Серьезном Сэме 3». Они долго возились с той сценой, пока вдруг не осенило. Все было настолько просто — неудивительно, что целое десятилетие это ускользало от всеобщего внимания.
Изменив всего одну простую опцию в игровом движке, у них получилось решить эту проблему. Однако сразу стало ясно, что на самом деле решение потребует гораздо больше времени и усилий. И не только от конкретной команды, но и от всей игровой экосистемы: разработчиков драйверов ГП, специалистов по сопровождению API, поставщиков ОС — всех.
Краткая история синхронизации кадров
Давным-давно, в далекой-далекой галактике… когда разработчики создавали первые видеоигры, обычно они это делали с учетом точной частоты кадров, на которой работал дисплей. В регионах NTSC, где телевизоры работают с частотой 60 Гц, это подразумевает 60 кадров в секунду, а в регионах PAL/SECAM, где телевизоры работают с частотой 50 Гц, — 50 кадров в секунду.
Большинство игр представляли собой очень простые концепции, работающие на фиксированном оборудовании — обычно на аркадной консоли или хорошо известном «домашнем микрокомпьютере», таком как ZX Spectrum, C64, Atari ST, Amstrad CPC 464, Amiga и т. д. Таким образом, создавая и тестируя игры для конкретной машины и определенной частоты кадров, разработчик всегда мог быть на 100% уверен, что фреймрейт никогда никуда не упадет.
Скорости объектов также сохранялись в «кадровых» единицах. Таким образом, вам необходимо было знать не на сколько пикселей в секунду будет перемещаться персонаж, а на сколько пикселей в кадре. Например, в Sonic The Hedgehog для Sega Genesis такая скорость составляет 16 пикселей на кадр. Многие игры даже имели отдельные версии для регионов PAL и NTSC, где анимация рисовалась от руки специально для 50 и 60 FPS, соответственно. По сути, работа с любой другой частотой кадров была просто невозможна.
И поскольку со временем игры стали запускаться на более разномастных устройствах, включая ПК с постоянно расширяемым и обновляемым оборудованием, нельзя было точно знать, на какой частоте кадров будет работать игра. Этот факт усугублялся тем, что сами игры стали более сложными и непредсказуемыми — особенно это заметно в 3D-играх, где могут быть большие различия в сложности сцены, иногда даже определяемые самими игроками. Например, всем же нравится стрелять по штабелям бочек с горючим, тем самым вызывая красочную череду взрывов… и неизбежное падение частоты кадра. Но поскольку это весело, то никто и не против.
Поэтому сложно предсказать, сколько времени потребуется для моделирования и рендеринга одного кадра. (Обратите внимание, что на современных консолях у нас, можно считать, фиксированное оборудование, но сами игры при этом все равно довольно непредсказуемы и сложны.)
Если вы не можете быть уверены, с какой частотой кадров будет работать игра, вам необходимо измерить текущую частоту кадров и постоянно адаптировать физику игры и скорость анимации под нее. Если один кадр занимает 1/60 секунды (16,67 мс), а ваш персонаж бежит со скоростью 10 м/с, то он перемещается на 1/6 метра в каждом кадре. Но если кадр вдруг начнет занимать 1/30 секунды (33,33 мс), то вы должны перемещать персонажа уже на 1/3 метра за кадр (в два раза «быстрее»), чтобы он продолжал двигаться с той же видимой скоростью.
Как это устроить? Как правило, игра замеряет время в начале соседних кадров и вычисляет разницу. Это довольно простой метод, но он работает очень хорошо.
Вернее, раньше работал очень хорошо. Еще в 90-х, когда 35 FPS считалась ого-го какой скоростью, люди были им более чем довольны. Но в то время видеокарты не были столь значительной частью ПК, и контроль надо всем происходящим на экране имел центральный процессор. Если у вас не было 3D-ускорителя, он даже сам рисовал объекты. Таким образом, он точно знал, когда они попадут на экран.
Как такое возможно?
Давайте рассмотрим это подробнее. Ниже представлено параллельное сравнение идеального плавного видео и видео со статтерингом:
Шесть последовательных кадров с точной синхронизацией. Наверху — правильно расположенные кадры, внизу — кадры со статтерингом.
Здесь можно увидеть две вещи: во-первых, они действительно работают с одинаковой скоростью: всякий раз, когда появляется новый кадр сверху (правильный), тогда же появляется новый кадр и снизу (статтеринг). Во-вторых, по какой-то причине кажется, что они двигаются немного иначе — в середине изображения есть заметный «разрыв», который колеблется между большим и меньшим разделением по времени.
Самые внимательные могут заметить еще одну любопытную деталь: нижнее изображение — якобы более «медленное»… на самом деле идет «впереди» правильного. Странно, не правда ли?
Если мы посмотрим на несколько последовательных кадров и их время, мы можем наблюдать еще кое-что интересное: первые два кадра идеально синхронизированы, но на третьем кадре дерево на «более медленном» видео значительно опережает свой аналог на «правильном» видео (обведено красным). Также можно заметить, что этот кадр явно занял больше времени (обведено желтым).
Подождите, подождите… но если видео «медленнее», а кадр «занял больше времени», то как оно может идти с опережением?
Для понимания дальнейших объяснений сначала необходимо разобраться, как современные игры и другие 3D-приложения вообще выполняют анимацию и рендеринг.
Ошибка 5. Оставлять локализацию на самый конец
Казалось, учитывать возможность перевода игры на другие языки должен каждый высокобюджетный проект. Ведь игры, собственно, для того и переводят, чтобы расширить рынки и вывести проект в другие страны.
Но даже разработчики игр ААА-класса иногда серьезно прокалываются с принципами локализации.
Возьмем, к примеру, культовую игру «Witcher 3: Wild Hunt». Что касается художественной части и озвучки, перевод на русский крайне хорош. На наше мнение в литературном плане это один из лучших переводов игр за все годы существования индустрии.
Но косяк все-таки был. И он подпортил игровой опыт многим. Это ускорение или замедление озвучки диалогов на русском.
Суть в том, что разработчики в «Ведьмаке» поставили жесткие тайминги диалогов, которые привязаны к коду. Что касается английской версии — здесь никаких проблем, ведь именно по ней устанавливали тайминги. А вот с переводом на другие языки получился косяк. Ведь переводы диалогов далеко не всегда совпадали по длительности с оригиналом. А тайминги-то жесткие, их не изменишь. Вот и пришлось укладчикам замедлять или ускорять диалоги. Если на скорости х1,1 это еще не заметно, то на х1,3 все уже очень плохо.
Как говорили сами разработчики, они приняли решение не переделывать код и допустить подобный костыль в локализациях. В самом начале они не учли этого, а вмешательство в код игры для установки гибких таймингов уже после завершения тестирований обошлось бы слишком дорого в плане затрат ресурсов — ведь по сути тестирования пришлось бы начинать заново.
Локализация игр — это больше, чем просто перевод. Тут не хватит просто хорошо знать английский, чтобы делать высококачественный продукт. Но мы предполагаем, что знания языка уже находятся на высоком уровне — это основа, без которой никакие ухищрения не помогут. Так что учите английский. А специалисты EnglishDom в этом помогут!
Только для читателей Хабра первый урок с преподавателем по Skype бесплатно! А при покупке занятий получите до 3 уроков в подарок!
Получи целый месяц премиум-подписки на приложение ED Words в подарок.
Введи промокод locafail на этой странице или прямо в приложении ED Words. Промокод действителен до 24.02.2021.
Различные предостережения и другие детали
Будем считать, что это конец основного текста. Разделы ниже представляют собой «бонусные функции», в основном независимые друг от друга и от описанного выше.
«Композитор»
Это что, эффект матового стекла? Ага, так вот почему у нас обязательно должен быть композитор. Довольно важно, не правда ли?
Во всем этом за кулисами задействована концепция под названием Compositing Window Manager, также известная как композитор. Это система, которая теперь присутствует в каждой ОС и позволяет окнам быть прозрачными, иметь размытый фон, тени и т. д. Композиторы могут пойти и дальше — и показывать окна ваших программ в 3D. Для этого композитор берет на себя управление самой последней частью кадра и решает, что с ним делать, непосредственно перед тем, как он попадает на монитор.
В некоторых ОС композитор можно отключить в полноэкранном режиме. Но это не всегда возможно, и даже в таких случаях — разве не можем мы запустить игру в оконном режиме?
Ошибка 2. Перевод игры без самой игры
Нельзя просто отдать на аутсорс кучу таблиц с текстами и ожидать, что у вас получится идеальная локализация.
В идеале, конечно, перевод любой игры требует детального разбора всех игровых моментов и создания общего глоссария. А если термины, имена и локации уже имеют установленный перевод в других играх или источниках сеттинга, то нужно использовать именно их.
Даже небольшие расхождения могут негативно влиять на игровой процесс.
К примеру, игра Baldur’s Gate (1998) основана на сеттинге настольной игры D&D. При этом во всем сеттинге нет каких-нибудь единых переводов названия города Baldur’s Gate. В разных локализациях игровых книг и игр серии его переводят как Врата Балдура, Врата Бальдура или Балдурс Гейт. И это главный номинатив. Что касается остальных, то там вообще все как попало.
Но понятно, что для детального и полного разбора лора и всех нюансов игры всегда нет времени. В таком случае нужно, чтобы локализаторы хотя бы видели игру и могли проверить диалоги в самом контексте.
Ведь иногда в таблицах текстов даже не указан пол персонажа — все приходится додумывать самостоятельно. Вот поэтому и случаются фейлы вроде легендарной озвучки TES IV: Oblivion.
Хотя если честно, конкретно этот пример — это косяк программистов, которые вытащили тексты диалогов без минимального контекста и привязки к персонажам, поэтому актерам пришлось озвучивать их вслепую.
Что теперь?
Ну, все не так уж и плохо. Много кто активно работает над реализацией поддержки правильной синхронизации кадров для разных API. Vulkan API уже имеет расширение под названием VK_GOOGLE_display_timing, которое зарекомендовало себя в реализации этой концепции, но оно доступно только для ограниченного числа устройств.
Ведется работа по предоставлению похожих и более лучших решений, хотелось бы верить, что уже во всех основных графических API. Когда? Сложно сказать, ведь проблема глубоко врезается в различные подсистемы ОС.
Тем не менее, мы надеемся, что вскоре это станет доступным для более широкой общественности.
Неужто это всё?
Конечно же нет. Это далеко не все разновидности игровых багов, но, пожалуй, самые часто встречаемые. Здесь я не затрагивал баги несоответствия, такие как "элемент записан в blueprints по одному, на back-end - по другому, объект или его атрибуты (ID, описание и т.д.) забыли куда-то добавить и прочее. А не затрагивал их, т.к. это больше не про специфики игр, а в целом неисправности, которые могут быть во многих программах.
А с какими багами вы встречались во время игры или работы над игрой? Буду рад пообщаться с вами на эту и другие релевантные темы в комментариях!
Индустрия компьютерных и консольных игр сегодня переживает колоссальный подъем. Каждый год выходят тысячи проектов, среди которых как минимум несколько десятков ААА-игр.
Но несмотря на масштабы отрасли, в локализациях игр все еще допускают идиотские ошибки, которые не только сильно портят впечатление от игры, но иногда и вовсе не позволяют нормально сделать перевод.
Кривая локализация или вовсе невозможность ее нормально сделать — это огромные убытки для проекта. Поэтому сегодня мы с вами разберем 5 ошибок, которые приводят к косякам локализации.
Значит, решение настолько просто?
К сожалению, нет. Это было просто только на тестах. Если бы мы прекратили измерять частоту кадров в реальных условиях и просто предположили, что она всегда равна 60 FPS, тогда, когда она упадет ниже 60 — а на ПК она рано или поздно упадет по какой бы то ни было причине: работа программ в фоновом режиме, сохранение энергии или защита от перегрева, кто знает, — тогда все замедлится.
Итак, если мы измеряем время кадра, происходит статтеринг, а если нет, в какой-то момент все может замедлиться. И что тогда?
Реальным решением было бы измерение не времени начала/окончания рендеринга кадра, а времени, когда изображение показывается на экране.
Но как игра может узнать, когда кадр действительно отображается на экране?
Да никак: в настоящий момент этого сделать невозможно.
Странно, но факт. Можно было бы ожидать, что это будет базовой функцией каждого графического API. Но нет: они претерпели изменения во всех других аспектах, кроме этого. Нет способа узнать наверняка, когда кадр действительно отобразится на экране. Можно выяснить, когда закончился рендеринг. Но это не то же, что время отображения на экране.
Что происходило все это время
Вот как это выглядит, когда игра «тормозит» даже при 60 FPS. Вы могли испытать нечто подобное, играя в любую современную игру, и, вероятно, первым делом подумали бы, что игра не оптимизирована. Что ж, давайте пересмотрим эту теорию.
Если игра «слишком медленная», это означает, что в некоторых моментах она не сможет отрендерить один кадр достаточно быстро, и монитору придется снова показать предыдущий кадр. Поэтому, когда мы снимаем видео со скоростью 60 кадров в секунду, оно должно показывать «пропущенные кадры» — когда следующий кадр не был отображен вовремя, отчего один и тот же был показан дважды.
Однако это происходит только тогда, когда вы воспроизводите всю анимацию целиком. Если бы вы перебирали ее покадрово, то никаких разрывов бы не обнаружили.
А не могли бы мы просто.
Не могли бы. :) Обычно измерение времени ГП предлагается как альтернатива времени отображения. Но при этом не учитывается наличие композитора и тот факт, что ни один из таймеров рендеринга ГП по факту не синхронизируется напрямую с обновлением дисплея. Для идеальной анимации нам определенно нужно точно знать время, когда изображение было выведено на экран, а не когда оно закончило рендеринг.
Сид Мейер как-то сказал, что «Игра — это последовательность интересных выборов». А значит, перед выпуском игры в массы тестировщик должен убедиться, что все выборы в игре интересные и работают правильно. Да и вообще работают!
Игровая механика представляет собой набор правил, по которым работает игра, и математическую модель, которая стоит за этими правилами. Вместе с дизайном уровней и системой обратной связи с игроком эти три столпа составляют тот самый геймплей. Вот по нему и оценивают геймеры свои впечатления об игре.
На каждом из этих этапов встречаются баги и недоработки, потому что игра — это комплексный труд нескольких человек, а когда речь идёт про AAA-проекты — даже не одного десятка людей. И допустить ошибку в одном из компонентов игры довольно легко.
Сегодня мы затронем тему не только локализационного, но и функционального тестирования. А помогать нам будет наш эксперт и руководитель отдела тестирования, Андрей Васильев.
Чтобы успешно заводить баги, нужно их систематизировать. Разделить и властвовать.
Итак, баги в играх можно условно классифицировать по следующим категориям.
- Баги функциональности. Не работают или неправильно работают какие-то функции в игре. Например, при переходе в настройки приложения происходит аварийное завершение работы.
- Баги интерфейса. Искажается графика, элементы не находятся на своих местах, текст не вписывается в отведенные ему рамки.
- Баги локализации. Ошибки в текстах, присутствие непереведённых строк. Скажем, вместо перевода выводятся заглушки, вроде «russian_text_001».
- Баги производительности. Приложение на устройстве работает медленно. Например, во время анимации атаки персонажа FPS заметно «проседает» на устройствах high-end сегмента.
- Баги логики и баланса. Выставленные настройки баланса и игровой логики не позволяют пройти игру или достигнуть нужных целей. К примеру, персонаж наносит урон в 100 единиц, вместо 150 обещанных в игре.
- Технические баги. Игра неправильно работает в условиях нестабильного интернет-соединения, как вариант, приложение не может подключиться к серверу в 3G сетях.
- Баги совместимости. Игра попросту не работает на совместимом устройстве или запускается с критическими ошибками.
Потренируемся: какой это баг по классификациям? Если вы ответили «Функциональный, низкоприоритетный, графический, затрагивающий команду разработки», то ура — вы тестировщик (нет)
Багам присваивается степень критичности: какие-то устраняются в первую очередь, а какие-то можно даже оставить в финальном релизе:
- максимальный приоритет — баги явно не дают игроку пройти дальше, влияют на способность приложения приносить деньги;
- средний приоритет — баги заметны пользователям, но не влияют на прогресс игрока или на заработок приложения;
- низкий приоритет — баги практически незаметны игрокам, очень редко воспроизводятся или только в очень ограниченных условиях, не мешают прогрессу и заработку.
Иногда разработчики специально оставляют низкоприоритетные баги в игре — для вирусного эффекта. В конце концов, это ведь уморительно, а игры должны развлекать, так почему бы и да?
Баги различают по затрагиваемой стороне. То есть кому они будут больше всего мешать использовать продукт:
- баги, затрагивающие пользователей. Влияют на популярность приложения, средний рейтинг в магазинах приложений;
- баги, затрагивающие бизнес. При этом могут не мешать пользователям. Например, игра слишком простая: это радует игроков, но не побуждает их вкладывать деньги;
- баги, затрагивающие команду разработки. Если функционал реализован не так, как задумывала команда, что не замечают пользователи (они не знают, как задумывалось) и не мешает приложению зарабатывать деньги.
Действительно, от чего? Почему в одних играх их просто огромное количество на альфа-тестах (привет, No Man’s Sky), а в других — практически нет? Всё довольно очевидно.
- В первую очередь это зависит от опытности команды разработки.
- На втором месте стоит техническая сложность проекта. Шансы появления багов прямо пропорциональны количеству кода и числу используемых библиотек.
- На третьем месте — количество возможностей в игре и разнообразие игрового процесса в целом.
- Серьёзная статья — это сетевой режим и пути взаимодействия игроков друг с другом. Для сетевого режима разработчики зачастую даже в играх, уже прошедших тестирование на этапе производства, запускают закрытые тестирования для настройки баланса и поиска неочевидных багов.
- Ну и конечно, прямая зависимость от эффективности тестирования именно на раннем этапе разработки. Дело в том, что чем больше багов будет найдено как можно раньше, тем меньше шансов, что эти баги позже приведут к появлению новых.
- RPG с сетевым режимом. Большой мир, масса сценариев взаимодействия игроков друг с другом;
- Игры с открытым миром. Очень много возможностей поведения игрока, которые надо тщательно тестировать;
- Любые игры с мощной графической составляющей. Практически невозможно одинаково оптимизировать игру под все устройства, если речь не о консольных тайтлах.
Сравнительно проще тестировать игры, где действия игрока ограничены, их реально проверить все за обозримое время теста. В основном, это казуальные игрушки:
- игры в жанре match-3. Здесь игрок ограничен только игровым полем и комбинациями фишек, бонусов и количеством игровых механик;
- игры в жанре hidden objects (поиск предметов), в которых, как правило, свобода игрока ограничена;
- файтинги;
- казуальные игры, действие которых происходит на одном экране — тайм-менеджеры, кликеры, shoot’em up и т.д.
Такова классификация багов с нашей точки зрения. В ходе написания материала мы нашли интересное видео с выступлением Дмитрия Химиона про «Тестирование игровой механики в компьютерных играх». Он утверждает, что есть ещё одна классификация ошибок в игре.
Появляются точки на локации вне досягаемости игрока. Застревания в текстурах, кстати, относят сюда же. И надо справедливости ради заметить, что застреваем мы вовсе не в текстуре, а в геометрической модели, потому как текстура — это картинка. Значит, левел дизайнер где-то ошибся и наделал лишних порогов и ступенек, а нога героя застряла и, пытаясь подчиниться законам физики, начинает вытворять невообразимое
Нет звукового или визуального подтверждения при совершаемых игроком действиях, когда игрок недополучает информацию о своём действии, когда он не понимает, кто и откуда его убил (никаких предпосылок — визуальных или звуковых — для этого не было).
Сюда относят все ошибки, связанные с элементами контроля и управления. Они могут возникать при неверной калибровке и невозможности сменить в настройках чувствительность мыши или аналоговых стиков.
Игровой баланс — это качественная характеристика, определяющая уравновешенность игровых сущностей и показателей, а еще поддерживающая интерес к игре. Само создание игрового баланса сопряжено с постоянным тестированием, поэтому ошибкой тут может считаться только незавершенное тестирование.
Несбалансированным может быть оружие, делающее бессмысленным использование любого другого, или дизайн уровня, позволяющий получать преимущество в определенной точке карты без риска. Словом, любые просчеты в балансе, делающие неинтересным игровой процесс в долгосрочной перспективе.
Знаменитая BFG 9000, несмотря на безумную мощь, является сбалансированным оружием — боеприпас на неё найти непросто
А с какими багами сталкивались вы? Присылайте нам в комментарии — похохочем, что ли.
И вообще, доверяйте свои игры профессиональным тестировщикам, да поменьше багов вам в готовых продуктах: далеко не все из них станут легендарными, вроде знаменитого «geddan».
Статья, конечно, не исчерпывающая, но будет полезна для обычного игрока, который в основном считает, что тестирование это альфа и бета, а второе проводится только в рекламных целях. Неплохо было бы еще и про требования расписать, какие бывают и откуда берутся.
Требования - это старый миф. Наиболее олдовые айтишники на древних форумах пишут, что существуют такие мифические существа как аналитики. По легенде, они подпускают к себе только девственниц и ПМов. Говорят, что когда Луна находится в нужной фазе, а звезды сходятся под верным углом, аналитик может окуклиться у себя на рабочем месте. Если правильно ухаживать за этой куколкой, то спустя 3-5 рабочих дней погружения в астрал и взаимодействия с эфиром, куколка аналитика раскрывается и тогда у проекта появляются записанные на священных скрижалях заветы - требования.
К сожалению, из-за вырубки лесов и вмешательства человека в экологию, сейчас этих дивных существ почти не встретишь, а потому труд обычного тестировщика тяжел и неблагодарен, поскольку приходится работать без требований.
* согласно исследованию. Имеются противопоказания. Перед применением проконсультируйтесь со специалистом!
Исследования показали, что есть прямая связь между скиллом в видеоиграх и мастерством в хирургии.
В результате исследования была обнаружена прямая связь между умением в видеоиграх и мастерством в малоинвазийных операциях и лапароскопической хирургии. Молодые хирурги, которые ранее играли минимум три часа в неделю на видеоигры, совершали на 37% меньше ошибок, были на 27% быстрее во время работы и, набирали в целом на 42% больше очков, чем хирурги, которые вообще никогда не играли в видеоигры.
В исследовании, проведенном в 2007 году медицинском центре Beth Israel в Нью-Йорке, были задействованы 21 молодых врачей со средним опытом работы от трех лет и еще 12 врачей старшего возраста с почти 13-летним стажем.
Каждого опрашивали об их геймерских привычках, а затем оценивали, когда они принимали участие в полуторадневном курсе, на котором хирурги оценивали время и ошибки во время имитационных хирургических упражнений. Геймерские навыки также оценивались в течение трех 25-минутных игровых сессий.
Среди участников эксперимента 42% никогда не играли в видеоигры, в то время, как 30% играли почти ежедневно.
Была зафиксирована прямая корреляция между навыками геймера и мастерством в лапароскопической хирургии: те, кто набрал наибольшее количество баллов в видеоиграх, лучше всех выполняли симуляцию хирургического курса
Геймеры, принявшие участие в эксперименте, допустили на 31% меньше ошибок, были на 24% быстрее и набирали на 26% больше очков, чем их коллеги, которые никогда не играли в видеоигры.
Треть участников составили топ-группу геймеров - они сделали на 47% меньше ошибок, выполняли задачи на 39% быстрее и на 41% лучше, чем те, кто проводил меньше времени, играя в видеоигры.
Авторы смогли предположить, что видеоигры могут быть практичным учебным инструментом в процессе подготовки хирургов.
Но Королевский колледж хирургов заявил, что исследование, проведенное профессором Арой Дарзи из хирургического отделения больницы Сент-Мэри в Лондоне, не показало никакой связи между видеоиграми и сноровкой в хирургии.
В первой статье мы поговорили о видах тестирования, применяемых в играх, а теперь поговорим о результате, который смущает PMов, вводит в краску разработчиков и так крайне не терпим Product Owner'ами на продакшене - багах. Сегодня я их также классифицирую и покажу вам некоторые из них на примерах.
Думаю многие видели этот баг из Assassins Creed. Причины могут быть разные - не подгрузился mesh или материал или материал и вовсе неправильный. А также не стоит исключать возможность включения LOD mesh, котороый не установлен
Было бы странно, если в такой комплексной системе как видео игры не было багов. Они есть, встречаются часто и этот бестиарий здесь крайне разнообразен. Ознакомившись с вышеприведёнными видами тестирования для игр, думаю вы догадываетесь, что и баги в видео играх встречаются далеко не только "404 not found" и "game crashed". Давайте же пробежимся по самым часто встречающимся из них в игровой индустрии!
В категорию Visual багов войдут: любые видимые артефакты (Visible Artefacts), пропущенные текстуры (missing textures), Clipping, Culling, Screen tearing, Z-fighting.
Примеры визуальных багов можете посмотреть ниже:
Visual Artefacts - любые визуальные баги, не подпадающие под другие виды.
Вупс. Что-то пошло не так
Missing Textures - пропущенные/исчезнувшие текстуры. Обычно на их месте стараются ставить "заглушку" в виде яркой текстуры по умолчанию в виде шахматной доски. Это не обязательно, но благодаря такому подходу, пропущенные текстуры видны не вооруженным взглядом.
Пропущенная текстура и хороший пример "шахматки" вместо потерянного файла
Z-fighting - данный баг появляется, когда несколько примитивов расположены на примерно одинаковом расстоянии до камеры и они имеют фактически одинаковые значения в Z-buffer, которые отслеживают глубину. Из-за этого примитивы могут частично отображаться один над другим.
Screen Tearing или "разрыв экрана" - это визуальный артефакт, при котором отображается информация из нескольких кадров на одном изображении.
Culling и Clipping - баги, относящиеся к работе рендера и графического пайплайна. Часто - пересечение двух объектов, при котором один закрывает геометрию другого, скрывая ее от взгляда. Если немного углубиться, то Culling - это отсечение того, что заведомо невидимо. В таком случае игра даже не будет пытаться отрисовать данный сегмент. Culling бывает разным и вот его примеры: rustrum culling - отсечение по пирамиде видимости, backface culling - отсечение "задних" граней, occlusion culling - отсечение граней факту их перекрытия другой геометрией, depth culling - перекрытие одной геометрии другой, которая уже была нарисована, но на основе depth buffer. А вот когда рисуется достаточно большой полигон и от него отрезается всё то, что заведомо находится за пределами экрана - это уже Clipping.
Также отдельно стоит выделить похожий, но в сути другой баг - проблемы коллизий. В видеоиграх отсечение может быть связано с набором алгоритмов, которые реагируют на взаимодействие двух смежных или перекрывающихся геометрий (collision detection). А для выявления таких багов существуют специальные режимы просмотра (view modes), но об этом я расскажу в следующей статье.
Вот так можно легко "войти" в объект с кривой коллизией (или без неё вовсе) Баг такого рода также можно описать термином occlusion, т.е. перекрытие одного объекта другим не так как задумано.
В рамках Audio bugs группы выделю достаточно базовые, но не менее надоедливые вещи: не возможность проиграть SFX/музыки/диалога, пропуск (тригера) проигрыша, плохое микширование (звук слишком тихий или громкий), искажения (distortions), дропы.
Баги левел дизайна - невидимые стены (invisible walls), пропасти в карте (map holes), застревания (stuck spots) и т.д. Также к багам левел дизайна я бы отнёс баги связанные с нав мешем (Navigation Mesh). Ниже приведу несколько примеров багов левел дизайна:
Invisible Walls (невидимые стены) могут являться как багом, так и фичей. Ранее так ограничивали передвижение персонажа игрока и не давали уйти дальше нужного. Сейчас же стараются не создавать "невидимых препятствий", а ограничивать "проходимость" при помощи левел дизайна, к примеру выставить непроходимую преграду, баррикаду, горы, ворота города и т.п. Показывать игроку, что впереди что-то есть, но при этом использовать невидимые стены для недопуска персонажа в эту зону - признаки плохого левел дизайна. Сейчас так почти не делают и невидимые стены часто могут быть следствием реконструкции уровня: к примеру какую-нибудь модель могли забыть убрать или добавили невидимых элемент в качестве временной заглушки.
Герой не может пройти дальше из-за невидимой стены, однако дорога всё не заканчивается.
Map Holes чаще всего вызваны не плотным прилеганием плоскостей объектов (пол, стены и т.п.). Это места, где пользователь может, незапланированно для разработчиков, попасть за границы игровой зоны. Такие баги часто ещё называют Out of Bounds.
А вот так ваша игра выглядит "изнутри"
Баги Navigation Mesh часто связаны с перестройкой уровня или автоматической генерацией сетки. К примеру вы передвинули предметы, однако навигационная сетка осталась старой. Как следствие, ваши NPC могут "идти в стену" или любой другой предмет, который они не смогут обойти и встрянут там (один из случаев Stuck Points).
Здесь Nav Mesh проходит сквозь объекты в красном круге
Ошибки искусственного интеллекта (AI): NPC не двигаются, застряли, не следуют за игроком, предполагаемое взаимодействие с предметами не работает, застревание, NPC делают то, что не задумано изначально и т.п.
Раз уж у нас есть и часть движка, отвечающая за физику, то было бы странно, если бы и багов с физикой не было. Тут может быть почти что угодно: левитирующие объекты, нереалистичная физика, ускорение свыше нормы, а также взмывание предметов " в космос" из-за сложения векторов при обработке контактов. Баги такого рода вы могли видеть в мемах самых разных игр, например GTA 5 или, из актуалочки, Cyberpunk 2077. Хороший разбор многих багов из Cyberpunk 2077, включая только что описанные, можно посмотреть тут.
Плотва, что ты делаешь. Летающие машины в Cyberpunk 2077 - не редкость
Баги стабильности и перформанса включают в себя фризы, краши, чёрные экраны, невозможность загрузить уровень, видимая для пользователя подгрузка хай поли моделей или вообще каких-либо объектов, просадка FPS, дооооооооолгая загрузка, а также микрофризы (подгрузки). Сюда же добавлю слишком долгую инсталляцию игры, а также невозможность запустить игру на ПК с минимально допустимыми требованиями.
Извините, я вас не узнал. У вас лицо не прогрузилось
Не редко встречаются и баги совместимости. Особенно частые примеры выглядят следующим образом: на некоторых видеокартах могут встречаться краши (к примеру на минимально возможных требованиях или новых видеокартах на рынке), контроллеры той или иной фирмы не работают, игра не запускается на какой-то определённой версии ОС, беспроводная гарнитура выдаёт звук в моно и т.п.
О проблемах онлайн игр наслышаны все. Плохое соединение, лаги, "невидимые игроки" или же "я зашёл за угол, а меня убили", ошибки подсчёта очков, невозможность реконнекта (если такая фича есть), потеря пакетов во время игры, расхождение в подсчётах информации между клиентом, дедикейтед сервером и бек эндом. Также при плохом соединении некоторые элементы интерфейса можно использовать по несколько раз, что-то может не прогрузиться и "пропасть" и т.д., но, как правило, это UI баги и сильно не влияют на user experience игрока.
С таким количеством повторений, походу это уже не баг, а фича. Пора вводить очереди как в Diablo 2
Под баги локализации и compliance, из нетривиального, можно отнести локализацию рекламы, размещение разных материалов на одних и тех же местах в разных регионах и странах (к примеру в этой стране запрещено к показу одно, а в другой - не запрещено или же возрастной ценз, под которые подпадает игра, может не разрешить что-либо показывать в том или ином регионе). Манипуляции с датой на вашем устройстве и сбой работы клиента с сервером я бы тоже отнёс сюда. Ну и "классические" баги локализации и интернационализации никто не отменял. Больше про них и о подходах к их правильному и полному тестированию можете прочитать в моей статье.
Зачем мне текст? И так же понятно куда клацать! И люди, и кони, и всё-всё тут намешано
Читайте также: