стресс-теста открытия врат Ан'Киража на PTR WoW Classic и опубликовали детальный материал, рассказав о некоторых улучшениях, что будут введены для стабилизации события в актуальной версии игры, хотя заметные задержки все равно ожидаются. Также ради получения дополнительных деталей они назначили второй стресс-тест, который состоится ночью в следующую пятницу, 26 июня.
Стресс-тест прошел успешно – спасибо вам!Всем привет!
Хочу лично поблагодарить каждого, кто помог нам в проведении вчерашнего стресс-теста. Вся команда WoW Classic присутствовала на нем и нам очень понравилось с вами играть. А вот пара дополнительных деталей о том, как прошел этот стресс-тест.
Что мы увиделиМногие люди во время тестирования спрашивали, а будет ли производительность игры такой же плохой в актуальной версии игры, в то время как некоторые шутили, будто считают, что все уже готово и нам срочно нужно все выпускать. Или они не шутили? Так или иначе, все во время вчерашнего стресс-теста было практически таким же, каким было на событии открытия врат Ан'Киража в 2006 году. Были огромные задержки, пара падений серверов, а когда игроки сдались и их численность сократилась, событие наконец подошло к концу. В этот раз мы собираемся сработать лучше, однако у нас нет возможности полностью избавиться от задержек.
Особенно мне хочется поблагодарить игроков, которые застряли в конце полета, поскольку мы смогли обнаружить и исправить эту проблему. Как и в случае со многими проблемами, как только удалось найти основную причину, мы смогли ее быстро исправить, к тому же дополнительно выяснилось, что также она влияла и на другие неполадки. Так что если в конце своего полета вы наблюдали геометрическое месиво, спасибо вам, вы сделали игру лучше для всех остальных.
Если вы оставались до 03:00 утра, то могли увидеть, что наши тестовые условия изменились до такой степени задержки, которую мы ожидаем увидеть в живой версии игры. У нас нет иного выбора кроме как пойти на компромисс между серверной задержкой и плотностью игроков. Чем больше людей, тем выше задержка, и в итоге когда в одном и том же месте оказывается слишком большое количество игроков, задержка повышается до такой степени, что сервер начинает считать будто он достиг мертвой точки (это такое интересное выражение из компьютерной техники, которое означает "застрял и не может восстановиться") и перезагружается.
Перезагрузка в результате того, что сервер считает себя попавшим в мертвую точку, является сбоем, но также представляет из себя особую проблему. Другие виды сбоев происходят тогда, когда программы пытаются сделать что-то по-настоящему плохое, поэтому мы находим эту плохую штуковину, исправляем ее и все. Мертвые точки же более сложны, поскольку это не одна-единственная проблема, а комбинация из них, которая становится все хуже и хуже. Однако все же существуют изменения, которые для улучшения ситуации мы можем ввести.
Плотность населенияПервая наша проблема – это экспоненциальное масштабирование. Представьте себе "Снежную бурю", которая наносит урон 10 игрокам, накладывая на каждого из них ауру, что замедляет скорость передвижения (ведь вы изучили талант "Улучшенная снежная буря", да?). За каждого игрока, на которого действует аура замедления, нам также необходимо отправить сообщение всем ближайшим игрокам о том, что эта аура была наложена. Это означает в общей сложности 100 сообщений. Каждый из 10 пораженных игроков отсылает по 10 сообщений (одно игроку, который произнес "Снежную бурю", и еще девять другим игрокам, которые под нее попали).
Если "Снежная буря" наносит урон 20 игрокам, то это в четыре раза больше сообщений. Если она поражает 40 игроков, то это 1600 сообщений. Удвоение количества игроков усложняет задачу в четыре раза. Переход от 10 игроков в этой области до 100 переводит нас от 100 к 10000 сообщений для одного этого заклинания. У нас уже есть мощная аппаратура, поэтому все сводится к определению того, как много игроков мы можем сдерживать без вхождения в мертвую точку, что и было ключевой целью стресс-теста и, поскольку к нему присоединилось много игроков, нам удалось собрать очень хорошие данные.
Оптимизация кодаЭтим мы занимаемся с 2004 года, и в течение пары последних месяцев мы оптимизировали код с учетом данного конкретного события. Вот несколько недавних примеров.
Для начала давайте рассмотрим ауру замедления. Что будет, если мы не разошлем все сообщения о наложении ауры сразу же? Если вы поражаете "Снежной бурей" 100 игроков, нужно ли вам знать в ту же самую секунду, что на каждого из них была наложена аура замедления? Сервер, конечно же, узнает об этом сразу, поэтому аура на самом деле накладывается и скорость передвижения игроков замедляется, но будет ли приемлемо, что вы одну-две секунды не будете наблюдать наличие ауры на них? Если это означает, что сервер не прекратит работу, наш ответ – да, поэтому мы позволили сообщениям об обновлении ауры задерживаться. У этого есть еще одно дополнительное преимущество: поскольку если в то время, как сообщения от первой ауры ожидают отправки, происходит обновление другой ауры, мы можем обновить их и в целом отправить меньше сообщений. Это приводит к возникновению меньшего количества пакетов в сети и меньшей работе для сервера.
Вчера мы протестировали другую оптимизацию кода, которая касается направления взгляда. Эта часть информации отвечает за то, в какую сторону направлен взгляд каждого игрока. А что, если мы замедлим или прекратим рассылку сообщений о направлении взгляда, когда численность игроков достигнет определенного значения? Оказывается, что цена этого будет совсем небольшой: игроки будут немного дергаться при движении. Когда зона перенаселена, игроки итак дергаются во время движения, так что это может быть серьезным повышением производительности без заметного визуального влияния. На самом деле, мне кажется, что при наличии этой оптимизации игроки дергались даже меньше, чем без нее.
Также мы повысили производительность определения целей рассылки сообщений. Когда тысячи игроков собираются в одном месте, даже просто определение того, кому нужно разослать сообщения об обновлении вашей ауры и о том, в какую сторону вы движетесь, – уже существенная задача, поэтому нами было улучшено и это.
Перенос игроковРассмотрев предыдущие вопросы, мы должны коснуться еще одного. Когда Ан'Кираж впервые был открыт в 2006 году, наши гейм-мастера вручную переносили игроков из локации, чтобы позволить событию продолжиться. Позднее дизайнеры создали автоматические системы, позволяющие телепортировать игроков наружу. В наши дни действуют очень хорошие автоматические телепорты, и мы используем их для управления локацией, ограничивая количество находящихся в ней игроков до значения, которое на наш взгляд все еще является играбельным. В Силитусе определенно будут наблюдаться задержки, но мы лучше будем переносить игроков, чем позволим ему перестать работать совсем.
Это событие охватывает значительную часть южного Калимдора, поэтому даже если вы не сможете попасть в Силитус, это вовсе не означает, что вы все пропустите. Анубисатов и силитидов будет можно убивать в течение 10 часов после удара в гонг и в Танарисе, и в Тысяче Игл, и в Фераласе, и в Степях.
Еще разВчерашнее тестирование дало нам довольно неплохое представление о том, какими должны быть ограничения на число игроков и о том, как мы можем восстанавливаться после сбоев, но нам хотелось бы узнать еще больше, поэтому мы решили устроить еще одно тестирование в пятницу, 26 июня, в то же самое время (01:00 MSK). На этот раз мы постараемся провести его побыстрее, поскольку надеемся, что нам потребуется меньше исследований и будет возникать меньше помех.
Надеемся увидеть всех вас там.
P.S. Летон просил передать вам, что ему очень понравились ваши духи в грибочках.
[Источник]