CanMove!? Первый шаг к осознанию подсознания.

[Hitcher]

Хроники

1. Interlude

Исходники

Присутствуют

Сборка

Acis 409

Здравствуйте!) захотелось поставить брейкпоинт на xyz и поклацать на f7 чтобы посмотреть как эти методы там работают... сделав всего лишь один маленький шаг в игре, это казалось так просто., я понял что процессов гораздо-значительно-бесконечно больше чем предполагалось. Не уверен на сколько можно реально понимать глубину взаимодействия всех процессов когда выполняется всего лишь один шаг. И насколько возможно понимать работу всего сервера и клиента в целом, удерживая такие потоки бесконечной информации в (своей) голове..!?

По мимо пинг понг процессов с миллионом итераций в переборе всех слоев, миллиардов проверок валидности, не в воде, не в воздухе, не на корабле, не в стене, не в дверях, не где то еще., защитных проверок от пакетхаков, читов, дюпов, болтов, и шурупов., сенд ресив хекс пакетов клиент сервер хуков, антиперегруз тридпул треш санитайзер макетов, с автоочисткой бинарных котлетов.
И Че-то ещеееее????))

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

Какие методы критически важны, какие нужно оставить для загрузки геоблоков и проверки слоев, а от каких лучше бы отказаться и или переписать?
Я заметил что одни и те же методы используются как для загрузки так и для CanSee так и для CanMove.

Еще вопрос по Path. Стоит ли создавать узлы Pathnode, или лучше генерировать маршруты на лету?

ClickHandler - или какая система должна быть для того чтобы сервер различал потолок стены и пол при клике в соответствующий пиксель?

Еще много вопросов) чем дальше тем их больше…

 

[Aristo]

Не стоит недооценивать мощность современных CPU. В большинстве случаев, если не требуется какие-то сложные IO-вызовы или аллокации памяти для объектов, итерации тысяч объектов в циклах - это не миллисекунды, а наносекунды. У современных процессоров огромная вычислительная мощность приближающаяся к триллионам операций в секунду.
Вот как раз из этой мощности вытекает проблема любой доступной для свободного скачивания сборки L2, которая заключается в том, что ее разработкой на разных этапах занимались люди, чаще всего бесконечно далекие от понимания того, как работает написанный и "улучшаемый" ими код, от принципов многопоточного программирования, написания высоконагруженных сервисов, да и даже не понимающих того, как вообще устроена структуру проекта и как там взаимосвязаны внутренние процессы.
Отсюда бесконечные состояния гонки у важнейших переменных, регулярные утечки памяти почти во всех сервисах, ботлнеки на бестолково синхронизированных участках кода, выполнение IO в сетевых потоках(или еще хуже в EventLoop), голодание потоков или наоборот забитые очереди пулов, когда 90% полезной нагрузки CPU тратится на добавление и сортировку задач в DelayedQueue внутри шедулера, просто кучи бестолкового говнокода, с десятками гигабайтами young объектов в секунду, когда GC задыхается в паузах по 5-10 секунд на онлайне в 300 человек и так далее и тому подобное.

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

К сожалению, MMORPG сервер - не самый удобный подопытный для профилирования, т.к большинство проблем проявляются прежде всего на высоких нагрузках, которые практически невозможно сымитировать в условиях локального запуска. Поэтому, когда приходит понимание, что код который неплохо работал на 50 игроках, внезапно умирает на 500, и почему-то скейлится квадратично, а не линейно на рост онлайна, как правило уже слишком дорого переписывать все то легаси-говно, которое накопилось за двадцатилетнюю историю L2j-дева.

А насчет переписывания и оптимизации кода комплексно - забейте. Если вы задаете такие вопросы, то вашей компетенции 100% будет недостаточно, чтобы системно поправить все эти проблемы. Вы только пополните ряды тех, кто пытался сделать это до вас и только увеличите энтропию.

