Это верно, но если всё хорошо сделано, то степень свобод остается достаточной. Например, в юнити встроен physx в кач-ве физ движка, и не умея писать ни строки кода можно заставить объекты вести себя по физике. Но если тебе physx'a мало, и ты хочешь другой движок, который ещё и например симуляцию мягких тел поддерживает - всегда можно добавить такой движок (например bullet), или даже написать свой, но для этого понадобятся уже определенные технические скиллы.
Всё не учтешь, но засчет разнообразия инструментов, движков и прочего - можно покрыть очень большой спектр потребностей, и постоянно его расширять, так как другие разработчики постоянно пилят разные инструменты и продают. К тому же разработчикам тоже всё не выучить, жизни не хватит
Кодерам в геймдеве как раз в среднем платят меньше, чем другим кодерам (веб, мобайл, и прочее), и условия работы похуже. Это в среднем именно, так-то везде по разному
Энивей любая работа программиста всегда сводится к тому, чтобы просто реализовать какой-либо функционал, и человек который пишет код и геймдизайнер - в нормальном случае два совершенно разных человека с разными скиллсетами. И когда есть возможность, команды обычно как раз стараются сделать так, чтоб кодеры написали инструметарий для различных дизайнеров, а те там воплощали свои задумки и тестировали идеи
Так что снижение входного порога в виде отсутствия необходимости уметь писать код - это как раз очень хорошо, геймдизайнерам это всё равно даром не надо и слава богу
Да ничего не дико звучит
Правда в юнити вроде Transform.LookAt есть для конкретно той операции
Но в целом в юнити не так много упрощений для не-разработчиков, что вредит всем, в том числе разработчикам. Я прилично времени так тратил на написание вспомогательных скриптов для дизайнеров, потому что им в прототипировании чего-то базового не хватало
Дизайн локации - чисто Quixel?
Сижу на юнити несколько лет, указанные проблемы кажутся притянутыми за уши по большей части
1 - а) Насчет Camera.main ты прав, а вот взятие трансформов, ригидбоди и других встроенных в юнити компонентов работает быстрее, чем взятие своих компонентов. Возможно кэширование ещё быстрее, но там итак достаточно быстро, чтобы об этом не думать
1 - б) Find в самом обычном подходе заменяется синглтонами, а частый instantiate пулами объектов. Только почему-то о синглтонах большинство туториалов начальных молчит, сам не понимаю почему (да, они так себе, но в тысячу раз лучше, чем GameObject.Find
1 - в) Не сталкивался с такой проблемой, ничего не могу сказать
2) Никогда с этим проблем не было, дело вкуса?
3) Тоже проблем не было, не понял откуда взялись
4) Time.timeScale можно для простой паузы использовать, но соглашусь, что тут проблема, что нельзя таймскейл не глобально устанавливать, а насчет сохранений - непонятно что ожидалось. Я создаю свои врапперы для данных, которые сериализую в json, сохраняя на диске/сервере. Есть вроде ассеты, которые позволяют прям сцену целиком сериализовать, но это как-то совсем жестко по-моему. А для совсем простых и быстрых штук есть PlayerPrefs
Не согласен с мыслью, что гк это промежуточный этап для джуна
Да, зачастую они бывают простые, а джуну меньше платить, и качество кода там неважно, но нередко бывают такие гк, на которые у джуна просто не хватит скилла, особенно если проект активно построен вокруг шейдеров или процедурных частей например
Выше ещё автор написал про зп в гк, что тоже не распространяется на рынок в целом, в гк хорошие деньги можно получать (но джуны они везде в примерно указанной автором вилке и получают почти всегда)
Да, гк - отличный вариант для джунов, нет сложной архитектуры, командных взаимодействий, QA, легаси, да и кучи всего другого. Но это отличный вариант и не только для джунов