Сколько нужно интерфейсов столько и нужно создавать. Не знаю насколько у вас большой проект, но в моем где-то на 50к строк кода интерфейсов всего пара десятков. И строки использовать это вообще вернейший способ выстрелить себе в ногу.
ECS навязывает очень определенный подход к архитектуре, который подходит к некоторым видам игр вроде RTS, но плохо подходит ко всему остальному. Вот про иерархические структуры например хорошо сказано, а они в более-менее крупной игре составляют большую часть игровой логики. То что подсистемы друг о друге не знают, это не так уж и хорошо, потому что придется продумывать комплексную логику их взаимодействия, чтобы это потом не развалилось. Ну да, в теории на простых примерах можно легко добавлять и удалять разные подсистемы, но в реальной разработке все опять окажется завязано друг на друга, только теперь еще с неявной логикой взаимодействия. На мой взгляд ECS подход можно использовать только в целях оптимизации и только для некоторых критичных подсистем, а не для всей логики.
Вопрос в том, как можно стать айтишником не зная английского языка? Вся документация на английском, все туториалы на английском, люди которые могут подсказать часто тоже англоговорящие.
А почему на сеньора дают такое относительно простое тестовое задание? Хотя тестовое и должно быть не очень сложным, но зачем его вообще дают на синьорскую вакансию? Разве не предполагается, что он уже должен уметь такие вещи?
Я думал там смотрят исключительно на подтвержденный опыт работы.
Вот я не так давно установил себе четыре импланта, притом для трех из них зубы пришлось удалить. Они конечно были в плохом состоянии, почти без коронковой части, но сейчас думаю - нельзя ли было их спасти все таки. И даже не потому, что жалко денег на имплант, а потому что родные зубы во рту приятней. И главное теперь уже никто не скажет, можно или нельзя было.
Что вообще должен давать ECS подход в сравнении с классическим? У стека DOTS юнити есть хотя бы нативная поддержка многопоточности и других оптимизаций, а что есть у third-party фреймворков?
Для отладки проекта важно знать, что и куда инжектится. Кроме того, так гораздо легче понимать какие части проекта зависят от других частей.
В случае с DI зависимости остаются те же самые, только теперь в неявном виде.
И не очень понял про поиск по использованию, в случае с zenject вроде как раз нельзя ничего найти таким образом.
Все что инжектится через Zenject невозможно отследить по зависимостям, потому что там нет прямых вызовов. Поэтому разобраться что куда и откуда попадает практически нереально.
Я думал что вся идея с атласами нужна для уменьшения числа батчей, а не оптимизации памяти? По идее, атласы то должны как раз занимать в целом больше памяти, за счет пустого пространства, разве нет?
А можно узнать зачем вам там вообще эти оптимизации? Я играл в вашу игру и на мой взгляд она и так не должна особо тормозить. Персонажей на экране обычно не очень много, а всякие монстрики скорей всего уже и так одним мешем сделаны.
Вот за это я и не люблю Zenject, он вносит кучу неявной логики в проект, как и бай дезайн, так и вот такими вот глюками.
Тут, конечно, это косяк не самого зенжекта, а юнити, но сам факт того что пришлось лезть в кишки чужой либы, чтобы разбираться с проблемой уже отталкивает.
Сколько нужно интерфейсов столько и нужно создавать. Не знаю насколько у вас большой проект, но в моем где-то на 50к строк кода интерфейсов всего пара десятков.
И строки использовать это вообще вернейший способ выстрелить себе в ногу.
У меня только вопрос - где механика с большим Г образным Enter, блин? Последняя такая клава, про которую знаю это Steelseries 6gv2
ECS навязывает очень определенный подход к архитектуре, который подходит к некоторым видам игр вроде RTS, но плохо подходит ко всему остальному.
Вот про иерархические структуры например хорошо сказано, а они в более-менее крупной игре составляют большую часть игровой логики.
То что подсистемы друг о друге не знают, это не так уж и хорошо, потому что придется продумывать комплексную логику их взаимодействия, чтобы это потом не развалилось.
Ну да, в теории на простых примерах можно легко добавлять и удалять разные подсистемы, но в реальной разработке все опять окажется завязано друг на друга, только теперь еще с неявной логикой взаимодействия.
На мой взгляд ECS подход можно использовать только в целях оптимизации и только для некоторых критичных подсистем, а не для всей логики.
Как раз благодаря слабой связности непонятно, что происходит. Плюс ECS всегда создает большое количество бойлерплейт кода.
Все таки ECS делает всю игровую логику в несколько раз сложней для понимания
Я не хочу говорить на японском, мне это не нужно, мне нужно читать.
Что-то не очень похоже на мидловские вопросы, больше похоже на базовый уровень владения движком
Вопрос в том, как можно стать айтишником не зная английского языка? Вся документация на английском, все туториалы на английском, люди которые могут подсказать часто тоже англоговорящие.
А почему на сеньора дают такое относительно простое тестовое задание? Хотя тестовое и должно быть не очень сложным, но зачем его вообще дают на синьорскую вакансию? Разве не предполагается, что он уже должен уметь такие вещи?
Я думал там смотрят исключительно на подтвержденный опыт работы.
Вот я не так давно установил себе четыре импланта, притом для трех из них зубы пришлось удалить. Они конечно были в плохом состоянии, почти без коронковой части, но сейчас думаю - нельзя ли было их спасти все таки. И даже не потому, что жалко денег на имплант, а потому что родные зубы во рту приятней. И главное теперь уже никто не скажет, можно или нельзя было.
В случае с DI зависимости остаются те же самые, только теперь в неявном виде.
И не очень понял про поиск по использованию, в случае с zenject вроде как раз нельзя ничего найти таким образом.
Но вашу статью я тоже прочитал с большим интересом.
Тут, конечно, это косяк не самого зенжекта, а юнити, но сам факт того что пришлось лезть в кишки чужой либы, чтобы разбираться с проблемой уже отталкивает.
Статик классы вполне себе нормально работают, ведь всегда легче подтянуть статик метод чем каждый раз создавать инстанс нужного класса.
Все таки энтерпрайзная жава и игровые проекты это разные вещи