Дневники разработчиков: исправление крашей

Танкисты!

Мы знаем, насколько для вас важно решение критичных проблем, которые мешают играть. К числу таких относятся вылеты во время боя. После установки версии 0.25 игроки могли столкнуться с подобной ситуацией, потому мы решили рассказать, как велась и ведется сейчас работа над ее исправлением. В патче, установленном 20 июня, большинство проблем было устранено. Тем не менее, часть вылетов сохранилась и жалобы еще есть. Мы попросили разработчиков рассказать о ситуации с крашами в игре и о борьбе с ними.

Краши — критичная проблема для игроков. Мы понимаем, насколько они мешают погрузиться в процесс игры и просто получать удовольствие. Устранение крашей или хотя бы снижение их количества — одна из основных задач. Причинами падений могут служить абсолютно разные события. Чтобы их выявить — необходимо собрать достаточное количество данных. При этом важно понимать, что зачастую такие проблемы на стороне разработчика не воспроизводятся. Потому особенно важно, чтобы вы отправляли автоматически формирующиеся отчеты в случае появления ошибки.

Техническая информация, которую вы отправляете, попадает в разные категории проблем сообразно их причинам: следовательно, работы над ошибками могут проводиться разными командами. Ниже, в части «Исправление крашей», мы на конкретных примерах расскажем об исправлении отдельных падений.

Ниже приведены графики, на которых видно, как меняется ситуация с крашами от предыдущей версии игры — «Карибский кризис» — к версии «Кавказский конфликт», а также в зависимости от разрядности версии операционной системы, используемой игроком. Данные представлены за период с 15 мая по 28 июня.

Рис. 1. Диаграмма крашей на примере версий 0.24 и 0.25 на 32-битных ОС

Рис. 2. Диаграмма крашей на примере версий 0.24 и 0.25 на 64-битных ОС

Вы видите общую статистику по падениям за каждый день. Обратите внимание: на 32-разрядных ОС в момент установки обновления 0.25 «Кавказский конфликт» общее количество крашей в день снизилось относительно мая. При этом у игроков с 64-разрядной ОС, наоборот — увеличилось.

Подробнее про 32-разрядные ОС

Важно отметить: над тем, чтобы клиент был более стабилен при работе на 32-разрядных ОС, велась целенаправленная работа, и ее результат мы видим на графиках.

Проблема 32-битных ОС в том, что приложение ограничено ресурсом памяти в 2 ГБ. То есть больше 2 ГБ памяти оно занимать не может и падает при попытке выделить лишнее. На самом деле, это происходит гораздо раньше, из-за фрагментации памяти. Фрагментация может приводить к тому, что уже после 1,5–1,6 ГБ не находится достаточно большого свободного куска памяти, который нужно выделить. Большинство падений на 32-разрядных ОС связано с нехваткой памяти. Поэтому мы и занимались оптимизацией ее потребления игровым клиентом. Это снизило эффект фрагментации.

Однако мы все же рекомендуем по возможности переходить с 32-битных версий ОС на 64-битные, так как из-за слишком ограниченного объема памяти работа больших приложений на них менее стабильна. Кроме того, производители ПО и железа начинают отказываться от поддержки 32-разрядных систем. Например, Nvidia объявила, что прекращает обновление драйверов для 32-битных ОС.

На рисунках выше цветом обозначены краши в разных патчах (номера патчей и соответствующие им цвета указаны на рисунках справа вверху). Красным выделены периоды после установки патча 20 июня, в котором часть причин крашей была устранена. Здесь мы видим, что количество падений клиента на 64-разрядных ОС значительно снизилось. Немного уменьшилось оно и на 32-разрядных ОС.

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

Мы пообщались с руководителем команды игрового клиента Алексеем Петрановским и ведущим программистом игровой механики Маратом Радченко. Они подробно рассказали нам о процессе работы над исправлением отдельных причин крашей: сборе статистики, анализе и поиске решения.

Рассмотрим случай, когда игрок прямо во время боя «вылетает» из игры и у него появляется автоматически сформированное сообщение о проблеме. Попав в такую ситуацию, вы спешите вернуться в бой и вновь загружаете Armored Warfare, не добавляя в сообщение дополнительные комментарии. Но это не критично. Главное — отправить отчет, нажав соответствующую кнопку («Отправить»). Это займет буквально 1–2 секунды. Далее все эти отчеты поступают к разработчикам в своеобразный коллектор.

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

