Grave

Ещё Demon souls и Prince of Persia Warrior Within. Bloodborne не рекомендую, так как она только на PS4, все остальное либо на пк есть либо на эмуляторе.

Да, вы правы, если разработчик перенес игру на Ecs и для него по производительности мало что поменялось (хотя это мало вероятно), скорее его устраивает производительность GameObjects, то ECS не нужен. В нашем проекте используется много NPC с физикой. Как вы могли видеть внизу поста есть 3 видео с производительностью, и, к сожалению, в пустой сцене на компьютере 100 машин на GameObjects выдают около 40 fps, а 500 машин на ECS - 300. На Андроиде разница между неиграбильно и 60 fps. Ecs уместно, если нужна производительность из коробки. Для нашего проекта она подходит больше, чем GameObjects. Для других проектов, более простых можно и даже нужно оставаться на GameObjects.

О как, а можешь ссылку скинуть? :)

Спасибо за фидбэк, про кастомные ECS ничего не писал, так как не пользовался. А на счёт чанков нужно было затронуть. Я ещё кое-что про кэш хотел написать и Burst компиляцию, но понял, что нужно остановиться и статью в срок выпустить. Хотел бы ещё немного обратной связи, как такой технический контент заходит, ожидаешь ли ты такое увидеть на DTF?

Забил в поисковик и нашел https://github.com/Antoshidza/NSprites. Как я уже и говорил, многое нужно искать или писать самому, Entities еще сыроваты.

Нет, тут наши мнения сходятся. Я описал, что Entities отстают фичам и разрабатывать игры сложнее, в некоторых местах. Если для вашего проекта отсутствуют критически важные компоненты и нет времени писать свои, то нужно возвращаться на GO.

Да, интересная история, не смогли сами написать мультиплеер и наняли людей, которые им все сделали.

Они недавно уволили Ричителлу, может теперь у них все наладится. На счёт увольнений сотрудников, штат у них действительно раздутый, чуть ли не в 2 раза больше работников, чем в Epic Games.

Их надо пожалеть, у них финансовые проблемы. Я думал, что они ECS вообще забросят, а они дотянули.

Зато у них есть Roadmap :)

У тебя нет шизы

Кстати нет, были ломающие изменения и после 1.0

Спасибо, поправил

https://youtrack.jetbrains.com/issue/RIDER-81198
Говорят, что уже пофиксили, но надо в настройках включить.
Вот что пишут:
Never mind, I was wrong. It is available in Rider. In order to fix this, I had to hit CTRL + SHIFT + A, search for "Smooth Scroll Options", then check the "Enable Windows High Precision Timer" option. I figured this was visible within the main Settings menu, but it seems that it must be opened from this route instead.

Так он и подчеркивает, да какой толк, если ты можешь это проигнорировать.

Не обращайте внимания на эти скрины, их надо обновить. И они не относятся к теме этой статьи. Проблемы с промахами кэша и с управлением памятью от этого никуда не денется у стандартного подхода :)

Да, вы правы, писать некоторые вещи на объектах удобнее. Например, ИИ, так как большинство общепринятых методов использует полиморфизм. Но, может, если бы Ecs был такой же популярный как и GO, мы бы сейчас говорили обратное.

Действительно, проблема GameObjects везде одинаковая, не только на Unity. Стандартный GameObject подход очень легок для освоения, поэтому он привлекает разработчиков. Но под всем этим скрывается ООП, которая является очень простой парадигмой для понимания, но очень сложной в реализации.

Производительность намного лучше, особенно с Burst-компилятором. Костыли и велосипеды стали поменьше :) Ecs в юнити стабилен, но отстает по фичам от обычного подхода.

Не проверял насколько влияет, но галочка стояла у меня, может когда-нибудь проведу исследование на эту тему.

Моя идея была в том, что Garbage collector скрывает управление памятью от разработчика и он расслабляется. Конечно можно использовать ручные методы для вызова Garbage Collector в ненагруженные моменты в игре, но тогда это уже будет больше похоже на ручную очистку в стиле C++. Большинство разработчиков не запариваются с этим.

Могу заверить, что переход в нашей игре с GameObjects на Ecs дал огромный буст в производительности, а использование Burst компилятора увеличила разрыв ещё больше. Это все будет расписано в следующей статье. Как было написано, одним из главных плюсов Ecs подхода является дружелюбность к кэшу, а это для игры очень критично. Ecs действительно намного удобнее для разработки чем ООП, все неудобства добавляет его кривая реализация в Unity.

Обрати внимание, что там написано на компонентах GameObjects.
На счёт рекламы Ecs, на следующей неделе выйдет статья со сравнением производительности с GameObjects и там будет очень сильно заметен оверхэд от их использования.

В интернете много споров по поводу нужен ли интерфейс для модели. Многие пишут, что годами пишут интерфейсы с одной реализацией для них и не понимают зачем. Некоторые говорят, что через 5 лет они могут понадобится и тогда будет понятно зачем. Хотя все эти споры в отрыве от юнити, без ее специфики.

Я имел ввиду
public class ProfileModel : IModel{}
Если модель находится в одной базе данных, а надо переключиться на другую или для тестирования. Конечно я понимаю, что здесь простая модель, но в случае с более замороженными вариантами не лучше использовать интерфейс?