Архитектура

Горячие пирожки прямиком из l2j-devel:

<Муркт>: ну да, а нынешняя архитектура не позволяет что-то ненапряжно делать
<Муркт>: любое изменение - рак тот ещё, помню-помню )
<Drac>: да уж
<Муркт>: никто не хочет попробовать переделать архитектуру? я могу рассказать как это то, что я хотел сделать со скилл-энжином, но скилл-энжином не ограничивается
<Drac>: можешь попробовать
<Муркт>: если вкратце - одна из основных идей состоит в том, чтобы сделать из L2Character не abstract, a final class
<Муркт>: соответственно получится где-то пяток компоновщиков, которые должны быть чем-то наподобии "наследник L2CharacterOwner"
<Муркт>: Player, Slave, Monster, NPC
<Drac>: ууу
<Муркт>: Они в свою очередь тоже должны не давать от себя наследоваться
<Муркт>: автоматически получим резкое упрощение в виде убирания разных L2Merchant, GateKeeper, warehousekeeper, lotteryticketer, hrenyakoNPC. Их там пару десятков вроде?
<Муркт>: у этого НПЦ должен быть какой-нибудь список его предназначений, и каждая возможность лежит в своём классе, и их очень просто скомбинировать между собой. А не так как сейчас - на каждую новую фичу делай класс-наследник от ФолкИнстанс
<Муркт>: в результате любая новая комбинация предназначений - это не изменение кода, а просто дописывание куда-нибудь через запятую ещё одного слова (в "базе")
<Drac>: осилил
<Drac>: правда надо будет много буковок переделывать
<Муркт>: плюс из самого класса л2чар надо выделить кучу классов
<Муркт>: в СФ в своё время этим чуть-чуть занялись (почти год назад), но бросили на полпути, да и сделали отстойно
<Муркт>: надо выделять всё, что можно выделить. Т.е. работу с эффектами - в отдельный объект CharacterEffects, все статы - отдельно, и т.д.
<Drac>: это надо серьезно заниматься
<Муркт>: К примеру, есть ещё такой у нас тупизм, как _sleeped, _stunned, _fakedeath, _ещёчтотонепомнючто
<Муркт>: всё это выделить наффег в CharacterStates и сделать это не кучей булевых переменных, а set'ом, в котором будет храниться совокупность состояний, сделать енум из SLEEP, STUN, FAKEDEATH, етц
<Муркт>: тогда ещё вместо кучи функций isSleeping, isStunned, isТрампарам выйдет одна функция isInState(State)
<Муркт>: ну и таких мелочей там тонны на самом деле
<Drac>: труевину глаголишь, только надо этим сильно серьезно заниматься, чтобы человек был настроен пройти полный цикл разработки этого
<Муркт>: под такую переделку автоматически попадают все чартемплейты, потому что сейчас они сделаны неудобно
<Муркт>: ну а со скиллами там и так всё понятно. Насчёт скиллов идея была ещё год назад...
<Муркт>: тут надо отметить три вещи, в целом
<Муркт>: 1) это очень много времени, соответственно заниматься должен человек, у которого времени много. Ну и который понимает очень хорошо, что он делает.
<Муркт>: 2) нормальная архитектура даст довольно приличный оверхед, по сравнению с тем, что есть сейчас, ИМХО
<Муркт>: 3) лёгкость работы с этим кодом впоследствии затмевает любые минусы оверхеда
<Муркт>: ну и ещё одно...
<Муркт>: если всё это сделать, то бить нещадно по рукам тех, кто будет хоть чуть-чуть отступать от политики партии и делать что-то подобно тому, как сделано всё сейчас.
<Drac>:
<Муркт>: потому что в результате получится то же самое, что есть сейчас, и куча усилий будет потрачена непонятно на что
<Муркт>: Drac: насчёт выделения кучи "служебных" классов из имеющихся - вот только что вспомнил ещё работу с ПвП-состояниями
<Муркт>: а, тут ещё одно преимущество вспомнил. При желании, можно будет поплотнее интегрировать питон, и юзать его хорошо. А не для каких-то квестов пацаватых

