Принцип "Если мне это не надо, значит никому не надо" в действии.
ScriptableObject - это префаб, только без трансформа. Делать из него игровые сущности так себе затея, но это отличный механизм для хранения настроек. Хранимый на сцене GameObject с параметрами может быть просто уничтожен, его трудно редактировать и переиспользовать.
MonoBehaviour по сравнению с POCO - оверхед на менеджмент GO, компонентов, времени жизни, плюс всякие подводные камни типа сравнения с null. Ну и иногда просто не хочется быть привязанным к UnityEngine.
Кстати, замена private SerializedField на public - плохая практика, если над проектом работает больше одного человека, чтобы всякие умники не меняли значения в рантайме.
MV* позволяет не держать в своей голове сразу всё. Можно собрать всю игру в одном классе, в этом нет ничего плохого. Но в какой-то момент игра разрастается до такого состояния, что менеджмент UI, настроек, сети, файлов хочется все-таки разделить на более контролируемые части.
Немного оверинжиниринга для учебного проекта необходимо, чтобы показать, как это вообще работает в реальных проектах. Ещё бы это объяснялось, почему так надо или не надо делать, и какие есть ещё варианты.
По моему мнению, здесь рефакторинг скорее не удался, чем удался. Согласен лишь с тем, что глобальный доступ к ивентам и настройкам - плохая идея.
Сомневаюсь, что в ЕС вообще где-то проверяют это. На русско-финской границе вполне видели по паспорту, что мне был выдан пермит и даже конкретную дату выдачи (хотя физически по почте он ещё не дошел).
В моем случае, henkilökortti не получал и в банке не показывал, хватило вообще одного визита со справкой из migri о том, что заявление в процессе, и номером ID. Зато счёт открывали две недели. Многие из приехавших вообще не заморачиваются и не получают карту. Граждане могут ездить с ней по ЕС, а для остальных есть смысл получать только ради того, чтобы не таскать с собой паспорт.
Partial-класс выглядит для меня еще более неказисто. А методы-расширения можно раскидать по namespace (в стиле LINQ) или сборкам, отключать и подключать их в нужных местах. Например, namespace с компонентом Damage и соответствующими методами-расширения для Entity только в том месте, где оно используется, и не пролистывать десятки ненужных методов в автодополнении :)
Кажется, я понял. Меня покоробили широкий функционал в GameState и Entity, завязанный на конкретные классы. Entity заведует и своим ID, и получением своих компонентов, и всей их функциональностью (урон, здоровье, вот это всё). Да, удобно, не спорю, и кодогенерация.
Может, будет удобней добавлять эту функциональность в Entity через методы расширения? Их можно писать/генерировать где-нибудь рядом с компонентом и добавлять или удалять вместе с ним же.
Да, уже посмотрел ваш вариант, интересно.
Достаточно почитать ветку форума про ECS, где народ предлагает и реактивное UI, и физику на GPU, а работники Unity отвечают в стиле: «Да, мы думаем над этим», «Мы хотим сделать что-то похожее» и т.д. В общем, пытаются везде успеть.
P.S. Забавно, но в субботу меня пригласили пройти собеседование в вашу компанию :)
Очень хотелось бы интеграции в текущую КОП систему, или полную замену текущей системы «под капотом». Не думаю, что станут терять совместимость (может, через пару-другую лет). Насколько знаю, у них не настолько большая команда, чтобы делать форк и поддерживать две версии движка.
Показалось странным, что Entity умеет вообще всё. Как вы различаете функциональность, например, объекта игрока и какого-нибудь интерактивного объекта (пикабл, дверь и т.д.)? Ведь у них у всех есть и Health, и AddDamage, и весь набор всевозможных компонентов.
И GameState с кучей таблиц разномастных компонентов, наследующих IComponent. Не пробовали собрать их в одну структуру с доступом по типу и id?
Принцип "Если мне это не надо, значит никому не надо" в действии.
ScriptableObject - это префаб, только без трансформа. Делать из него игровые сущности так себе затея, но это отличный механизм для хранения настроек. Хранимый на сцене GameObject с параметрами может быть просто уничтожен, его трудно редактировать и переиспользовать.
MonoBehaviour по сравнению с POCO - оверхед на менеджмент GO, компонентов, времени жизни, плюс всякие подводные камни типа сравнения с null. Ну и иногда просто не хочется быть привязанным к UnityEngine.
Кстати, замена private SerializedField на public - плохая практика, если над проектом работает больше одного человека, чтобы всякие умники не меняли значения в рантайме.
MV* позволяет не держать в своей голове сразу всё. Можно собрать всю игру в одном классе, в этом нет ничего плохого. Но в какой-то момент игра разрастается до такого состояния, что менеджмент UI, настроек, сети, файлов хочется все-таки разделить на более контролируемые части.
Немного оверинжиниринга для учебного проекта необходимо, чтобы показать, как это вообще работает в реальных проектах. Ещё бы это объяснялось, почему так надо или не надо делать, и какие есть ещё варианты.
По моему мнению, здесь рефакторинг скорее не удался, чем удался. Согласен лишь с тем, что глобальный доступ к ивентам и настройкам - плохая идея.
https://habr.com/en/company/otus/blog/556784/
https://habr.com/en/company/otus/blog/557832/
Зачем писать что-то новое, когда можно раз в неделю копипастить одно и то же
4 недели, после года работы на одном месте — 5. Но слышал, что можно договориться на 5 недель сразу.
Думаю, что тут про принцип "composition over inheritance"
Они их цепляют по мере надобности. В составе может ходить от одной до трех электричек в зависимости от загруженности.
Сомневаюсь, что в ЕС вообще где-то проверяют это. На русско-финской границе вполне видели по паспорту, что мне был выдан пермит и даже конкретную дату выдачи (хотя физически по почте он ещё не дошел).
Вот not for travel именно потому что не гражданин
В моем случае, henkilökortti не получал и в банке не показывал, хватило вообще одного визита со справкой из migri о том, что заявление в процессе, и номером ID. Зато счёт открывали две недели. Многие из приехавших вообще не заморачиваются и не получают карту. Граждане могут ездить с ней по ЕС, а для остальных есть смысл получать только ради того, чтобы не таскать с собой паспорт.
И 5 лет ждать не надо: https://www.playground.ru/blogs/fortnite_battle_royale/deti_uznayut_kianu_rivza_tolko_kak_chuvaka_iz_fortnite-353564
Может, будет удобней добавлять эту функциональность в Entity через методы расширения? Их можно писать/генерировать где-нибудь рядом с компонентом и добавлять или удалять вместе с ним же.
Достаточно почитать ветку форума про ECS, где народ предлагает и реактивное UI, и физику на GPU, а работники Unity отвечают в стиле: «Да, мы думаем над этим», «Мы хотим сделать что-то похожее» и т.д. В общем, пытаются везде успеть.
P.S. Забавно, но в субботу меня пригласили пройти собеседование в вашу компанию :)
И GameState с кучей таблиц разномастных компонентов, наследующих IComponent. Не пробовали собрать их в одну структуру с доступом по типу и id?