Даниил Басманов

У тайлов нет стандартных размеров, какие пропорции нужны для художественного стиля, такие и берутся. Иногда берут числа кратные степеням двойки для оптимизации, но и это не обязательно.

Для работы с тайлами вам нужно либо взять бету 2017.2, либо скачать плагин из магазина, руками расстанавливать тайлы очень неудобно, замучаетесь с позиционированием и заделкой щелей. Тайлы разного размера в одной игре редко делают, но если уж так вышло, то можно их разнести по разным слоям, главное, чтобы оба набора можно было уложить в сетку одной размерности.

Потому что порог вхождения очень низкий и любой рукожопый разработчик может дотащить свою игру до магазина. Сам движок ни в чём не виноват кроме доступности, средств для оптимизации предостаточно: встроенный профайлер, внешние профайлеры, Frame Debugger, RenderDoc и т. п.

Нагружает движок всё, что есть в игре. Если оно сделано неаккуратно или из рук вон плохо, то и результат будет соответствующий. Решается это построением правильного производственного процесса и регулярным тестированием и профилированием. Если в план разработки изначально не заложена фаза тестирования и полировки, то потом, скорее всего, на неё уже не останется ресурсов. Кроме того, некоторые оптимизации требуют изменения подхода к разработке и на полуготовой игре их уже не применить. Многие студии находятся под влиянием "людей с деньгами", которые ожидают увидеть результат в кратчайшие сроки, а процесс оптимизации видимых результатов практически не даёт, и, если игра большую часть времени нормально играется, то на всё остальное закрывают глаза. Кроме того, тормоза и баги редко сильно влияют на продажи.

Что касается того, как оптимизировать игры на юнити, про это есть куча разделов в мануале, даже есть официальный туториал. В основном всё сводится к запуску профайлера и фрейм дебаггера и анализу циферок.

Blizzard недавно выпустили инструменты для программирования ботов для StarCraft, но, вообще говоря, это cкорее исключение из правил. Делать игры само по себе сложно, а поддерживать внешнее API только для того, чтобы с ним поигрались два-три программиста, не очень выгодно. Конечно, бывают игры чисто про программирование, например CodeCombat , их достаточно много, на Steam даже есть специальный раздел, но в них обычно боты дерутся с ботами. Ещё как вариант можете поискать игры с открытым исходным кодом, например Quake или Doom.

Билды под линукс не очень стабильные, поэтому распространяются через форум.
https://forum.unity3d.com/threads/unity-on-linux-r...

Это баг юнити, они поменяли процесс проверки лицензии, и после апгрейда до 2017 не у всех корректно обновляются файлы движка. Кому-то помогает перелогинивание в юнитёвый аккаунт, кому-то нет. Ещё можете попробовать удалить файлы как описано здесь. У меня после пары переустановок пропало.

GUI.Button это старый и медленный способ, никто им не пользуется, вам нужен Canvas, можете начать с официального туториала. Для "если нажали на спрайт" существует специальный компонент Button.

Вы неправильно понимаете суть классов и компонентов, внимательно почитайте документацию. GameObject это не компонент, с помощью каста в другой класс нельзя магическим образом достать из него компонент, для этого существует специальный метод GameObject.GetComponent. Кроме того, в вашем случае конструкцию с FindGameObjectWithTag можно заменить вызовом Camera.main, результат будет такой же. Это не очень хорошая практика в контексте камер, но это уж вам решать. Что касаемо второй ошибки, она случается из-за того, что в вашем старте в первой строчке вызывается исключение, что обрывает поток метода, и все последующие строчки не вызываются, поэтому camera2 остаётся null.

Вам нужен движок, который умеет делать сборку для WebGL. Самые развитые трёхмерные движки сейчас это Unity и Unreal, с коллизиями там всё замечательно, документации и туториалов полно. Если веб вам ближе, то можете поискать чисто браузерные движки, но возни с ними будет больше.

Со стороны редактора - как вам удобнее, так и делайте. Со стороны движка есть разница в производительности и скорости интеграции. Если моделька цельная, то и в видеокарту она отправится целиком, если она разбита на куски, то каждый кусок будет рисоваться отдельной операцией. Если кусочки достаточно маленького размера, то есть шанс, что их склеит динамическим батчингом, но тогда встаёт вопрос, а на кой чёрт было разбивать модельку на куски, чтобы потом тратить время процессора на склейку обратно. Помимо производительности нужно ещё помнить про стоимость интеграции моделек в движок, если в модельке сто кусочков и сто материалов, то настраивать её внешний вид будет гораздо сложнее, чем один кусок с одним материалом. В целом, если со стороны движка не нужны отдельные подвижные части, то и не надо их экспортировать, а вот как у вас в редакторе всё будет, это уже от вашего рабочего процесса зависит.

Так работает ортографическая камера, если сильно приблизиться к объектам в сцене, то их начнёт отрезать ближней плоскостью камеры. Если переключить камеру сцены из двадэшного режима в тридэшный, то станет понятнее. Не очень очевидное поведение, но так уж есть. Для фокусировки на объектах можете использовать горячую клавишу F, либо двойной клик по объекту.