PointerRage

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

Если делать через аугментацию, то это даст невозможность наложения оригинальной аугментации на предмет, если на нем лежит печать. Атрибутов в ИТ клиенте нет Касательно клиента: экстендер пакетки айтемов + расширение пакета аугментации. Тут же понадобится правка u-скриптов. Мало того, экстендер будет несовместим с любыми "защитами" (для СГ - решаемо, там есть система модулей). В общем, это никак не 50 баксов и даже не 200. А если вводить систему а-ля атрибуты на клиент, то ценник уезжает за штуку баксов и очень близок к 2к. Рекомендую переосмыслить свою идею:)

Могу попробовать сделать на выходных, при более подробном описании (за исключением дата-части). Цена: 50 USD.

Готов вписаться на указанное время при оплате от 1к usd в месяц при правильно поставленном рабочем процессе. На классике не играл. Обо мне тут. Последняя работа была по контракту в геймдеве, длительностью чуть больше года.

Джонни, где пруфы? Ато вдруг, наговариваешь на хороших людей, а-та-та!

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

@Silentium вангую, что ничего. Скорее всего ребята просто сперли откуда-то исходник, который немного отличается)

Все очень сильно зависит от типа монетизации сервера. Допустим, возьмем наиболее эффективную монетизацию: различные сундуки с плюшками внутри. Ключевая плюшка, ради которой люди будут покупать данные боксы - должна иметь наименьший шанс выпадения, шанс должен расчитываться исходя из того сколько требуется выжать из одного игрока, обычно это чуть менее 100 долларов. Расчитываете цену и устанавливаете требуемый шанс, чтобы при приближении к порогу требуемой цены статистический шанс вытащить плюшку возрастал. Также и с расчетом остальных плюшек внутри бокса. Касательно что туда пихать. Нормальной практикой считается: визуал и различные расходники, иногда бывает премиум/season pass, и другие похожие вещи. Наиболее "редкие" расходники должны отвечать одному простому требованию: они должны использоваться для создания топ-эквипа, который был создан в крайнем обновлении игры. Вывод денег: самое элементарное и что используется чаще всего - вывод внутрянки с помощью различных fun-эвентов; например летний эвент: собирай мешочки из которых могут выпасть кристаллы с определенным шансом, за которые можно собрать некий визуал. Мешочки имеют флаги обмена и продажи, поэтому игроки продают их друг другу. Достаточно просто, можно довольно незаметно выставлять на аукцион созданные из ничего такие мешки и продавать их игрокам, главное делать это аккуратно и управлять ценой. В результате внутрянка собирается с игроков и изымается из оборота. В случае крайних мер, можно подвязать эвент на покупку каких-нибудь сколлов у NPC, которые дают шанс на выпадение таких мешков с мобов, что даст огромный вывод внутрянки с рынка и дефляцию. В паре с этим работает и монетизация, совместно с эвентом запускаются и боксы из которых можно вытащить похожий визуал, но не точно такой же. Также, монетизацию следует обновлять сразу после введения нового контентного обновления, но конкретные вещи, которые позволяют добыть "новый контент", стоит добавлять с некоторым временным промежутком после самого обновления, иначе можно получить нехилый такой баттхерт и снижение лояльности игроков. --- Касательно не-визуал эквипа: его чистое добавление снижает получаемый доход и снижает лояльность игроков. Поэтому обычно используются расходники, которые позволяют больше выжать с игроков, что заодно и не так сильно снижает лояльность.

http://l2.m0nster.io/system/5etoa_salvation_152_ru.7z

Никто и не говорил о динамике с пересечением, так как данную задачу почти невозможно решить (адекватно по производительности), если агентов много и у них различные скорости. Поэтому и существует динамический avoidance основанный на сенсорике. Кстати говоря, примерно так монстры и не стакаются на ретейле. Впрочем, по большей части, это уже разговор о других играх. В более ранних версиях игроки не были проходимы;) Дело не в анимации, она далеко не root motion, чтобы она играла какую-то роль, а именно в изменении скорости движения. Сделать "это правильно" - применить линейную интерполяцию на каждый тик движения, в зависимости от времени. Впрочем, подойдет и любой метод получения координат, который будет экстраполировать/интерполировать координаты, в зависимости от времени. В ином случае, с текущей трединговой моделью, расчет попросту будет неверным. А кто говорил про решение проблемы увеличением тикрейта? У меня вообще на одном сервере (не lineage 2, к счастью) тикрейт самого сервера (а это, на секундочку, вообще все серверные геймплейные операции, куда входит и движение) выставлен в 15 раз в секунду, что очень и очень низко, особенно, смотря на некоторые сервера, которые имеют тикрейт в 60 фреймов. С этого и следовало начинать! Вы считаете координаты по запросу. Вопросов в этом плане больше не имею:) Касательно скачков пинга - эта проблема, к сожалению, есть везде и у меня нет идей, как это можно решить. Кроме варианта зашития, в сам заголовок пакета, времени отправки, для расчета трип тайма на каждый пакет.

