Комментарии 166
Чертовски понравилась идея с замедлением времени — действительно изящный ход
Да, разработчики нашли интересный выход с учетом игровой механики EVE. Но согласитесь, в большинстве игр такое решение не применимо.
НЛО прилетело и опубликовало эту надпись здесь
Ага, т. е. если в нашей вселенной частица разгоняется до скорости света, то она перегружает сервер и время для неё замедляется? :)
Верно, но мы этого не замечаем, так как являемся частью мира.
Красивая идея. Впервые проникся ей в рассказе Каганова «Путешествие фантаста Свечникова».
НЛО прилетело и опубликовало эту надпись здесь
Можно еще такую аналогию привести — чем больше частиц в каком то объеме пространства вселенной, тем там медленнее течет время. Для черных дыр оно вообще почти останавливается.
Кстати, такая идея прекрасно объясняет один из постулатов квантовой теории. Постулат гласит о том, что сам факт наличия наблюдателя влияет на поведение частицы.
Идея хорошая, но она не позволяет полностью решить проблему обработки массового скопления игроков. Проблема в том, что если мы снизим скорость игры в 10 раз (как в нашем примере), то это линейно отразится на скорость обработки запросов сервером (в идеальном мире — производительность увеличиться в 10 раз). В то же время передача информации о близлежащих объектах (а также в большинстве случаев — обработка их взаимодействия) это задача с квадратичной сложностью (N игрокам нужно сообщать об N игроках).
Ход может и изящный, но как игроки на это реагируют? Бой начинает длиться в 10 раз медленнее. Это же сколько времени придется ждать? Мне бы лично это надоело. Хотя конечно тех отчаянных пилотов я не знаю.
10% это не в десять раз если что
«на 10% от реального» это значит что каждая секунда длится 10. Что и есть в 10 раз.
Если выстрел идет 100 секунд умножаем его на 10%, то есть на 1.1 в итоге получается, что выстрел будет 110секунд.
То есть вы не правы. Но в начале говориться не о 10%, а в 10 раз, то есть 100 секунд умножаем на 10
То есть вы не правы. Но в начале говориться не о 10%, а в 10 раз, то есть 100 секунд умножаем на 10
И За что тут минус? да вы получили значение 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
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
Видите ли, в противном случае вы бы точно так же ждали — но перед черным экраном, а потом либо вылетели бы к черту с сервера, либо прогрузились уже убитым тем, к кому велий лагательный рандом оказался снисходительнее. А тут медленно, но игра, с тактикой и стратегией. Ева — это не шутер, там иногда и без нагрузки на сервер хочется замедлить происходящее и подумать куда отварпать.
Игра в общем-то не обычная и люди, которые в неё играют, проводят за игрой много времени. В Eve не получится, подключиться и сразу же отправиться в вихрь битвы, а через 15 минут выключить компьютер и пойти спать.
Даже больше, сами битвы длятся очень коротко и составляют очень маленькую часть всего игрового процесса.
Даже больше, сами битвы длятся очень коротко и составляют очень маленькую часть всего игрового процесса.
Забавно, что самые убогие и примитивные игры со неразвязанным графическим и игровым движком обладают тем же свойством. При стрессе скорость игры замедляется вместе с фреймрейтом.
В понятие «лаг» входит понятие «замедление времени».
нет
Не на константу. Скорость ответа при больших лагах малопредсказуема, потому что нельзя точно сказать, сколько запросов будет через минуту, две три. В результате игрок не знает, как быстро придет ответ; момент времени странным образом растягивается для всех игроков, в результате кто-то оказывается в будущем, кто-то в прошлом на игровой шкале времени. Сервер может успеть обработать действия вашего соперника, но не успеть оповестить вас. Вы еще думаете, что успеваете сбежать, но на самом деле ваш персонаж мертв, а корабль разбит прилетевшей издалека бомбой.
CCP же подбирает коэффициент замедления так, чтобы заведомо превысить возможные лаги для каждого игрока, намеренно удерживая всех в одном времени и ставя всех в одни условия боя.
Интересно, можно ли рассматривать ОТО как систему борьбы с лагами в матрице? :)
CCP же подбирает коэффициент замедления так, чтобы заведомо превысить возможные лаги для каждого игрока, намеренно удерживая всех в одном времени и ставя всех в одни условия боя.
Интересно, можно ли рассматривать ОТО как систему борьбы с лагами в матрице? :)
А меня вот больше впечатлила фраза:
Ориентировочно потери составили 700 миллиардов в игровой валюте или 24 000 долларов.
Самый ценный ресурс евы, к сожалению, не купить. Время есть время.
С размахом поиграли.
Это не так много. Если честно, даже удивлен, что такая сумма (вообщем-то, небольшая по меркам EVE)
Я не знаком с мерками EVE. Видно я отстал от жизни, но такие суммы озвученные в контексте с действиями внутри игрового мира… впечатляют. Смешанные эмоции. Будущее уже здесь, с одной стороны, но с другой… столько денег в цветные пиксели…
Так разделите на 3000 игроков.
Да ладно… у людей большая часть жизни уходит либо в пустоту, либо в унитаз…
Люди кучу времени тратят просто выходя покурить. При этом тратят кучу денег и при этом еще и портят свое здоровье.
Пьют алкоголь, тратя еще больше больше денег и опять же, в ущерб здоровью.
Делают много бесполезных вещей, суть просто тратят время в пустую. И т.д. и т.п.
Так что это все лишь еще один способ потратить собственные деньги в удовольствие…
Люди кучу времени тратят просто выходя покурить. При этом тратят кучу денег и при этом еще и портят свое здоровье.
Пьют алкоголь, тратя еще больше больше денег и опять же, в ущерб здоровью.
Делают много бесполезных вещей, суть просто тратят время в пустую. И т.д. и т.п.
Так что это все лишь еще один способ потратить собственные деньги в удовольствие…
По моим прикидкам близзард на абонентке за вов получает 24к$ примерно за десять минут игрового времени. А общие годовые прибыли того же близзарда за все их «цветные пиксели» исчисляется в миллиардах. Чьи же это миллиарды?
Мне представляется, что сравнение не совсем корректно.
Абонентская подписка за использования сервера для игры — это всё же покупка услуги. И в Eve она тоже присутствует — все игроки платят за игру на сервере.
В этом плане прибыль обеих компании зависит только от популярности. Кто больше спотов на серверах продал — тот и заработал больше.
А вот эти 24k$ — это не подписка, а введённые или заработанное в самой игре деньги, которые были выведены из оборота в результате боя. У Близзард вроде бы ни в одной игре нельзя потерять то, что ты приобрёл, в Eve наоборот можно купить корабль за введённые в игру деньги и при уничтожении этого корабля, это, утрируя, сжигает эти самые деньги.
P.S.: Тут как раз таки похоже на казино, в котором вы платите за вход, потом покупаете фишки, на которые играете. Должно быть, это очень сильно будоражит и адреналит зашкаливает у азартных людей.
Абонентская подписка за использования сервера для игры — это всё же покупка услуги. И в Eve она тоже присутствует — все игроки платят за игру на сервере.
В этом плане прибыль обеих компании зависит только от популярности. Кто больше спотов на серверах продал — тот и заработал больше.
А вот эти 24k$ — это не подписка, а введённые или заработанное в самой игре деньги, которые были выведены из оборота в результате боя. У Близзард вроде бы ни в одной игре нельзя потерять то, что ты приобрёл, в Eve наоборот можно купить корабль за введённые в игру деньги и при уничтожении этого корабля, это, утрируя, сжигает эти самые деньги.
P.S.: Тут как раз таки похоже на казино, в котором вы платите за вход, потом покупаете фишки, на которые играете. Должно быть, это очень сильно будоражит и адреналит зашкаливает у азартных людей.
не знаю какие суммы проигрывают в онлайн покер, но предполагаю что покер-игроки смотрят на потери в EVE с улыбкой)
по экономике в EVE даже статьи пишут. если я ничего не путаю, у них там штатно сидит пара головастых экономистов. на хабре вроде статья пробегала, сейчас не могу нарыть.
Это не очень много. Большая часть этой суммы заработана внутри игры, и на неё не тратился реал. Так что да, игроки пойдут покупать себе новые корабли, и кто-то заплатит живых денег. Но не 24000$.
Насколько я понимаю экономика в EVE честная и на «заработано внутри игры» точно также тратиться реал, просто это перераспределение кредитов от тех, кто купил PLEX за реал и продал за кредиты, тем, кто в игре их отрабатывал.
А награды за выполнение квестов? Они-то точно «из воздуха». Да и вообще я не особо верю в возможность построения сбалансированной закрытой экономики внутри игры. Даже при таком онлайне. Практически наверняка админы удерживают рынок в желаемых параметрах, иначе это неиграбельно будет.
Удерживают конечно, только что в этом плохого. Награды за квесты и т.п. компенсируется потерями в боях, беоприпасами\расходными материалами, использованными PLEXами и т.п., я полагаю пара экономистов у них за тем и сидит, чтоб регулируя управляемые параметры, вроде наград за квесты не давать им сколько-нибудь солидно влиять на закрытый сегмент экономики.
Компания заинтересована в прибыли, в первую очередь. Им нужно держать соотношение курса PLEX/ISK в зоне равновесной цены. Если меньше или больше, то они будут недополучать деньги. Если освободить рынок полностью, у них доходы будут сильно прыгать. Чуть где-то масштабные действия корпораций произошли (военные или экономические, неважно), рынок наклонился, и у них процентов на 20 просела выручка. Регулировать рынок надо. А учитывая механику игры, им приходится либо изымать ISK из оборота или наоборот их туда вливать.
Динамической регулировкой наград за квесты не обойтись, т.к. это сильно влияет на геймплей. Условно — сегодня мне хватает награды, чтобы восстановить корабль, купить няшку для него, пополнить запас боеприпасов и лететь на следующее задание. А завтра не хватает даже чтобы патроны купить.
Единственный беспроигрышный вариант — это прямые интервенции на рынке. Администрация может: 1. скупать выставленный товар игроков (вливая ISK), и 2. выставлять товар на рынок (изымая ISK). Таким образом можно регулировать, что угодно. Но это, простите, уже не закрытая экономика.
Вполне допускаю, что у администрации есть и другие экономические рычаги (я не игрок, деталей не знаю), но мне кажется что прямые интервенции — это самое очевидное решение.
Динамической регулировкой наград за квесты не обойтись, т.к. это сильно влияет на геймплей. Условно — сегодня мне хватает награды, чтобы восстановить корабль, купить няшку для него, пополнить запас боеприпасов и лететь на следующее задание. А завтра не хватает даже чтобы патроны купить.
Единственный беспроигрышный вариант — это прямые интервенции на рынке. Администрация может: 1. скупать выставленный товар игроков (вливая ISK), и 2. выставлять товар на рынок (изымая ISK). Таким образом можно регулировать, что угодно. Но это, простите, уже не закрытая экономика.
Вполне допускаю, что у администрации есть и другие экономические рычаги (я не игрок, деталей не знаю), но мне кажется что прямые интервенции — это самое очевидное решение.
Прямых интервенций в том виде как вы описываете нет 100%, там есть целый слой игроков, которые с презрением относятся к «пиу-пиу», занимаясь исключительно торговлей, производством и т.п., у каждого товара всегда прописан продавец и т.п., любая прямая интервенция послужила бы причиной убытков у того или иного игрока и хай бы тут же поднялся на полную катушку.
НЛО прилетело и опубликовало эту надпись здесь
Не потерями, а добычей :) Потери как раз увеличивают «необеспеченную» денежную массу — обвес сгорел, а деньги-то в игре остались.
Награды за квесты, страховка и другая «эмиссия» валюты компенсируется добычей минералов, лутом и прочими игровыми ништяками.
Под «честной» имеется в виду, что администрация не рисует деньги или рары в обмен на наличку.
Под «честной» имеется в виду, что администрация не рисует деньги или рары в обмен на наличку.
Что-то мне подсказывает, что именно в игровых системах и будут созданы системы управления гипертрафиком на орбите Земли (и других планет) в будущем.
Жалкие 3000 игроков и они радуются что все работает с «не очень фатальными» лагами?
Передавайте привет Питону.
Но прогресс конечно есть, когда я играл пару лет назад — на 1000 человек лагало гораздо хуже. Это была прям специальная олимпиада какая-то по ведению боев в легах.
Передавайте привет Питону.
Но прогресс конечно есть, когда я играл пару лет назад — на 1000 человек лагало гораздо хуже. Это была прям специальная олимпиада какая-то по ведению боев в легах.
У Вас есть примеры где over 3000 игроков на локации не лагают?
В линейке например во времена C4 все было на одном монолитном C++ ядре, и держало десятки тысяч клиентов без особых лагов. Железо тогда тоже было намного проще.
А теперь добавьте что каждый из этих 3000 клиентов должен просчитать например траекторию ракеты (дрона, лазерного луча, etc) и просчет всего дамага который единомоментно влетает на каждый из этих 3к клиентов ложится на сервер, в линейке расчет очень простой:
Пришло: Удар мечом
Посчитать: rand(1,20) — def*rand(1,5)
Отправить:result
грубо говоря как-то так, а клиент просто отрисовывает стандартную анимацию удара, если крит повесить над головой табличку
Пришло: Удар мечом
Посчитать: rand(1,20) — def*rand(1,5)
Отправить:result
грубо говоря как-то так, а клиент просто отрисовывает стандартную анимацию удара, если крит повесить над головой табличку
Траектория ракеты в EVE насколько я помню — исключительно декоративное явление, никаких коллизий там не просчитывается.
Как долетит — формула такая-же как и в Линейке получается :-)
Как долетит — формула такая-же как и в Линейке получается :-)
Повреждения от ракет ЕВЕ зависят от многих факторов, и это далеко не рандом в линейке линк
Тем не менее, формула повреждений — на одну строчку, да и едва-ли её сложность на что-то повлияла бы в любом случае — взрывов ракет не большее сотни-другой в секунду.
В EVE ракета может нанести урон не только по цели, но и часть урона если кто то был рядом с целью, так сказать взрывной волной. На это тоже нужен обсчет. в зависимости от траектории, скорости, удаления, тоже разный урон, что тоже надо обсчитать.
Каждый дрон это можно сказать НПЦ со своим АИ. Поставьте в туже ленейку еще пару тысяч мобов.
И ракет намного больше. В среднем с одной ракетницы идет 1 ракета в 2с, ракетниц скажем 6. Это 3 ракеты в секунду. Да и другие игроки тоже стреляют и некоторые быстрее. Это уже не сотня-другая ударов в секунду, это 6000+ выстрелов не считая дронов.
Что в итоге хотел донести: в EVE много расчетов, намного больше чем в классической онлайн игре.
Каждый дрон это можно сказать НПЦ со своим АИ. Поставьте в туже ленейку еще пару тысяч мобов.
И ракет намного больше. В среднем с одной ракетницы идет 1 ракета в 2с, ракетниц скажем 6. Это 3 ракеты в секунду. Да и другие игроки тоже стреляют и некоторые быстрее. Это уже не сотня-другая ударов в секунду, это 6000+ выстрелов не считая дронов.
Что в итоге хотел донести: в EVE много расчетов, намного больше чем в классической онлайн игре.
Было бы интересно почитать про «часть урона тем кто рядом», например описание на wiki.eveonline.com/en/wiki/Missiles#Damage_Calculation пишет только о том, что ракета всегда попадает в цель, если она не сбита.
По описанию — влияет только скорость корабля и взрыва, размер сигнатуры, радиус взрыва и все. Никаких траекторий обсчитывать не нужно.
Вопрос с бомбами отдельный.
По описанию — влияет только скорость корабля и взрыва, размер сигнатуры, радиус взрыва и все. Никаких траекторий обсчитывать не нужно.
Вопрос с бомбами отдельный.
eve-ru.com/guide/missiles/
Там про взрывную волну написано и то что урон наносится в момент попадания, а не в момент выстрела. Ракета может лететь пару секунд, а за это время траектория цели изменится или цель может улететь от ракеты.
Урон зависит не только от скорости цели, на сколько быстро удаляется одна от другой, но и от угловой скорости. Оружия имеет поворот (не считая ракет) и это надо обсчитывать, как успевают турели поворачиваться за целью, если нет, то и урона не будет.
Если поиграть в EVE, то станет понятно что математики там куча :)
Там про взрывную волну написано и то что урон наносится в момент попадания, а не в момент выстрела. Ракета может лететь пару секунд, а за это время траектория цели изменится или цель может улететь от ракеты.
Урон зависит не только от скорости цели, на сколько быстро удаляется одна от другой, но и от угловой скорости. Оружия имеет поворот (не считая ракет) и это надо обсчитывать, как успевают турели поворачиваться за целью, если нет, то и урона не будет.
Если поиграть в EVE, то станет понятно что математики там куча :)
От ракеты можно «удрать» и ракету можно сбить в полете, аж тремя видами вооружения, и для двух из них важна именно траектория полета ракеты.
Увы, нет. Чтобы взорваться, ракета должна долететь.
Есть ракета, которая летит со скоростью 4000м/с и топлива у неё на 10 секунд. Она попадет по цели, которая от нас в 22 километрах? Ответ прост.
А по цели, которая улетает от нас со скоростью 1970м/с? Чуть сложнее, правда?
А по цели, которая кружится вокруг нас на постоянной орбите радиусом 7500 метров (орбита только постоянно меняется слегка, то астероиды там, то игрок притормозит), со скоростью 3900м/с? 3975м/с? 4100 м/с?
А если эта цель запускает 4 тяжелых противоракеты по нашему залпу из 4 тяжелых и 3 легких ракет, а у противоракет тоже конечная дальность полета, скорость и урон, а оба корабля маневрируют относительно друг друга, то сколько ракет долетит и какого пилота выпрут из корпы, потому что он забыл застраховать корабль?
Это вполне реальные игровые примеры.
И я уж не говорю про AoE оружие, которое, скажем, одномоментно поражает все в радиусе 10 км от корабля. Сколько ракет из залпа будет уничтожено при активации модуля? Так что там все сложнее чем в линейке в разы.
Есть ракета, которая летит со скоростью 4000м/с и топлива у неё на 10 секунд. Она попадет по цели, которая от нас в 22 километрах? Ответ прост.
А по цели, которая улетает от нас со скоростью 1970м/с? Чуть сложнее, правда?
А по цели, которая кружится вокруг нас на постоянной орбите радиусом 7500 метров (орбита только постоянно меняется слегка, то астероиды там, то игрок притормозит), со скоростью 3900м/с? 3975м/с? 4100 м/с?
А если эта цель запускает 4 тяжелых противоракеты по нашему залпу из 4 тяжелых и 3 легких ракет, а у противоракет тоже конечная дальность полета, скорость и урон, а оба корабля маневрируют относительно друг друга, то сколько ракет долетит и какого пилота выпрут из корпы, потому что он забыл застраховать корабль?
Это вполне реальные игровые примеры.
И я уж не говорю про AoE оружие, которое, скажем, одномоментно поражает все в радиусе 10 км от корабля. Сколько ракет из залпа будет уничтожено при активации модуля? Так что там все сложнее чем в линейке в разы.
Да, я уже понял, вы правы.
Да Вы не сдавайтесь, в Лайнейдже ничуть не проще потроха, как бывший разработчик эмулятора говорю :)
Фактически, любое преследование или атака — это не просто аналог самонаведения ракеты, а ещё с постоянной ежесекундной перепроверкой или коррекцией. И массовое поражение там тоже было. Да ещё всё это не в пустом пространстве, а на сложном рельефе с препятствиями. И мало самих игроков обрабатывать, там же десятки тысяч мобов, каждый со своим ИИ, который отслеживает других игроков и соседних мобов, проводит атаку, если необходимо…
Такую уйму интересных алгоритмических задач приходилось решать :)
Фактически, любое преследование или атака — это не просто аналог самонаведения ракеты, а ещё с постоянной ежесекундной перепроверкой или коррекцией. И массовое поражение там тоже было. Да ещё всё это не в пустом пространстве, а на сложном рельефе с препятствиями. И мало самих игроков обрабатывать, там же десятки тысяч мобов, каждый со своим ИИ, который отслеживает других игроков и соседних мобов, проводит атаку, если необходимо…
Такую уйму интересных алгоритмических задач приходилось решать :)
Тем не менее это не сравнимо. Эти игроки находятся не в прямой видимости друг друга и вам не нужно отправлять каждому игроку данные о действиях каждого другого игрока. Прямое взаимодействие игроков начинает многократно в геометрической прогрессии увеличивать нагрузку на сервер и в те же времена C4 сервера весело отваливались уже при осаде замка в несколько сотен человек.
Никакой геометрической прогрессии нет, если есть агрегация отправляемых данных.
При правильной реализации, на 10FPS — на 3000 игроков нам нужно будет отправлять 30к пакетов в секунду, и на этом все.
При правильной реализации, на 10FPS — на 3000 игроков нам нужно будет отправлять 30к пакетов в секунду, и на этом все.
Ну типа да, только в каждый этот пакет нужно подготовить результат и напихать все изменения по остальным 2999 игрокам.
Когда игроки размазаны по серверу равномерно — они в пакете получают изменений всего по 30-50 игрокам вокруг. Что уж говорить если в линейке даже в крупном городе с онлайном человек в 500 сервер начинал выдавать передвижения и действия игроков с приличными задержками.
Когда игроки размазаны по серверу равномерно — они в пакете получают изменений всего по 30-50 игрокам вокруг. Что уж говорить если в линейке даже в крупном городе с онлайном человек в 500 сервер начинал выдавать передвижения и действия игроков с приличными задержками.
В линейке например во времена C4 все было на одном монолитном C++ ядре, и держало десятки тысяч клиентов без особых лагов. Железо тогда тоже было намного проще.
Только не рассказывайте нам про то что влинейке 10тки тысяч клиентов :) Там максимум около 5 — 8к на весь сервер и это при самом хорошем раскладе.
Десятки тысяч клиентов в одной локации? Вы шутите? Не помню осад с более чем полутора тысячами участников, по крайней мере в NA. Может у корейцев.
На сервере линеечки клиенткап времен С4 это 5000 — и это было даже на евро.
Другое дело, что хотя сам протокол и довольно простой — а вот движок тупо не справляется с таким количеством полигонов в кадре. Во времена памятного замеса красных против желтых за Баюма на теоне («вперед, мои хомячки!», кхе-кхе) было всего примерно 300 на 300 на 13 этаже. У меня выдавало 1-2 fps, работал чисто по ассисту — благо играл соркой
Другое дело, что хотя сам протокол и довольно простой — а вот движок тупо не справляется с таким количеством полигонов в кадре. Во времена памятного замеса красных против желтых за Баюма на теоне («вперед, мои хомячки!», кхе-кхе) было всего примерно 300 на 300 на 13 этаже. У меня выдавало 1-2 fps, работал чисто по ассисту — благо играл соркой
1500 несколько лет назад в сложном окружении (рельеф, строения) — это куда больше впечатляет, чем 3000 сегодня и в открытом пространстве :)
Ну eve online — тоже не самая новая игра, релиз был в 2003-м.
НЛО прилетело и опубликовало эту надпись здесь
4 игровых демона + парочка дополнительных (не считая БД) это нынче монолит? Десятки тысяч оно могло держать только суммарно по всем игровым мирам, для обеспечения работы каждого требовалось 3 отдельных демона из 4 упомянутых. К тому же, в серверной части был захардкоден лимит в 5000 CCU, а на осадах замков все равно лагало все что только могло лагать (на оффе в основном только на клиентской стороне, на пиратских серверах со слабым железом могло вставать колом абсолютно все).
10 тыс на одном сервере, а не в одной локации. В линейке эти 10 тыс не видят друг друга и их легко раскидать по независимым сервакам.
Прямо классический пример заблуждения технического человека в бизнесе. Я думаю, в CCP передали привет Питону, посмотрели на свои финансовые результаты, улыбнулись и пошли дальше хеннесси пить. С C++ они бы вписались в разработку на годы, были бы менее динамичны, и в результате вообще могли не взлететь или не вырасти до таких объемов.
Я не утверждаю, что все нужно писать на С++.
Но ситуация выглядит интересно — сначала написать все на питоне, потом — писать радостные статьи о том, что они начали чуть меньше лагать (эта статья — не первая, и даже не десятая на эту тему) :-) Если производительность не имеет значение, зачем вообще тогда такие статьи?
Прямо как в поговорке «создать себе проблемы, а потом героически их преодолевать».
Но ситуация выглядит интересно — сначала написать все на питоне, потом — писать радостные статьи о том, что они начали чуть меньше лагать (эта статья — не первая, и даже не десятая на эту тему) :-) Если производительность не имеет значение, зачем вообще тогда такие статьи?
Прямо как в поговорке «создать себе проблемы, а потом героически их преодолевать».
Ну как зачем такие статьи. Паблисити в среде разработчиков — раз, просто PR-повод — два. К тому же, я думаю, они столько бабла сэкономили на питоне, что могут поставить Fusion IO в каждый сервер и еще на сдачу купить игрушечный марсоход. У всех оптимизаций есть величина ROI. Если все игроки в целом довольны скоростью, плюс с небольшими манипуляциями они могут тянуть такие замесы, зачем тратить лишние деньги на преждевременные улучшения?.. Все мы, разработчики, знаем, что улучшать можно бесконечно :)
Передавайте привет Питону.
У вас есть каменные доказательства того, что если бы вместо Stackless (который достаточно быстр, посмотрите на производительность близкого его сородича PyPy в сравнении с программой на C (gcc -O3) на числодробительной синтетике) серверный софт был бы переписан на C/C++, это
1) Кардинально улучшило бы ситуацию с лагами, которым подвержены только участники больших баталий (извините, но в нормальных условиях и Жита не лагает, а 3000 игроков в одной локации, как правильно говорят выше, залагают в любой ММО);
2)… и что очень и очень немаловажно (и как человек, которому не чужда IT-сфера, вы должны это понимать) — что это позволит настолько же эффективно и быстро поддерживать софт, фиксить баги и развивать возможности, как при использовании не в пример более высокоуровневого языка?
PyPy — быстр из-за JIT-компиляции, это мне нравится.
Есть ли в Stackless Python JIT-компиляция?
По второму пункту — я полностью согласен с тем, что с экономической точки зрения дешевая и быстрая разработка с лагами иногда — может быть выгодна. Но не понимаю, почему нужно радоваться каждый раз когда такое экономичное решение начинает несколько меньше лагать. Постоянная борьба с лагами в таких условиях — это именно что заурядная рутина, а подают так, как будто это фантастический прорыв.
Есть ли в Stackless Python JIT-компиляция?
По второму пункту — я полностью согласен с тем, что с экономической точки зрения дешевая и быстрая разработка с лагами иногда — может быть выгодна. Но не понимаю, почему нужно радоваться каждый раз когда такое экономичное решение начинает несколько меньше лагать. Постоянная борьба с лагами в таких условиях — это именно что заурядная рутина, а подают так, как будто это фантастический прорыв.
>Кардинально улучшило бы ситуацию с лагами, которым подвержены только участники больших баталий
Да, однозначно. Есть масса тестов на этот счёт.
>что это позволит настолько же эффективно и быстро поддерживать софт, фиксить баги и развивать возможности
А вот тут — нет. Потому Питон и был выбран.
Я думаю, разработчики EVE не рассчитывали на такую популярность и массовость, потому и выбрали решение, позволяющее дешевле, быстрее и эффективнее разрабатывать сервер за счёт производительности. Ну а сейчас уже поздно коней на переправе менять, поддерживают и развивают что получилось.
Да, однозначно. Есть масса тестов на этот счёт.
>что это позволит настолько же эффективно и быстро поддерживать софт, фиксить баги и развивать возможности
А вот тут — нет. Потому Питон и был выбран.
Я думаю, разработчики EVE не рассчитывали на такую популярность и массовость, потому и выбрали решение, позволяющее дешевле, быстрее и эффективнее разрабатывать сервер за счёт производительности. Ну а сейчас уже поздно коней на переправе менять, поддерживают и развивают что получилось.
Разрабы еще 2 года назад говорили что ядро не использует питон. Там проблема в том что одна солнечная система не масштабируется на несколько серверов. Это проблема архитектуры игрового движка и пока она не решена.
>Разрабы еще 2 года назад говорили что ядро не использует питон.
Значит, таки, переписали.
>Там проблема в том что одна солнечная система не масштабируется на несколько серверов.
С другой стороны я, вот, имея некоторый опыт работы с такими системами, искренне не понимаю, зачем для 3000 игроков в открытом пространстве систему растаскивать на несколько серверов :) То есть в варианте с Питоном, как раз, понятно. Но если ядро на чём-то более производительном, хотя бы на Java, то уже — непонятно.
Наверное, проблемы тогда лезут уже не из ограничений производительности, а из пропускной способности канала. Если протокол не очень компактный, то 3000 активных клиентов даже гигабитный канал могут сожрать и не поморщиться.
Трафик EVE замеряли, сколько клиент в час потребляет?
Значит, таки, переписали.
>Там проблема в том что одна солнечная система не масштабируется на несколько серверов.
С другой стороны я, вот, имея некоторый опыт работы с такими системами, искренне не понимаю, зачем для 3000 игроков в открытом пространстве систему растаскивать на несколько серверов :) То есть в варианте с Питоном, как раз, понятно. Но если ядро на чём-то более производительном, хотя бы на Java, то уже — непонятно.
Наверное, проблемы тогда лезут уже не из ограничений производительности, а из пропускной способности канала. Если протокол не очень компактный, то 3000 активных клиентов даже гигабитный канал могут сожрать и не поморщиться.
Трафик EVE замеряли, сколько клиент в час потребляет?
> одна солнечная система не масштабируется на несколько серверов.
Засада в том, что она не масштабируется даже на несколько процессорных ядер в рамках одного сервера, и ВСЯ система работает в одном потоке.
Засада в том, что она не масштабируется даже на несколько процессорных ядер в рамках одного сервера, и ВСЯ система работает в одном потоке.
Некорректное сравнение. Скомпиленый С код хоть и был скомпилен на -O3, реально это не дало никаких дивидендов, ибо вызываемая функция находилась в другой единице трансляции. Перенесли бы они все в один файл — тогда бы и сравнивали. Результаты получились совсем другие.
Фразы разработчиков («Мы перемещаем другие солнечные системы с ноды, на которой идет сражение...») звучат так, будто они представители Цивилизации VI Типа. Даже немного жалею, что ни разу не играл в EVE Online.
>Супеавианосец
Странный перевод. Поменяйте пожалуйста на «мазершип» (mothership) или «материнский корабль».
>замедляющееся до предельного уровня в 10% время
Хмм, странно. Неужели 10% — максимум? По ощущениям, замедлиться может и на 30-40%. Кисель же.
Странный перевод. Поменяйте пожалуйста на «мазершип» (mothership) или «материнский корабль».
>замедляющееся до предельного уровня в 10% время
Хмм, странно. Неужели 10% — максимум? По ощущениям, замедлиться может и на 30-40%. Кисель же.
www.youtube.com/watch?v=NGIALyoZc3o
Я смотрю, телепортировать «Титан» ко врагам это сейчас модно в EVE :)
Я смотрю, телепортировать «Титан» ко врагам это сейчас модно в EVE :)
Всегда было «модно».
В меню у пилотов титанов опции «jump to» (прыгнуть на маячок самому) и «bridge to» (открыть портал на маячок) находятся близко :)
Люди путают бывает, вот и получается то что на видео. Т.е. титан таким образом сам попадает один-одинешенек в гущу врагов.
В меню у пилотов титанов опции «jump to» (прыгнуть на маячок самому) и «bridge to» (открыть портал на маячок) находятся близко :)
Люди путают бывает, вот и получается то что на видео. Т.е. титан таким образом сам попадает один-одинешенек в гущу врагов.
Это едва ли не единственная дизайн-функция титана, так что да, да =)
Ещё бы понять что происходит на видео. Все бьют друг друга? Я никогда не играл в EVE и не понимаю механику игры.
По-моему, это не новый ход.
Я вот жутко удивился, сыграв 15-минутную партию в Supreme commander forged alliance за 40 минут. Уже вторая партия поставила все на свои места — время идет почти «нормально» до «засвета» противника. Как только количество видимых юнитов переваливает за условные 3к, время начинает вытягиваться.
Но имхо, это всяко лучше, чем в World of Tanks, где бои всегда 15х15, но только днем снаряд летит на 900м секунду, а вечером тоже секунду, только выстреливает и попадает с таким лагом, что результат сильно разный
Я вот жутко удивился, сыграв 15-минутную партию в Supreme commander forged alliance за 40 минут. Уже вторая партия поставила все на свои места — время идет почти «нормально» до «засвета» противника. Как только количество видимых юнитов переваливает за условные 3к, время начинает вытягиваться.
Но имхо, это всяко лучше, чем в World of Tanks, где бои всегда 15х15, но только днем снаряд летит на 900м секунду, а вечером тоже секунду, только выстреливает и попадает с таким лагом, что результат сильно разный
Это просто называется «лаги». Внутриигровой таймер супримы рассчитан на то, что вся игра идёт на скорости +0, тогда время таймера реальное. Когда у кого-то в партии очень слабый комп и он начинает тормозить (заметьте! не только сервер!), то TPS проседает и таймер идёт согласно новому TPS. Ничего более, просто лаги.
По поводу WOT: тот же TPS. Если TPS сервера ниже, то снаряд делает за секунду меньше циклов, чем обычно, соответственно, алгоритмы полета, основанные на простых формулах, становятся невероятно неточными.
В EVE же замедление это не прямое следствие лагов, а «костыль» для избавления от них. Если бы просто на сервере проседал TPS, то все становилось бы только хуже: просевший сервер стал бы «захлёбываться» пакетами игроков, которые бы продолжали идти с нормальной скоростью, все наращивая и наращивая очередь пакетов на обработку и уровень лагов. По этому в EVE замедление напрямую управляется с сервера и передаётся клиентам, и клиент начинает слать пакеты тоже медленнее.
По поводу WOT: тот же TPS. Если TPS сервера ниже, то снаряд делает за секунду меньше циклов, чем обычно, соответственно, алгоритмы полета, основанные на простых формулах, становятся невероятно неточными.
В EVE же замедление это не прямое следствие лагов, а «костыль» для избавления от них. Если бы просто на сервере проседал TPS, то все становилось бы только хуже: просевший сервер стал бы «захлёбываться» пакетами игроков, которые бы продолжали идти с нормальной скоростью, все наращивая и наращивая очередь пакетов на обработку и уровень лагов. По этому в EVE замедление напрямую управляется с сервера и передаётся клиентам, и клиент начинает слать пакеты тоже медленнее.
Теперь ясно, почему в стрессовой ситуации у человека иногда время начинает растягиваться, сервера не успевают!
Многие здесь не знакомы с EVE и поэтому могут некоторые вещи неправильно понять.
Насчет масштабов битвы — это действительно одно из крупнейших или даже самое крупное сражение в истории игры. С технической точки зрения нужно понимать, что к 3 тысячям кораблей нужно добавить отслеживание ракет, файтеров, бомберов и простых дронов, активацию кучи модулей и просчет их работы (в игре довольно сложная механика), движение в 3х-мерном простанстве. Года 2 назад такие битвы происходили в виде сплошного лага — люди 20 минут грузились в систему, кому повезло загрузиться — раз в 10 минут могли стрельнуть. Очень часто ход действий можно было проще и быстрее отследить по апи и борде (уже достаточно автоматизированные вещи) а не по тому, что видно в клиенте. Лаг был одним из основных аспектов подобных боев. Замедление времени позволило переместить контроль над результатом боя обратно в руки игроков, пусть даже и не полностью.
По поводу потерь — примерно 1.5 года назад была битва с несколько более печальными потерями — 8 титанов и 15 мазершипов. Но опять же — приведенные в статье цифры и оценка в реальной валюте хоть и имеет место быть, но уже давно подобные вещи не вызывают интереса.
Насчет масштабов битвы — это действительно одно из крупнейших или даже самое крупное сражение в истории игры. С технической точки зрения нужно понимать, что к 3 тысячям кораблей нужно добавить отслеживание ракет, файтеров, бомберов и простых дронов, активацию кучи модулей и просчет их работы (в игре довольно сложная механика), движение в 3х-мерном простанстве. Года 2 назад такие битвы происходили в виде сплошного лага — люди 20 минут грузились в систему, кому повезло загрузиться — раз в 10 минут могли стрельнуть. Очень часто ход действий можно было проще и быстрее отследить по апи и борде (уже достаточно автоматизированные вещи) а не по тому, что видно в клиенте. Лаг был одним из основных аспектов подобных боев. Замедление времени позволило переместить контроль над результатом боя обратно в руки игроков, пусть даже и не полностью.
По поводу потерь — примерно 1.5 года назад была битва с несколько более печальными потерями — 8 титанов и 15 мазершипов. Но опять же — приведенные в статье цифры и оценка в реальной валюте хоть и имеет место быть, но уже давно подобные вещи не вызывают интереса.
20 минут грузиться в системе? В битве за LXQ я одним чаром 4 часа на черный экран любовался после пропрыга в систему. А лаг всех действий был около 10 минут. Хотя конечно это был рекорд онлайна на то время и ССР было удивлено что нода выдержала :)
Так что 20 минут прогружаться в системе — это и не лаг совсем, а так, небольшая задержка пакетов :)
Так что 20 минут прогружаться в системе — это и не лаг совсем, а так, небольшая задержка пакетов :)
Хочу немного порассуждать об архитектуре подобной системы.
Сейчас, как я понимаю, несколько процессов обработки систем (назову их нодами) висят на одном сервере, и разделить их сложно — необходимо остановить процесс (с потерей соединений) и поднять на новой машине.
А теперь пофантазируем. Поместим все расчётные ноды в облачный кластер — отдельный процесс обработки солнечной системы (ноду) в отдельную ВМ. За счёт возможности миграции виртуальной машины на другой узел кластера без остановки самой виртуальной машины появляется куча интересных возможностей по гибкому управлению нодами — балансировка нагрузкой серверов за счёт переноса нод, освобождение мощности сервера под возросшую нагрузку одной ноды вынесением остальных с сервера.
Получится ли перенести ноду, держащую нужную систему на сервер помощнее, как миграция относится к постоянным коннектам, сохранит ли?
За какое время осуществляется миграция, и что при этом происходит с самой машиной? Замораживается на несколько секунд/минут? Продолжает работать в штатном режиме, обрабатывая запросы?
P.S. Я только начал изучать возможности виртуализации, так что если вопрос ламерский — не обессудьте…
Сейчас, как я понимаю, несколько процессов обработки систем (назову их нодами) висят на одном сервере, и разделить их сложно — необходимо остановить процесс (с потерей соединений) и поднять на новой машине.
А теперь пофантазируем. Поместим все расчётные ноды в облачный кластер — отдельный процесс обработки солнечной системы (ноду) в отдельную ВМ. За счёт возможности миграции виртуальной машины на другой узел кластера без остановки самой виртуальной машины появляется куча интересных возможностей по гибкому управлению нодами — балансировка нагрузкой серверов за счёт переноса нод, освобождение мощности сервера под возросшую нагрузку одной ноды вынесением остальных с сервера.
Получится ли перенести ноду, держащую нужную систему на сервер помощнее, как миграция относится к постоянным коннектам, сохранит ли?
За какое время осуществляется миграция, и что при этом происходит с самой машиной? Замораживается на несколько секунд/минут? Продолжает работать в штатном режиме, обрабатывая запросы?
P.S. Я только начал изучать возможности виртуализации, так что если вопрос ламерский — не обессудьте…
Там все немного сложнее. То что обычно называют «сервером» сегодня не является «сервером» в обычном смысле. Современная серверная архитектура MMO — это как раз облачный кластер и балансировщик нагрузки, который перераспределяет ресурсы физических машин.
С другой стороны нужно понимать, что за работу игры ответственны сразу куча более-менее независимых систем. В зависимости от реализации конкретной игры, они могут взаимодействовать совершенно по-разному. Грубо говоря, у вас есть логин-сервер, патч-сервер, зонные сервера, чат-сервер, нечто, обеспечивающее связь всего этого с БД персонажей, и так далее. Все это может либо работать либо вместе, либо по-отдельности. Например чат обычно полностью независим от всего остального, поэтому иногда можно наблюдать ситуацию, когда клиент потерял коннект с игровым сервером, и на экране у вас все встало, а чат работает.
Естественно, архитектура взаимодействия этих компонентов будет влиять на возможности балансировки нагрузки, так что сложно получить представление о каком-то «общем случае».
Про архитектуру в EVE online можно немножко почитать вот тут (статья на английском).
С другой стороны нужно понимать, что за работу игры ответственны сразу куча более-менее независимых систем. В зависимости от реализации конкретной игры, они могут взаимодействовать совершенно по-разному. Грубо говоря, у вас есть логин-сервер, патч-сервер, зонные сервера, чат-сервер, нечто, обеспечивающее связь всего этого с БД персонажей, и так далее. Все это может либо работать либо вместе, либо по-отдельности. Например чат обычно полностью независим от всего остального, поэтому иногда можно наблюдать ситуацию, когда клиент потерял коннект с игровым сервером, и на экране у вас все встало, а чат работает.
Естественно, архитектура взаимодействия этих компонентов будет влиять на возможности балансировки нагрузки, так что сложно получить представление о каком-то «общем случае».
Про архитектуру в EVE online можно немножко почитать вот тут (статья на английском).
Спасибо за ссылку.
>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 — загруженные, перетасуем их вместе».
>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 — загруженные, перетасуем их вместе».
Ну, судя по всему, да. Мой комментарий конкретно к ним не относился, это я так, абстрактно. Еще ведь важную роль играет специфика самой игры (простите за каламбур). Например если вы знаете, что из-за каких-то факторов (ресурсы, расположение, или что-то еще) крупные битвы будут происходить в основном в вот этой, вот этой и вот этой звездной системах, то вы можете заранее вынести их на более высокопроизводительное оборудование.
После прочтения статьи я удивился, что они не могут переносить эти процессы на горячую. Конечно это не совсем просто, но вполне реализуемо на мой взгляд для такого большого и старого проекта, как ив.
Просто оставлю это здесь: ru.wikipedia.org/wiki/CRIU
По крайней мере в технологии OpenVZ возможен перенос процессов на другую физическую машину без потери сетевых соединений.
ru.wikipedia.org/wiki/OpenVZ#Чекпоинтинг_и_миграция_на_лету
>Так как все детали состояния VE, включая открытые сетевые соединения, сохраняются, то с точки зрения пользователя VE процесс миграции выглядит как задержка в ответе: скажем, одна из транзакций базы данных заняла больше времени, чем обычно, и далее работа продолжается как обычно; таким образом, пользователь не замечает, что его сервер баз данных работает уже на другом физическом сервере.
ru.wikipedia.org/wiki/OpenVZ#Чекпоинтинг_и_миграция_на_лету
>Так как все детали состояния VE, включая открытые сетевые соединения, сохраняются, то с точки зрения пользователя VE процесс миграции выглядит как задержка в ответе: скажем, одна из транзакций базы данных заняла больше времени, чем обычно, и далее работа продолжается как обычно; таким образом, пользователь не замечает, что его сервер баз данных работает уже на другом физическом сервере.
А насколько эта задержка заметна?
К сожалению, не могу проверить.
Я себе поставил на сервер систему виртуализации Proxmox (была на хабре пара статей о ней. Коротко — класс!), которая поддерживает OpenVZ- и kvm-виртуализацию. Но у меня только одна машина, поэтому миграцию не могу попробовать… А хотелось бы.
Но по прикидкам — нужно записать память в файл, передать по сети на соседнюю машину и там распаковать обратно в память. Пару секунд сохранять память, чуть дольше передавать и там ещё пару секунд запускать.
В общем, несколько секунд, вряд ли больше 2-3 минут. Но зависит от объёма памяти.
Я себе поставил на сервер систему виртуализации Proxmox (была на хабре пара статей о ней. Коротко — класс!), которая поддерживает OpenVZ- и kvm-виртуализацию. Но у меня только одна машина, поэтому миграцию не могу попробовать… А хотелось бы.
Но по прикидкам — нужно записать память в файл, передать по сети на соседнюю машину и там распаковать обратно в память. Пару секунд сохранять память, чуть дольше передавать и там ещё пару секунд запускать.
В общем, несколько секунд, вряд ли больше 2-3 минут. Но зависит от объёма памяти.
У них на сервере венда, в ней нет OpenVZ.
Мне непонятно как можно было «просрать все полимеры» как 3 Титана и 6 Дредноутов не смогли замочить хоть один вражеский Титан? Кстати былобы интересно узнать соотношение сил победивших в принципе было гораздо больше? Если примерно одинаково, то за счет чего победитель выиграл? Неужели в космосе есть какаято там тактика? Врядли там работает такое: «вот сейчас я облечу его сбоку и начну палить ему в сраку и никто меня не заметит».
НЛО прилетело и опубликовало эту надпись здесь
Тактика есть конечно. В таких боях основная — правильный выбор цели для фокуса :)
Разбор полетов: 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.
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.
Про тактику. В космосе есть несколько основных принципов.
— сделай так, чтобы противник не смог улететь вдаль.
Был блистательно выполнен одним из учавствующих альянсов, который постоянно подводил корабли, не дающие противнику отпрыгнуть куда-то ещё. Их уничтожали, но пилоты воскрешались и приводили ещё корабли. Корабли такого типа (heavy interdictors) были выкуплены полностью в системах на много прыжков вокруг.
— вылечи своих друзей;
VS
— не дай врагам лечиться;
Выполняется за счет логистов — кораблей с модулями удаленного ремонта брони/щитов. Часто это авианосцы. Не давать лечиться можно или вынося вражеских логистов, или снося корабли так быстро, чтобы они не успели отреагировать (альфа-страйк, привет Battletech!), или используя средства РЭБ. Забиваем компы логистов фигней, они не могут нацелиться на друзей — никого не лечат. Или высасываем у логистов всю энергию и та же фигня. Альфа-страйк с такими большими кораблями правда не проходит обычно — но борьба против логистов почти всегда есть.
— сноси всех дронами;
VS
— сноси дронов;
VS
— не дай сносить дронов;
У мазершипов и (реже) у авианосцев есть согласно названию куча мелких дронов. Они очень и очень больно бьют, быстро летают, приносят с собой лаг и вообще полезны для битвы. Для борьбы с ними обычно применяются линкоры (battleship), в которые вместо турелей вставляют AoE оружие, бъющее по всем целям вокруг линкора в определенном радиусе. Пиу-пиу и дронов нет — вражеский ДПС упал — ура, мы ломим. В свою очередь такие линкоры пытаются задержать подальше от дронов, ибо радиус этого оружия невелик. Насколько я видел по ролику — такое было.
— используй моменты уязвимости противника для подтягивания подкреплений;
VS
— не проебите полимеры;
Дредноуты, авианосцы, титаны при использовании определенных функций входят в режим, где они не способны двигаться на определенное время. Часто это — 10 минут. Соответственно эти 10 минут они никуда с поля боя не денутся вообще, кроме как в облако плазмы. Можно дождаться этого момента и внезапно привести подкрепления, разобрав их в этот момент.
— всемером батьку бить легче.
Основная тактика евы. Что защитники сделали правильно — увидев вражеский титан они сразу начали собирать подкрепления по разным альянсам. Случайно там мимокрокодил флот из 50 Дредноутов, например. В результате битва и удалась такой эпичной — флитком-уже-без-титана подтягивал флот своего альянса, а на огонек собирались все остальные.
— сделай так, чтобы противник не смог улететь вдаль.
Был блистательно выполнен одним из учавствующих альянсов, который постоянно подводил корабли, не дающие противнику отпрыгнуть куда-то ещё. Их уничтожали, но пилоты воскрешались и приводили ещё корабли. Корабли такого типа (heavy interdictors) были выкуплены полностью в системах на много прыжков вокруг.
— вылечи своих друзей;
VS
— не дай врагам лечиться;
Выполняется за счет логистов — кораблей с модулями удаленного ремонта брони/щитов. Часто это авианосцы. Не давать лечиться можно или вынося вражеских логистов, или снося корабли так быстро, чтобы они не успели отреагировать (альфа-страйк, привет Battletech!), или используя средства РЭБ. Забиваем компы логистов фигней, они не могут нацелиться на друзей — никого не лечат. Или высасываем у логистов всю энергию и та же фигня. Альфа-страйк с такими большими кораблями правда не проходит обычно — но борьба против логистов почти всегда есть.
— сноси всех дронами;
VS
— сноси дронов;
VS
— не дай сносить дронов;
У мазершипов и (реже) у авианосцев есть согласно названию куча мелких дронов. Они очень и очень больно бьют, быстро летают, приносят с собой лаг и вообще полезны для битвы. Для борьбы с ними обычно применяются линкоры (battleship), в которые вместо турелей вставляют AoE оружие, бъющее по всем целям вокруг линкора в определенном радиусе. Пиу-пиу и дронов нет — вражеский ДПС упал — ура, мы ломим. В свою очередь такие линкоры пытаются задержать подальше от дронов, ибо радиус этого оружия невелик. Насколько я видел по ролику — такое было.
— используй моменты уязвимости противника для подтягивания подкреплений;
VS
— не проебите полимеры;
Дредноуты, авианосцы, титаны при использовании определенных функций входят в режим, где они не способны двигаться на определенное время. Часто это — 10 минут. Соответственно эти 10 минут они никуда с поля боя не денутся вообще, кроме как в облако плазмы. Можно дождаться этого момента и внезапно привести подкрепления, разобрав их в этот момент.
— всемером батьку бить легче.
Основная тактика евы. Что защитники сделали правильно — увидев вражеский титан они сразу начали собирать подкрепления по разным альянсам. Случайно там мимокрокодил флот из 50 Дредноутов, например. В результате битва и удалась такой эпичной — флитком-уже-без-титана подтягивал флот своего альянса, а на огонек собирались все остальные.
В дополнение к моему комменту выше.
Если честно, мне жалко программистов EVE Online. По-моему, у них явно прослеживается то, о чем я писала в своей статье. Они не рассчитывали, что их проект будет таким огромным. Поэтому воспользовались совершенно не масштабируемыми технологиями на питоне. Почитайте их блог, если думаете, что я говорю это в пустую или беру с потолка. Сейчас они стараются всё это держать как есть, ставя костыли и чуть ли не изобретая совершенно новые технологии, чтобы питон не разваливался, когда в солнечной системе много игроков.
Напоминает твиттер, они такую же глупость сделали (кажется, на Rubby on Rails, если мне не изменяет память), а потом тащили лаги, которые начали появляться, когда твиттер стал ужасно популярен, и выдумывали, как бы это протащить не переписывая всю систему…
Не хочу ничего сказать плохого в сторону питона или RR, нет! Просто это не языки, которые придумали для РЕАЛЬНО БОЛЬШИХ и масштабируемых проектов. Как минимум, автор RR считает так же, про питон не знаю…
Лучше бы вложили средства в переписывание серверной части на более масштабируемых технологиях, чем на покупку новых серверов…
Если честно, мне жалко программистов EVE Online. По-моему, у них явно прослеживается то, о чем я писала в своей статье. Они не рассчитывали, что их проект будет таким огромным. Поэтому воспользовались совершенно не масштабируемыми технологиями на питоне. Почитайте их блог, если думаете, что я говорю это в пустую или беру с потолка. Сейчас они стараются всё это держать как есть, ставя костыли и чуть ли не изобретая совершенно новые технологии, чтобы питон не разваливался, когда в солнечной системе много игроков.
Напоминает твиттер, они такую же глупость сделали (кажется, на Rubby on Rails, если мне не изменяет память), а потом тащили лаги, которые начали появляться, когда твиттер стал ужасно популярен, и выдумывали, как бы это протащить не переписывая всю систему…
Не хочу ничего сказать плохого в сторону питона или RR, нет! Просто это не языки, которые придумали для РЕАЛЬНО БОЛЬШИХ и масштабируемых проектов. Как минимум, автор RR считает так же, про питон не знаю…
Лучше бы вложили средства в переписывание серверной части на более масштабируемых технологиях, чем на покупку новых серверов…
Есть мнение, что новые сервера дешевле чем платить людям. Вот только сервера нужны будут постоянно, а хорошую систему нужно переделать только один раз. Да и у одного сервера в любом случае есть лимит производительности, сколько за него не заплати, особенно если используется однопоточная архитектура. А значит, такая архитектура в любом случае в конце врежется в лимит и перестанет с чем-либо справляться нормально…
> хорошую систему нужно переделать только один раз
Хорошую систему переделывать не нужно.
А сервера дешевле / не дешевле, это вопрос сложный. Проблема тут даже не в том, что людям жалко платить. А в том, чтобы этих людей в необходимом количестве и качестве отыскать. Сервера то вот они. А людей дефицит жесткий :-(.
Хорошую систему переделывать не нужно.
А сервера дешевле / не дешевле, это вопрос сложный. Проблема тут даже не в том, что людям жалко платить. А в том, чтобы этих людей в необходимом количестве и качестве отыскать. Сервера то вот они. А людей дефицит жесткий :-(.
> совершенно не масштабируемыми технологиями на питоне
Ммм? Это Eve то плохо масштабируется?
А питон или не питон в общем то не важно. Масштабируемые системы можно хоть на JS писать.
> Просто это не языки, которые придумали для РЕАЛЬНО БОЛЬШИХ и масштабируемых проектов.
Оу. А ты случайно не Java-программист?)
Btw, RoR это не язык, ну да что я к оговоркам придираюсь… А кто там что считает или не считает это его личное дело. На RoR есть куча больших систем (оно конечно жмет и колется, особенно в мастшабах твиттера, но состоятельность свою доказало).
Ммм? Это Eve то плохо масштабируется?
А питон или не питон в общем то не важно. Масштабируемые системы можно хоть на JS писать.
> Просто это не языки, которые придумали для РЕАЛЬНО БОЛЬШИХ и масштабируемых проектов.
Оу. А ты случайно не Java-программист?)
Btw, RoR это не язык, ну да что я к оговоркам придираюсь… А кто там что считает или не считает это его личное дело. На RoR есть куча больших систем (оно конечно жмет и колется, особенно в мастшабах твиттера, но состоятельность свою доказало).
Нуб ищет корпорацию.
Каребирю на Каракале, сальважу на Корморанте, вяжу крестиком.
В наличии 100мбит/с, гарнитура, ТС3.
Каребирю на Каракале, сальважу на Корморанте, вяжу крестиком.
В наличии 100мбит/с, гарнитура, ТС3.
Я так и не понял, кто победил?
> Битву при Asakai называют полным разгромом.
Кто разгромлен? Нападавшие или защищающиеся? Клан HoneyBadgers — это нападающие или защищающиеся?
На хабре уже несколько статей об этой битве, а кто победил — так и не понятно. Одни догадки.
> Битву при Asakai называют полным разгромом.
Кто разгромлен? Нападавшие или защищающиеся? Клан HoneyBadgers — это нападающие или защищающиеся?
На хабре уже несколько статей об этой битве, а кто победил — так и не понятно. Одни догадки.
В тот момент, когда нагрузка на сервер достигает критической точки, игра автоматически замедляет время на определенную величину для борьбы с перегрузкой. Время в битве на 3000 игроков запущено на 10% от реального, что составляет максимально возможное замедление.
Интересно провести параллель с впечатлениями людей, участвующих в реальных боях (на войне/войнах).
Вспомните, многие говорят/вспоминают, что время как бы замедляется в такие вот ответственные моменты.
Летчик-штурмовик Сергей Иванович Колыбин, вылетая на одноместном Ил-2 в июле 1941 года, конечно догадывался, что опасное задание может стать для него последним. Но никакого воображения у него не хватило бы, чтобы предсказать свою дальнейшую судьбу: всего через час он станет первым и единственным летчиком, выжившим после наземного тарана; все его бомбы пройдут мимо цели, но тем не менее вражеская переправа будет уничтожена; трое суток он проваляется, никем не замеченный, в виде кровавого куска мяса; его ждут несколько лет в гитлеровских, а затем в сталинских лагерях… Но тогда он просто вылетел на задание и не выполнил его. Штурмовик был подбит, и фашистские солдаты уже бежали к месту его предполагаемой посадки. Колыбин круто развернул Ил-2 (а вместе с ним — всю свою дальнейшую судьбу) и врезался в мост. Это мгновение он запомнил на всю свою жизнь и о нем мог рассказывать часами. Самолет перед взрывом задел за конструкцию моста крылом и перевернулся, Колыбин вылетел из кабины… и время в его восприятии остановилось: он рассмотрел выражение лиц всех окружающих его гитлеровцев, видел, как некоторые из них пытались выбраться из танковых люков, другие бежали, ложились, хотели спрятаться от языков пламени, но все их движения были чересчур медленными…
Другие примеры.
Ни на какие мысли не наводит?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Сражение при Asakai: как EVE Online справляется с гигантскими битвами