Алексей Павлов

В целом разрабатывать на Xamarin удобно.
1. Можно открыть книгу по разработке под Android на java и копипастить примеры оттуда с минимальными доработками, с учетом языка и xamarin'a
2. Сам язык C# более чем годен, очень активно развивается. Есть куча шарповых библиотек как платных так и бесплатных, как в репозитории пакетов так и на GitHub в виде исходников. Xamarin позволяет подцеплять нативные либы на java, если чего-то не хватает.
3. Есть "нативный" Xamarin (Xamarin.Android, Xamarin.iOs и т.д.) - это обёртка над нативными API, UI делается привычным для нативных разработчиков способом. Есть Xamarin.Forms - там можно делать единый UI с помощью XAML. Инструмент более чем работающий, но нужно к нему привыкнуть, знать минусы, знать особенности платформ под которые разрабатывается приложение, знать что Xamarin Forms можно использовать не для всех приложений, знать как делать быстрый UI. XF - в целом готов для использования.
4. Да, размер пакета приложения если сделать все по дефолту большой, есть куча статей по оптимизации размера приложений, но размер приложения будет больше чем у нативных.
5. Основная проблема Xamarin Forms - не баги, размер или еще что-то. Это неправильные ожидания которые к нему предъявляются. У него своя ниша.

Сделайте сервис, который сможет отдавать нужные вам данные по запросу нужного метода.
И заинжектите сервис в twig.
В config.yml:

twig:
    globals:
        your_service: '@your_service'

В twig можно просто дергать {{ your_service.someMethod() }}

Немного документации.

[Serialized] GameObject enemy в это поле ПОДСТАВЛЯТЬ нужный префаб. Сделали 5/10/20 префабов, нужный подгрузили и подставили в поле для генерации. А вот "обертки над поведением" сделать одинаковыми. У любого врага одинаково вызывается анимация/атака/смерть.

В чем проблема то генерить нужный префаб?)

Как я понял: речь про баланс: контроль игрового мира <-> объём передаваемых данных по сети.
Вопрос хороший.
Не всегда нужно делать всё на сервере, иначе объём трафика - возрастёт дико во время игры. Но также, нельзя доверять клиентским данным.
Поэтому, всегда делается аппроксимация: промежуточная визуализация - вычисляется на клиенте, а пришедшие на сервер данные - всегда тщательно проверяются сервером в рамках логики(модели) работы игрового мира. И если отклонения слишком велики - фиксируется "читерство", иначе - по получению новых позиций объектов, клиент плавно, но с ускорением ("параболически") устраняет расхождения с серверным игровым миром: синхронизирует актуальное состояние мира сервера с отображаемым пользователю.
Это происходит в 99% случаев незаметно для глаз игрока за монитором.

На сервере и на клиенте - лучше всего дублировать логику механики и синхронизировать каждые N-кадров или принудительно по каким-либо важным игровым событиям.

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

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

При наличии готового проекта лучше всего изучать именно на этом готовом проекте. Практика в 100 раз лучше любой теории.

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

Я не могу никоем чудом работать с JSON на C#

А может таки добить и начать работать? LitJSON норм, например.

1,5 года работал на проекте - автоматизация парковочной системы (петли, шлагбаумы, картридеры, платежные терминалы... ). Было все на .net
Поскольку работа с самим железом напрямую у вас решена (драйвера), c# вполне подойдет

Смотря зачем)). Я когда делаю Code Review критерии следующие:

* Безопасность:
- Каждый аргумент метода простого типа должен проверяться на тип в случае его проксирования и на граничные значения в случае обработки. Чуть что не так - бросается исключение. Если метод с кучкой аргументов на 80% состоит из поверки из аргументов - это вполне норм))
- Никаких trigger_error, только исключения.
- Исключения ДОЛЖНЫ быть человеко-понятны, всякие "Something went wrong" можно отдавать пользователю, но в лог должно попасть исключение со стектрейсом и человеко-понятным описанием, что же там пошло не так.
- Каждый аргумент (объект) метода должен быть с тайпхинтингом на этот его класс, или интерфейс.
- За eval как правило шлю на **й.
- @ допускается только в безвыходных ситуациях, например проверка json_last_error.
- Перед работой с БД - обязательная проверка данных.
- Никаких == и !=. Со swtich - единственное исключение, по ситуации.
- Если метод возвращает не только bool, а еще что-то - жесткая проверка с ===, или !== обязательна.
- Никаких условий с присваиваниями внутри. while($row = ...) - тоже идет лесом.
- Магические геттеры/сеттеры разрешаются только в безвыходных ситуациях, в остальном - запрещены.
- Конкатенации в sql - только в безвыходных ситуациях.
- Параметры в sql - ТОЛЬКО через плейсхолдеры.
- Никаких глобальных переменных.
- Даты в виде строки разрешаются только в шаблонах и в БД, в пхп коде сразу преобразуется в \DateTimeImmutable (в безвыходных ситуациях разрешено \DateTime)
- Конечно зависит от проекта, но как приавло должно быть всего две точки входа: index.php для web и console(или как-то по другому назваться) - для консоли.