Одно время данный функционал был на официальном сервере, однако, позже его убрали по неизвестным причинам. Впрочем, его отголоски до сих пор можно заметить, допустим: использовать большую трансформацию и перегородить вход куда-либо. Это до сих пор актуально на текущей версии NA-сервера. В HF-версиях, клиент может послать пакет CannotMoveAnymore (или как-то так), но сервер в силах и без этого пакета все правильно обработать и забраковать путь. Раньше в ретейле использовалось не BVH-дерево, а дискретный метод (специальная хеш-таблица) для определения столкновений. Но в таком подходе минусов целая коробка и маленький контейнер. Я раньше эксперементировал с различными алгоритмами поиска пути, в контексте lineage 2: руки, двусторонний поиск, различные вариации жадных алгоритмов и различные направленные версии. В общем, лично я, остановился на направленном A*. А потом вообще плюнул на все это и выкинул геодату, и просто вгрузил все коллайдеры с карт. Прогнал их через оптимизатор вершин и получился вполне нормальный граф, по которому можно искать путь (причем в большинстве случаев он легковеснее той же геодаты), как плюс, можно делать нормальные "физические" рейкасты (на самом деле, они реально нормальные, а не то говно, которое трассируется через геодату) для проверки видимости. В теории, можно вообще психануть и написать BSP для тех же рейкастов, но производительность BVH меня вполне устраивает. Там считается время движения до нулевой точки, чтобы компенсировать линейное увеличение скорости движения персонажа при беге, которое отлично видно в начале движения. Это не правильно, я согласен. Но чтобы сделать правильно - необходимы тики, в ином случае, на маленьких дистанция рассинхронизация будет вполне заметна, а если таким методом двигаться почти беспрерывно, то разница координат может достигать в несколько сотен точек. Ага, знаю такой механизм, это синхронизация клиентской экстраполяции. Но, если честно, мне было лень ее разбирать на клиенте, поэтому я на это успешно забил:) На счет "забить на 20-200мс" - мне не кажется это хорошей идеей, так как при увеличении нагрузки на сервер, время самого серверного процессинга будет увеличиваться без роста сетевой задержки, из-за чего итоговая задержка запроса может быть намного выше 200мс и это следует учитывать. Нечто вроде: delay = trip time + processing time. Извиняюсь за столь долгий ответ, впредь постараюсь отвечать быстрее:)