Бранч под это выделять будете?

Муркт - не помнишь случайно номера ревизий, где СФ пытались это реализовать?

И можешь описать вкратце вашу текую архитектуру?

Ну или хотя бы отличия её от архитектуры СФ, если они есть? )

damnedkluev> Бранч под это выделять будете?

Реализовывать некому, так что никаких бранчей. Это просто обсуджение.

damnedkluev> Муркт - не помнишь случайно номера ревизий, где СФ пытались это реализовать?

Они не пытались это реализовать, они всего-лишь вытянули из L2Character или PcInstance пяток классов. Если я правильно помню, то они лежат в model/entity. Если за полгода ничего не изменилось

damnedkluev> И можешь описать вкратце вашу текую архитектуру?
damnedkluev> Ну или хотя бы отличия её от архитектуры СФ, если они есть? )

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

Т.е. у всех происходит наследование от L2Character, у всех происходит наследование от L2Skill и SkillHandler (кроме фортресса, в июне я хендлеры скиллов убрал), у всех неудобные темплейты и кривая изначально система с саммонами

Как-нибудь сподоблюсь и напишу мысли по поводу скиллов, темплейтов.

Murkt: а почему бы тебе самому этим не заняться? Ну в смысле не самому переписывать, т.к. у тебя вроде бы нет времени, а хотя-бы руководить, изредка появляться и советы давать
Я со своей стороны готов переделать все скиллы под нужный формат. Только нужна уверенность, что дело не встанет, иначе обидно будет работать зря

Еще замечу, пока не забыл - надо что-то делать с фортом. Там полный бардак у нас сейчас. Переделать все надо, убрать лишнее.

Megawolf> а почему бы тебе самому этим не заняться? Ну в смысле не самому переписывать, т.к. у тебя вроде бы нет времени, а хотя-бы руководить, изредка появляться и советы давать

Изредка появляться и советы давать я могу, но
<Муркт>: 1) это очень много времени, соответственно заниматься должен человек, у которого времени много. Ну и который понимает очень хорошо, что он делает.

Кто?

Megawolf> Я со своей стороны готов переделать все скиллы под нужный формат. Только нужна уверенность, что дело не встанет, иначе обидно будет работать зря

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

Megawolf> Еще замечу, пока не забыл - надо что-то делать с фортом. Там полный бардак у нас сейчас. Переделать все надо, убрать лишнее.

У форта есть несколько проблем, которые решить нельзя в принципе. Это факт. Но у джитона проблемы почти те же, просто он используется в другом ключе, потому с ним самим проблем меньше. Когда меняешь что-то в джаве, то не знаешь, как это отобразится на скриптах Но вообще здесь не о форте речь. Сама интеграция сделана на 6 по пятибалльной системе Ни прибавить, ни убрать. Так что о форте разговор не в этой теме

А можно поподробнее о проблемах с фортом? )

Насчет скиллов - ну некоторая оптимизация формата все же требуется. Там неразбериха с типами/эффектами, непонять черезо что делать, и какой тип присваивать некоторым скиллам. Например скилл слип + рут, что пихать в эффекты а что в тип?
Я предлагаю все переделать на эффекты а типы сделать общего характера.

Насчет форта - я не про переписку его движка и его интеграции, я про его датапак. Он сейчас заброшен давно, далеко и надолго, и там бардак.

Megawolf> Насчет скиллов - ну некоторая оптимизация формата все же требуется. Там неразбериха с типами/эффектами, непонять черезо что делать, и какой тип присваивать некоторым скиллам. Например скилл слип + рут, что пихать в эффекты а что в тип?
Megawolf> Я предлагаю все переделать на эффекты а типы сделать общего характера.

Давно придумано. Три общих типа - пассивный, переключаемый, активный (разделение на три активных, как в оффе, - излишне). Кто займётся? )))

Megawolf> Насчет форта - я не про переписку его движка и его интеграции, я про его датапак.

Я же говорю - разговор про форт не для этого топика.

