- Хроники
- Interlude
- Исходники
- Присутствуют
- Сборка
- Vasyan.NET
Всем привет! Я вот уже 12 лет занимаюсь кодингом пять дней в неделю по 8 часов в день и решил попробовать ради эксперимента написать свою сборку.
В качестве ЯП буду использовать C# на .NET фреймворке. В помощь себе беру Claude c подпиской за 200 баксов и этот форум как источник костылей и велосипедов, информации о багах/дюпах. В качестве интереса готов ответить на все ваши вопросы и поделиться всей инфой по архитектуре ядра. Буду признателен если вы задушите меня техническими вопросами и будете меня критиковать на каждом шагу, чтобы я смог использовать вашу критику для улучшения будущей сборки. По поводу раздачи исходников я пока не решил - на данный момент исходники показывать не буду, но возможно после получения того или иного результата, поменяю свое мнение.
По плану в MVP хочу сделать серверную сборку для IL хроник, но с возможностью дальнейших расширений под любые будущие хроники. Я понимаю, что механики сильно меняются от хроники к хронике, некоторые кардинально, это будет учтено в архитектуре ядра. Такую дельту между хрониками планирую реализовывать в виде подключаемых и отключаемых плагинов.
Проанализировав код расшаренных Java сборок, я сделал вывод, что многопоточная архитектура с блокировками несет большой риск дэдлоков и гонок, приводящих к дюпам, поэтому я думаю сделать сборку на тиковой системе. Условно положим тик сервера = 100мс.
За время одного тика сервер буферизирует все приложенные к нему пакеты и в конце тика делает транзакционную запись в БД. Таким образом, если пользователь выкинул что-то из инвентаря на пол, операция удалить предмет из инвентаря и положить предмет на пол будет атомарна и выполнена в транзакции - если что-то пошло не так, то откатятся оба действия.
Также тиковый подход исключит любые гонки и блокировки потоков, но не запретит параллельную обработку буфера. В текущих ява сборках при PVP удар игрока по другому игроку может обработаться сервером не последовательно во времени, а по порядку, который определила ОС при обработке потоков. Мне кажется это нифига не честно
Тиковый подход строго сортирует пакеты по времени прихода на сервер и буфер гарантирует обработку в нужном порядке - если ты ударил соперника раньше, то и сервер обработает это по-честному.
Также я откажусь от использования ООП для работы с игровыми объектами, чтобы исключить лишние аллокации и не загружать сборщик мусора. Но об этом я расскажу в следующем посте, если соберу позитивный фидбек от вас. Спасибо, что прочитали.
В качестве ЯП буду использовать C# на .NET фреймворке. В помощь себе беру Claude c подпиской за 200 баксов и этот форум как источник костылей и велосипедов, информации о багах/дюпах. В качестве интереса готов ответить на все ваши вопросы и поделиться всей инфой по архитектуре ядра. Буду признателен если вы задушите меня техническими вопросами и будете меня критиковать на каждом шагу, чтобы я смог использовать вашу критику для улучшения будущей сборки. По поводу раздачи исходников я пока не решил - на данный момент исходники показывать не буду, но возможно после получения того или иного результата, поменяю свое мнение.
По плану в MVP хочу сделать серверную сборку для IL хроник, но с возможностью дальнейших расширений под любые будущие хроники. Я понимаю, что механики сильно меняются от хроники к хронике, некоторые кардинально, это будет учтено в архитектуре ядра. Такую дельту между хрониками планирую реализовывать в виде подключаемых и отключаемых плагинов.
Проанализировав код расшаренных Java сборок, я сделал вывод, что многопоточная архитектура с блокировками несет большой риск дэдлоков и гонок, приводящих к дюпам, поэтому я думаю сделать сборку на тиковой системе. Условно положим тик сервера = 100мс.
За время одного тика сервер буферизирует все приложенные к нему пакеты и в конце тика делает транзакционную запись в БД. Таким образом, если пользователь выкинул что-то из инвентаря на пол, операция удалить предмет из инвентаря и положить предмет на пол будет атомарна и выполнена в транзакции - если что-то пошло не так, то откатятся оба действия.
Также тиковый подход исключит любые гонки и блокировки потоков, но не запретит параллельную обработку буфера. В текущих ява сборках при PVP удар игрока по другому игроку может обработаться сервером не последовательно во времени, а по порядку, который определила ОС при обработке потоков. Мне кажется это нифига не честно
Тиковый подход строго сортирует пакеты по времени прихода на сервер и буфер гарантирует обработку в нужном порядке - если ты ударил соперника раньше, то и сервер обработает это по-честному.
Также я откажусь от использования ООП для работы с игровыми объектами, чтобы исключить лишние аллокации и не загружать сборщик мусора. Но об этом я расскажу в следующем посте, если соберу позитивный фидбек от вас. Спасибо, что прочитали.