Комментарии 4
Вы много всего писали, но я пока не увидел явного преимущества ECS модели над «просто пишем классы». В чем таки основная фишка?
Мы уже писали об этом в статье про выбор ECS вот тут habr.com/company/pixonic/blog/413729.
Дело в том, что тут нельзя выделить какую-то одну-единственную фишку. Смысл в том, что это совершенно другая парадигма, как, например, функциональное программирование, у которой есть свои плюсы и минусы.
Из плюсов могу перечислить то, что мы смогли гораздо удобнее и быстрее выкатывать игровые фичи, сериализовать и копировать данные последовательно, иметь очень низкую связанность кода, делать красивую кодогенерацию для данных (за счёт отказа от смешивания их с логикой) и т.п. Эта парадигма даёт возможность последовательного детерминированного исполнения кода, что позволяет нам запускать часть этого кода на клиенте и ожидать одинаковые результаты на выходе. Вообще, хранение данных отдельно от логики даёт уйму преимуществ.
Композиционный подход вместо наследования, к которому всё больше склоняется ООП сообщество, тут реализован из коробки.
В общем случае, конечно, можно было бы сделать те же вещи используя множество уровней абстракций с помощью «классического» ООП, но это бы выглядело на порядок сложнее для разработки и поддержки.
Недавно наша компания проводила Pixonic DevGamm Talks, на котором был доклад, также посвященный этой теме. Рекомендую ознакомиться с выступлением моего коллеги на нём youtu.be/GFb84n9gz94?t=2h29m39s
Дело в том, что тут нельзя выделить какую-то одну-единственную фишку. Смысл в том, что это совершенно другая парадигма, как, например, функциональное программирование, у которой есть свои плюсы и минусы.
Из плюсов могу перечислить то, что мы смогли гораздо удобнее и быстрее выкатывать игровые фичи, сериализовать и копировать данные последовательно, иметь очень низкую связанность кода, делать красивую кодогенерацию для данных (за счёт отказа от смешивания их с логикой) и т.п. Эта парадигма даёт возможность последовательного детерминированного исполнения кода, что позволяет нам запускать часть этого кода на клиенте и ожидать одинаковые результаты на выходе. Вообще, хранение данных отдельно от логики даёт уйму преимуществ.
Композиционный подход вместо наследования, к которому всё больше склоняется ООП сообщество, тут реализован из коробки.
В общем случае, конечно, можно было бы сделать те же вещи используя множество уровней абстракций с помощью «классического» ООП, но это бы выглядело на порядок сложнее для разработки и поддержки.
Недавно наша компания проводила Pixonic DevGamm Talks, на котором был доклад, также посвященный этой теме. Рекомендую ознакомиться с выступлением моего коллеги на нём youtu.be/GFb84n9gz94?t=2h29m39s
Обработка идёт довольно стандартным способом
Поперхнулся утренним кофе. Писать в 2018-ом году работу с HTTP врукопашную на голых сокетах — это так стандартно, угу.
Тут дело в том, что нам не нужны возможности, предоставляемые более универсальными решениями. Мы не обрабатываем тысячи запросов к тулзе, а потому написали лишь минимально необходимый уровень. К тому же, на сервере не должно быть ничего, что мешает производительности основных потоков с играми. Грубо говоря, мы не можем позволить себе гигабайт аллокаций на такую элементарную вещь как один HTTP запрос.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как мы отлаживаем в браузере самописный ECS на игровом сервере