Вопрос-ответ

Попробуем новый формат, чтобы в одном посте отвечать на несколько вопросов. А то мой завал предполагается до середины апреля (что я даже дайджесты не пишу, так как новостей не так уж и много, но я обязательно к ним вернусь!) Итак, поехали.

Можешь рассказать больше про карьеру технического художника и сравнить ее с разработчиком? Особенно интересуют следующие критерии: кто может из них может заработать больше денег и каким образом, какие знания и опыт более важны для инди команды и самое главное, как впечатлить девушку на свидании, если ты технический художник?)

Сильно тут не подскажу, так как это скорее нужно спрашивать у тех. артов. Я всё же в первую очередь именно разработчик, а сейчас вообще технический продюсер. По найму со своей стороны и деталям. Тех. арты конечно дороже. Но тут есть две причины. Первое, их экспертиза действительно сложная, так как это стык инженера и художника. Второе, она нужна в некотором смысле реже. VFX не все себе могут позволить, он не всем проектам нужен сложный и его не всегда в проекте много. Поэтому тут нет такого простого ответа. Инди команды — это такое широкое понятие, что там тоже ответят. Некоторые инди дадут фору многим конторам называющим себя компаниями. Ну девушку впечатлить красивыми эффектами конечно же можно, но это только для избранных девушек :)

Какие существуют 'Best Practice' для снятия телеметрии игроков и аналитики по производительности в Unity (ReleaseBuild, без участия редактора)? Особенно интересуют с прицелом на PC (Steam) и Nintendo.

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

Здравствуйте Григорий. Есть несколько тогглов (Toggle) по нажатиям на которые стартуют разные команды: рисования, редактирования 3д объектов. Тогглы в разных группах. Комманду можно прервать по нажатию Esc на клавиатуре - в этом случае нужно обновить статус тоггла, который был нажат. Какая архитектура должна быть, чтобы обновлять статус тогглов (isOn, true/false)? Я сделал статический класс с текущим тогглом и отжимаю его если стартует новая команда или пользователь нажимает Эскейп, но это какой-то костыль.

Да, это какой-то костыль. Задача решается вроде бы просто обсервером. Статический центральный ивентбас, который оповещает о нажатии кнопки интерфейс — это странно. В базовой архитектуре у нас интерфейс всегда отображает состояние модели. Новички обычно в апдейте модель опрашивают, а уже более прошаренные в таких случаях пишут обсервер на изменение модели. Аналог реактив проперти, систему событий и т.п. Так как нет разницы какой источник изменения состояния. Модель по команде ESC изменилась, а может по событию сервера. Суть в том, что изменилось состояние модели игры, соответственно у нас идёт оповещение всего View (а это гуй, модели и так далее) и он меняется в соответствии.

Как перестать писать весь код на монобехах? Или это нормальная практика?

В среднем что нормально, а что нет зависит от проекта и контекста. Меня смущает когда в монобехах классы модели. Ну уж если писать в совсем Unity-way хотя бы Scriptable Object, хотя это тоже не хорошо. Так как Scriptable Object можно воспринимать как репозиторий данных, ну или базу данных и т.п. Это механизм их хранения через юнити сериализацию в качестве статического решения. А модель должна существовать отдельно, так как завтра мы захотим хранить это на сервере в виде json и так далее.

Код должен быть простым и логичным. Я видел и обратную сторону медали, когда люди выносили контроллеры из монобехов и прокидывали события Update через центральный менеджер. Ну повеситься в execution order без регистрации и переплат, чтобы сэкономить пару спичек дело конечно достойное, но мне непонятное. Хотя если кому-то удобно, то на всякий случай не осуждаю. Просто для меня подобное лишняя конструкция ни за чем.