Компания
52,78
рейтинг
30 января 2013 в 16:43

Разработка → Сражение при Asakai: как EVE Online справляется с гигантскими битвами перевод

Битва у Asakai стала второй по количеству столкнувшихся кораблей в истории EVE Online (об этом прекрасно написал комрад madmaxcorp, там же вы можете посмотреть без преувеличения галактической красоты видео очевидца). История сражения интересна сама по себе (человеческая ошибка), но нас традиционно больше интересует что же было с серверами игры во время этой сумасшедшей битвы, как CCP (создатель EVE Online) удается справляться с такими нагрузками?

«Наша команда поддержки (игровые мастера, GMs) следит за гигантскими битвами, подобными этим», — говорит один из разработчиков. «У нас есть веб-страница со статусом кластера, на которой появляются большие красные цифры в случае перегрузки нод в сражениях. Так что довольно легко видеть что происходит». Более интересно то, что стоит за этими цифрами.



Доступные варианты



Наиболее распространенный ответ – ничего не делать. Почти все сражения создают вменяемую нагрузку на сервера, либо они так быстры, что уже сделать ничего нельзя. Тем не менее, как только становится ясно, что делать что-то надо, у команды есть несколько возможностей.

Трудно заметить, но иногда админы изменяют само игровое пространство. «Мы перемещаем другие солнечные системы с ноды, на которой идет сражение. Это временно отключает всех, кто находится в этих системах, но избавляет их от симптомов, присущих перегруженному серверу». – объясняет разработчик. «Это немного помогает системе, в которой идет сражение, особенно если флоты подкрепления проходят через переносимые системы. Это было сделано и в случае прошедшего сражения, но такое случается редко».

Есть и более значительное оружие для поддержки работоспособности серверов под экстремальной нагрузкой, но они уже компромиссные. «У нас есть пара машин с самым лучшим железом, лучше среднего в кластере».

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

Итак, вариантов решения проблемы на самом деле мало. Сервера всегда загружены на 100%, так что ничего невозможно подкрутить в настройках. Однако в игре есть встроенный механизм для решения проблемы больших битв. Она замедляется.

Замедление времени



Это уже давно знакомая ветеранам EVE Online функция, но любопытный способ борьбы с высокой нагрузкой и лагами в ситуации, когда игра должна работать. В тот момент, когда нагрузка на сервер достигает критической точки, игра автоматически замедляет время на определенную величину для борьбы с перегрузкой. Время в битве на 3000 игроков запущено на 10% от реального, что составляет максимально возможное замедление. Вот видео, которое демонстрирует замедление времени на практике.



«Это очень изящный способ справиться с лагами в ситуации, когда сервера других игр просто плавятся», — пишет автор. «На самом деле время в системе замедляется для того, что бы запросы к серверу и его ответы реализовывались и реализовывались правильно. В этом случае люди, вступающие в игру, получают постепенно замедляющееся до предельного уровня в 10% время — на самом деле мир медленный, но вполне работоспособный с точки зрения геймплея и тактики».

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

«Для клана HoneyBadgers потери составили 6 Дредноутов, 11 Авианосцев и один Суперавианосец. Для Clusters все обернулось хуже — 4 Дредноута, 29 Авианосцев, 5 Суперавианосцев и три Титана», — пишет PC Gamer. Битву при Asakai называют полным разгромом.

