65 ответов в теме

[Wyrm]

Да сделают как фб, что их, зря что ли ввели в таком виде.
Анимация онли, отдельного объекта - ракеты - нет, и т.п.

И прекрасно, хотя бы потому что щас анимация ракет оч убогая... А так хоть будет повод сделать нормальную анимацию.

[DotSlayer]

Да.

Я не смотрел внутрь и на трафик (ленивый я).
Но у меня сложилось впечатление что есть куча проверок на стороне клиента.
В том числе и время лока считается на клиенте и только потом идет эвент на сервер.
С клокой похожая бодяга.

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

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

[January]

У меня одного ощущение, что блог описывает увлекательный процесс замазывания трещин в фасаде, оставляя за кадром факт, покосившегося фундамента, из-за чего собственно и трещины?

[MOH]

У меня одного ощущение, что блог описывает увлекательный процесс замазывания трещин в фасаде, оставляя за кадром факт, покосившегося фундамента, из-за чего собственно и трещины?

Угу. Но хотябы это.

[January]

Мне другое в этом контексте интересно: а есть ли в ССР команда, которая ставит эксперименты не по оптимизации существующей архитектуры, а пытается выдумать новую архитектуру, которая изначально бы была лишена ошибок времён студенческих лет первых разработчиков Евы?

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

[Mauller]

У меня одного ощущение, что блог описывает увлекательный процесс замазывания трещин в фасаде, оставляя за кадром факт, покосившегося фундамента, из-за чего собственно и трещины?

А у меня как раз наоборот, ощущение описания процесса оптимизации внутренних процессов ядра (фундамента если хотите).

Once per second, we go through these steps. Whatever time is left over is then used to process everything else that needs to happen. It is important to note that the Destiny tick is entirely non-blocking - we can't do any asynchronous operations such as database queries or anything that might cause execution to yield. Most of the collision callbacks, for example, simply schedule a task to be run later. In this task, we can than perform database operations we need, such as creating wrecks, and moving characters to the clone bay.

В контексте всего параграфа исходного текста картина имхо будет выглядеть более полной. Я бы перевел так:

"Раз в секунду мы проходим через эти 3 этапа. Все оставшееся время в секунде после этих этапов используется для обработки всего остального, что должно случиться. Важно отметить, что тик (состоящий только из этих трех этапов) полностью неблокируемый, т.е. в нем отсутствуют "приостанавливающие выполнение" (или, как вариант "передающие управление в другое место кода", извне этих трех tick-этапов) операции, вроде запросов к БД. Для примера, обработчики столкновений в большинстве случаев просто ставят задачу в очередь, которая обработается позднее (в остающееся после трех этапов время ). И уже в этой задаче мы можем обращаться к базе и создавать вреки или перемещать персонажей в клонилку."

This is why, in loaded situations, there is sometimes a delay between a missile hitting a target and that target actually exploding. Sometimes this is even long enough for the target to warp out and think he is safe. In fact, he is already dead - he just doesn't know it yet!

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

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


PS: Мне вот интересно, насколько возможно в их архитектуре варьирование этого 1-секундного интервала, и собираются ли они выбрать одним из возможных вариантов решения проблемы массив-флит-заруб динамическое увеличение этого интервала.

[Belfigor]

Лучше бы они фиксили дрейки а не лаги

г-н Belfigor отправляется в РО до момента приведения подписи в соответствие правилам форума.

дубль в личке

Сообщение отредактировал Liteik: 11 December 2010 - 19:52

[Mauller]

Еще заинтересовало вот это:

2) Sending an update to each client identified in the step above. Further investigation showed that this is mainly expensive due to the time required to serialise each update message. (Serialising means converting a data structure in memory into a stream of bytes that can be sent over a network)

Рассылка результатов по всем клиентам у них отжирает чуть ли не более половины времени трех-этапного tick-а. Имхо, тут есть большое непаханное поле для оптимизации. К тому же они используют сериализацию. Собственно у них всё в еве представлено в виде объектов, а сериализация объекта в обыкновенный поток (массив) значащих данных может быть весьма дорогостоящей по времени операцией. Особенно если этих объектов докуя и больше.

