Реализация KnownList

[KID]

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

[Alay]

Ну дело в том - что в принципе модель регионов она типо статична. тоесть в принципе она будет и при 100 онлайне занимать определенное время цп и при 1000 примерно такое же.
А вот с уникальным кноун листом под каждый игровой объект нагрузка в основном на блокировщик чтения\записи будет уже увеличиваться по экспоненте. На счет шила на мыло я отчасти согласен а отчасти все таки нет. Опять же плохо то что при пробежке по регионам, нам нужно бегать по 9-ти циклам ради 1 боардкаста.
В кноунлисте была только лишь одна пробежка. Как следствие - попадание в кеш, и более быстрое выполнение.

Добавлено через 4 минуты

Сообщение от KID

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

у меня 4к ребро и регионов получилось 19584. Карта линдвиор.
что и так давольно таки не мало. Но доступ к ним моментальный (они в массиве)

Добавлено через 13 минут
а если выставить размер по 2к то получаем 78336 лошадок)

[linliss]

Сообщение от KID

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

Не совсем так. Я делал тесты с knownlist и region, нагрузка на процессор была в 3 раза ниже с рассылкой пакета по регионам, чем по knownlist'am.

[KID]

linliss, в чем именно эти тесты заключались?

[Visor]

Сообщение от KID

полный бордель.
регионы были сделаны очень давно, во время запуска серверов на селеронах. нынешнее железо позволяет итерировать эти списки практически моментально. пытаться вылизать фичу до идеала на стадии ее разработки невозможно. сделайте как есть, а потом, когда уже будут сопутствующие части кода, концепт может изменится.
отсутствие knownList - плохой путь, имхо. получение игроком CI/NI на расстоянии до 8к стремно.
лучше научить эти листы взаимодействию только с определенными объектами, в основном это с игроками.

Я рад, что не только я понимаю, что с knownlist не все так, как это пытаются представить.

Если вспомнить историю с появлением knownlist-ов резко повысилось потребление памяти и утечки стали накапливаться значительно быстрее ... javolution ...
Когда этот вопрос был снят, то и утечек нет.
Вопрос не в модели, она не дублирует модель регионов - это разные вещи. Но конечно можно сделать рассылку пакетов через регионы - тогда модель листов известных объектов по сути отсутствует.

Пример - у меня даже нет авторестарта каждое утро, утечки незначительные, рестарт 2 раза в неделю достаточно. knownlist-ы есть.
Возможно вместо поиска причин лучше взглянуть на ситуацию более взвешенно.

Добавлено через 40 секунд

Сообщение от DiagoD

не до 8к, а ровно 6к, это более чем приемлемо ибо радиус видимости клиента около 3к, точно уже не помню.

около 3200 эмпирически, подтвердить реверсом не могу.

Добавлено через 2 минуты

Сообщение от linliss

Не совсем так. Я делал тесты с knownlist и region, нагрузка на процессор была в 3 раза ниже с рассылкой пакета по регионам, чем по knownlist'am.

Тот же вопрос, это что за тест такой? Нагрузка на процессор? На итераторах с knownlist и из регионов?

Наверное единственное, что я бы хотел сказать - если бы я выложил фикс javolution в 2010 или 2011 году, когда я нашел его и исправил, эта история о листах известных объектов могла бы быть другая ...

[n3k0nation]

Сообщение от KID

полный бордель.
регионы были сделаны очень давно, во время запуска серверов на селеронах. нынешнее железо позволяет итерировать эти списки практически моментально. пытаться вылизать фичу до идеала на стадии ее разработки невозможно. сделайте как есть, а потом, когда уже будут сопутствующие части кода, концепт может изменится.
отсутствие knownList - плохой путь, имхо. получение игроком CI/NI на расстоянии до 8к стремно.
лучше научить эти листы взаимодействию только с определенными объектами, в основном это с игроками.

Сообщение от KID

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

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

Конечно можно сказать: "добавим пару процов и плашек!" - но вечно выежать на таком подходе нереально, да и бабла это все сожрет огромное количество. Можно конечно же расти и в ширину, но это уже совсем другая история. Вообще, где-то тут, Камелеон писал такой пост о железе, рекомендуется к прочтению.
Можно, блин, конечно считать и полигоны, и сферы, но ЗАЧЕМ?

[ANZO]

Сообщение от Visor

Я рад, что не только я понимаю, что с knownlist не все так, как это пытаются представить.

Если вспомнить историю с появлением knownlist-ов резко повысилось потребление памяти и утечки стали накапливаться значительно быстрее ... javolution ...
Когда этот вопрос был снят, то и утечек нет.
Вопрос не в модели, она не дублирует модель регионов - это разные вещи. Но конечно можно сделать рассылку пакетов через регионы - тогда модель листов известных объектов по сути отсутствует.

Я бы посмотрел что было бы с сервером, когда бы в одной локации активно пвпшилось 400+ тел.
Еже(милли\нано\пико)секундно обновляющаяся коллекция с размером 400+ на каждого игрока или массив с прямым чтением и записью и одной коллекцией на регион такого же размера с всегда известным размером в пики онлайна.
Случай, когда у вас регионов больше чем игроков не рассматриваем.

[KID]

сплошные максималисты собрались
прочитал пост камелиона - не рекомендую к прочтению, ибо совершенно не понятна его сравнение про отжор оперативки с двумя ядрами, а потом скачок аж на 140гб оперативки.
раз у вас онлайн позволяет делать замесы в 400+ объектов на замок, значит и с общим онлайном все в порядке, а значит компик должен быть несколько мощнее чем обычно.

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

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

[Camelion]

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

Кто вас заставляет делать все регионы одинакового размера? Сделайте динамическую сетку. Условно говоря один игрок - одна ячейка на весь мир, два игрока - тоже одна ячейка, если они в зоне видимости друг друга и две если на разных концах карты. 10000 игроков - делите между ними игровой мир на куски, по размеру зависящие от заселенности региона, но не меньше чем минимальное ребро ячейки. Так вы получите две вещи: на дев компе у вас не будет жора оперативки и продакшн железо будет утилизироваться равномерно с пиками посещаемости, а не 100 гигов на старте, при стабильном онлайна 10чел. И да, идеально квадратный регион - это влажные мечты разработчика, ему так удобнее их в своей голове прокручивать.

Сообщение от KID

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

То, что вы их не знаете != тому, что их нет.

[KID]

Camelion, поделишься примером?