Это понятно, ибо эвристика. Я говорю про саму реализацию avoidance динамических актеров, чтобы движущиеся актеры не сталкивались и рекалькулировали свой путь, для избежания столкновений. Очевидно, что это реализуется в рантайме:) Обычно такие задачи решаются отложенным пересчетом пути актера и динамическим изменением веса клетки, по которым, другие актеры двигаются (в случаях дискретной сетки). В более хороших и правильных реализациях используются BVH деревья (причем обычно достаточно балансного AABB дерева), чтобы реализовать приемлемый avoidance. Кстати говоря, второй подход также используется в физических движках, но это уже тема для иного разговора. Потому-что на моей памяти, во всех l2j-ях эврестическая стоимость клетки имеет вид: D(sqrt(x*x + y*y + (z*z) / modifier)) - или нечто похожее. Впрочем, даже выставляя "честную" эвристику по Z-оси, результат задастую выходит не таким, какой ожидается, из-за того, что вес клеток по "правильному" пути намного выше, чем вес до, условно, неверного пути. Сюда же можно добавить и то, что во всех l2j-ях реализация поиска пути работает по алгоритму "первый лучший". Не согласен. Рассинхронизация возникает только потому-что игра сетевая, а сеть имеет задержку. К тому же, сюда стоит еще добавить, что методы передвижения актеров на сервере и клиенте разные, из-за чего результаты получаются различными. В добавок, стоит добавить, то что на клиенте расчет движения осуществляется с помощью чисел с плавающей точкой, только этого достаточно, чтобы получать различные результаты на различных машинах. Я уже не говорю о том, что на сервере везде используются натуральные числа, которые еще из-за аппроксимации из/в дискретные координаты, ну совсем уж, не похожи на клиентский результат. Минутка шуток: администратор локалхоста недоумевает, как связаны координаты присылаемые клиентом серверу с пингом, потому-что у него нулевой пинг. А если серьезно, то они непосредственно связаны тем, что: 1. Сервер по расчетам движения всегда впереди клиента, потому-что пакет MoveToLocation не доставляется моментально на клиент. 2. Клиент при отправке запроса ValidateLocation, отправляет координаты, которые актуальны на текущий момент. Пока пакет обработается в очереди, пока отправится, дойдет до сервера, сервер его обработает... Пройдет значительное время, чтобы процессинг на сервере сказал: "нифига, эти координаты неверны". А отсутствие снапшотов не дает заглянуть в прошлое и сверить правильность координат на момент времени отправки клиентом пакета. Именно поэтому я предположил, что может использоваться экстраполяция координат для их проверки, чтобы довести эти клиентские координаты до "текущей точки времени" и проверить, очевидно, их правильность. 3. Если актер движется и сервер меняет ему путь, то, очевидно, в пакете MoveToLocation должны быть указаны "начальные" координаты и "конечные". К "конечным" нет никаких вопросов, однако, начальные координаты следует экстраполировать по трип-тайму, тобишь, времени пакета в пути, либо, в ином случае, клиенту начинает быть довольно плохо. Определение слоев, да, есть такая проблема, но я не о ней говорю на данный момент, потому-что это исправляется легко и быстро, да и обсуждать это как-то не очень интересно:) Попробуйте на клиенте подойти очень близко к преграде, а после этого сконвертируйте координаты в дискретные. Вы будете неприятно удивлены, что в части кейсов, дискретные координаты будут указывать на "пустоту", тобишь, на внутренности, например, статик меша. Причем, это происходит из-за самой алгоритмики перевода реальных координат в дискретные. Соответственно, перевод таких дискретных координат в реальные, даст точку внутри статик-меша, там где клетка гео-даты вообще отсутствует. Возможно Вы просто не замечали таких кейсов, но когда я еще занимался этими всеми l2j-ями, причем на довольно нагруженных проектах (от 1 200 онлайна до 2 000), такие проблемы всплывали, однако, не сразу. Спасибо за ответ. Я, если честно, даже не надеялся на ответ. Всегда приятно обсудить интересные технические задачи и способы их решения:) На счет терминов: BVH дерево - дерево хранящее внутри себя набор геометрических фигур. AABB дерево - дерево хранящее внутри себя "коробки" актеров. Если простыми словами, то "коробка" - прямоугольник (либо же куб, в случае хранения трехмерных коробок), который включает в себя полный размер актера. AABB - "коробка", см. AABB дерево. Avoidance - механизм уклонения (обхода) от динамических актеров. Балансное дерево - дерево, которое имеет сбалансированное количество количество веток и листов на них, на каждом уровне глубины/высоты.

Рантайм изменения веса клеток для патчфинда есть? Это для процессинга avoidance, тобишь, обход других актеров во время поиска пути. Или сделано, как обычно, костылем?:) Если есть, то как разрешили задачу многопоточного доступа на модификацию веса клетки? Потому-что в этих ваших l2j-ях по другому невозможно, из-за того что общего тика сервера вообще нету. Что с перестроением уже найденных путей при изменении веса клеток? Или может быть запилен avoidance по столкновениям? В таком случае какой вид деревьев использовали и опять же, как решили задачу с многопоточным доступом модификации BVH дерева? Поиск пути по прежнему выдает говно в случаях с трехмерными плоскостями? (Как пример лестница у кристала в замках) Как делаете синхронизацию координат сервер-клиент в условиях авторитарного сервера, да еще и без снапшотов (общих тиков, то у сервера нет, чтобы их возможно было делать)? Как экстраполируете координаты клиента, в условиях того, что получение пинга, это вообще отдельный пакет? Касательно этого момента: Я понял, что имелось ввиду и что это за фикс. Но скажу к слову: в ретейле, непосредственно, векторное изменение координат идет по дискретным точкам, тобишь по гео-точкам. Результаты игнорирования этого можно посмотреть в любом l2j эмуляторе, со всякими ошибками координат около преград, из-за чего трассировщик высоты ломается и выдает неверный слой геодаты в многоуровневых локациях. Хотели нормальных вопросов и дискаса - получите;)

Конечно есть. Вон сколько спецификаций написано для различных дебагеров. Удачной отладки.

Специальная защита от людей, которые не могут в код, для шаровой версии.