Серверу, чтобы понять, какая команда что значит, нужно сперва превратить поток байтов во что-то вразумительное. Проблема в том, что для команды 1 и для команды 2 нужны разные способы десериализации. Т.е. команду 2 мы пытаемся десериализовать неправильным способом и получает какую-то фигню вместо команды. Поэтому мы не можем понять, что это была команда 2.
Мы могли бы показывать игроку пинг до нашего датацентра, на который мы никак повлиять не можем. Тогда бы он был стабильный и не вызывал вопросов. Но это было бы ложное ощущение, т.к. качество обслуживания могло не соответствовать указанному значения. Мы же показываем «честный пинг»: реальную задержку между применением команды и получением результата. Это тот параметр, над улучшением которого мы можем работать.
Почему «пинг» не сокращается
Как я писал выше, значение «пинга» — это сумма нескольких слагаемых. FPS, а точнее производительность клиента, может влиять только на сериализацию. Поэтому можно легко загнать один из слагаемых в гору, значительно увеличив сумму, но, уменьшив его до минимума, не получить явной выгоды, т.к. остальные слагаемые никуда не делись.
Кстати, на днях мы заметили, что включенный в фоновом режиме uTorrent может задирать «пинг» до 4к. Правда, пока мы не знаем точных причин.
Телепортируешься(скилом) уже мёртвым, ульта срабатывает после смерти, мобы убивают последним хитом, после того как они были сами убиты.
А вот эти все проблемы могут быть как связаны с пингом, так и быть отдельными. Например, сервер честно прислал сообщение клиенту и уже отработал его, но рендер не успел показать, что аватар умер. Или интерфейс послал команду с запозданием. Я понимаю, что вам, как конечному пользователю не очень интересна причина бага. Просто хочу объяснить, что не «пингом» единым.
я мирюсь с этими косяками и надеюсь вы успешно победите все эти косяки и отполируете шероховатости
Пинг, который вы видите в игре — это не то же самое, что результат выполнения команды ping. Это сериализация + отправка + пересылка + прием + десереализация сообщения. Я сейчас посмотрел график латенси с идущего прямо сейчас стресс-теста:
95 перцентиль — ~110 мс.
90 перцентиль — ~86 мс.
80 перцентиль — ~60 мс.
70 перцентиль — ~ 43 мс.
50 перцентиль — ~ 23 мс.
И так далее. Т.е. в принципе, ваши ощущения верны. У значительного числа пользователей разброс от 35 до 100.
Так же верны ваши наблюдения, что при падении ФПС падает пинг — мы работаем медленнее, медленнее отправляет и принимаем сообщения.
Наши механики отлично должны себя чувствовать до 300мс. У нас есть различные механизмы компенсации пинга, чтобы бой смотрел и игрался хорошо.
Нет, конечно. Мы не чиним race condition добавлением sleep. Мы так только дебажимся :) Хотя в данном случае, sleep отработал бы лучше.
Мы добавили сообщение-уведомление для сервера, что клиент посылает следующее сообщение в новом состоянии. Чтобы сервер явно переключил сетевое соединение в нужное нам состояние. Проблема была в том, что на медленных соединениях TCP любезно склеивал пакеты «переключи состояние» и следующее сообщение, и они приходили в рамках одного тика сервера. Сервер же не мог отработать в рамках одного состояния два сообщения, предназначенные для двух разных состояний. Но я согласен, что фиксили на скорую руку. Потому что не предусмотрели все варианты развития событий. Простым добавлением в клиент ожидания подтверждения от сервера о переходе в нужное состояние удалось пофиксить таймаут в этом месте еще раз.
Да, протокол входа в игру был не очень надежен. Именно для того, чтобы находить такие баги, и были заведены таймауты. Если мы в стейт-машине входа в игру не переходим из одного состояния в другое слишком долго, то оповещаем об этом игрока и «выходим».
Старый «движок» входа в игру понравился бы вам еще меньше, поэтому мы его и переписали, добавив диагностики и таймаутов. Раньше можно было застрять в каком-то состоянии навсегда.
Это баг, вызванный гонкой состояний в масштабах клиента и сервера. Представьте, что клиент посылает две команды, при этом клиент ожидает, что после первой команды сетевой поток, его обслуживающий, успел переключиться в нужный для второй команды режим. Но при хорошем подключении две команды идут так быстро, что сервер не поспевает. И получает второе сообщение в невалидном состоянии. Лечится, как правило, путём добавления сообщения-ответа в духе «состояние переключил — давай следующее сообщение».
У нас нет каких-то планов по написанию статей. Захотел — написал. Попросили — написал. Поэтому я не обладаю никакой инсайдерской информацией на эту тему. Поэтому только SergeyMakeev знает, будет он еще писать или нет.
Статья об утилите для нагрузочного тестирования, но при этом не сказано, сколько запросов в секунду она может выдать на определенном железе, пока не упрётся во что-нибудь (процессор, память, канал). Было бы круто провести исследование и добавить подобную информацию к статье.
Сделайте обзор, чего есть, что платят, что делать :) У меня коллега недавно к вам уехал, правда, уже в Питер переезжает. Но Калининград в этом не виноват.
Доля местных, работающих программистами, вряд ли превышает 10%. Хотя это моя диванная оценка :)
Соглашусь, что круг замкнут. Но, т.к. сейчас бизнесу уже тупо не хватает мощи столичных университетов, они идут в провинцию. В ведущих компаниях давно уже есть «пакеты по переезду» (помощь с поиском жилья и какие-то деньги на первое время), при этом перевозят не только внутри РФ, но и из-за рубежа, и даже за пределами СНГ. Но т.к. это тоже дорого — нужно платить московскую зарплату, идет следующий шаг — помощь региональным ВУЗам, укрупнение региональных центров. У нас есть офисы в Воронеже и Нижнем Новгороде, у Яндекса — в Екатеринбурге и Симферополе. Программы обучения (различные «Школы» и «Технопарки») вышли за пределы Москвы. Когда и там ресурсы будут исчерпаны, крупный бизнес доберется и до условного Гадюкино :)
В условном Гадюкино нет условных МФТИ, МГТУ, МГУ, МИФИ, МИЭТ, СПбГУ, СПбГТУ, ИТМО… А именно они являются основными поставщиками кадров. Поэтому такой дисбаланс неудивителен.
За сотку — это опытные программисты, приносящие пользу, в компаниях, где разработка ПО является профильной деятельностью. Это точно не удача, не исключение и не редкие специалисты.
Всё-таки работа над большими изменениями в DVCS и в VCS сильно отличается. В VCS я не могу сохранить текущий стейт локально, иначе как сделав патч. Чтобы продолжить с ним работу после правки какого-нибудь важного бага, например.
Так же в VCS намного сложнее организовать красивый пайплан: отдельные ветки для фичей. Это не невозможно, но это просто сложнее сделать.
Лично мой опыт показывает, что работать с DVCS командой проще, быстрее, эффективнее.
Кроме Adobe, все остальные компании в списках вижу впервые. Уже успели чем-нибудь воспользоваться и оценить качество услуг, какие-то блага или удобства?
На логотипе программы, кстати, есть SurveyMonkey, а списках нет — почему?
Как я писал выше, значение «пинга» — это сумма нескольких слагаемых. FPS, а точнее производительность клиента, может влиять только на сериализацию. Поэтому можно легко загнать один из слагаемых в гору, значительно увеличив сумму, но, уменьшив его до минимума, не получить явной выгоды, т.к. остальные слагаемые никуда не делись.
Кстати, на днях мы заметили, что включенный в фоновом режиме uTorrent может задирать «пинг» до 4к. Правда, пока мы не знаем точных причин.
А вот эти все проблемы могут быть как связаны с пингом, так и быть отдельными. Например, сервер честно прислал сообщение клиенту и уже отработал его, но рендер не успел показать, что аватар умер. Или интерфейс послал команду с запозданием. Я понимаю, что вам, как конечному пользователю не очень интересна причина бага. Просто хочу объяснить, что не «пингом» единым.
Спасибо за добрый отзыв.
95 перцентиль — ~110 мс.
90 перцентиль — ~86 мс.
80 перцентиль — ~60 мс.
70 перцентиль — ~ 43 мс.
50 перцентиль — ~ 23 мс.
И так далее. Т.е. в принципе, ваши ощущения верны. У значительного числа пользователей разброс от 35 до 100.
Так же верны ваши наблюдения, что при падении ФПС падает пинг — мы работаем медленнее, медленнее отправляет и принимаем сообщения.
Наши механики отлично должны себя чувствовать до 300мс. У нас есть различные механизмы компенсации пинга, чтобы бой смотрел и игрался хорошо.
Мы добавили сообщение-уведомление для сервера, что клиент посылает следующее сообщение в новом состоянии. Чтобы сервер явно переключил сетевое соединение в нужное нам состояние. Проблема была в том, что на медленных соединениях TCP любезно склеивал пакеты «переключи состояние» и следующее сообщение, и они приходили в рамках одного тика сервера. Сервер же не мог отработать в рамках одного состояния два сообщения, предназначенные для двух разных состояний. Но я согласен, что фиксили на скорую руку. Потому что не предусмотрели все варианты развития событий. Простым добавлением в клиент ожидания подтверждения от сервера о переходе в нужное состояние удалось пофиксить таймаут в этом месте еще раз.
Если (t2 + dt) > t1, то всё было хорошо. Иначе сообщение_2 приходило в момент, когда его никто не мог корректно обработать.
Это был самый первый баг ошибки 107, которому были подвержены пользователи с маленьким пингом и быстрым клиентом.
Старый «движок» входа в игру понравился бы вам еще меньше, поэтому мы его и переписали, добавив диагностики и таймаутов. Раньше можно было застрять в каком-то состоянии навсегда.
У нас нет каких-то планов по написанию статей. Захотел — написал. Попросили — написал. Поэтому я не обладаю никакой инсайдерской информацией на эту тему. Поэтому только SergeyMakeev знает, будет он еще писать или нет.
Соглашусь, что круг замкнут. Но, т.к. сейчас бизнесу уже тупо не хватает мощи столичных университетов, они идут в провинцию. В ведущих компаниях давно уже есть «пакеты по переезду» (помощь с поиском жилья и какие-то деньги на первое время), при этом перевозят не только внутри РФ, но и из-за рубежа, и даже за пределами СНГ. Но т.к. это тоже дорого — нужно платить московскую зарплату, идет следующий шаг — помощь региональным ВУЗам, укрупнение региональных центров. У нас есть офисы в Воронеже и Нижнем Новгороде, у Яндекса — в Екатеринбурге и Симферополе. Программы обучения (различные «Школы» и «Технопарки») вышли за пределы Москвы. Когда и там ресурсы будут исчерпаны, крупный бизнес доберется и до условного Гадюкино :)
Так же в VCS намного сложнее организовать красивый пайплан: отдельные ветки для фичей. Это не невозможно, но это просто сложнее сделать.
Лично мой опыт показывает, что работать с DVCS командой проще, быстрее, эффективнее.
На Git — дизайнерам.
А так, ценой некоторых усилий, счастливы все.
На логотипе программы, кстати, есть SurveyMonkey, а списках нет — почему?
О какой сумме идет речь и на какой срок?
И что с медицинской страховкой на время обучения в бизнес-инкубаторе?