Megawolf>> Насчет скиллов - ну некоторая оптимизация формата все же требуется. Там неразбериха с типами/эффектами, непонять черезо что делать, и какой тип присваивать некоторым скиллам. Например скилл слип + рут, что пихать в эффекты а что в тип?
Megawolf>> Я предлагаю все переделать на эффекты а типы сделать общего характера.
Murkt> Давно придумано. Кто займётся? )))

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

Megawolf>только бы кто сделал основу для этого, движок

Так а я о чём? О том самом и глаголю.

Муркт>: если вкратце - одна из основных идей состоит в том, чтобы сделать из L2Character не abstract, a final class

Смысл этого - не понял

Вся логика наследования в ООП говорит именно о такой классификации. Базовый класс, потом - последовательные уточнения.

Муркт>: у этого НПЦ должен быть какой-нибудь список его предназначений, и каждая возможность лежит в своём классе, и их очень просто скомбинировать между собой. А не так как сейчас - на каждую новую фичу делай класс-наследник от ФолкИнстанс

А, понял. Но это ничем не лучше нынешней ситуации. Вместо 10 классов чаров будет 10 классов предназначений.

Муркт>: К примеру, есть ещё такой у нас тупизм, как _sleeped, _stunned, _fakedeath, _ещёчтотонепомнючто
<Муркт>>: всё это выделить наффег в CharacterStates

Это - можно. А вот всякие _x, _y, _z, как это сделали в SF, выносить в CharacterCoordinates ни в коем случае нельзя. Производительность падает сразу в разЫ. А обращения к этим полям - одни из самых частых на сервере. При интенсивной работе даже .getX() отжирает процентов до 5 всех(!) ресурсов сервера.

>и сделать это не кучей булевых переменных, а set'ом, в котором будет храниться совокупность состояний

Редко модифицируемые - можно. Если только разрядности хватит.

Муркт>: 2) нормальная архитектура даст довольно приличный оверхед, по сравнению с тем, что есть сейчас, ИМХО

В нашем случае архитектуру имеет смысл приносить в жертву скорости. Ибо скорости и сейчас не хватает. Куда уж хуже-то?

Муркт>: 3) лёгкость работы с этим кодом впоследствии затмевает любые минусы оверхеда

Кому нужен будет лёгкий код, если он будет тянуть максимум 50 человек онлайн?

Муркт>: если всё это сделать, то бить нещадно по рукам тех, кто будет хоть чуть-чуть отступать от политики партии и делать что-то подобно тому, как сделано всё сейчас.

А писать нормально - можно и в рамках имеющейся архитектуры. И бить по рукам за аномальную писанину нужно тоже уже сейчас.

Муркт>: а, тут ещё одно преимущество вспомнил. При желании, можно будет поплотнее интегрировать питон, и юзать его хорошо. А не для каких-то квестов пацаватых

Зачем нам этот тормоз?? Я не знаю на сегодня более тормозного серверного скриптово языка. Он в 29(!) раз тормознее неоптимизированного чистого Питона

Муркт>>: если вкратце - одна из основных идей состоит в том, чтобы сделать из L2Character не abstract, a final class
Balancer> Смысл этого - не понял
Balancer> Вся логика наследования в ООП говорит именно о такой классификации. Базовый класс, потом - последовательные уточнения.

Логика наследования - да. Но ведь не всегда нужно использовать наследование? Я вот не вижу смысла разделения монстров и саммонов.

Муркт>>: у этого НПЦ должен быть какой-нибудь список его предназначений, и каждая возможность лежит в своём классе, и их очень просто скомбинировать между собой. А не так как сейчас - на каждую новую фичу делай класс-наследник от ФолкИнстанс
Balancer> А, понял. Но это ничем не лучше нынешней ситуации. Вместо 10 классов чаров будет 10 классов предназначений.

Почему не лучше?

Balancer> А вот всякие _x, _y, _z, как это сделали в SF, выносить в CharacterCoordinates ни в коем случае нельзя. Производительность падает сразу в разЫ. А обращения к этим полям - одни из самых частых на сервере. При интенсивной работе даже .getX() отжирает процентов до 5 всех(!) ресурсов сервера.

Ну тут уже ой Доводить до абсурда и выделять абсолютно всё не надо.

