для рекламы и GooglePlay Instant для игр которые будут весить до 10 MB
А MonoBeh если и уйдут в историю году эдак в 2030 то к тому времени DOTS станет таким же удобным как сейчас MonoBeh
Я понимаю что эта статься это крик души и именно по этому многие тезисы недостаточно аргументированы. Просто субъективное часто неверное мнение автора :)
И именно про это и сказал. MVVM как раз за то чтобы именно так и делать (настраивать вызов в инспекторе) и не иметь зависимости кода от UI. Только контролируемо.
Стандартный инспектор юнити не дает никакого контроля и да лучше его не использовать.
У на для этого свой компонент который делает это верно (с нашей точки зрения :))
он дает вызывать только методы которые явно в коде отмечены аттрибутом [Callable]
Программисты явно выдают методы для вызова из UI и код не зависит от того есть там кнопка в том UI или нет и вообще где она и сколько их. И может то вообще не кнопка а чекбокс который вызывает метод на включении… то уже дело UI.
Неплохой набор моментов о которых стоит задуматься :)
Некоторые оч спорные это да, кажется некоторые хорошо ложатся на одиночную разработку и не подходят для студии :)
такие как этот:
Постарайтесь определить как можно больше в коде, а не полагаться на Unity Editor или предварительную сериализацию. Когда вам понадобится что-то рефакторить, наличие множества вещей, соединенных в единые YAML-файлы, добавит вам проблем. Используйте редактор, чтобы быстро найти хороший набор значений в рантайме, затем впишите его в код и удалите [SerializeField].
А этот вообще оч хорош:
Подумайте о моддинге на ранней стадии. Разложите начальную архитектуру проекта так, чтобы вы могли построить ядро игры в виде мода или набора модов. Игровой контент должен быть «мягкой» архитектурой, он должен легко модифицироваться.
Хотелось бы узнать у автора какая боль ему встретилась что он такое предлагает:
Никогда не подключайте кнопки пользовательского интерфейса к редактору Unity Editor. Вместо этого используйте onClick.AddListener из кода.
Я например тут полностью несогласен. Тут сильно лучше встроить какой нить MVVM фреймворк, если нету своего, и никогда не не делать код зависимым от UI. Только UI зависимый от кода.
Неверно
есть куча готовых встроенных способов это упростить до нескольких строк и можно свои сделать
IJobChunk нужен только если планируется оптимизация простого кода, а оптимизация всегда делает код менее простым но более шустрым
для рекламы и GooglePlay Instant
для игр которые будут весить до 10 MB
А MonoBeh если и уйдут в историю году эдак в 2030 то к тому времени DOTS станет таким же удобным как сейчас MonoBeh
Я понимаю что эта статься это крик души и именно по этому многие тезисы недостаточно аргументированы. Просто субъективное часто неверное мнение автора :)
И именно про это и сказал. MVVM как раз за то чтобы именно так и делать (настраивать вызов в инспекторе) и не иметь зависимости кода от UI. Только контролируемо.
Стандартный инспектор юнити не дает никакого контроля и да лучше его не использовать.
У на для этого свой компонент который делает это верно (с нашей точки зрения :))
он дает вызывать только методы которые явно в коде отмечены аттрибутом [Callable]
Программисты явно выдают методы для вызова из UI и код не зависит от того есть там кнопка в том UI или нет и вообще где она и сколько их. И может то вообще не кнопка а чекбокс который вызывает метод на включении… то уже дело UI.
Некоторые оч спорные это да, кажется некоторые хорошо ложатся на одиночную разработку и не подходят для студии :)
такие как этот:
А этот вообще оч хорош:
Хотелось бы узнать у автора какая боль ему встретилась что он такое предлагает:
Я например тут полностью несогласен. Тут сильно лучше встроить какой нить MVVM фреймворк, если нету своего, и никогда не не делать код зависимым от UI. Только UI зависимый от кода.