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

Вам нужен Root Motion, в мануале про это есть статья. Ещё можете поискать презентации на их канале, не так давно было несколько для GDC. Инверсная кинематика нужна для правильной постановки стопы на землю, на скорость движения она не влияет.

Вариантов несколько:

1. Качаете картинку с помощью WWW (или UnityWebRequest) и достаёте текстуру с помощью WWW.LoadImageIntoTexture. Неархивированные картинки могут долго грузиться, но, если их у вас не очень много, это может быть самым простым вариантом.
   
2. Качаете зазипованную картинку, берёте чистые байты напрямую из WWW.bytes, разархивируете с помощью плагина (например этого), потом грузите в текстуру с помощью ImageConversion.LoadImage. Нужно быть аккуратным во время процесса скачивания-разархивирования, чтобы не держать одновременно в памяти слишком много копий картинки в разных форматах, но, в целом, это самый гибкий и удобный вариант.
   
3. Собираете AssetBundle, качаете с помощью UnityWebRequest.GetAssetBundle, достаёте текстуру с помощью AssetBundle.LoadAsset, выгружаете бандл с помощью AssetBundle.Unload. Для картинок бандлы не очень подходят, их неудобно собирать и для каждой платформы нужно собирать свой бандл. AssetBundle Manager может немного помочь, но на сервере, например, их автоматически просто так не соберёшь. С другой стороны, бандлы поддерживают версионность из коробки, и в новых версиях юнити появились новые форматы сжатия. Я бандлы для картинок давно не пробовал, возможно, процесс распаковки занимает меньше места в памяти по с равнению с зипом.
   

Без материалов вы ничего запечь не сможете, материалы нужны для отображения меша, в шейдере лайтмапы могут вообще не использоваться. Что касаемо самого запекания, вторая ошибка вам говорит о том, что в вашей модельке нету uv-канала. Если нет основного канала, то и генерировать uv2 для лайтмапов неоткуда. Эта опция существует для тех случаев, когда вам для тектурирования модели и лайтмапов не нужны разные uv-карты. Если бы, например, вы хотели в каком-то месте подправить тени, то тогда вы могли бы сделать специальную развёртку и использовать её для лайтмапов. Судя по вашему вопросу, текстуры вам не особенно нужны, иначе вы бы давно поняли в чём проблема, поэтому могу посоветовать плагин ProBuilder для моделирования прямо в редакторе, он генерирует все нужные развёртки автоматически.

1. Для статус-бара раньше была настройка в PlayerSettings, но она теперь не работает под андроид, вам нужно либо править манифест, либо писать плагин. Чтобы показать панель навигации нужно Screen.fullScreen выставить в false.
2. Для определения размера клавиатуры можно использовать TouchScreenKeyboard.area, как конкретно вы будете сдвигать интерфейс зависит от вашей реализации.
3. Лишнее поле ввода можно спрятать с помощью TouchScreenKeyboard.hideInput.

Хреново искали, на официальном сайте есть ссылка на все поддерживаемые движки

Оттуда можно перейти на GitHub, где есть все нужные инструкции.

В первую очередь советую вам узнать побольше про виртуальную реальность, начать можете с Oculus Best Practices, ещё рекомендую посмотреть презентации с GDC.
Касаемо конкретной реализации в юнити, в качестве простого решения можете попробовать прилепить индикатор здоровья на уровне пояса где-нибудь в полуметре от игрока, просто вставьте Canvas в режиме World Space в корень иерархии и повесьте скрипт, который будет поворачивать канвас так, чтобы он всегда был перед игроком.

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

Делать нужно так:

private List<Enemy> enemies = new List<Enemy>();

private void DestroyEnemy(Enemy enemy)
{
    enemies.Remove(enemy);
    Destroy(enemy.gameObject);
}

Если сначала уничтожать gameObject, а потом пытаться выкинуть из списка, то может случиться нулреф из-за того, что компонент уже уничтожен.

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

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

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