>>и сделать это не кучей булевых переменных, а set'ом, в котором будет храниться совокупность состояний
Balancer> Редко модифицируемые - можно. Если только разрядности хватит.

Они редко модифицируются.

Муркт>>: 2) нормальная архитектура даст довольно приличный оверхед, по сравнению с тем, что есть сейчас, ИМХО
Balancer> В нашем случае архитектуру имеет смысл приносить в жертву скорости. Ибо скорости и сейчас не хватает. Куда уж хуже-то?

Почему ты забываешь, что хорошая/плохая архитектура практически не влияет на сами вычисления? То что пожирает проц сейчас, то будет пожирать проц и потом точно так же, и как раз там оверхеда практически не будет. А вот именно взаимодействие всяких скиллов, чаров, неписей и саммонов - оно съедает сейчас... Ну пусть 2%. Даже 100%-ый оверхед не жесток.

Муркт>>: 3) лёгкость работы с этим кодом впоследствии затмевает любые минусы оверхеда
Balancer> Кому нужен будет лёгкий код, если он будет тянуть максимум 50 человек онлайн?

Если нынешний тянет 500, к примеру, то новый будет тянуть где-то 480 Но можно и по-другому сказать - зачем нужен плохой код, который тянет 500 человек, если там играть будет всего 3?

Муркт>>: если всё это сделать, то бить нещадно по рукам тех, кто будет хоть чуть-чуть отступать от политики партии и делать что-то подобно тому, как сделано всё сейчас.
Balancer> А писать нормально - можно и в рамках имеющейся архитектуры. И бить по рукам за аномальную писанину нужно тоже уже сейчас.

Это да - одно другому не мешает, и собственно к архитектуре отношения не имеет.

Муркт>>: а, тут ещё одно преимущество вспомнил. При желании, можно будет поплотнее интегрировать питон, и юзать его хорошо. А не для каких-то квестов пацаватых
Balancer> Зачем нам этот тормоз?? Я не знаю на сегодня более тормозного серверного скриптово языка. Он в 29(!) раз тормознее неоптимизированного чистого Питона
У меня цифры - приблизительно в два раза медленнее, чем нынешний CPython. Можно тогда попробовать прикрутить Stackless Python. АФАИК отличная вещь.

Murkt> Логика наследования - да. Но ведь не всегда нужно использовать наследование? Я вот не вижу смысла разделения монстров и саммонов.

У саммонов целая масса специфических функций, которые не нужны монстрам. Начиная от их владельца, кончая инвентарём и т.п.

Murkt> Почему не лучше?

Шило на мыло.

Murkt> Ну тут уже ой Доводить до абсурда и выделять абсолютно всё не надо.

А статсы и прочее, обращений к чему не много - это сам Бог велел выносить. Тут я не спорю

Murkt> Почему ты забываешь, что хорошая/плохая архитектура практически не влияет на сами вычисления?

Ты сам писал об оверхеде

> То что пожирает проц сейчас, то будет пожирать проц и потом точно так же, и как раз там оверхеда практически не будет. А вот именно взаимодействие всяких скиллов, чаров, неписей и саммонов - оно съедает сейчас... Ну пусть 2%. Даже 100%-ый оверхед не жесток.

Если это именно из 2% вылезет. В общем, это требует очень вдумчивого и поэтапного подхода.

Murkt> У меня цифры - приблизительно в два раза медленнее, чем нынешний CPython. Можно тогда попробовать прикрутить Stackless Python. АФАИК отличная вещь.

Не знаю, кто такой CPython, но Jython на Linux на рекурсивных вычислениях Фибоначи в 29 раз медленнее, чем нативный Python Если же считать с psyco - то разница ещё раз в 60 может вырасти...

Murkt>> Логика наследования - да. Но ведь не всегда нужно использовать наследование? Я вот не вижу смысла разделения монстров и саммонов.
Balancer> У саммонов целая масса специфических функций, которые не нужны монстрам. Начиная от их владельца, кончая инвентарём и т.п.