Ориентировочно потери составили 700 миллиардов в игровой валюте или 24 000 долларов. И именно поэтому так важно, чтобы такие сражения проходили на стабильных серверах. К счастью, CCP была готова к такому событию. И EVE Online продолжает оставаться увлекательной игрой.
Автор: @Apps4All_post BEN KUCHERA
Apps4All
рейтинг 52,78
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Комментарии (166)

  • +39
    Чертовски понравилась идея с замедлением времени — действительно изящный ход
    • +13
      Да, разработчики нашли интересный выход с учетом игровой механики EVE. Но согласитесь, в большинстве игр такое решение не применимо.
      • –4
        В Max Pain вродебы даже на радость.
        В BF3 наверное снайпера бы радовались ))))
    • 0
      Похоже, что-то такое в Hitman Absolution используется. Мало народу — ГГ даже ходит бегом, много — вроде бежит, но как-то не спеша. Как иллюстрация — миссия в китайском квартале: сравните скорость передвижения ГГ относительно земли до выхода из переулка на площадь и после.
      • 0
        На сколько я знаю, замедление времени — в синглплеере ничего не дает. Кол-во итераций не меняется, меняется dt. У Eve Online тут выигрыш за счет уменьшения кол-ва запросов.
    • +48
      Ага, т. е. если в нашей вселенной частица разгоняется до скорости света, то она перегружает сервер и время для неё замедляется? :)
      • +5
        Верно, но мы этого не замечаем, так как являемся частью мира.
        • +13
          Просто переносят на другие серверы тех, кто в это время спит :)
          • 0
            Эх не переносят, им просто соединения подвешивают :)
            • +6
              Детализацию снижают. Сны-то нужно как-то обрабатывать.
              • 0
                У нас есть фазы быстрого сна и фазы медленного сна… а если сервер сновидений перегружен, некоторые юниты не помнят снов… потому, что на них мощности не хватило
        • 0
          мы же нпц
          • +1
            Смейтесь или нет, но с детства у меня была мысль, что у создателя мира просто фантазия исчерпалась… я проезжал с родителями разные города и думал — о, это дерево я видел там и там… эта лавочка мне знакома и т.д. Просто существующие модели он распихал по миру в произвольном порядке, только и всего. И нет, лечиться я не пробовал.
            • +1
              А еще бывают повторяющиеся заскриптованые сцены, некоторые ихз называют дежавю
      • +3
        Красивая идея. Впервые проникся ей в рассказе Каганова «Путешествие фантаста Свечникова».
      • 0
        У меня была другая теория. Представьте себе окно на мониторе, в центре которого находитесь вы. Когда вы перемещаететсь, картинка в окне тоже движется так чтобы вы всегда оставались в центре. Но если разогнаться до скорости света, то картинка не успеет переместиться и вы ударитесь в границу окна.
      • 0
        Можно еще такую аналогию привести — чем больше частиц в каком то объеме пространства вселенной, тем там медленнее течет время. Для черных дыр оно вообще почти останавливается.
      • –4
        Кстати, такая идея прекрасно объясняет один из постулатов квантовой теории. Постулат гласит о том, что сам факт наличия наблюдателя влияет на поведение частицы.
        • +1
          Ленивые вычисления!
    • 0
      Идея хорошая, но она не позволяет полностью решить проблему обработки массового скопления игроков. Проблема в том, что если мы снизим скорость игры в 10 раз (как в нашем примере), то это линейно отразится на скорость обработки запросов сервером (в идеальном мире — производительность увеличиться в 10 раз). В то же время передача информации о близлежащих объектах (а также в большинстве случаев — обработка их взаимодействия) это задача с квадратичной сложностью (N игрокам нужно сообщать об N игроках).
      • 0
        Я думаю лаг компенсация адекватно реагирует на замедление, а количество пакетов падает относительно нормального времени.
    • +3
      Ход может и изящный, но как игроки на это реагируют? Бой начинает длиться в 10 раз медленнее. Это же сколько времени придется ждать? Мне бы лично это надоело. Хотя конечно тех отчаянных пилотов я не знаю.
      • –18
        10% это не в десять раз если что
        • +4
          «на 10% от реального» это значит что каждая секунда длится 10. Что и есть в 10 раз.
          • –16
            Если выстрел идет 100 секунд умножаем его на 10%, то есть на 1.1 в итоге получается, что выстрел будет 110секунд.
            То есть вы не правы. Но в начале говориться не о 10%, а в 10 раз, то есть 100 секунд умножаем на 10
            • +2
              • –12
                И За что тут минус? да вы получили значение 10%, на которое увеличивается время. только забыли добавить 100% текущего времени выстрела. возьмем время выстрела за x. тогда увелечение на 10% будет x+x*0.1, что в сокращенном варианте будет x*1.1

                www.google.ru/#hl=en&sugexp=les%3B&gs_rn=1&gs_ri=hp&tok=XmhX-TO1ssia_B51WruVJw&cp=7&gs_id=c2&xhr=t&q=100*10%25&es_nrs=true&pf=p&safe=off&tbo=d&output=search&sclient=psy-ab&oq=100*10%25&gs_l=&pbx=1&fp=1&biw=1440&bih=702&bav=on.2,or.r_gc.r_pw.r_cp.r_qf.&cad=b
                • +12
                  Вы путаете: «10% от нормального времени» и «на 10% медленнее»
      • +4
        Видите ли, в противном случае вы бы точно так же ждали — но перед черным экраном, а потом либо вылетели бы к черту с сервера, либо прогрузились уже убитым тем, к кому велий лагательный рандом оказался снисходительнее. А тут медленно, но игра, с тактикой и стратегией. Ева — это не шутер, там иногда и без нагрузки на сервер хочется замедлить происходящее и подумать куда отварпать.
        • +5
          За столько лет ниасилили живую миграцию систем между нодами но зато да, теперь мы тормозим игровое время и говорим: «Зато это не влияет на геймплей! Так и надо, парни!»

          Костыль со временем становится протезом.
          • 0
            Кстати, лаги были и с ТиДи: и черные экраны и падения клиентов…
      • 0
        Игра в общем-то не обычная и люди, которые в неё играют, проводят за игрой много времени. В Eve не получится, подключиться и сразу же отправиться в вихрь битвы, а через 15 минут выключить компьютер и пойти спать.

        Даже больше, сами битвы длятся очень коротко и составляют очень маленькую часть всего игрового процесса.
        • 0
          Ну как не получится. Если где-нибудь на входе в нули разлогиниться, то битва почти сразу обеспечена :) В общем от стиля игры многое зависит.

          Но вообще да, в типовых сценариях много времени нужно тратить, чтобы обеспечить бой.

    • 0
      Забавно, что самые убогие и примитивные игры со неразвязанным графическим и игровым движком обладают тем же свойством. При стрессе скорость игры замедляется вместе с фреймрейтом.
  • –10
    В понятие «лаг» входит понятие «замедление времени».
    • +12
      нет
    • +3
      Не на константу. Скорость ответа при больших лагах малопредсказуема, потому что нельзя точно сказать, сколько запросов будет через минуту, две три. В результате игрок не знает, как быстро придет ответ; момент времени странным образом растягивается для всех игроков, в результате кто-то оказывается в будущем, кто-то в прошлом на игровой шкале времени. Сервер может успеть обработать действия вашего соперника, но не успеть оповестить вас. Вы еще думаете, что успеваете сбежать, но на самом деле ваш персонаж мертв, а корабль разбит прилетевшей издалека бомбой.
      CCP же подбирает коэффициент замедления так, чтобы заведомо превысить возможные лаги для каждого игрока, намеренно удерживая всех в одном времени и ставя всех в одни условия боя.

      Интересно, можно ли рассматривать ОТО как систему борьбы с лагами в матрице? :)
      • 0
        По поводу ОТО: Посчитайте асимптотику такого алгоритма, чтобы его можно было таким эффектом компенсировать.
        • 0
          Не годится, ОТО как раз делает время разным для всех. Скорее наоборот тогда, ОТО — лаг.
  • +2
    А меня вот больше впечатлила фраза:
    Ориентировочно потери составили 700 миллиардов в игровой валюте или 24 000 долларов.
    • +3
      Самый ценный ресурс евы, к сожалению, не купить. Время есть время.
    • +2
      С размахом поиграли.
    • +1
      Это не так много. Если честно, даже удивлен, что такая сумма (вообщем-то, небольшая по меркам EVE)
      • 0
        Я не знаком с мерками EVE. Видно я отстал от жизни, но такие суммы озвученные в контексте с действиями внутри игрового мира… впечатляют. Смешанные эмоции. Будущее уже здесь, с одной стороны, но с другой… столько денег в цветные пиксели…
        • +4
          Так разделите на 3000 игроков.
        • +10
          Да ладно… у людей большая часть жизни уходит либо в пустоту, либо в унитаз…
          Люди кучу времени тратят просто выходя покурить. При этом тратят кучу денег и при этом еще и портят свое здоровье.
          Пьют алкоголь, тратя еще больше больше денег и опять же, в ущерб здоровью.
          Делают много бесполезных вещей, суть просто тратят время в пустую. И т.д. и т.п.

          Так что это все лишь еще один способ потратить собственные деньги в удовольствие…
        • 0
          По моим прикидкам близзард на абонентке за вов получает 24к$ примерно за десять минут игрового времени. А общие годовые прибыли того же близзарда за все их «цветные пиксели» исчисляется в миллиардах. Чьи же это миллиарды?
          • 0
            Мне представляется, что сравнение не совсем корректно.
            Абонентская подписка за использования сервера для игры — это всё же покупка услуги. И в Eve она тоже присутствует — все игроки платят за игру на сервере.

            В этом плане прибыль обеих компании зависит только от популярности. Кто больше спотов на серверах продал — тот и заработал больше.

            А вот эти 24k$ — это не подписка, а введённые или заработанное в самой игре деньги, которые были выведены из оборота в результате боя. У Близзард вроде бы ни в одной игре нельзя потерять то, что ты приобрёл, в Eve наоборот можно купить корабль за введённые в игру деньги и при уничтожении этого корабля, это, утрируя, сжигает эти самые деньги.

            P.S.: Тут как раз таки похоже на казино, в котором вы платите за вход, потом покупаете фишки, на которые играете. Должно быть, это очень сильно будоражит и адреналит зашкаливает у азартных людей.
            • 0
              Или работаете на казино за фишки :)
        • +3
          не знаю какие суммы проигрывают в онлайн покер, но предполагаю что покер-игроки смотрят на потери в EVE с улыбкой)
        • 0
          по экономике в EVE даже статьи пишут. если я ничего не путаю, у них там штатно сидит пара головастых экономистов. на хабре вроде статья пробегала, сейчас не могу нарыть.
    • +1
      Это не очень много. Большая часть этой суммы заработана внутри игры, и на неё не тратился реал. Так что да, игроки пойдут покупать себе новые корабли, и кто-то заплатит живых денег. Но не 24000$.
      • +1
        Насколько я понимаю экономика в EVE честная и на «заработано внутри игры» точно также тратиться реал, просто это перераспределение кредитов от тех, кто купил PLEX за реал и продал за кредиты, тем, кто в игре их отрабатывал.
        • 0
          А награды за выполнение квестов? Они-то точно «из воздуха». Да и вообще я не особо верю в возможность построения сбалансированной закрытой экономики внутри игры. Даже при таком онлайне. Практически наверняка админы удерживают рынок в желаемых параметрах, иначе это неиграбельно будет.
          • 0
            Удерживают конечно, только что в этом плохого. Награды за квесты и т.п. компенсируется потерями в боях, беоприпасами\расходными материалами, использованными PLEXами и т.п., я полагаю пара экономистов у них за тем и сидит, чтоб регулируя управляемые параметры, вроде наград за квесты не давать им сколько-нибудь солидно влиять на закрытый сегмент экономики.
            • 0
              Компания заинтересована в прибыли, в первую очередь. Им нужно держать соотношение курса PLEX/ISK в зоне равновесной цены. Если меньше или больше, то они будут недополучать деньги. Если освободить рынок полностью, у них доходы будут сильно прыгать. Чуть где-то масштабные действия корпораций произошли (военные или экономические, неважно), рынок наклонился, и у них процентов на 20 просела выручка. Регулировать рынок надо. А учитывая механику игры, им приходится либо изымать ISK из оборота или наоборот их туда вливать.

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

              Единственный беспроигрышный вариант — это прямые интервенции на рынке. Администрация может: 1. скупать выставленный товар игроков (вливая ISK), и 2. выставлять товар на рынок (изымая ISK). Таким образом можно регулировать, что угодно. Но это, простите, уже не закрытая экономика.

              Вполне допускаю, что у администрации есть и другие экономические рычаги (я не игрок, деталей не знаю), но мне кажется что прямые интервенции — это самое очевидное решение.
              • 0
                Прямых интервенций в том виде как вы описываете нет 100%, там есть целый слой игроков, которые с презрением относятся к «пиу-пиу», занимаясь исключительно торговлей, производством и т.п., у каждого товара всегда прописан продавец и т.п., любая прямая интервенция послужила бы причиной убытков у того или иного игрока и хай бы тут же поднялся на полную катушку.
                • 0
                  NPC-торговля есть же.
              • 0
                Надо понимать, как работает рынок в игре. Если я выставлю товар на рынке с меньшей стоимостью, а кто-то выберет точно такой же товар, но с большей стоимостью, то реально он выкупит мою позицию, а разница уйдет в CCP (то есть, в никуда).
            • 0
              Не потерями, а добычей :) Потери как раз увеличивают «необеспеченную» денежную массу — обвес сгорел, а деньги-то в игре остались.
          • 0
            Награды за квесты, страховка и другая «эмиссия» валюты компенсируется добычей минералов, лутом и прочими игровыми ништяками.

            Под «честной» имеется в виду, что администрация не рисует деньги или рары в обмен на наличку.
            • 0
              Она вполне это может делать завуалированно. Вы уверены, что продавая PLEX, вы продаёте его живому игроку? ;-)
              • 0
                В принципе может, конечно, но как-то думаю есть более разумные способы регулировки.
  • +1
    Что-то мне подсказывает, что именно в игровых системах и будут созданы системы управления гипертрафиком на орбите Земли (и других планет) в будущем.
    • +9
      С замедлением времени
  • –10
    Жалкие 3000 игроков и они радуются что все работает с «не очень фатальными» лагами?
    Передавайте привет Питону.

    Но прогресс конечно есть, когда я играл пару лет назад — на 1000 человек лагало гораздо хуже. Это была прям специальная олимпиада какая-то по ведению боев в легах.
    • +5
      У Вас есть примеры где over 3000 игроков на локации не лагают?
      • –9
        В линейке например во времена C4 все было на одном монолитном C++ ядре, и держало десятки тысяч клиентов без особых лагов. Железо тогда тоже было намного проще.
        • +1
          А теперь добавьте что каждый из этих 3000 клиентов должен просчитать например траекторию ракеты (дрона, лазерного луча, etc) и просчет всего дамага который единомоментно влетает на каждый из этих 3к клиентов ложится на сервер, в линейке расчет очень простой:
          Пришло: Удар мечом
          Посчитать: rand(1,20) — def*rand(1,5)
          Отправить:result

          грубо говоря как-то так, а клиент просто отрисовывает стандартную анимацию удара, если крит повесить над головой табличку
          • +2
            Траектория ракеты в EVE насколько я помню — исключительно декоративное явление, никаких коллизий там не просчитывается.

            Как долетит — формула такая-же как и в Линейке получается :-)
            • +1
              Повреждения от ракет ЕВЕ зависят от многих факторов, и это далеко не рандом в линейке линк
              • –1
                Тем не менее, формула повреждений — на одну строчку, да и едва-ли её сложность на что-то повлияла бы в любом случае — взрывов ракет не большее сотни-другой в секунду.
                • +4
                  В EVE ракета может нанести урон не только по цели, но и часть урона если кто то был рядом с целью, так сказать взрывной волной. На это тоже нужен обсчет. в зависимости от траектории, скорости, удаления, тоже разный урон, что тоже надо обсчитать.

                  Каждый дрон это можно сказать НПЦ со своим АИ. Поставьте в туже ленейку еще пару тысяч мобов.

                  И ракет намного больше. В среднем с одной ракетницы идет 1 ракета в 2с, ракетниц скажем 6. Это 3 ракеты в секунду. Да и другие игроки тоже стреляют и некоторые быстрее. Это уже не сотня-другая ударов в секунду, это 6000+ выстрелов не считая дронов.

                  Что в итоге хотел донести: в EVE много расчетов, намного больше чем в классической онлайн игре.
                  • –3
                    Было бы интересно почитать про «часть урона тем кто рядом», например описание на wiki.eveonline.com/en/wiki/Missiles#Damage_Calculation пишет только о том, что ракета всегда попадает в цель, если она не сбита.

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

                    Вопрос с бомбами отдельный.
                    • +2
                      eve-ru.com/guide/missiles/

                      Там про взрывную волну написано и то что урон наносится в момент попадания, а не в момент выстрела. Ракета может лететь пару секунд, а за это время траектория цели изменится или цель может улететь от ракеты.

                      Урон зависит не только от скорости цели, на сколько быстро удаляется одна от другой, но и от угловой скорости. Оружия имеет поворот (не считая ракет) и это надо обсчитывать, как успевают турели поворачиваться за целью, если нет, то и урона не будет.

                      Если поиграть в EVE, то станет понятно что математики там куча :)
                      • +1
                        Что-ж, теперь согласен, упустил момент что от них можно улететь :-)
                      • +1
                        Ракеты не наносят урон соседним кораблям. Радиус взрыва учитывается только при обсчете урона от попаданий.
                        • 0
                          Попробуйте пострелять в цель когда они будут рядом.
                          • +1
                            Пробовали неоднократно. Ракеты бьют одну цель, AOE-повреждения наносят только smartbomb и bomb.
                      • +1
                        Скорость полета ракеты, так же как время полета зависят от самой ракеты, типа корабля, скилов и фита. Она наносит повреждение только цели.
                • 0
                  От ракеты можно «удрать» и ракету можно сбить в полете, аж тремя видами вооружения, и для двух из них важна именно траектория полета ракеты.
            • +7
              Увы, нет. Чтобы взорваться, ракета должна долететь.
              Есть ракета, которая летит со скоростью 4000м/с и топлива у неё на 10 секунд. Она попадет по цели, которая от нас в 22 километрах? Ответ прост.
              А по цели, которая улетает от нас со скоростью 1970м/с? Чуть сложнее, правда?
              А по цели, которая кружится вокруг нас на постоянной орбите радиусом 7500 метров (орбита только постоянно меняется слегка, то астероиды там, то игрок притормозит), со скоростью 3900м/с? 3975м/с? 4100 м/с?
              А если эта цель запускает 4 тяжелых противоракеты по нашему залпу из 4 тяжелых и 3 легких ракет, а у противоракет тоже конечная дальность полета, скорость и урон, а оба корабля маневрируют относительно друг друга, то сколько ракет долетит и какого пилота выпрут из корпы, потому что он забыл застраховать корабль?

              Это вполне реальные игровые примеры.
              И я уж не говорю про AoE оружие, которое, скажем, одномоментно поражает все в радиусе 10 км от корабля. Сколько ракет из залпа будет уничтожено при активации модуля? Так что там все сложнее чем в линейке в разы.
              • +3
                Да, я уже понял, вы правы.
                • +3
                  Да Вы не сдавайтесь, в Лайнейдже ничуть не проще потроха, как бывший разработчик эмулятора говорю :)

                  Фактически, любое преследование или атака — это не просто аналог самонаведения ракеты, а ещё с постоянной ежесекундной перепроверкой или коррекцией. И массовое поражение там тоже было. Да ещё всё это не в пустом пространстве, а на сложном рельефе с препятствиями. И мало самих игроков обрабатывать, там же десятки тысяч мобов, каждый со своим ИИ, который отслеживает других игроков и соседних мобов, проводит атаку, если необходимо…

                  Такую уйму интересных алгоритмических задач приходилось решать :)
        • +2
          Тем не менее это не сравнимо. Эти игроки находятся не в прямой видимости друг друга и вам не нужно отправлять каждому игроку данные о действиях каждого другого игрока. Прямое взаимодействие игроков начинает многократно в геометрической прогрессии увеличивать нагрузку на сервер и в те же времена C4 сервера весело отваливались уже при осаде замка в несколько сотен человек.
          • –9
            Никакой геометрической прогрессии нет, если есть агрегация отправляемых данных.

            При правильной реализации, на 10FPS — на 3000 игроков нам нужно будет отправлять 30к пакетов в секунду, и на этом все.
            • 0
              Ну типа да, только в каждый этот пакет нужно подготовить результат и напихать все изменения по остальным 2999 игрокам.

              Когда игроки размазаны по серверу равномерно — они в пакете получают изменений всего по 30-50 игрокам вокруг. Что уж говорить если в линейке даже в крупном городе с онлайном человек в 500 сервер начинал выдавать передвижения и действия игроков с приличными задержками.
              • –5
                Давайте посчитаем: 3000*3000*10FPS = 90 миллионов апдейтов в секунду.

                Я не вижу ничего героического в том, что обработка 90млн апдейтов в секунду требует чудотворного «замедления времени» на их топовом железе.
                • +2
                  А мне просто кажется что там сидят не дураки (судя по их подходу к работе с нагрузками) и если бы можно было так просто решить эту проблему — она бы уже была решена.
        • +3
          В линейке например во времена C4 все было на одном монолитном C++ ядре, и держало десятки тысяч клиентов без особых лагов. Железо тогда тоже было намного проще.

          Только не рассказывайте нам про то что влинейке 10тки тысяч клиентов :) Там максимум около 5 — 8к на весь сервер и это при самом хорошем раскладе.
          • –5
            Вы про какую линейку говорите? Про старую C4, которая была на C++, или новую L2J которая на Java?
            • +1
              Я говорю про офф сервера.
        • +1
          Десятки тысяч клиентов в одной локации? Вы шутите? Не помню осад с более чем полутора тысячами участников, по крайней мере в NA. Может у корейцев.
          • 0
            На сервере линеечки клиенткап времен С4 это 5000 — и это было даже на евро.
            Другое дело, что хотя сам протокол и довольно простой — а вот движок тупо не справляется с таким количеством полигонов в кадре. Во времена памятного замеса красных против желтых за Баюма на теоне («вперед, мои хомячки!», кхе-кхе) было всего примерно 300 на 300 на 13 этаже. У меня выдавало 1-2 fps, работал чисто по ассисту — благо играл соркой
            • +1
              Клиенткап ладно, но 5000 человек не взаимодействуют друг с другом в одном месте, по большей части из них на сервере нужно обрабатывать только эпическую схватку с очередным келтирчиком. Если бы все 5к явились бы на осаду, сервер бы очень удивился.
          • 0
            1500 несколько лет назад в сложном окружении (рельеф, строения) — это куда больше впечатляет, чем 3000 сегодня и в открытом пространстве :)
            • 0
              Ну eve online — тоже не самая новая игра, релиз был в 2003-м.
              • 0
                Моя ошибка, не уточнил, думал по логике понятно. Речь, конечно, идёт о типовом железе 6..9 лет назад и сегодня.

                Боюсь, что на том железе, на котором в 2006..2007гг гоняли Линейку, ни о каких 3000 игроках в EVE и близко нельзя будет говорить.
                • 0
                  А, тогда простите. Думал вы говорите о софтовой составляющей.
            • 0
              Когда говорят, что 1500 на осаде в ЛА2, тут же вспоминаю поговорку: «У страха глаза велики». Тысяча человек на осаде, да ещё и на N/A, это что-то невероятное (откуда там такой онлайн?).
              • 0
                Даже на крошечных L2J на осадах бывало до 300..500 человек. А 1000+ человек на осаде офа — не редкость была.

                Вот, «пиратский» сервер:



                На официальных серверах было куда больше.
                • 0
                  Кол-во участников осады оценивается по комманд чату одной и другой сторон (СС). Если уж вам настолько важно, почитайте форум Абусса, раздел осады и там наверняка найдете интересующую вас статистику.

                  PS: Скриншот маленький, не могу разглядеть значки. Если не ошибаюсь, то вижу РоА и BHoD. Они в сумме 1к не дадут просто из-за кол-ва мемберов.
        • +1
          4 игровых демона + парочка дополнительных (не считая БД) это нынче монолит? Десятки тысяч оно могло держать только суммарно по всем игровым мирам, для обеспечения работы каждого требовалось 3 отдельных демона из 4 упомянутых. К тому же, в серверной части был захардкоден лимит в 5000 CCU, а на осадах замков все равно лагало все что только могло лагать (на оффе в основном только на клиентской стороне, на пиратских серверах со слабым железом могло вставать колом абсолютно все).
        • +1
          10 тыс на одном сервере, а не в одной локации. В линейке эти 10 тыс не видят друг друга и их легко раскидать по независимым сервакам.
    • +15
      Прямо классический пример заблуждения технического человека в бизнесе. Я думаю, в CCP передали привет Питону, посмотрели на свои финансовые результаты, улыбнулись и пошли дальше хеннесси пить. С C++ они бы вписались в разработку на годы, были бы менее динамичны, и в результате вообще могли не взлететь или не вырасти до таких объемов.
      • +1
        Я не утверждаю, что все нужно писать на С++.

        Но ситуация выглядит интересно — сначала написать все на питоне, потом — писать радостные статьи о том, что они начали чуть меньше лагать (эта статья — не первая, и даже не десятая на эту тему) :-) Если производительность не имеет значение, зачем вообще тогда такие статьи?

        Прямо как в поговорке «создать себе проблемы, а потом героически их преодолевать».
        • +7
          Ну как зачем такие статьи. Паблисити в среде разработчиков — раз, просто PR-повод — два. К тому же, я думаю, они столько бабла сэкономили на питоне, что могут поставить Fusion IO в каждый сервер и еще на сдачу купить игрушечный марсоход. У всех оптимизаций есть величина ROI. Если все игроки в целом довольны скоростью, плюс с небольшими манипуляциями они могут тянуть такие замесы, зачем тратить лишние деньги на преждевременные улучшения?.. Все мы, разработчики, знаем, что улучшать можно бесконечно :)
    • 0
      Передавайте привет Питону.

      У вас есть каменные доказательства того, что если бы вместо Stackless (который достаточно быстр, посмотрите на производительность близкого его сородича PyPy в сравнении с программой на C (gcc -O3) на числодробительной синтетике) серверный софт был бы переписан на C/C++, это
      1) Кардинально улучшило бы ситуацию с лагами, которым подвержены только участники больших баталий (извините, но в нормальных условиях и Жита не лагает, а 3000 игроков в одной локации, как правильно говорят выше, залагают в любой ММО);
      2)… и что очень и очень немаловажно (и как человек, которому не чужда IT-сфера, вы должны это понимать) — что это позволит настолько же эффективно и быстро поддерживать софт, фиксить баги и развивать возможности, как при использовании не в пример более высокоуровневого языка?
      • 0
        PyPy — быстр из-за JIT-компиляции, это мне нравится.
        Есть ли в Stackless Python JIT-компиляция?

        По второму пункту — я полностью согласен с тем, что с экономической точки зрения дешевая и быстрая разработка с лагами иногда — может быть выгодна. Но не понимаю, почему нужно радоваться каждый раз когда такое экономичное решение начинает несколько меньше лагать. Постоянная борьба с лагами в таких условиях — это именно что заурядная рутина, а подают так, как будто это фантастический прорыв.
        • 0
          Это называется маркетинг.
      • 0
        >Кардинально улучшило бы ситуацию с лагами, которым подвержены только участники больших баталий

        Да, однозначно. Есть масса тестов на этот счёт.

        >что это позволит настолько же эффективно и быстро поддерживать софт, фиксить баги и развивать возможности

        А вот тут — нет. Потому Питон и был выбран.

        Я думаю, разработчики EVE не рассчитывали на такую популярность и массовость, потому и выбрали решение, позволяющее дешевле, быстрее и эффективнее разрабатывать сервер за счёт производительности. Ну а сейчас уже поздно коней на переправе менять, поддерживают и развивают что получилось.
        • 0
          Разрабы еще 2 года назад говорили что ядро не использует питон. Там проблема в том что одна солнечная система не масштабируется на несколько серверов. Это проблема архитектуры игрового движка и пока она не решена.
          • +1
            >Разрабы еще 2 года назад говорили что ядро не использует питон.

            Значит, таки, переписали.

            >Там проблема в том что одна солнечная система не масштабируется на несколько серверов.

            С другой стороны я, вот, имея некоторый опыт работы с такими системами, искренне не понимаю, зачем для 3000 игроков в открытом пространстве систему растаскивать на несколько серверов :) То есть в варианте с Питоном, как раз, понятно. Но если ядро на чём-то более производительном, хотя бы на Java, то уже — непонятно.

            Наверное, проблемы тогда лезут уже не из ограничений производительности, а из пропускной способности канала. Если протокол не очень компактный, то 3000 активных клиентов даже гигабитный канал могут сожрать и не поморщиться.

            Трафик EVE замеряли, сколько клиент в час потребляет?
            • 0
              Сильно зависит от массы параметров. В состоянии покоя, типа «сижу на станции в пустой системе, и даже чатики закрыты» потребление совсем мизерное. А в крупных битвах, или при перемещении через множество систем, или если активно рынок пролистывать — во много раз больше.
              • 0
                Ну, у нас же контекст именно массированного боя.
          • 0
            > одна солнечная система не масштабируется на несколько серверов.

            Засада в том, что она не масштабируется даже на несколько процессорных ядер в рамках одного сервера, и ВСЯ система работает в одном потоке.
      • 0
        Некорректное сравнение. Скомпиленый С код хоть и был скомпилен на -O3, реально это не дало никаких дивидендов, ибо вызываемая функция находилась в другой единице трансляции. Перенесли бы они все в один файл — тогда бы и сравнивали. Результаты получились совсем другие.
  • +8
    Фразы разработчиков («Мы перемещаем другие солнечные системы с ноды, на которой идет сражение...») звучат так, будто они представители Цивилизации VI Типа. Даже немного жалею, что ни разу не играл в EVE Online.
    • 0
      Да, очень порадовало — Демиурги, перемещающие солнечные системы, и замедляющие время…
    • +3
      Я играл всего пару недель более 7 лет назад. К счастью бесплатный аккаунт быстро кончился и я таки дописал свой диплом. Затягивает невероятно.
  • 0
    >Супеавианосец
    Странный перевод. Поменяйте пожалуйста на «мазершип» (mothership) или «материнский корабль».

    >замедляющееся до предельного уровня в 10% время
    Хмм, странно. Неужели 10% — максимум? По ощущениям, замедлиться может и на 30-40%. Кисель же.
    • +2
      уровень в 10% очевидно имеется ввиду от обычного состояния — то есть замедление в 10 раз
      • 0
        Точно так.
    • 0
      Это не Mothership, это Carrier.
      Как это в реалиях EVE будет?
      • +2
        Carrier = авианосец
        Mothership = SuperDuperCarrier = мазершип
        • +1
          Раньше в фантастике был очень распространён термин «корабль-матка». Но сейчас он из обихода как-то вышел, в нынешних реалиях «не звучит» :)
          • 0
            Корабль-фаллопиева труба
    • 0
      Гораздо проще не адаптировать русский перевод, а перейти на английскую версию клиента.
  • 0
    www.youtube.com/watch?v=NGIALyoZc3o
    Я смотрю, телепортировать «Титан» ко врагам это сейчас модно в EVE :)
    • 0
      Всегда было «модно».
      В меню у пилотов титанов опции «jump to» (прыгнуть на маячок самому) и «bridge to» (открыть портал на маячок) находятся близко :)
      Люди путают бывает, вот и получается то что на видео. Т.е. титан таким образом сам попадает один-одинешенек в гущу врагов.
    • +1
      Это едва ли не единственная дизайн-функция титана, так что да, да =)
      • 0
        Им ещё можно бампать. Медитативно так… да. И руду копать.
  • +1
    Ещё бы понять что происходит на видео. Все бьют друг друга? Я никогда не играл в EVE и не понимаю механику игры.
    • 0
      Все разделены на две стороны, с каждой стороны есть флиты (флоты), в состав которых входят корабли (флиты могут делиться, объединяться, но всё это уже детали). В каждом флите есть флитком, коммандир, который отдает приказы. Так или иначе, выбирается т.к. «праймари», основная цель и по ней ведется сфокусированный огонь до уничтожения.
    • +1
      Очень тяжело понять что-то на картинке, потому что в принципе в еве все управление идет в основном по приборам.
  • 0
    По-моему, это не новый ход.
    Я вот жутко удивился, сыграв 15-минутную партию в Supreme commander forged alliance за 40 минут. Уже вторая партия поставила все на свои места — время идет почти «нормально» до «засвета» противника. Как только количество видимых юнитов переваливает за условные 3к, время начинает вытягиваться.
    Но имхо, это всяко лучше, чем в World of Tanks, где бои всегда 15х15, но только днем снаряд летит на 900м секунду, а вечером тоже секунду, только выстреливает и попадает с таким лагом, что результат сильно разный
    • +1
      Это просто называется «лаги». Внутриигровой таймер супримы рассчитан на то, что вся игра идёт на скорости +0, тогда время таймера реальное. Когда у кого-то в партии очень слабый комп и он начинает тормозить (заметьте! не только сервер!), то TPS проседает и таймер идёт согласно новому TPS. Ничего более, просто лаги.

      По поводу WOT: тот же TPS. Если TPS сервера ниже, то снаряд делает за секунду меньше циклов, чем обычно, соответственно, алгоритмы полета, основанные на простых формулах, становятся невероятно неточными.

      В EVE же замедление это не прямое следствие лагов, а «костыль» для избавления от них. Если бы просто на сервере проседал TPS, то все становилось бы только хуже: просевший сервер стал бы «захлёбываться» пакетами игроков, которые бы продолжали идти с нормальной скоростью, все наращивая и наращивая очередь пакетов на обработку и уровень лагов. По этому в EVE замедление напрямую управляется с сервера и передаётся клиентам, и клиент начинает слать пакеты тоже медленнее.
  • +5
    Теперь ясно, почему в стрессовой ситуации у человека иногда время начинает растягиваться, сервера не успевают!
    • 0
      Скорее, активируется brain overclocking.
  • +1
    Многие здесь не знакомы с EVE и поэтому могут некоторые вещи неправильно понять.

    Насчет масштабов битвы — это действительно одно из крупнейших или даже самое крупное сражение в истории игры. С технической точки зрения нужно понимать, что к 3 тысячям кораблей нужно добавить отслеживание ракет, файтеров, бомберов и простых дронов, активацию кучи модулей и просчет их работы (в игре довольно сложная механика), движение в 3х-мерном простанстве. Года 2 назад такие битвы происходили в виде сплошного лага — люди 20 минут грузились в систему, кому повезло загрузиться — раз в 10 минут могли стрельнуть. Очень часто ход действий можно было проще и быстрее отследить по апи и борде (уже достаточно автоматизированные вещи) а не по тому, что видно в клиенте. Лаг был одним из основных аспектов подобных боев. Замедление времени позволило переместить контроль над результатом боя обратно в руки игроков, пусть даже и не полностью.

    По поводу потерь — примерно 1.5 года назад была битва с несколько более печальными потерями — 8 титанов и 15 мазершипов. Но опять же — приведенные в статье цифры и оценка в реальной валюте хоть и имеет место быть, но уже давно подобные вещи не вызывают интереса.
    • 0
      20 минут грузиться в системе? В битве за LXQ я одним чаром 4 часа на черный экран любовался после пропрыга в систему. А лаг всех действий был около 10 минут. Хотя конечно это был рекорд онлайна на то время и ССР было удивлено что нода выдержала :)
      Так что 20 минут прогружаться в системе — это и не лаг совсем, а так, небольшая задержка пакетов :)
  • 0
    Хочу немного порассуждать об архитектуре подобной системы.

    Сейчас, как я понимаю, несколько процессов обработки систем (назову их нодами) висят на одном сервере, и разделить их сложно — необходимо остановить процесс (с потерей соединений) и поднять на новой машине.

    А теперь пофантазируем. Поместим все расчётные ноды в облачный кластер — отдельный процесс обработки солнечной системы (ноду) в отдельную ВМ. За счёт возможности миграции виртуальной машины на другой узел кластера без остановки самой виртуальной машины появляется куча интересных возможностей по гибкому управлению нодами — балансировка нагрузкой серверов за счёт переноса нод, освобождение мощности сервера под возросшую нагрузку одной ноды вынесением остальных с сервера.

    Получится ли перенести ноду, держащую нужную систему на сервер помощнее, как миграция относится к постоянным коннектам, сохранит ли?
    За какое время осуществляется миграция, и что при этом происходит с самой машиной? Замораживается на несколько секунд/минут? Продолжает работать в штатном режиме, обрабатывая запросы?

    P.S. Я только начал изучать возможности виртуализации, так что если вопрос ламерский — не обессудьте…
    • 0
      Там все немного сложнее. То что обычно называют «сервером» сегодня не является «сервером» в обычном смысле. Современная серверная архитектура MMO — это как раз облачный кластер и балансировщик нагрузки, который перераспределяет ресурсы физических машин.

      С другой стороны нужно понимать, что за работу игры ответственны сразу куча более-менее независимых систем. В зависимости от реализации конкретной игры, они могут взаимодействовать совершенно по-разному. Грубо говоря, у вас есть логин-сервер, патч-сервер, зонные сервера, чат-сервер, нечто, обеспечивающее связь всего этого с БД персонажей, и так далее. Все это может либо работать либо вместе, либо по-отдельности. Например чат обычно полностью независим от всего остального, поэтому иногда можно наблюдать ситуацию, когда клиент потерял коннект с игровым сервером, и на экране у вас все встало, а чат работает.

      Естественно, архитектура взаимодействия этих компонентов будет влиять на возможности балансировки нагрузки, так что сложно получить представление о каком-то «общем случае».

      Про архитектуру в EVE online можно немножко почитать вот тут (статья на английском).
      • 0
        Спасибо за ссылку.
        >Each of EVE's 5000+ star systems is loaded as a separate process onto any one of hundreds of IBM blade servers, with some high-load systems being given a server all to themselves and many low-load systems being combined and run on servers together

        Интересно, что здесь не говорится про облако — «Каждая из 5000+ звёздных систем загружены как отдельные процессы на одном из сотен блейд-серверов».

        Я сейчас не говорю что у них плохая система (всё-таки справляется с впечатляющей нагрузкой). Но, судя по всему, «на горячую» они переносить процессы не могут, и балансируется нагрузка не в реальном времени, а по статистике — «эти 4500 систем малопосещаемые, а эти 500 — загруженные, перетасуем их вместе».
        • 0
          Ну, судя по всему, да. Мой комментарий конкретно к ним не относился, это я так, абстрактно. Еще ведь важную роль играет специфика самой игры (простите за каламбур). Например если вы знаете, что из-за каких-то факторов (ресурсы, расположение, или что-то еще) крупные битвы будут происходить в основном в вот этой, вот этой и вот этой звездной системах, то вы можете заранее вынести их на более высокопроизводительное оборудование.
        • 0
          После прочтения статьи я удивился, что они не могут переносить эти процессы на горячую. Конечно это не совсем просто, но вполне реализуемо на мой взгляд для такого большого и старого проекта, как ив.
        • 0
          По крайней мере в технологии OpenVZ возможен перенос процессов на другую физическую машину без потери сетевых соединений.
          ru.wikipedia.org/wiki/OpenVZ#Чекпоинтинг_и_миграция_на_лету
          >Так как все детали состояния VE, включая открытые сетевые соединения, сохраняются, то с точки зрения пользователя VE процесс миграции выглядит как задержка в ответе: скажем, одна из транзакций базы данных заняла больше времени, чем обычно, и далее работа продолжается как обычно; таким образом, пользователь не замечает, что его сервер баз данных работает уже на другом физическом сервере.
          • 0
            А насколько эта задержка заметна?
            • 0
              К сожалению, не могу проверить.
              Я себе поставил на сервер систему виртуализации Proxmox (была на хабре пара статей о ней. Коротко — класс!), которая поддерживает OpenVZ- и kvm-виртуализацию. Но у меня только одна машина, поэтому миграцию не могу попробовать… А хотелось бы.
              Но по прикидкам — нужно записать память в файл, передать по сети на соседнюю машину и там распаковать обратно в память. Пару секунд сохранять память, чуть дольше передавать и там ещё пару секунд запускать.
              В общем, несколько секунд, вряд ли больше 2-3 минут. Но зависит от объёма памяти.
          • 0
            У них на сервере венда, в ней нет OpenVZ.
  • 0
    Мне непонятно как можно было «просрать все полимеры» как 3 Титана и 6 Дредноутов не смогли замочить хоть один вражеский Титан? Кстати былобы интересно узнать соотношение сил победивших в принципе было гораздо больше? Если примерно одинаково, то за счет чего победитель выиграл? Неужели в космосе есть какаято там тактика? Врядли там работает такое: «вот сейчас я облечу его сбоку и начну палить ему в сраку и никто меня не заметит».
    • 0
      Есть корабли поддержки, которые восстанавливают повреждения у других кораблей.

      В соседней статье в комментариях была ссылка на видео по которому можно оценить отношение сил (примерно): www.youtube.com/watch?v=SFPHNB8Rq2o (фиолетовые — союзники, остальные — враги).

      Тактика, безусловно, присутствует, хотя бы за счет специализации кораблей, но как правило рулят численным превосходством, т.к. фулл лут.
    • 0
      Тактика есть конечно. В таких боях основная — правильный выбор цели для фокуса :)
    • +1
      Разбор полетов: themittani.com/news/asakai-aftermath-all-over-cobalt-moon

      This fight could appropriately be called Everyone vs. CFC. The HBC, N3 and BL all put up huge numbers in this fight and unified purely in opposition to the CFC forces.
    • +2
      Про тактику. В космосе есть несколько основных принципов.

      — сделай так, чтобы противник не смог улететь вдаль.
      Был блистательно выполнен одним из учавствующих альянсов, который постоянно подводил корабли, не дающие противнику отпрыгнуть куда-то ещё. Их уничтожали, но пилоты воскрешались и приводили ещё корабли. Корабли такого типа (heavy interdictors) были выкуплены полностью в системах на много прыжков вокруг.

      — вылечи своих друзей;
      VS
      — не дай врагам лечиться;
      Выполняется за счет логистов — кораблей с модулями удаленного ремонта брони/щитов. Часто это авианосцы. Не давать лечиться можно или вынося вражеских логистов, или снося корабли так быстро, чтобы они не успели отреагировать (альфа-страйк, привет Battletech!), или используя средства РЭБ. Забиваем компы логистов фигней, они не могут нацелиться на друзей — никого не лечат. Или высасываем у логистов всю энергию и та же фигня. Альфа-страйк с такими большими кораблями правда не проходит обычно — но борьба против логистов почти всегда есть.

      — сноси всех дронами;
      VS
      — сноси дронов;
      VS
      — не дай сносить дронов;
      У мазершипов и (реже) у авианосцев есть согласно названию куча мелких дронов. Они очень и очень больно бьют, быстро летают, приносят с собой лаг и вообще полезны для битвы. Для борьбы с ними обычно применяются линкоры (battleship), в которые вместо турелей вставляют AoE оружие, бъющее по всем целям вокруг линкора в определенном радиусе. Пиу-пиу и дронов нет — вражеский ДПС упал — ура, мы ломим. В свою очередь такие линкоры пытаются задержать подальше от дронов, ибо радиус этого оружия невелик. Насколько я видел по ролику — такое было.

      — используй моменты уязвимости противника для подтягивания подкреплений;
      VS
      — не проебите полимеры;
      Дредноуты, авианосцы, титаны при использовании определенных функций входят в режим, где они не способны двигаться на определенное время. Часто это — 10 минут. Соответственно эти 10 минут они никуда с поля боя не денутся вообще, кроме как в облако плазмы. Можно дождаться этого момента и внезапно привести подкрепления, разобрав их в этот момент.

      — всемером батьку бить легче.
      Основная тактика евы. Что защитники сделали правильно — увидев вражеский титан они сразу начали собирать подкрепления по разным альянсам. Случайно там мимокрокодил флот из 50 Дредноутов, например. В результате битва и удалась такой эпичной — флитком-уже-без-титана подтягивал флот своего альянса, а на огонек собирались все остальные.
  • 0
    В дополнение к моему комменту выше.

    Если честно, мне жалко программистов EVE Online. По-моему, у них явно прослеживается то, о чем я писала в своей статье. Они не рассчитывали, что их проект будет таким огромным. Поэтому воспользовались совершенно не масштабируемыми технологиями на питоне. Почитайте их блог, если думаете, что я говорю это в пустую или беру с потолка. Сейчас они стараются всё это держать как есть, ставя костыли и чуть ли не изобретая совершенно новые технологии, чтобы питон не разваливался, когда в солнечной системе много игроков.

    Напоминает твиттер, они такую же глупость сделали (кажется, на Rubby on Rails, если мне не изменяет память), а потом тащили лаги, которые начали появляться, когда твиттер стал ужасно популярен, и выдумывали, как бы это протащить не переписывая всю систему…

    Не хочу ничего сказать плохого в сторону питона или RR, нет! Просто это не языки, которые придумали для РЕАЛЬНО БОЛЬШИХ и масштабируемых проектов. Как минимум, автор RR считает так же, про питон не знаю…

    Лучше бы вложили средства в переписывание серверной части на более масштабируемых технологиях, чем на покупку новых серверов…
    • 0
      Есть мнение, что новые сервера дешевле чем платить людям. Вот только сервера нужны будут постоянно, а хорошую систему нужно переделать только один раз. Да и у одного сервера в любом случае есть лимит производительности, сколько за него не заплати, особенно если используется однопоточная архитектура. А значит, такая архитектура в любом случае в конце врежется в лимит и перестанет с чем-либо справляться нормально…
      • 0
        > хорошую систему нужно переделать только один раз

        Хорошую систему переделывать не нужно.

        А сервера дешевле / не дешевле, это вопрос сложный. Проблема тут даже не в том, что людям жалко платить. А в том, чтобы этих людей в необходимом количестве и качестве отыскать. Сервера то вот они. А людей дефицит жесткий :-(.
    • 0
      > совершенно не масштабируемыми технологиями на питоне

      Ммм? Это Eve то плохо масштабируется?
      А питон или не питон в общем то не важно. Масштабируемые системы можно хоть на JS писать.

      > Просто это не языки, которые придумали для РЕАЛЬНО БОЛЬШИХ и масштабируемых проектов.

      Оу. А ты случайно не Java-программист?)

      Btw, RoR это не язык, ну да что я к оговоркам придираюсь… А кто там что считает или не считает это его личное дело. На RoR есть куча больших систем (оно конечно жмет и колется, особенно в мастшабах твиттера, но состоятельность свою доказало).
  • –1
    Нуб ищет корпорацию.
    Каребирю на Каракале, сальважу на Корморанте, вяжу крестиком.
    В наличии 100мбит/с, гарнитура, ТС3.
  • 0
    Я так и не понял, кто победил?
    > Битву при Asakai называют полным разгромом.
    Кто разгромлен? Нападавшие или защищающиеся? Клан HoneyBadgers — это нападающие или защищающиеся?
    На хабре уже несколько статей об этой битве, а кто победил — так и не понятно. Одни догадки.
    • 0
      Наверно потому что для большинства (которые не игроки EVE ONLINE) не так важно кто победил, важен сам факт сражения и его размер.
      А вообще гугль в помощь наверно на профильных ресурсах более проброно должно быть освещено а хабр все же ресурс с IT уклоном, как бы :)))
      • 0
        Но, все же, хабр претендует на полноту и целостность информации. Зачем заставлять читателя гуглить, если можно просто дописать пару «лишних» строк?
  • 0
    В тот момент, когда нагрузка на сервер достигает критической точки, игра автоматически замедляет время на определенную величину для борьбы с перегрузкой. Время в битве на 3000 игроков запущено на 10% от реального, что составляет максимально возможное замедление.


    Интересно провести параллель с впечатлениями людей, участвующих в реальных боях (на войне/войнах).
    Вспомните, многие говорят/вспоминают, что время как бы замедляется в такие вот ответственные моменты.

    Летчик-штурмовик Сергей Иванович Колыбин, вылетая на одноместном Ил-2 в июле 1941 года, конечно догадывался, что опасное задание может стать для него последним. Но никакого воображения у него не хватило бы, чтобы предсказать свою дальнейшую судьбу: всего через час он станет первым и единственным летчиком, выжившим после наземного тарана; все его бомбы пройдут мимо цели, но тем не менее вражеская переправа будет уничтожена; трое суток он проваляется, никем не замеченный, в виде кровавого куска мяса; его ждут несколько лет в гитлеровских, а затем в сталинских лагерях… Но тогда он просто вылетел на задание и не выполнил его. Штурмовик был подбит, и фашистские солдаты уже бежали к месту его предполагаемой посадки. Колыбин круто развернул Ил-2 (а вместе с ним — всю свою дальнейшую судьбу) и врезался в мост. Это мгновение он запомнил на всю свою жизнь и о нем мог рассказывать часами. Самолет перед взрывом задел за конструкцию моста крылом и перевернулся, Колыбин вылетел из кабины… и время в его восприятии остановилось: он рассмотрел выражение лиц всех окружающих его гитлеровцев, видел, как некоторые из них пытались выбраться из танковых люков, другие бежали, ложились, хотели спрятаться от языков пламени, но все их движения были чересчур медленными…

    Другие примеры.
    Ни на какие мысли не наводит?
    • 0
      За вами уже… вылетели

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

Самое читаемое Разработка