mmo-dev team

whiteo

cvaba community
Уважаемый собеседник
Разработчик
Победитель в номинации 2025
Орден Великого Хилера
Баг мой - друг мой
Старожил I степени
Хроники
  1. Prelude
  2. Harbingers of War
  3. Age of Splendor
  4. Rise of Darkness
  5. Scions of Destiny
  6. Oath of Blood
  7. Interlude
  8. The 1st Throne: The Kamael
  9. The 1st Throne: Hellbound
  10. The 2nd Throne: Gracia
  11. The 2nd Throne: Freya
  12. Chaotic Throne: High Five
  13. Goddess of Destruction Awakening
  14. Goddess of Destruction Harmony
  15. Goddess of Destruction Tauti
  16. Goddess of Destruction Glory Days
  17. Goddess of Destruction Lindvior
  18. Valliance / Epeisodion / Raiders
  19. Ertheia / Dimensional Strangers
  20. Infinite Odyssey
  21. Helios
  22. Grand Cursade
  23. Salvation
  24. Fafurion
  25. Shadow of the Kamael
  26. Prelude Of War
  27. Homunculus
  28. Return Of The Queen Ant
  29. Master Class
Всем привет, в моей прошлой теме тыц, мы успели пообсуждать кто, что и как пишет.
В итоге я решил что пора бы уже делать что-то, что можно было бы и людям показать.
Посему предлагаю организовать команду, чтобы совместно сделать качественный продукт.
Конечно, не все захотят тратить время, а кому-то денег подавай, но тут каждому свое. Если хотите внести вклад — милости просим.
Сразу скажу: Java, Go :Bingo:
Для начала я выкатил в репозиторий только логин-сервер. Но даже по нему уже можно посмотреть, насколько я упоролся.
Если ты такой же упоротый — ты тот, кто нужен команде mmo-dev team!
З.Ы. Зачатки гейм-сервера залью чуть позже.

github:

P.S. Пост будет дополнятся.
 
Последнее редактирование:
Сразу скажу: Java, Go :Bingo:
Почему не zig, как в другой теме обсуждалось? Или любой другой нормальный язык? Ну go явно не подходит для сервера :). Микро-макро сервисы с минимум действий может быть и окей, но вот что то глубокое и серьезное, как будто бы не для него. В недавнем обновление конечно ускорили GC на 52% вроде как если не путаю это в мае было, но всё таки, язык пустой же. Кучу бойлерплейтного кода, потому что сложно было в try catch или посмотреть как реализованы в том же rust, без try catch. С помощью Result<T, E>, для критических ошибок макрос panic! или при помощь синтаксического сахара ?
Как то читал статью, человек в принципе дал развернутый комментарий, о котором бы я точно так же бы высказался, в принципе нашёл этот комментарий и оно целиком относится к этому:
В богатой доменной модели Go плетётся в хвосте.

Rust > C#>Java>PHP>Go

Rust - sum types (enum), pattern matching, трейты, ownership - отлично ложится на domain modeling в духе Влашина ("Making Illegal States Unrepresentable").

C# подтянулся: records, discriminated unions пока нет нативно. Java - sealed classes, но многословно. PHP - слабая типизация мешает.

Go в хвосте: нет enum с данными, нет дженериков до недавнего (и они слабые), error handling через if err != nil - домен тонет в бойлерплейте. Structs + interfaces - плоская модель, сложные инварианты выражать тяжело.

Но Go и не для этого. Его ниша (ой, тут утверждали про тотальность/универсальность?) - сетевые сервисы с простой доменной логикой, где anemic model + процедурный стиль нормально работает. Проблема когда на Go пытаются писать сложный домен - получается месиво.

Второй большой недостаток - го не может вызвать или быть вызванным из других программ, только по сети.
Нет иммутабельности значит нет функционалльного программирования нормального, но ООП тоже нет. Остаётся процедурный стиль со структурами и интерфейсами. По сути это улучшенный C из 70х с GC и горутинами