(у саммонов инвентаря нет, он есть у петов) Ну это понятное дело, что у них есть специфические функции (штук пять на самом деле), но почему именно наследование? ИМХО, оно здесь неудобно. Будут отдельные классы, которые будут содержать своего подчинённого-L2Character'а, и свои специфические функции. Тогда можно на лету менять базу, либо же "обёртку", делать из монстра саммона (чарм! ), и наоборот.

Murkt>> Почему не лучше?
Balancer> Шило на мыло.

Я так не думаю

Murkt>> Почему ты забываешь, что хорошая/плохая архитектура практически не влияет на сами вычисления?
Balancer> Ты сам писал об оверхеде

А если бы я сказал, что с новой архитектурой получится быстрее, ты бы мне прям так и поверил сразу?

Murkt>> То что пожирает проц сейчас, то будет пожирать проц и потом точно так же, и как раз там оверхеда практически не будет. А вот именно взаимодействие всяких скиллов, чаров, неписей и саммонов - оно съедает сейчас... Ну пусть 2%. Даже 100%-ый оверхед не жесток.
Balancer> Если это именно из 2% вылезет. В общем, это требует очень вдумчивого и поэтапного подхода.

Естественно. И не в транке

Balancer> Не знаю, кто такой CPython, но Jython на Linux на рекурсивных вычислениях Фибоначи в 29 раз медленнее, чем нативный Python Если же считать с psyco - то разница ещё раз в 60 может вырасти...
CPython - это нативный Питон. Просто он на С пишется, и при обсуждении его и других реализация (Jython, IronPython), обычно указывают конкретно Cpython, чтобы различать реализацию и сам язык (синтаксис).

Насчёт оверхеда. Предпочитаю писать что будет медленно: если будет медленно, то никто не огорчится, а если будет быстро - порадуются А если напишу, что будет быстро, а окажется медленно... Обманутые ожидания :-\ Плохо.

Murkt> (у саммонов инвентаря нет, он есть у петов) Ну это понятное дело, что у них есть специфические функции (штук пять на самом деле), но почему именно наследование? ИМХО, оно здесь неудобно.

Хотя бы потому, что Java заточена под наследование И вызов переопределённой функции потомка происходит намного быстрее, чем вызов функции из класса, который прописан в каком-то поле базового класса.

Я на эту тему целое исследование проводил, именно в контексте l2j, о чём писал на форуме. Блин, нужно поиск скорее приделывать к форуму

В общем, если нужно что-то достать из класса, то самый быстрый способ - переопределение функции у наследника.

Кстати, метод с instanceof - крайне медленный (я даже делал в сборке серию замен с instanceof на связки пустая функция + её переопределение у потомков).

Murkt> Я так не думаю

Поиграй с бенчмарками

Кроме того, вызов субкласса по полю и из него - функции - это метод менее красивый, чем прямой вызов функции (где это применимо и удобно).

Murkt> А если бы я сказал, что с новой архитектурой получится быстрее, ты бы мне прям так и поверил сразу?

Нет, я бы тебе сказал про оверхед

Murkt>> но почему именно наследование? ИМХО, оно здесь неудобно.
Balancer> Хотя бы потому, что Java заточена под наследование И вызов переопределённой функции потомка происходит намного быстрее, чем вызов функции из класса, который прописан в каком-то поле базового класса.

Опять про скорость. Заточена? Это как сказать, что Джава заточена под плюсование, а не умножение - ведь плюсование быстрее. Но ведь это не значит, что надо везде использовать плюс, а не умножение.

Balancer> Кстати, метод с instanceof - крайне медленный (я даже делал в сборке серию замен с instanceof на связки пустая функция + её переопределение у потомков).

А instanceof здесь каким образом побывал теперь? Или это просто "кстати", и к теме разговора отношения особо не имеет?

Murkt>> Я так не думаю
Balancer> Поиграй с бенчмарками

О5 25.

Balancer> Кроме того, вызов субкласса по полю и из него - функции - это метод менее красивый, чем прямой вызов функции (где это применимо и удобно).

Менее красивый? А держать двести килобайт кода в одном классе - это более красиво?..

Так заниматься этим или нет?

Или закройте тему...

Зачем тему закрывать?!