Для примера, сколько там клиентов и дрейко-ракет?

* 200 тонких клиентов летят на дрейках (у каждого 3 полностью заряженных хеви миссайл ланчера, изображающих 3 группы ланчеров)
* 100 тонких клиентов летат на других кораблях. Они изображают нагрузку от наблюдателей – других участников боя. Это важный момент, поскольку вычислительная цена ракеты в некоторой мере пропорциональна тому ,сколько клиентов ее наблюдают.

200 дряков * 3 ланчера = максимально 600 пачек ракет в космосе в единицу времени.
Т.е. нужно сериализовать 600 объектов и передать все это на 300 клиентов.
На это у них уходит около 150 мс - и это процессорного времени! Собственно сама отправка подготовленных данных в сеть процессорного времени практически не жрет совсем, проще говоря, массив байт пересылается в буфер сетевухи и дальше им занимается специально для этого предназначенное железо. А цифра 150 - говорит уже о большом времени "подготовки массива данных к пересылке", и не последнюю роль здесь наверняка играет сериализация.

[Basil]

В принципе у них слабое место - создание/уничтожение новых объектов. Это видно из блога и графика.Дрейк пускает ракету - создается новый объект, все клиенты в гриде должны получить уведомление о созданном объекте, чтобы его корректно отрисовать. Когда выпускаются сотни ракет, нагрузка сильно растет. ЦЦПшники думают над тем, как максимально ускорить операцию создания отдельного объекта. Скорее всего, будет кеширование типов ракет, чтобы на каждую ракету объект создавался не заново, а бралась копия из кэша.

[Wisdoom]

Дрейк = лаги. => Фиксим Дрейк = Фиксим лаги.

Эврибади хаппи!

Вот что я понял из девблога.

[Mauller]

..ЦЦПшники думают над тем, как максимально ускорить операцию создания отдельного объекта. Скорее всего, будет кеширование типов ракет, чтобы на каждую ракету объект создавался не заново, а бралась копия из кэша.

Согласен, вполне себе вариант. Кэширование сериализованных данных думаю тоже может не слабо помочь.

[Tester128]

судя по картинке, отключение видимости ракетам уже должно нехило помочь

[Mauller]

Думаю, они на это не пойдут, пока есть любые другие варианты.

[January]

А какие "другие варианты", если всё так устроено, что ганг дрейков порождает проблемы с производительностью, как только начинает стрелять? Самое действенное уже было сделано - группировка оружейных слотов и отображение одной условной "ракеты" вместо n ракет при залпе из всех лаунчеров.

[bo4]

То есть при разгруппировке ракет, 30 дрейков при желании могут изобразить аж 210 )
Осталось придумать как бы это применить.

[January]

Если верить девблогу - именно так.

[St1'n'Gear]

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

А как же непись? Она конечно знает, что все равно умрет, но при этом любит подпортить кровь нашему брату карибасу.
К тому же дефендеры можно будет сделать аналогино ракетам, в крайнем случае
Насчет времени полета это да заодно можно будет его и к прожектилам с гибридами прикрутить для реализма (лазер-то инстадамаг ибо летит со скоростью света).
З.Ы. кстати а как сейчас выглядит эффект от оружия файтер бомберов? Просто не каровод поэтому проверить возможности нету

[CHoh]

А как же непись? Она конечно знает, что все равно умрет, но при этом любит подпортить кровь нашему брату карибасу.

У неписи всё равно эти дефендеры полностью читерные. Так что если их уберут - совершенно никто не расстроится.

[MOH]

PS: Мне вот интересно, насколько возможно в их архитектуре варьирование этого 1-секундного интервала, и собираются ли они выбрать одним из возможных вариантов решения проблемы массив-флит-заруб динамическое увеличение этого интервала.

Никак. Нодо делать или Реал-тайм систему ( будут ограничения в геймдезайне). Или не Реал тайм - будут лаги.

То что у них сейчас это ППЦ. (я преподавал на курсах по реалтайм системам, если кому интерестно)

[Tester128]

дестини же реалтайм вроде, судя по блогу