Это с чем столкнулся
Ну и ещё десяток недостатков...
Про C# в целом не согласен в комментарии и Java уж явно после PHP будет, но да... Это по сути улучшенный Си из 70x годов, одна и та же каша и как выше указано и в цитате одна из главных проблем весь код покрывается вот таким ужасом if err != nil
Как и с ещё одной цитатой
Го создан не для разработчика, а для себя, любимой корпорации
В принципе это хорошо и видно
1779376738926.webp
1779376771826.webp
1779376871132.webp
Хоть это и официальная позиция гугла .
В том же Rust это эффективно сделано, т.к Result это обычная структура, просто тег + данные, процессор видит прозрачные, прямолинейные инструкции. Предсказатель переходов идеально оптимизирует ветку Ok, так как она выполняется чаще всего. Для логин сервера может и окей, а как в game сервере это всё будет развиваться? Какие либо изменения в языке уже маловероятно будут сделать, если хочется чего то, то наверное стоит посмотреть в , тоже самое что go.
Для игрового сервера, go лишнее, а упираться дальше будет лишь в костыли и реализовывать кучу пакетов для нормального виденья и работы. Можно же взять подходящий под это всё язык, а не вот так, кроме как для локального пет-проекта, чтобы прокачать свои навыки шансы на выход в живой и рабочий продукт очень малы, к тому же маложизнеспособны.
 
kick, zig был лишь экспериментом, так же как и py, ts.
У меня есть что-то на java - но в шаре есть решения лучше/багаче.
Я выбрал go потому что это компромис для меня.
В тот же rust я погружаюсь не с такой интенсивностью, как ожидалось..
Что есть нормальный язык?
По поводу ужаса с if err != nil я вот тоже не совсем уловил, визуально не нравится отсутствие сахара? оно ж явное и прозрачное для обработки, это ли не плюс?
 
У меня есть что-то на java - но в шаре есть решения лучше/багаче.
Но можно же лучше, нормальный код, нормальную базу сделать. Почему нет? Современные реалии позволяют, где то взять spring boot, какая разница какой будет реализация? Смотря как считать, лучше/багаче, по реализации возможно, по коду есть сомнения, открыт же полный фарш и нормальными современными инструментами, как раз таки не повторять старых ошибок, заложить хорошую архитектуру.
Есть же kotlin к тому же и хоть 1 человек не любит его, называя "Еретическое ответвление богоподобной явы", но все равно, весьма тоже активный язык и тот же spring boot и не только на нём есть.
Я выбрал go потому что это компромис для меня.
Компромисс в чём? Архитектурно это всё решалось, выбирался язык под задачу, он очень пустой же
Есть много языков C++, Rust, C#, F#, Java(Kotlin), Elixir, Zig, Nim. Если знаком с java я пробовал бы kotlin
Что есть нормальный язык?
Который способен решать поставленные бизнес-задачи под то что он и разрабатывался, go этим похвастаться не может, это равноценно что взять си 70 годов и будет тот же уровень, только в разы лучше и обширнее. Можем взять современный си, все те же самые плюсы будут и так, что нам даст go по сравнению с си? Готовые библиотеки для реализации каких то макро-микросервисов с минимум бизнес логики, чуть посерьезнее уже не будет хватать.
По поводу ужаса с if err != nil я вот тоже не совсем уловил, визуально не нравится отсутствие сахара? оно ж явное и прозрачное для обработки, это ли не плюс?
На каждый if, процессор выполняет операции угадывания, это уже минус по производительности. Это проверка многословная и начинает раздражать на больших объёмах кода, потому что почти везде нужно писать один и тот же код if err != nil, соответственно разрастается бизнес логика, сложнее видеть доменную логику среди этих проверок, появляется copy paste одного и того же, что соответственно нарушает паттерн программирования DRY, потому что мы повторяемся).
Код:
a, err: = step1()
if err != nil {
    return err
}
b, err: = step2(a)
if err != nil {
    return err
}
c, err: = step3(b)
if err != nil {
    return err
}
Ну вот что это?) А потом ты либо начинаешь это игнорировать, пропускать, надеяться, что все будет окей, а оказывается, что нет и это постоянно так. И если только сеть была бы на go ещё может быть да, но это же не только про сеть, а ещё:
Геодата
AI
Поиск пути
Скилы
Формулы
Синхронизации
Состояния
Эффекты
Переходы
Для сложного домена оперировать лишь структурами, интерфейсами, switch и рантайм проверками ну такое, начнётся свой колхоз, создания своих расширений к языку, доп либ и пакетов или существующих и тут будут проблемы, в этом можно утонуть, нужно думать глобальнее. А если сеть, то лучше Elixir вообще нет ничего и оперирует лишь он потоком данных. Да и создавался он как раз для абонентов сотовой связи изначально, плюс можно сразу в live режиме обновлять.
Или планируется реализация разных микросервисов?) Имеется тогда смысл делать на разных языках и разные сервисы в том где они хороши, это уж куда интереснее было бы и открыло бы куда больше возможностей.
Java по сути уже прошла тот самый путь и многие кейсы со сборщиком мусора и многие баги до сих пор ещё фиксятся с ним, но многие остановки и не только исправлены, а Go ещё проходит и как раз таки с ним будут проблемы и на механиках линейки это будет видно и потом на онлайне как он будет работать. Гарантированно паузы GC и особенно на большом онлайне будут видны, уже кстати проверено на 1 проекте tencent при 1к+ онлайне и одновременном выполнение действий видно было как летели ошибки и паузы сборщика мусора, а к ним добавится latency spikes и засорение памяти временными объектами. Java это уже всё это прошло и хоть внедрение фич очень долгое и пока комитет примет эту фичу в других языках она будет реализована. При этом появились весьма крутые фичи records, sealed classes, pattern matching, virtual threads и не только. Но C# лучше Java, но главный плюс они схожи и почему его было не взять? Шикарный DI, LINQ, Async/await к тому же в 9 в превью ввели ещё лучше async/await а в 10 уже вроде заменили на превьюшный, value types, source generator и структуры в разы сильнее гоушных, есть нативный AOT, Span, Memory, выделение стэка и куча крутых фич, особенно когда работаешь со спанами.
В цитате всё хорошо и прямо описано
Но Go и не для этого. Его ниша (ой, тут утверждали про тотальность/универсальность?) - сетевые сервисы с простой доменной логикой, где anemic model + процедурный стиль нормально работает. Проблема когда на Go пытаются писать сложный домен - получается месиво.
А ММО это как раз сложный домен)
Я не отговариваю от go, но говорю сразу проблемы будут и проблем будет не мало, а когда дело дойдёт до реализации различных механик все эти проблемы вылезут и как только это появится на онлайне, будут баги, проблемы и погружение в код, пока это пет-проект это одно, а когда это становится на онлайн это уже будет совсем другое.
 
