Вход
Регистрация
Тема закрыта
CCP Gangleri | 2009.07.08 21:03:28 | Оригинал блога
Мы недавно исправили баг, который вызывал зависание клиента у некоторых наших пользователей. Были топики на форумах призывающие снести нам головы и тому подобные злобные высказывания. Что можно понять, мы напортачили. Этот блог - это совместная работа меня и CCP GingerDude посвященная раскрытию истории этого бага.
И так начинаем
Присядьте крошки и дайте мне рассказать вам сказку. Давным-давно в беззаботные дни молодости ЕВЕ, в игру была введена клоака. Это было хорошо, и позволило больше гангкать. Потом, пожелания Создателя были таковы, что клоачный шип должен расклоачиваться, если окажется в 2000 местрах от объекта. Это работало, кроме некоторых случаев, когда кто-то варпнул к станции и не расклоачивался по какой-то странной причине, позволяя пилоту задокаться так, чтобы его никто из других игроков не увидел. Этот баг был описан в середине 2004, но это был частный случай, который происходил только на некоторых станциях. Это не сильно мешало игре, и было сложно починить, поэтому было помечено низким приоритетом и оставлено собирать пыль годами.
Входит CCP GingerDude, которому не нравится, когда баги становятся фичами. Чтобы очистить записи от очень старых проблем, он проанализировал обработку близости связанную с клоакой и изменил механизм, чтобы сенсоры ограниченно чувствовали клоачный объект. Вообще говоря, это считалось хорошей штукой, не считая нескольких мелких проблем, казалось, что оно работает хорошо. Так было, пока кто-то не обнаружил, что если вы появляется на определенном расстоянии от НПЦ оставайся заклоаченным на несколько секунд, то НПЦ будут игрорировать вас, поскольку их сенсоры уже вас обработали, пока вы были заклоаченны и расклоачевание не «будило их» снова.
«Ага», – подумал GingerDude, – «нам нужно создать новое событие, когда объект расклоачивается» и решил ввести изменение состояния с клоачной на расклочившееся. Из-за сложных технических проблем корабль не мог просто сгенерировать событие, когда расклоачивался, поэтому он должен себя пометить «расклоачиваюсь», так чтобы симуляция подхватила этот флажок, сгенерировало событие и закончила расклоачивание. Для всех намеряний и целей, находясь в процессе расклоачивания означало, что вы всё ещё в клоаке пока полностью не расклоачитесь. Это важно.
За несколько дней перед запуском Апокрифа 1.2 новая проблема была открыта. Когда корабли пропрыгивали через гейты было несоответствие состояния клоачности в разных клиентах, в некоторых случаях. Это приводило к тому, что клиент не мог обновить состояние клоачности. Это исправли тем, что клиент стал считать состояние расклоачивания так, как будто корабль уже полностью расклоачился (поскольку он всё равно полностью расклоачится через 2 секунды после этого). Но с этим исправлением появилась другая проблема, когда корабль расклоачивался после пропрыга, другие игроки его видят и способны залочить в течении 1-2 секунд, ещё до того как корабль сможет что-либо сделать сам. Это было не очень хорошо, по очевидным причинам.
Чтобы исправить это последний промах мы изменили правила с «расклоачивается значит заклочен» на «расклоачивается значит расклочен» и обновили в соответствии с эти коды сервера и клиента.
Но мы кое-что пропустили.
Глубоко в редко посещаемых пещерах основ симуляции и взаимосвязи слоёв было прописанное предположение, о том какую информацию может хранить переменная клоачного состояния. Расклоачивание игрока А означало, что его корабль должен быть добавлен в симуляцию всех других клиентов в пределах видимости, но этот кусок кода игнорировал корабли в промежуточном состоянии и не добавлял их в симуляции других игроков в это время.
Так из-за чего же зависал мой клиент?
Если корабль расклоачивался в то же самое время как игрок прогружал сцену, то это вызывало проблемы для последнего, ниже приведена пошаговая инструкция в нашей внутренней системе отслеживания дефектов:
Необходимо 2 аккаунта.
1. Два пилота размещаются на одном гейте
2. Первым запрыгивает А, потом Б на примерно 2 секунды позже
3. когда Б прогружает сцену на другой стороне А должен полететь, чтобы его корабль расклочился.
4. заметьте что сессия игрока Б теперь полностью испорчена.
Так что это не то, что случается обычно, если вы часто прыгаете. Это было очень специфичная последовательность событий, которая должна была произойти в узкий промежуток времени, чтобы обнаружить баг. Но тем не менее около 3 миллионов прыжков случались каждый день на Транке, так что не трудно было оказаться «удачливым» в живом окружении. Вот причина, по которой эта специфичная проблема не была поймана, до того как она попала на Транк, просто маловероятно, что она случится на наших малонаселённых тестовых серверах. Даже когда мы знали, как его вызвать, нам было трудно синхронизировать наши действия в локальной тестовой обстановке. В случаях как этот, может быть очень полезно иметь баг репорты, которые детализированы настолько, насколько это возможно, узкий круг событий, которые с одной стороны, кажется, не имеют отношения к проблеме, с другой стороны могут оказаться чекой для целого ряда событий, приводящим к неприятным багам таким, как этот. Зачастую одного баг репорта недостаточно, но когда их накопится достаточно, то мозаика может сложиться в картинку.
Внедрение?
Когда появляется проблема, которая оказывает такой эффект на игре, мы всегда стараемся исправить её как можно скорее. Чтобы это сделать есть специальная команда экспертов, которая называется Live Team. Отличительная черта этих людей в том, что их могут оторвать от всего, чего бы они не делали, если возникнет серьёзная проблема, которая попадает в их область знаний и сообщена на Транке. Этот подход доказал, что он намного более продуктивен, чем отрывание абсолютно всех людей от процесса разработки. Обычно требуется только несколько отдельных людей, чтобы решить каждую проблем, а все остальные могут продолжать свою нормальную рутинную работа по разработке игры. Исправления от этой команды обычно внедряются как хотфиксы, что означает что сервер обновляется в течении ДТ (в редких случаях были обновления без отключения сервера) Без обновления клиента весь процесс разработки гораздо проще, к сожалению, в данном случае необходимо было исправить клиент. И это снова нас возвращает к проблеме времени, клиент обычно обновляется по вторникам, потому что это даёт нам понедельник на подготовку и оставшуюся неделю на то чтобы следить и реагировать на промахи. К сожалению, в данном случае Четверг 21-го был выходным.
Тестирование
Патч клиента требует много работы, мы должны протестировать все поддерживаемые платформы, множество версий патча для клиента должны быть построены и протестированы прежде чем загружать их на сайт и потом их нужно снова скачать, чтобы перепроверить. Каждая модификация, которая была сделана, должна быть проверена, а также должны быть проведены проверки всех аспектов игры, чтобы обнаружить непредвиденные промахи где-либо ещё. Обычно это занимает несколько дней. К сожалению, в этот раз у всех (кроме CCP GingerDude) в Исладнском офисе был выходной в четверг, так что создание патча не могло начаться до пятницы, тестирование было проведено в понедельник и наконец мы внедрили исправление на Транквилити во вторник 26-го. Что довольно поздно, но мы не хотели нарушать протокол и рисковать появление других грубых ошибок.
В заключении приводим порядок событий от обнаружения до внедрения:
Время указано по Гринвичу (по ЕВЕ).
Tuesday,19th of May - Apocrypha 1.2 release
Вторник, 19-е Мая – выпуск Апокрифа 1.2
17:47 -> GM Nythanos, работающий в офисе в Атланте, присылает е-мэйл, сообщающий об огромном количестве петиций, описывающих зависание клиента после пропрыга.
18:35 -> Никаких ошибок в базе данных не обнаружено, она подгружается как надо и не может быть причиной.
19:33 -> Сделана внутренняя бирка, чтобы собирать все баг репорты связанные с этой проблемой.
20:20 -> Создан топик на форуме, который просит, чтобы начинались действия.
22:39 -> Ответ на топик, призывающий отсылать больше баг репортов.
Среда, 20-е Мая – Начинается Расследование
07:54 -> Проблему передают специальной команде, об этом дальше.
12:19 -> Второй ответ в топике на форуме, несколько полезных баг репортов пришло в течение ночи.
12:35 -> CCP Tuxford смог воспроизвести ошибку, и начинает разбираться в коде
14:13 -> Третий ответ в топике на форуме.
Четверг, 21-е Мая – Решение (выходной)
09:33 -> CCP GingerDude начинает работать над исправление проблемы.
12:43 -> Исправление сделано.
17:27 -> Официальный информационный топик создан.
Пятница, 22-е Мая – Создание патча
Построение и тестирование многих версий патча необходимо, что начинать обновление клиента.
Понедельник, 25-е Мая – Зелёный свет для внедрения
Окончательные тесты проведены и проверены все аспекты без видимых проблем, дан зелёный свет для внедрения.
Вторник, 26-е Мая – Обновление Транквилити
09:00 -> Сервер остановлен и устанавливается обновление.
11:57 -> Серверы выходит из VIP режима, то есть открыт для пользователей.
И это, крошки, конец моей сказки о маленьком баге, который попытался ускользнуть.
Сообщение отредактировал Trimutius III: 09 July 2009 - 10:20
Наверх
