Высокоуровнево предлагалось массовое использование паттерна ECS. Это такой архитектурный паттерн, который в основном используется в играх (иногда в онлайн-сервисах) для представления объектов игрового мира. ECS говорит, что сущности (entity) состоят из компонентов данных (component) , а управляют ими системы (system) . Для примера, если ты делаешь полоску здоровья, то entity — это айдишник этой полоски, component — это какая-то структура для хранения инфы о здоровье, system содержит код который обрабатывает эффекты добавления и удаления. Если полностью забыть про ООП, выбросить все MonoBehavior-ы и переписать игру в таком стиле — она должна резко ускориться. Да и писать в таком стиле гораздо проще — ты режешь задачу на очень четкие понятные срезы и не отвлекаешься на глобальное состояние. Особенно должно помочь для мультиплеера.
Комментарий недоступен
чего стоят создаваемые каждый кадр буферыБлядь скажи что ты шутишь
У нас программист воет от него. Говорит, что всё нравится, но из-за того, что юнити ОЧЕНЬ медленно его поддерживает, возникают проблемы.
В смысле, вы его используете в реальном продукте, не в прототипах?
Пробовали использовать - откатились через пару дней страданий :) Больше пробовать не будем
В чем были самые серьезные страдания?
Паттерн очень крутой, реализация юнити говно. Пробовал очень давно, может, что-то и поменялось.
- Burst джобы не работают с большими объёмами данных (генерил чанки как в майнкрафте, лютейше тормозило из-за копирования данных в нативный буффер и обратно), пришлось использовать обычный мультитрединг из C# вместо них.
- Поддержка ECS в редакторе рудиментарная (есть/был костыльный компонент ConvertToEntity), "pure ecs" нерабочий из-за того, что в движке очень мало pure систем (емнип систем частиц нет и с коллайдерами какие-то проблемы).
Идея зарефакторить весь движок под корень (project tiny) под ECS хороша, но этим никто не занимается. Проект утонул в хреновом менеджменте.
Бросил играться с Юнькой в итоге из-за кое-какой другой проблемы.