Так... ну у меня появилась надежда научиться писать на Java быстрее чем реализуется сервер на Go!
 
kick, расписал красиво.
Кто в здравом уме будет писать сервер с нуля на java? не видел такого, если мы говорим про что-то более нежели эксперименты.
Go для меня баланс, баланс скорости и результата.
Go пустой - это ж его фича (не баг, а фича (с)).
if err != nil это 99% happy path и не DRY тут осознанный выбор.
Java/C# прошли эти пути за овер много лет и да, то что ты описываешь и правда будет показывать лучший результат в плане архитектуры и перформанса, но не кажется ли тебе что ключевое все таки не язык а архитектура?
ММО сложный домен, но L2 нет.
Я и не планировал все бросать и бежать свичится на другой язык, я уже много эксперементировал с разными языками, в итоге имеем то что имеем.
Сообщение объединено:
dLeto, challenge accepted?:Happy:
 
Кто в здравом уме будет писать сервер с нуля на java? не видел такого, если мы говорим про что-то более нежели эксперименты.
Почему нет? В чем проблемы, вот не вижу в этом проблем, как и закладыванием нормальной архитектуры.
Go для меня баланс, баланс скорости и результата.
А чем rust/c#/java медленные? Разогнанная java по скорости сравнима с C++, только лишь вопрос в оперативной памяти встанет. C# тоже быстр, к тому же есть крутые фичи в виде Span, stackalloc и не только о чем выше писал. Rust сопоставим плюсам и так же не имеет gc.
Go пустой - это ж его фича (не баг, а фича (с)).
А в чем фича? Что он может предложить, что не могут предоставить эти языки?) горутины, так аналоги есть
Java/C# прошли эти пути за овер много лет и да, то что ты описываешь и правда будет показывать лучший результат в плане архитектуры и перформанса, но не кажется ли тебе что ключевое все таки не язык а архитектура?
ММО сложный домен, но L2 нет.
Л2 не сложный домен?) 🤣. Так язык и не подходит под эту архитектуру, он не может предоставить покрытие этой самой архитектуры и тут весьма все сложнее. Тут очень много нюансов и не говорил бы, что он весьма простой. Это может на первый взгляд выглядит, что все просто и видя перед собой реализацию сборок l2j. Но когда начнешь делать и начнешь делать правильно, нормальную архитектуру в этом просто потонешь. И смотреть не на реализацию l2j и других сборок а брать правильный референс в качестве официальной сборки, вот там то и будут все проблемы и в реализации.
А с банальным отсутствием enum для типов скилов, понадобится городить костыль в виде интерфейсов, а это лишь малая часть и самое элементарное.
if err != nil это 99% happy path и не DRY тут осознанный выбор.
Sad patch, а не happy. И по факту DRY, ведь одни повторы
dLeto, с ней все так, отличный язык, но я не вижу смысла писать l2j с нуля, да и ни кто это делать не будет.
С чего такая уверенность? Т.е на go делать с 0 ок, а на java делать не ок, в чем логика?
 