* Кодстайл PSR-2 + PSR-5 как минимум, + еще куча более жестких требований (для начала все то что в PSR помечено как SHOULD - становится MUST)
- В PhpStorm ни одна строчка не должна подсвечиваться (исключением является typo ошибки, например словарик не знает какой-то из аббревиатур, принятых в вашем проекте). При этом разрешается использовать /** @noinspection *** */ для безвыходных ситуаций.
- Если кто-то говорит, что пишет в другом редакторе и у него не подсвечивается, на эти отговорки кладется ВОТ ТАКЕЕЕНЫЙ мужской половой **й и отправляется на доработку)).

* Организация кода:
- Никаких глобальных функций.
- Классы без неймспейса разрешаются только в исключительно безвыходных ситуациях.

* Тестируемость (в смысле простота тестирования) кода должна быть высокая.
- Покрытие кода обязательно для всех возможных кейсов использования каждого публичного метода с моками зависимостей.

* Принципы MVC:
- Никаких обработок пользовательского ввода в моделях, от слова совсем.
- Никаких ***ть запросов в БД из шаблонов.
- Никаких верстки/js/css/sql-ин в контроллерах.
- В моделях НИКАКОЙ МАГИИ, только приватные свойства + геттеры с сеттерами.
- В моделях разрешено использовать метод save(при наличии такого разумеется) только в исключительных ситуациях. Во всех остальных - либо insert, либо update.

* Принципы SOLD:
- Никаких божественных объектов умеющих во все.
- Если метод для внутреннего пользования - private, никаких public.
- Статические методы разрешаются только в случае безвыходности.

* Принцип DRY разрешено нарушать в случаях:
- Явного разделения обязанностей
- В тестах (каждый тест должен быть независимым, на сколько это возможно)

* Работа с БД:
- Запрос в цикле должен быть РЕАЛЬНО обоснован.
- За ORDER BY RAND() - шлю на***й.
- Поиск не по ключам (конечно если таблица НЕ на 5 строк) запрещен.
- Поиск без LIMIT (опять же если таблица НЕ на 5 строк) запрещен.
- SELECT * - запрещен.
- Денормализация БД должна быть обоснована.
- MyISAM не используется (так уж)) )
- Множественные операции обязательно в транзакции, с откатом если чо пошло не так.
- БД не должна содержать бизнес логики, только данные в целостном виде.
- Не должно быть нецелесообразного дерганья БД там, где без этого можно обойтись.

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

* О людях:
- "Я привык писать так и буду дальше" - не вопрос, ревью пройдешь только когда поменяешь свое мнение.
- "Я пишу в vim-е и мне так удобно" - здорово, код консолью я тоже в нем пишу)) но есть требования к коду, если в них не сможешь - не пройдешь ревью.
- "Я скопировал этот страшный метод и поменял 2 строчки" - это конечно замечательно, но по блейму автор всего этого метода ты, так что давай без говняшек, хорошо?
- "Оно же работает!" - вот эта фраза переводится примерно так: "да, я понимаю, что пишу полную хрень, но не могу писать нормально потому, что руки из жо", я правильно тебя понял?))
- "У меня все работает!" - рад за тебя, а как на счет продакшна?
- "Там все просто" - не используй слово "просто", от слова "совсем". Вот тебе кусок кода (первого попавшегося с сложной бизнес логикой), где там ошибка (не важно есть она, или нет)? Ты смотришь его уже 2 минуты, в чем проблема, там же все "просто"))

* Всякое:
ActiveRecord (это я вам как в прошлом фанат Yii говорю) - полное говно, примите за исходную. По факту у вас бесконтрольно по проекту гуляют модельки с подключением к БД. Не раз натыкался на то, что в тех же шаблонах вызывают save, или update (за такое надо сжигать).
То, что используется Laravel - это печально((. Что бы выполнить требования приведенные выше, приходится "воевать" с фреймворком.

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

UPD

Формализировал данные критерии по ссылочке: https://github.com/index0h/php-conventions

Создать класс:

class Entity {
   public double X = 0;
   public double Y = 0;
   public double Z = 0;
}

class Element : Entity {
  public string color = "red";
}

class Room : Entity {
  public List<Element> objects;
  public void Add(Element obj) {
    objects.Add(obj);
  }
}

class Door : Element{
  public string style = "modern";
}

class Window : Element{
  public string material = "wood";
}

Room room = new Room();

room.Add(new Door());
room.Add(new Window());

Никому она не мешает, эта dll-ка.
Но если так уж нужно - stackoverflow.com/questions/10137937/merge-dll-into-exe