Тем не менее, если вы хотите попробовать - вооружайтесь профайлером и исправляйте для начала хотя бы самые ярковыраженные проблемы в отдельных механизмах.
Например, если пользуетесь IDEA, в ней есть неплохой встроенный профайлер. Также рекомендую VisualVM с сэмплером, который позволяет делать снапшоты объектов, анализировать дельту их количества, а также наиболее "горячие" методы.
Запускайте профайлер, имитируйте нагрузку. Смотрите, какие методы и строки в коде занимают больше всего CPU-времени, создают мусор. После этого, можете обращаться за помощью к нейронкам, с просьбой объяснить причины такого поведения кода и возможные пути исправления. Современные модели с лихвой покроют этот кейс. Чаще всего, в процессе профилирования приходит понимание, что действительность сильно отличается от представлений и проблемы совершенно не в тех местах, о которых вы могли подумать вначале. Какая-то строчка кода может вызываться миллионы раз в секунду, но тратить суммарно на эти миллионы вызовов - десяток микросекунд, а какой-то вызов может быть брошен десять раз за весь лайфтайм проекта, но порождать лаги по полсекунды. Начните с малого, просто побегав десять минут под профайлером и изучив результат. Геодвиг - как раз один из тех, немногих механизмов, поведение которого можно профилировать локально, просто заставив бегать десяток тысяч мобов рандомно по локам.

 

[Hitcher]

Не стоит недооценивать мощность современных CPU. В большинстве случаев, если не требуется какие-то сложные IO-вызовы или аллокации памяти для объектов, итерации тысяч объектов в циклах - это не миллисекунды, а наносекунды. У современных процессоров огромная вычислительная мощность приближающаяся к триллионам операций в секунду.
Вот как раз из этой мощности вытекает проблема любой доступной для свободного скачивания сборки L2, которая заключается в том, что ее разработкой на разных этапах занимались люди, чаще всего бесконечно далекие от понимания того, как работает написанный и "улучшаемый" ими код, от принципов многопоточного программирования, написания высоконагруженных сервисов, да и даже не понимающих того, как вообще устроена структуру проекта и как там взаимосвязаны внутренние процессы.
Отсюда бесконечные состояния гонки у важнейших переменных, регулярные утечки памяти почти во всех сервисах, ботлнеки на бестолково синхронизированных участках кода, выполнение IO в сетевых потоках(или еще хуже в EventLoop), голодание потоков или наоборот забитые очереди пулов, когда 90% полезной нагрузки CPU тратится на добавление и сортировку задач в DelayedQueue внутри шедулера, просто кучи бестолкового говнокода, с десятками гигабайтами young объектов в секунду, когда GC задыхается в паузах по 5-10 секунд на онлайне в 300 человек и так далее и тому подобное.

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

К сожалению, MMORPG сервер - не самый удобный подопытный для профилирования, т.к большинство проблем проявляются прежде всего на высоких нагрузках, которые практически невозможно сымитировать в условиях локального запуска. Поэтому, когда приходит понимание, что код который неплохо работал на 50 игроках, внезапно умирает на 500, и почему-то скейлится квадратично, а не линейно на рост онлайна, как правило уже слишком дорого переписывать все то легаси-говно, которое накопилось за двадцатилетнюю историю L2j-дева.

А насчет переписывания и оптимизации кода комплексно - забейте. Если вы задаете такие вопросы, то вашей компетенции 100% будет недостаточно, чтобы системно поправить все эти проблемы. Вы только пополните ряды тех, кто пытался сделать это до вас и только увеличите энтропию.

Тем не менее, если вы хотите попробовать - вооружайтесь профайлером и исправляйте для начала хотя бы самые ярковыраженные проблемы в отдельных механизмах.
Например, если пользуетесь IDEA, в ней есть неплохой встроенный профайлер. Также рекомендую VisualVM с сэмплером, который позволяет делать снапшоты объектов, анализировать дельту их количества, а также наиболее "горячие" методы.
Запускайте профайлер, имитируйте нагрузку. Смотрите, какие методы и строки в коде занимают больше всего CPU-времени, создают мусор. После этого, можете обращаться за помощью к нейронкам, с просьбой объяснить причины такого поведения кода и возможные пути исправления. Современные модели с лихвой покроют этот кейс. Чаще всего, в процессе профилирования приходит понимание, что действительность сильно отличается от представлений и проблемы совершенно не в тех местах, о которых вы могли подумать вначале. Какая-то строчка кода может вызываться миллионы раз в секунду, но тратить суммарно на эти миллионы вызовов - десяток микросекунд, а какой-то вызов может быть брошен десять раз за весь лайфтайм проекта, но порождать лаги по полсекунды. Начните с малого, просто побегав десять минут под профайлером и изучив результат. Геодвиг - как раз один из тех, немногих механизмов, поведение которого можно профилировать локально, просто заставив бегать десяток тысяч мобов рандомно по локам.

 

[Aristo]

Какие-то мескалиновые рофлы, у вас)