А чем rust/c#/java медленные? Разогнанная java по скорости сравнима с C++, только лишь вопрос в оперативной памяти встанет. C# тоже быстр, к тому же есть крутые фичи в виде Span, stackalloc и не только о чем выше писал. Rust сопоставим плюсам и так же не имеет gc.
Я не говорил что они медленные, я лишь написал что лично для меня go это компромисс.
А в чем фича? Что он может предложить, что не могут предоставить эти языки?) горутины, так аналоги есть
в простоте, аналоги есть.
Л2 не сложный домен?) 🤣. Так язык и не подходит под эту архитектуру, он не может предоставить покрытие этой самой архитектуры и тут весьма все сложнее. Тут очень много нюансов и не говорил бы, что он весьма простой. Это может на первый взгляд выглядит, что все просто и видя перед собой реализацию сборок l2j. Но когда начнешь делать и начнешь делать правильно, нормальную архитектуру в этом просто потонешь. И смотреть не на реализацию l2j и других сборок а брать правильный референс в качестве официальной сборки, вот там то и будут все проблемы и в реализации.
А с банальным отсутствием enum для типов скилов, понадобится городить костыль в виде интерфейсов, а это лишь малая часть и самое элементарное.
Когда я столкнусь с архитектурным затыком, я естественно об это напишу. У меня есть .pdb а в go есть iota, плюс я не претендую на решение всех решений, для любителей offlike есть экстеншены.
Sad patch, а не happy. И по факту DRY, ведь одни повторы
Как вяжется DRY с if err != nil, как это sad path если в 99% случаях ошибки там нет?
С чего такая уверенность? Т.е на go делать с 0 ок, а на java делать не ок, в чем логика?
Логика проста, речь про интерес и энтузиазм в целом, мне не интересно ковырять java в очередной раз. Плюс даже если бы я написал что-то типа, айда запилим новую сборку на java/с#/etc? Ты скорее всего бы написал что я делаю это не так или делаю это не правильно)
 
Я не говорил что они медленные, я лишь написал что лично для меня go это компромисс.
Так в чём этот компромисс)
в простоте, аналоги есть.
Простоты делфей ещё никто не переплюнул)
Как вяжется DRY с if err != nil, как это sad path если в 99% случаях ошибки там нет?
снижение повторения информации, ты дублируешь постоянно один и тот же код, конечно можно изобретать свои костыли в виде функции ещё чего, чтобы не дублировать, то окей dry уйдёт, а sad path, т.к блок проверяет, произошла ли ошибка. Если условие выполняется (ошибка есть), выполнение программы сворачивает с "пути счастливого сценария" и переходит к обработке этой ошибки.
Ты скорее всего бы написал что я делаю это не так или делаю это не правильно)
даже если бы и так было, это лишь обычное мнение, с которым можно соглашаться или не соглашаться, а считать как истинно верным не возможно его считать, это уже должен каждый сам для себя решить, что как и куда. Но как и писал выше путь go более чем скорее ошибочный, не вижу, что он прям идеально или хорошо ложится на домен л2
 
Так в чём этот компромисс)
Скорость и результат
Простоты делфей ещё никто не переплюнул)
Туше
снижение повторения информации, ты дублируешь постоянно один и тот же код, конечно можно изобретать свои костыли в виде функции ещё чего, чтобы не дублировать, то окей dry уйдёт, а sad path, т.к блок проверяет, произошла ли ошибка. Если условие выполняется (ошибка есть), выполнение программы сворачивает с "пути счастливого сценария" и переходит к обработке этой ошибки.
Dry никак не запрещает нам повторения синтаксический конструкций. Благодаря предсказателю переходов все проверки скипаются.
даже если бы и так было, это лишь обычное мнение, с которым можно соглашаться или не соглашаться, а считать как истинно верным не возможно его считать, это уже должен каждый сам для себя решить, что как и куда. Но как и писал выше путь go более чем скорее ошибочный, не вижу, что он прям идеально или хорошо ложится на домен л2
Так в этом и суть, ты видишь один путь реализации и строго выбранный язык, я же в свою очередь сделал свой выбор.
 
dLeto, с ней все так, отличный язык, но я не вижу смысла писать l2j с нуля, да и ни кто это делать не будет.
Друг тут думаю все бы помогли и покавырялись бы в общем проекте.

Но с нуля... Сервера линейки уже 21 год развиваются ,то есть когда мы дойдём до того же что есть счас мне будит 60+ -

Ну такая себе перспектива.
 
whiteo, ты сервер пишешь? Тут больше слов чем кода =)
 
Назад
Сверху Снизу