6к строк это еще немного. Я работал в проекте написанном 6 "сеньорами", в котором классы по 10к строк являлись нормой, а 6к любой средний "контроллер" или "менеджер" занимал. На любые аргументы ответ один: Проект зарабатывает, значит у нас все правильно.
Примерно так и пишу систему сохранений, как описано в статье. Всегда думал, что я просто слабый разработчик, а остальные пишут гениальные системы сохранения. Приятно видеть, что я не один такой слабый разработчик.
Всякие ассеты со стора мне всегда казались неуклюжими навороченными монстрами, которые в итоге приносили больше проблем, чеи пользы.
Продукты Paradox на удивление хороши. Использую NodeCanvas только в прокте для реализации системы решений NPC, и меня удивляет насколько качественно и визуально красиво сделан NodeCanvas. Спасибо за статью, весьма дельное описание темы.
Empty — костыль сцена для 100% выгрузки всех ресурсов предыдущей сцены.
Черт, я делал так же и думал что это настолько отвратительный костыль, что все используют гораздо более лучшее решение
По многим пунктам пришел к плюс-минус таким же мыслям. Всегда занятно видеть как другой человек приходит у примерно таким же выводам, как и ты. Пора в лиды значит топать :)
Нет никаких проблем с ходом инициализации приложения. Bootstrap + StateMachine для контроля цикла жизни приложения решают все проблемы. Во всяком случае я себе не могу представить когда это могло бы не хватить
Кому мешает "лишний" функционал Zenject, берет VContainer. О каком не малом времени идет речь на изучение? Любой мало-мальски нормальный разработчик через пару часов с докой поймет основные принципы. Только недавно решил в новом проекте использовать VContainer, и через пару часов с докой я понял практически все, что мне надо на данный момент. Плюс изучив в одной фирме Zenject или VContainer, я смогу применять эти знания в любой другой. Кастомный же велосипед при переходе в другую команду это просто мусорные знания.
Вы пишите что все эти ITickable лишние, но при этом сами же вводите IUpdateListener. Так может не такие уж они лишние?
Короче, очередная кастомная архитектура, которая не нужна.
VContainer ни капли не менее User Friendly на мой взгляд. И на мой взгляд, прежде чем делать кастомную архитектуру, нужно собраться командой и очень хорошо ответить на вопрос, почему не использовать Zenject или VContainer. И только после того, как ответ будет дан, причем не шаблонными ответами из интернета, а действительно из опыта разработчиков, которые имели опыт с вышеперечисленными решениями, приступать к разработке своего решения. Потому что кастомное решение это всегда время на поддержку и разработку, сложности с интеграцией новых членов команды и, будем откровенны, зачастую просто хотелка коллектива поиграть в архитекторов.
А можно не заниматься ерундной, взять готовый контейнер и на этом успокоиться. Долго сам использовал сервис-локатор самописный, пока не взял Zenject. После этого понял, что пока у вас нет конкретной причины отказаться от готового DI-Container'a, делать этого не надо.
Это методы, которые движок Unity вызывает сам. Очень грубо говоря, при наличии такого метода в классе, отнаследованном от Monobehaviour, движок занесет его в свой список "исполнять каждый кадр", и каждый кадр будет вызывать этот метод. Unity предоставляет целый набор таких методов с разной функциональностью.
Четыре года назад ровно ушел из ремонта электроники, потому что для меня тенденция упрощения устройства до «засунем все в одну микросхему» стала очевидной. Перешел как раз в программисты. Жалко было опыт накопленный, да и нравилось мне ремонтить, особенно видеокарты, но что поделать.
Ах, какие же все таки милые эти люди, которые всех гребут под свою гребенку. Вам отлично читается со смартфона? Пожалуйста, читайте. У меня при чтении с чего-либо размером меньше 10 дюймов невероятно сильно устают глаза. Поэтому при возможности я всегда буду читать бумажный вариант книги. И в 2018, и в 2218, если доживу.
6к строк это еще немного. Я работал в проекте написанном 6 "сеньорами", в котором классы по 10к строк являлись нормой, а 6к любой средний "контроллер" или "менеджер" занимал. На любые аргументы ответ один: Проект зарабатывает, значит у нас все правильно.
Примерно так и пишу систему сохранений, как описано в статье. Всегда думал, что я просто слабый разработчик, а остальные пишут гениальные системы сохранения. Приятно видеть, что я не один такой слабый разработчик.
Всякие ассеты со стора мне всегда казались неуклюжими навороченными монстрами, которые в итоге приносили больше проблем, чеи пользы.
Продукты Paradox на удивление хороши. Использую NodeCanvas только в прокте для реализации системы решений NPC, и меня удивляет насколько качественно и визуально красиво сделан NodeCanvas. Спасибо за статью, весьма дельное описание темы.
То есть челики рендерят всегда зубы по 6к вершин, а виновата Unity? Классика. Не рукожопые разрабы, а плохой Unity!
Empty— костыль сцена для 100% выгрузки всех ресурсов предыдущей сцены.Черт, я делал так же и думал что это настолько отвратительный костыль, что все используют гораздо более лучшее решение
По многим пунктам пришел к плюс-минус таким же мыслям. Всегда занятно видеть как другой человек приходит у примерно таким же выводам, как и ты. Пора в лиды значит топать :)
Рад что ты пилишь таки свою РТС. Главное не забросить)
Нет никаких проблем с ходом инициализации приложения. Bootstrap + StateMachine для контроля цикла жизни приложения решают все проблемы. Во всяком случае я себе не могу представить когда это могло бы не хватить
Кому мешает "лишний" функционал Zenject, берет VContainer. О каком не малом времени идет речь на изучение? Любой мало-мальски нормальный разработчик через пару часов с докой поймет основные принципы. Только недавно решил в новом проекте использовать VContainer, и через пару часов с докой я понял практически все, что мне надо на данный момент. Плюс изучив в одной фирме Zenject или VContainer, я смогу применять эти знания в любой другой. Кастомный же велосипед при переходе в другую команду это просто мусорные знания.
Вы пишите что все эти ITickable лишние, но при этом сами же вводите IUpdateListener. Так может не такие уж они лишние?
Короче, очередная кастомная архитектура, которая не нужна.
Мало ли сколько GiftedMamba бродит по интернету.
VContainer ни капли не менее User Friendly на мой взгляд. И на мой взгляд, прежде чем делать кастомную архитектуру, нужно собраться командой и очень хорошо ответить на вопрос, почему не использовать Zenject или VContainer. И только после того, как ответ будет дан, причем не шаблонными ответами из интернета, а действительно из опыта разработчиков, которые имели опыт с вышеперечисленными решениями, приступать к разработке своего решения. Потому что кастомное решение это всегда время на поддержку и разработку, сложности с интеграцией новых членов команды и, будем откровенны, зачастую просто хотелка коллектива поиграть в архитекторов.
А можно не заниматься ерундной, взять готовый контейнер и на этом успокоиться. Долго сам использовал сервис-локатор самописный, пока не взял Zenject. После этого понял, что пока у вас нет конкретной причины отказаться от готового DI-Container'a, делать этого не надо.
Это методы, которые движок Unity вызывает сам. Очень грубо говоря, при наличии такого метода в классе, отнаследованном от Monobehaviour, движок занесет его в свой список "исполнять каждый кадр", и каждый кадр будет вызывать этот метод. Unity предоставляет целый набор таких методов с разной функциональностью.