Davilkus Games

Можно

using System;
using System.Collections.Generic;
using System.Linq;
using Microsoft.CSharp;
using System.CodeDom.Compiler;

class Program
{
    static void Main(string[] args)
    {
        var csc = new CSharpCodeProvider(new Dictionary<string, string>() { { "CompilerVersion", "v3.5" } });
        var parameters = new CompilerParameters(new[] { "mscorlib.dll", "System.Core.dll" }, "foo.exe", true);
        parameters.GenerateExecutable = true;
        CompilerResults results = csc.CompileAssemblyFromSource(parameters,
        @"using System.Linq;
            class Program {
              public static void Main(string[] args) {
                var q = from i in Enumerable.Range(1,100)
                          where i % 2 == 0
                          select i;
              }
            }");
        results.Errors.Cast<CompilerError>().ToList().ForEach(error => Console.WriteLine(error.ErrorText));
        Assembly assembly = results.CompiledAssembly;
        Type program = assembly.GetType("Program");
        MethodInfo main = program.GetMethod("Main");
        main.Invoke(null, null);
    }
}

Это разве не оно - https://docs.unity3d.com/Manual/nav-CreateOffMeshL...

Укрытие, вместе с точками, можно сразу засунуть в префаб.
В зависимости от расстояния до игрока, для юнита может быть предпочтительная дальность перехода до укрытия. При виде игрока, юнит решает, бей или беги, в случае бега, определяет укрытия в радиусе предпочтительной дальности перехода, и спрашивает их, подходят ли они, чтоб прятаться от игрока, который там. Получив ответы, сравнивает и по дальности, типу укрытия и углу укрытия, определяет куда лучше бежать.
В зависимости от того, 1 он или нет, выбирает подходящие действия: кинуть гранату, стрелять(в слепую или нет), скрываться, менять позицию, опять же, всё это в зависимости от расстояния до игрока и возможно его оружия. В зависимости от расстановки укрытий. можно даже ставить ловушки.
Опять же в зависимости от типа врага, меняются предпочтения, тяжёлой бронированной пехоте, не интересны укрытия, ближники, либо перебегают из укрытия в укрытие, чем ближе тем меньше предпочтительное расстояние, могут пытаться обойти, перебегать когда игрок не видит и тд... Либо укуренные, бегут по прямой.
Юниты должны стараться занять предпочтительную позицию, для своей роли, если юнит с дробовиком но на большом расстоянии, он может сменить роль и вести огонь на подавление или затаиться.

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

UPD: установите\переустановить в сборке android skd. Можете также проверить путь в Unity>Preferences.

Нет, установка Генту делает из вас хорошего копипастера мануалов.
Источник: личный опыт.

Нет, не стоит.
Вы тупо будете слушать, как картавый мычащий Васян пересказывает какой-нибудь learnjavascript, пропуская половину тем, которые сам не понимает.
И таких видео - 90%.

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

У тебя должна быть:
1. система описания и хранения пакетов дополнений/модификаций, с учетом их версий и взаимозависимостей
уже на этом этапе готовое это что то типа пакетного менеджера из мира linux (dpkg apt или rpm, ими все не заканичивается пакетных менеджеров сотни в мире) именно они предлагают полную и готовую инфраструктуру по всем параметрам, осторожно с лицензиями, там могут быть GPL а не LPGL, что ограничит использование в проприетарных проектах.
Помимо просто функции добавить пакет+версия, тут должна быть функция отзыва.. попробуй реализуй когда у пакета зависимости
2. система раздачи и загрузки файлов
настоятельно рекомендую не изобретать ничего нового, если размер пакетов маленький (сотни мегабайтов максимум) то хватит просто http протокола, статики на веб сервере (именно его используют вышеописанные пакетные менеджеры)
Если файлы большие, то сам бог велел использовать torrent протокол, на сервере достаточно минимального трекера и так же http веб сервер со статикой, на клиенте - libtorrent с поддержкой webtorrent (последние версии) и опционально запущенный торент клиент, для минимальной поддержки dht (в этом случае не потребуется раздавать torrent файлы, хватит просто magnet ссылки, но обычно это уже не важно)
В этом случае можно сильно (от слово много) сэкономить денег на поддержке серверов, так как после нескольких сотен клиентов, загружающих единомоментно гигабайты контента (сами гигабайты не дорогие, проблема раздать сразу много), опустошаются даже богатые кошельки.
3. система контроля за целостностью файлов клиента
это вообще адовый ад, готовых инструментов чтобы все в вместе - нет
по отдельности да, например готовые античит (за много денег)
Решение тесно переплетается с собственно системой установки файлов (каждый пакет контролирует свой список файлов, какие то модифицирует, какие то заменяет, контролировать конфликты зависимостей (даже linux-пакетные менеджеры это делают с помощью клиента, но тут вопрос больше к тому как организуешь саму базу и как ее будешь тестировать, пользователи иногда ну очень странные вещи хотят, например фиксируют старые версии отдельных пакетов)

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

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

Если объектов на сцене немного, то практического смысла от occlusion culling тоже мало. Если это не так, то вы получите хороший прирост производительности. Что касается рейкаста, то occlusion culling можно применять, если объекты на заднем плане точно не будут являться raycast target. Если нет такой уверенности - использовать occlusion culling не стоит. В таком случае есть смысл избавиться от рейкастов в пользу менее нагруженных решений т.к. сами по себе рейкасты тоже несут немалую нагрузку.

microsoft visual studio, среда разработки, фреймворк и пакет языков c# (плюс managed c плюс vb# и т.п.), мощный комбаин, которого по уму будет достаточно для создания приложения люббого типа, от клиент-серверных до десктопных и мбоильных

... но с привязкой к экосистеме майкрософт (операционки и сервера), где то можно поступившись с удобствами использовать открытые альтернативы, где то нет.

Мое мнение, если у тебя цель, писать много формочек для работы с данными (базы данных например) или управление параметрами запуска других приложений , то лучше майкрософтовских winforms или wfp не найти.... очень легкий старт, очень много можно сделать из интерфейса с помощью мышки и готовых мастеров (например подключить базу данных, загрузить структуру таблиц, настроить связи с элементами интерфейса и максимум где будет код писаться - это обработка граничных случаев типа нули).

Если будешь использовать в Update - сильно. Если будешь использовать в Start (т.е. кешируя) - приемлимо.
Чем больше объектов на сцене - тем дольше выполняется метод.

Есть более оптимальный способ. Почитай про паттерн Service-Locator. На первое время хватит.

https://docs.microsoft.com/ru-ru/dotnet/csharp/lan...
var - говорит "дальше будет переменная", а тип переменной уже определяет компилятор.
В вашем, конкретном, примере понятно, что обе переменные - double из правой части присваивания.