Второй андроид уже много лет как не поддерживается, четвёртому тоже уже седьмой год пошёл, но он ещё не так давно работал. В настройках плеера есть пункт "Minimum API Level", возьмите версию юнити постарше и поменяйте настройку.

Вы наверное хотели использовать Quaternion.LookRotation, правильнее будет так:

Instantiate(currentProjectille, transform.position, Quaternion.LookRotation(transform.position + direction));

В качестве простого решения, можете подвинуть пивот вниз у спрайтов игрока и врагов в Sprite Editor, тогда при сравнении положение по оси игрек будет не так сильно различаться.

EventTrigger перехватывает все события, поэтому они не попадают в ScrollRect. Если хотите подписаться на какое-то событие, то нужно делать специальный класс и наследоваться от конкретного интерфейса, например IPointerDownHandler.

1. Сделайте два списка: список активных блоков и список неактивных. Когда блок уходит за экран, деактивируйте его и переносите из списка активных в список неактивных, а когда нужен новый блок, делайте наоборот. Для пула неактивных объектов лучше использовать очередь, чтобы "дать остыть" выключенным объектам, не все юнитёвые компоненты дружат с быстрым включением-выключением. Если при включении-выключении есть заметная задержка, то можете заменить его на телепортацию объектов куда-нибудь подальше, где их не видно, либо можете выключать только рендереры и аудио-источники.

2. Можно, просто объявляете тип переменной как List<GameObject>[], но, скорее всего, удобнее будет работать с List<List<GameObject>>. Если и так не удобно, то можете сделать класс-обёртку и будет у вас что-нибудь вроде List<Pool>.

Если использовать ScreenCapture.CaptureScreenshot, то сложнее управлять процессом съёмки, в кадр могут попасть лишние слои, будут фризы при загрузке картинки обратно с диска, больше потребление памяти. Правильнее всего делать это с помощью Camera.Render и RenderTexture, при такой схеме можно включать/выключать постэффекты, проще управлять разрешением скриншота и отображать превью в интерфейсе. В нужный момент просто создаёте рендер-текстуру, втыкаете её в Camera.targetTexture, вызываете Render и возвращаете старое значение targetTexture. Всё, после этого у вас есть текстура, которую можно вывести на экран с помощью компонента RawImage.

Чтобы сохранить текстуру на диск, её нужно сначала сконвертировать в Texture2D с помощью Texture2D.ReadPixels, а потом закодировать в нужный формат вызвав ImageConversion.EncodeToPNG или ImageConversion.EncodeToJPG. Из коробки Unity умеет сохранять картинки на мобилках только в Application.persistentDataPath, для доступа к галерее нужен плагин, в AssetStore их полно, некоторые умеют даже сохранять сразу рендер-текстуру.

Unity ничего не выбирает, редактор про гит ничего не знает. После автоматического мерджа в гите у вас просто разламываются файлы, а юнити с этим живёт как может. Такие проблемы решаются либо грамотной организацией работы с общими файлами, либо с помощью stash и ручного разрешения конфликтов. Почитайте про гит здесь и здесь.

Папка StramingAssets вшивается в приложение, если вы в редакторе что-то туда положили, оно будет доступно в рантайме.
Во-первых, вы уверены, что у вас на телефоне pdf нормально открывается? Попробуйте открыть его руками.
Во-вторых, попробуйте вывести в консоль путь, по которому вы пытаетесь открыть файл, может быть он у вас неправильно склеился. Если это так, то попробуйте использовать вместо плюса Path.Combine.

Исходить нужно из доступных ресурсов и желаемой стилистики. Если можете моделить и анимировать, то делайте всё трёхмерное, скорость итерации будет выше, работать с освещением будет проще, не нужно будет пересобирать атласы, меньше требования по памяти. С другой стороны, если вы умеете рисовать не хуже художников The Banner Saga, то вам выгоднее будет делать всё двухмерное. Насчёт ресурсов мобильников я бы не особо думал, в обоих случаях придётся делать тонну оптимизаций, просто с двухмерной графикой бюджет будет чуть побольше.