• Клиент вызывает различные функции.
• При сборе данных список этих функций передается разработчикам.
• Далее, в зависимости от этого списка, генерируется код, характеризующий данную проблему. В дальнейшем всем ошибкам такого типа (с подобным набором вызываемых в момент падения функций) присваивается этот код. Когда разработчик, занимающийся решением конкретной проблемы, собирает полученные от игроков данные, он может легко отсортировать их по коду. Так становится понятно, каков процент той или иной проблемы (см. рис. 3).

Рис. 3. Диаграмма ошибок

Вы видите список крашей, на появление которых влияют разные факторы. При этом некоторые из них выглядят одинаково, находятся в одной главной категории, но немного различаются причинами. Поэтому подкатегории в этих случаях разные (ниже приведены примеры с крашами 1 и 3, а также 4, 5 и 7 на диаграмме). Мы попросили рассказать о работе над наиболее массовыми проблемами, которые занимают первые 7 позиций на графике.

1. В обновлении, установленном 20 июня, содержались исправления 1-й и 3-й причин крашей. В этом случае крашился сетевой код, что приводило к падениям клиента у игрока. Эти две проблемы разбирала команда механики, которая занимается вопросами боя и того, что в нем происходит. В результате исправлений количество крашей на основном сервере в целом снизилось на 30%.
2. В случае с крашем 2 DirectX в какой-то момент как бы «теряет» видеокарту, и клиент закрывается с ошибкой. У этого падения может быть много причин: проблемы с видеокартой, ошибки в ее драйвере, перегрев системы, ошибки в рендерном коде игры. Мы можем бороться только с последней. К сожалению, по крашрепортам эту проблему решить очень сложно: требуется найти способ воспроизведения в среде разработки, чем мы и занимаемся. Сейчас это — одна из главных задач для специалистов команды клиента.
3. 4, 5 и 7-й краши появляются в момент, когда игрок видит загрузочный экран при входе в бой. В процессе загрузки основной игровой поток занят именно тем, что грузит ресурсы. А чтобы происходило обновление загрузочного экрана, используется дополнительный поток. Но отдельные части игры не ожидают, что с ними будут работать из неосновного потока, и «падают». Над исправлением этой проблемы работала команда интерфейса. В ближайшем обновлении будет устранена значительная часть таких крашей.
4. Падение под номером 6 искусственно вызывается системой контроля зависаний. Называют такую систему Watch Dog. Она следит за работой игры и, если та не отвечает в течение нескольких минут, вызывает падение. Вызов таких крашей необходим, чтобы мы могли получать информацию о зависаниях, собранную в это время, и имели возможность анализировать состояние игры в моменты зависаний, аналогично с падениями. Такие проблемы могут быть как системными (перегрузка процессора, диска, нехватка памяти на стороне «железа» игрока), так и багом в игре. Данным вопросом также занимается команда игрового клиента.

Как вы уже узнали, в процессе сбора статистики становится понятно, какие из крашей — наиболее массовые, и исправление каких из них будет иметь наивысший приоритет. При этом работы над устранением других проблем ведутся параллельно. Нужно понимать, что сбор статистики по редким крашам еще более важен. Поэтому, если вы столкнулись с такой ошибкой — отправляйте автоматические сообщения. Не надо думать, будто данные отправит кто-нибудь другой: такие рассуждения не помогут скорейшему выявлению причин и решению проблемы. Помните — важны сообщения каждого игрока, столкнувшегося с «вылетами» или другими ошибками.

Важно! Проблемы бывают разного характера. На стороне сервера, клиента, железа и т. д. Некоторые из них могут воспроизводиться на стороне разработки, тогда «отловить» проблему и найти причины проще. Некоторые — не воспроизводятся, тогда важен сбор технических данных от игроков. Вы можете отправлять автоматические сообщения или данные, собранные собственноручно, в службу поддержки, специалисты которой передадут их нам. Мы благодарны всем игрокам, отправляющим отчеты.

На этом все. Надеемся, вам было интересно подробнее узнать о процессе работы с такими аспектами игры.

До встречи на поле боя!