КОДОГЕНЕРАЦИЯ
Фича, которая реже всего встречается на проектах, где я работал.
Что странно, ведь это очень эффективный инструмент с очень высоким отношением затрат и результата, и вот почему:
1️⃣ Единственный способ увеличить продуктивность программистов — использовать кодогенерацию.
Т.е. генерировать код, для создания которого требуется сформировать абстрактную модель в голове, а потом перевести ее в реальный код.
С учетом того что цикл перевода знаний из краткосрочной в долгосрочную память занимает больше 24 часов (об этом я писал тут и тут).
2️⃣ Вы тратите время только на поддержку кодогенератора, а не кода, который он генерирует.
Если в сгенерированном коде баг — исправляем генератор, а не все объекты, что он создал.
Такая же логика работает для всего, что генератор создает.
Т.е. в сравнении имплементации с кодогенерацией и без, поддерживать нужно будет меньше кода.
3️⃣ Это очень легко.
Чем отличается генерация JSON-файла от генерации скрипта?
— Вообще ничем. Любой класс — это текст внутри файла.
Компилятор увидит эти файлы, сотворит магию (нет) и код будет готов к использованию.
Вот крутой пример из самого популярного DI-контейнера для Unity (всего 90 строк кода🤯 ).
Никаких хаков и продвинутого понимания языка. Просто код, который генерирует код😅
4️⃣ Это может быть очень быстро.
Вместо использования рефлексии можно сгенерировать код, который будет вызывать нужные методы напрямую.
Из популярного:
🔸Операции (де-)сериализации
Например, тот же
В unity же значение в каждый из элементов объекта проставляется через рефлексию.
Жду реализации через SourceGenerator'ы🛞
🔸Генерация Data Transfer Object'ов
Для общения клиента и сервера, вместо того чтобы писать объекты для данных вручную, можно их полностью генерировать.
Безусловно, такая фича уже давно есть в Swagger и много где еще, но в игровых проектах я все равно встречаю такое редко.
Чаще генерация происходит через первый сайт в google'е🫠
🔸 Связь с нативной частью Unity.
Например, перехват событий из Animation Event можно полностью сгенерировать.
Тем самым избежав типичных: "Ой, эффект на персонаже X перестал работать, посмотри чо там🥺 ".
Мы этот подход использовали на проекте Magic Battle Arena и полностью генерировали из имен fbx-объектов:
🔹 События анимации, которые вызывали нужный метод в коде
🔹 Уникальные типы анимации для каждого персонажа.
Каждый персонаж — свой enum, который всегда консистентен с анимациями, которые на нем есть.
🔹 Настройки для художников спецэффектов.
Добавил fbx, нажал одну кнопку, настройки со всеми типами анимации готовы за 1 секунду.
5️⃣ Можно генерировать целые фичи.
На Magic Battle Arena мы генерировали DTO, (де-)маршалинг данных и Memory Pool для всех этих объектов😎
Т.е. по сути весь транспортный слой, отвечающий за коммуникацию клиента и сервера, полностью кодогенерировался.
Мы использовали T4 Templates. До сих пор очень мощный и крутой инструмент🫡
Итого:
Лично для себя не вижу ни одного повода чтобы не задавать себе каждый раз перед написанием новой фичи:
"А могу ли я какую-то часть накодогенить?"🤔
Так шаг за шагом и проект сам себя рано или поздно напишет🤣
🔻Давайте соберем маленькую базу мест, где еще кодоген будет полезен.
Расскажите в комментах, где вы используете(-али) кодоген и он сослужил вам верную службу🫡
Ты знаешь кому переслать этот пост.
Ставь 👍 если тебе по кайфу такая движуха
#проект_в_разработке@UniArchitect
Фича, которая реже всего встречается на проектах, где я работал.
Что странно, ведь это очень эффективный инструмент с очень высоким отношением затрат и результата, и вот почему:
1️⃣ Единственный способ увеличить продуктивность программистов — использовать кодогенерацию.
Т.е. генерировать код, для создания которого требуется сформировать абстрактную модель в голове, а потом перевести ее в реальный код.
С учетом того что цикл перевода знаний из краткосрочной в долгосрочную память занимает больше 24 часов (об этом я писал тут и тут).
2️⃣ Вы тратите время только на поддержку кодогенератора, а не кода, который он генерирует.
Если в сгенерированном коде баг — исправляем генератор, а не все объекты, что он создал.
Такая же логика работает для всего, что генератор создает.
Т.е. в сравнении имплементации с кодогенерацией и без, поддерживать нужно будет меньше кода.
3️⃣ Это очень легко.
Чем отличается генерация JSON-файла от генерации скрипта?
— Вообще ничем. Любой класс — это текст внутри файла.
Компилятор увидит эти файлы, сотворит магию (нет) и код будет готов к использованию.
Вот крутой пример из самого популярного DI-контейнера для Unity (всего 90 строк кода
Никаких хаков и продвинутого понимания языка. Просто код, который генерирует код
4️⃣ Это может быть очень быстро.
Вместо использования рефлексии можно сгенерировать код, который будет вызывать нужные методы напрямую.
Из популярного:
🔸Операции (де-)сериализации
Например, тот же
Newtonsoft.Json использует IL Weaving для генерации IL-кода, который преобразует строку в объект во время исполнения программы.В unity же значение в каждый из элементов объекта проставляется через рефлексию.
Жду реализации через SourceGenerator'ы
🔸Генерация Data Transfer Object'ов
Для общения клиента и сервера, вместо того чтобы писать объекты для данных вручную, можно их полностью генерировать.
Безусловно, такая фича уже давно есть в Swagger и много где еще, но в игровых проектах я все равно встречаю такое редко.
Чаще генерация происходит через первый сайт в google'е
🔸 Связь с нативной частью Unity.
Например, перехват событий из Animation Event можно полностью сгенерировать.
Тем самым избежав типичных: "Ой, эффект на персонаже X перестал работать, посмотри чо там
Мы этот подход использовали на проекте Magic Battle Arena и полностью генерировали из имен fbx-объектов:
🔹 События анимации, которые вызывали нужный метод в коде
🔹 Уникальные типы анимации для каждого персонажа.
Каждый персонаж — свой enum, который всегда консистентен с анимациями, которые на нем есть.
🔹 Настройки для художников спецэффектов.
Добавил fbx, нажал одну кнопку, настройки со всеми типами анимации готовы за 1 секунду.
5️⃣ Можно генерировать целые фичи.
На Magic Battle Arena мы генерировали DTO, (де-)маршалинг данных и Memory Pool для всех этих объектов
Т.е. по сути весь транспортный слой, отвечающий за коммуникацию клиента и сервера, полностью кодогенерировался.
Мы использовали T4 Templates. До сих пор очень мощный и крутой инструмент
Итого:
Лично для себя не вижу ни одного повода чтобы не задавать себе каждый раз перед написанием новой фичи:
"А могу ли я какую-то часть накодогенить?"
Так шаг за шагом и проект сам себя рано или поздно напишет
🔻Давайте соберем маленькую базу мест, где еще кодоген будет полезен.
Расскажите в комментах, где вы используете(-али) кодоген и он сослужил вам верную службу
Ты знаешь кому переслать этот пост.
Ставь 👍 если тебе по кайфу такая движуха
#проект_в_разработке@UniArchitect
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥39👍27
Почему я сделал курс по архитектуре проектов в Unity?
Потому что вижу дикий разрыв между «учебными» рассказами о том, как делать проект, и тем, как всё происходит в реальности.
Этот разрыв настолько большой, что приходится чуть ли не полностью забывать то, чему учат, и делать всё по-другому, когда речь идёт о настоящей командной разработке игр🤓
Почему так? Есть несколько причин:
1️⃣ Требования при одиночной и командной разработке — это разные миры.
Отсюда возникают неочевидные задачи: управление конфигами, совместная работа в Git, настройка staging (dev/prod окружения), аналитика, CI/CD, code review.
Вроде базовые вещи, но в контексте игровой разработки обсуждают их мало, а без них в реальном проекте никак.
2️⃣ Проклятие знаний.
Часто, поработав в одном проекте, люди думают: «Ну, все же делают так же».
Кажется, что и рассказывать особо нечего. Но на деле разрыв растёт: новичков и даже мидлов бросают в реальный проект, где всё иначе, и они не понимают, куда попали.
3️⃣ NDA.
Из-за жёстких пунктов о неразглашении с большими штрафами никто не рвётся делиться подробностями процессов и архитектуры. Порой вообще неясно, что можно рассказывать, а что нет.
4️⃣ Нет времени.
В игровых компаниях плотный график фичевой разработки. После работы уже не до статей и видео, у всех своя жизнь, семья. Так что делиться опытными находками просто некогда.
5️⃣ Высокая требовательность к себе и сложность материала.
Тема непростая, хочется делать материалы качественно. Да и негатив или токсичность по поводу «недостаточно глубоко раскрыл» мало кому интересны. Проще не выносить ничего в публичное поле.
🔸В итоге имеем кучу базовых «стартовых» курсов, которые не очень помогают, когда ты переходишь на серьёзный уровень в реальном проекте. Что-то более глубокое приходится буквально выискивать по крупицам — да и то не факт, что найдёшь.
Я думал, что этот разрыв закроют k-syndicate в 2022-м, когда они выпустили свой курс по архитектуре. Но они сместили фокус на создание собственной игровой студии, и вопрос снова остался открытым😬
🔸Время шло, я видел, что пробела никто не заполняет, и год назад решил взяться за свой курс.
За весь период с января 2023 по сентябрь 2024 я упорно изучал разные книги, научные статьи, базу знаний по реальным проектам, анализировал личный опыт — всё для того, чтобы этот разрыв хоть немного сократить.
Понимаю, что сейчас кругом агрессивные продажи и курсы с обещаниями «200к за 2 месяца», и многие уже устали от подобного.
Но я действительно хочу делиться наработками и продавать результат своей работы — ведь вкладывал в это уйму сил и времени🫠
🔻Важный момент:
🔸Буду рассказывать о нём в блоге, стараясь делать это спокойно и без агрессивной рекламы. Если кому-то интересно прокачаться с учётом реальных процессов, подтянуть архитектуру и все эти нюансы командной разработки — милости прошу. Если нет — всё нормально, у меня нет цели загонять туда всех подряд.
Главное, чтобы вы понимали, зачем вообще этот курс появился и почему я считаю нужным его продвигать: в реальности сложных игровых проектов слишком много незакрытых вопросов, и хочется, чтобы люди не прыгали в омут с головой без нормальной подготовки😵💫
Ставь 👍 если тебе по кайфу такая движуха.
#курс@UniArchitect
Потому что вижу дикий разрыв между «учебными» рассказами о том, как делать проект, и тем, как всё происходит в реальности.
Этот разрыв настолько большой, что приходится чуть ли не полностью забывать то, чему учат, и делать всё по-другому, когда речь идёт о настоящей командной разработке игр
Почему так? Есть несколько причин:
1️⃣ Требования при одиночной и командной разработке — это разные миры.
Отсюда возникают неочевидные задачи: управление конфигами, совместная работа в Git, настройка staging (dev/prod окружения), аналитика, CI/CD, code review.
Вроде базовые вещи, но в контексте игровой разработки обсуждают их мало, а без них в реальном проекте никак.
2️⃣ Проклятие знаний.
Часто, поработав в одном проекте, люди думают: «Ну, все же делают так же».
Кажется, что и рассказывать особо нечего. Но на деле разрыв растёт: новичков и даже мидлов бросают в реальный проект, где всё иначе, и они не понимают, куда попали.
3️⃣ NDA.
Из-за жёстких пунктов о неразглашении с большими штрафами никто не рвётся делиться подробностями процессов и архитектуры. Порой вообще неясно, что можно рассказывать, а что нет.
4️⃣ Нет времени.
В игровых компаниях плотный график фичевой разработки. После работы уже не до статей и видео, у всех своя жизнь, семья. Так что делиться опытными находками просто некогда.
5️⃣ Высокая требовательность к себе и сложность материала.
Тема непростая, хочется делать материалы качественно. Да и негатив или токсичность по поводу «недостаточно глубоко раскрыл» мало кому интересны. Проще не выносить ничего в публичное поле.
🔸В итоге имеем кучу базовых «стартовых» курсов, которые не очень помогают, когда ты переходишь на серьёзный уровень в реальном проекте. Что-то более глубокое приходится буквально выискивать по крупицам — да и то не факт, что найдёшь.
Я думал, что этот разрыв закроют k-syndicate в 2022-м, когда они выпустили свой курс по архитектуре. Но они сместили фокус на создание собственной игровой студии, и вопрос снова остался открытым
🔸Время шло, я видел, что пробела никто не заполняет, и год назад решил взяться за свой курс.
За весь период с января 2023 по сентябрь 2024 я упорно изучал разные книги, научные статьи, базу знаний по реальным проектам, анализировал личный опыт — всё для того, чтобы этот разрыв хоть немного сократить.
Понимаю, что сейчас кругом агрессивные продажи и курсы с обещаниями «200к за 2 месяца», и многие уже устали от подобного.
Но я действительно хочу делиться наработками и продавать результат своей работы — ведь вкладывал в это уйму сил и времени
🔻Важный момент:
Я не маркетолог и не собираюсь навязывать курс кому бы то ни было, чтобы не выглядеть в глазах аудитории очередным инфоцыганом.
🔸Буду рассказывать о нём в блоге, стараясь делать это спокойно и без агрессивной рекламы. Если кому-то интересно прокачаться с учётом реальных процессов, подтянуть архитектуру и все эти нюансы командной разработки — милости прошу. Если нет — всё нормально, у меня нет цели загонять туда всех подряд.
Главное, чтобы вы понимали, зачем вообще этот курс появился и почему я считаю нужным его продвигать: в реальности сложных игровых проектов слишком много незакрытых вопросов, и хочется, чтобы люди не прыгали в омут с головой без нормальной подготовки
Ставь 👍 если тебе по кайфу такая движуха.
#курс@UniArchitect
Please open Telegram to view this post
VIEW IN TELEGRAM
👍131🤮8
КАЧАЕМ ФАЙЛЫ БЫСТРЕЕ НА 30%
Если вы на старте игры качаете более чем 100 файлов, то есть один забавный способ ускорить загрузку до 30%.
Контента в игре у вас много, а размер билда должен быть <150МБ.
Потому часть вы запаковали в 100 Asset Bundle'ов.
А на старте игры качаете их из CDN через Unity Web Request.
В коде это выглядит примерно так:
Уверен что у каждого в проекте есть похожий кусок.
Есть идеи как его ускорить?😬
Ответ:
Application.targetFrameRate = 120
Дисклеймер:
Как и всегда, есть нюансы. Перед тем как применять подобное у себя, тщательно изучите ограничения платформ для вашего проекта.
🔸Как так получается?
— Если вы знаете что такое Synchronization Context, то возможно, вы уже догадываетесь в чем дело.
Это специальный класс в dotnet, который представляет из себя очередь delegate'ов на MoveNext (машин состояний), которые будут вызваны в момент когда наше приложение готово продолжить выполнение асинхронного кода.
В unity синхронизация вызывается в UnityEngine.PlayerLoop.Update.ScriptRunDelayedTasks из нативной части, путем вызова статического метода UnitySynchronizationContext.ExecuteTasks.
🔸Или проще говоря:
— Все продолжения ваших асинхронных операций длиннее одного кадра будут вызваны на следующий кадр в
🔸Риторический вопрос:
Действительно ли время загрузки файлов по сети привязано к длине кадра?
— Вообще нет. Установление соединения и скачивание идет в другом потоке в нативной части.
Но вот результаты и обновление состояний синхронизированы с основным потоком и происходят в UnityEngine.PlayerLoop.EarlyUpdate.UnityWebRequestUpdate.
🔸Это значит:
Что если файл качается 45ms, а ваша игра работает при 30FPS, то ~15ms данные будут ждать синхронизации.
Того самого вызова MoveNext для вашего метода
Т.е. данные в памяти в нативной части будут через 45ms, но у себя вы их получите только через 66ms.
И буст (местами до 30%) можно получить как раз за счет снижения времени "простоя" данных в ожидании вызова нужной фазы PlayerLoop'а.
Это тот забавный случай, когда магическая строчка в одном месте почему-то дает ощутимый результат🤣
Так что, как идею, берите на вооружение увеличение FPS на время загрузки и возвращение его в нормальное значение после😅
❗️Но блин, ребят, это не silver bullet. Проверяйте последствия на своих проектах.
На слабых девайсах это может только сделать хуже.
Если интересно копнуть больше в эту тему, рекомендую посмотреть видео с конференции CLRium.
CLRium #6: Контексты синхронизации (SynchronizationContext)
У меня огромная куча тем по архитектуре которым хочется с вами поделиться, но пока я сильно загружен ведением курса.
Статьи пока выходят редко, но блог не заброшен, вернусь совсем скоро как закончу курс🫡
Ставь 👍 если тебе по кайфу такая движуха.
#будни@UniArchitect
Если вы на старте игры качаете более чем 100 файлов, то есть один забавный способ ускорить загрузку до 30%.
Контента в игре у вас много, а размер билда должен быть <150МБ.
Потому часть вы запаковали в 100 Asset Bundle'ов.
А на старте игры качаете их из CDN через Unity Web Request.
В коде это выглядит примерно так:
IEnumerator DownloadAssetBundle(string url, Action<byte[]> onSuccess)
{
using var request = UnityWebRequestAssetBundle.GetAssetBundle(url);
var op = request.SendWebRequest();
while (!op.isDone)
yield return null;
onSuccess?.Invoke(request.downloadHandler.data);
}
Уверен что у каждого в проекте есть похожий кусок.
Есть идеи как его ускорить?
Ответ:
Application.targetFrameRate = 120
Дисклеймер:
Как и всегда, есть нюансы. Перед тем как применять подобное у себя, тщательно изучите ограничения платформ для вашего проекта.
🔸Как так получается?
— Если вы знаете что такое Synchronization Context, то возможно, вы уже догадываетесь в чем дело.
Это специальный класс в dotnet, который представляет из себя очередь delegate'ов на MoveNext (машин состояний), которые будут вызваны в момент когда наше приложение готово продолжить выполнение асинхронного кода.
В unity синхронизация вызывается в UnityEngine.PlayerLoop.Update.ScriptRunDelayedTasks из нативной части, путем вызова статического метода UnitySynchronizationContext.ExecuteTasks.
🔸Или проще говоря:
— Все продолжения ваших асинхронных операций длиннее одного кадра будут вызваны на следующий кадр в
Update.ScriptRunDelayedTasks фазе.🔸Риторический вопрос:
Действительно ли время загрузки файлов по сети привязано к длине кадра?
— Вообще нет. Установление соединения и скачивание идет в другом потоке в нативной части.
Но вот результаты и обновление состояний синхронизированы с основным потоком и происходят в UnityEngine.PlayerLoop.EarlyUpdate.UnityWebRequestUpdate.
🔸Это значит:
Что если файл качается 45ms, а ваша игра работает при 30FPS, то ~15ms данные будут ждать синхронизации.
Того самого вызова MoveNext для вашего метода
DownloadAssetBundle.Т.е. данные в памяти в нативной части будут через 45ms, но у себя вы их получите только через 66ms.
И буст (местами до 30%) можно получить как раз за счет снижения времени "простоя" данных в ожидании вызова нужной фазы PlayerLoop'а.
Это тот забавный случай, когда магическая строчка в одном месте почему-то дает ощутимый результат
Так что, как идею, берите на вооружение увеличение FPS на время загрузки и возвращение его в нормальное значение после
❗️Но блин, ребят, это не silver bullet. Проверяйте последствия на своих проектах.
На слабых девайсах это может только сделать хуже.
Если интересно копнуть больше в эту тему, рекомендую посмотреть видео с конференции CLRium.
CLRium #6: Контексты синхронизации (SynchronizationContext)
У меня огромная куча тем по архитектуре которым хочется с вами поделиться, но пока я сильно загружен ведением курса.
Статьи пока выходят редко, но блог не заброшен, вернусь совсем скоро как закончу курс
Ставь 👍 если тебе по кайфу такая движуха.
#будни@UniArchitect
Please open Telegram to view this post
VIEW IN TELEGRAM
👍109🔥10
MV*
Сколько копий сломано об эту тему...
Давайте по порядку:
— В 1974-79 годах Trygve M. H. Reenskaug (автор MVC) работал над портативным компьютером "для детей всех возрастов" Dynabook в компании XEROX.
— Именно тогда/там закладывались основы графического интерфейса, формировалось понятие "дружелюбного интерфейса".
— В те же года была и опубликована короткая заметка про разделение на model/view/editor, которая позже преобразовалась в MVC.
С тех пор много воды утекло, разработка значительно продвинулась вперед, а изначальные идеи сильно исказались, что нынче приводит к жуткой путанице в проектах.
Давайте попробуем распутать этот клубок, проанализировав первоисточники:
🔸Model:
1. Model — это функциональность, которая возникает при комбинации нескольких систем.
Т.е. это модуль/объект, который вбирает в себя необходимые сервисы системы и использует их для формирования функциональности необходимой для controller/view.
2. Model это не данные, а исключительно интерфейсы/объекты-посредники/фильтры, обеспечивающие удобный доступ к данным, которые могут находится где угодно.
🔸View:
Вспомните пост про ПОРТЫ И АДАПТЕРЫ и представьте что вы пишете код, которые раскрашивает пискели на экране 50 лет назад😬
Вам придется написать огромный пласт прежде чем вывести
— Данные из порта пришли в один из сервисов системы, обработались и готовы к использованию в model.
— View, подписавшись на callback от операционной системы, получила и обработала нажатие на кнопку и вызвала соответствующую часть model.
И как раз для отделения кода связанного с рендером "нужного цвета пикселя в нужном окне на экране" с бизнес-логикой и была выделена view.
🔸Controller:
Яблоко раздора, вносящее сумятицу во всю систему...
Вместо 1000 слов и долгих объяснений: controller — это выпадающее меню, появляющееся при нажатии на правую клавишу мыши.
Это то, делает отображение сцены в редакторе из 2D в 3D, отключает ненужные gizmos на экране и дает возможность переключать Move, Rotate, Scale, Transform для объектов.
Логика view и model в таком случае никак не меняется. Меняется лишь настройка отображения, которая необходима пользователю для работы.
Вместо длинных выводов:
❌ “Грамотный” UI в Unity всегда должен состоять из model/view/controller.
✅ Нет. В 99.9% случаев вам вообще не нужен controller.
А иногда вы можете и модель не выделять, используя интерфейс сервисов.
Всем этим я лишь хочу подсветить то, насколько изначальные идеи исказались и как мы иногда можем переусложнять работу с UI в наших проектах.
❗️ Потому что изначальная идея MVC удовлетворяет очень узкому набору требований для разработки первого UI для первого портативного компьютера.
И попытка переноса идеи 1к1 приведет лишь к переусложнению вашего проекта (раз, два).
Если вам интересно узнать больше, рекомендую почитать крутой цикл статей на хабре, где автор еще в 2017 году проделал аналогичное исследование🫡
Это далеко не все выводы, в одной статье невозможно раскрыть столь большой топик.
Ставь 👍 если тебе по кайфу такая движуха.
#архитектурные_подходы@UniArchitect
Сколько копий сломано об эту тему...
Давайте по порядку:
— В 1974-79 годах Trygve M. H. Reenskaug (автор MVC) работал над портативным компьютером "для детей всех возрастов" Dynabook в компании XEROX.
— Именно тогда/там закладывались основы графического интерфейса, формировалось понятие "дружелюбного интерфейса".
— В те же года была и опубликована короткая заметка про разделение на model/view/editor, которая позже преобразовалась в MVC.
С тех пор много воды утекло, разработка значительно продвинулась вперед, а изначальные идеи сильно исказались, что нынче приводит к жуткой путанице в проектах.
Давайте попробуем распутать этот клубок, проанализировав первоисточники:
🔸Model:
Модели представляют знания. Модель может быть одиночным объектом (что не очень интересно) или структурой из нескольких объектов.
Между моделью и ее частями, с одной стороны, и представляемым миром, как его воспринимает владелец модели, с другой стороны, должна быть однозначная связь.
MODELS - VIEWS - CONTROLLERS
1. Model — это функциональность, которая возникает при комбинации нескольких систем.
Т.е. это модуль/объект, который вбирает в себя необходимые сервисы системы и использует их для формирования функциональности необходимой для controller/view.
2. Model это не данные, а исключительно интерфейсы/объекты-посредники/фильтры, обеспечивающие удобный доступ к данным, которые могут находится где угодно.
🔸View:
View — это визуальное отображение своей модели. Обычно оно подчеркивает определенные атрибуты модели и скрывает другие, действуя как фильтр.
Представление привязано к своей модели (или ее части) и получает необходимые данные для отображения, запрашивая их у модели.
The original MVC reports
Вспомните пост про ПОРТЫ И АДАПТЕРЫ и представьте что вы пишете код, которые раскрашивает пискели на экране 50 лет назад
Вам придется написать огромный пласт прежде чем вывести
Hello World на экран:— Данные из порта пришли в один из сервисов системы, обработались и готовы к использованию в model.
— View, подписавшись на callback от операционной системы, получила и обработала нажатие на кнопку и вызвала соответствующую часть model.
И как раз для отделения кода связанного с рендером "нужного цвета пикселя в нужном окне на экране" с бизнес-логикой и была выделена view.
🔸Controller:
Контроллер — это связующее звено между пользователем и системой. Он обеспечивает средства для вывода пользовательских команд, предлагая меню или другие способы ввода команд и данных, переводит их в соответствующие сообщения и передает эти сообщения одному или нескольким представлениям.
MVC XEROX PARC 1978-79
Яблоко раздора, вносящее сумятицу во всю систему...
Вместо 1000 слов и долгих объяснений: controller — это выпадающее меню, появляющееся при нажатии на правую клавишу мыши.
Это то, делает отображение сцены в редакторе из 2D в 3D, отключает ненужные gizmos на экране и дает возможность переключать Move, Rotate, Scale, Transform для объектов.
Логика view и model в таком случае никак не меняется. Меняется лишь настройка отображения, которая необходима пользователю для работы.
Вместо длинных выводов:
❌ “Грамотный” UI в Unity всегда должен состоять из model/view/controller.
✅ Нет. В 99.9% случаев вам вообще не нужен controller.
А иногда вы можете и модель не выделять, используя интерфейс сервисов.
Всем этим я лишь хочу подсветить то, насколько изначальные идеи исказались и как мы иногда можем переусложнять работу с UI в наших проектах.
И попытка переноса идеи 1к1 приведет лишь к переусложнению вашего проекта (раз, два).
Если вам интересно узнать больше, рекомендую почитать крутой цикл статей на хабре, где автор еще в 2017 году проделал аналогичное исследование
Это далеко не все выводы, в одной статье невозможно раскрыть столь большой топик.
Ставь 👍 если тебе по кайфу такая движуха.
#архитектурные_подходы@UniArchitect
Please open Telegram to view this post
VIEW IN TELEGRAM
👍87
ПРОЕКТИРОВАНИЕ: С ЧЕГО НАЧИНАТЬ
Устроился в Nexters, где сейчас переписываю внутриигровой чат со старой технологии на новую. Проектирую его как отдельный dotnet микросервис и должен встроить в существующую архитектуру.
Впереди согласование с техническим директором, бэкенд-лидом, CTO — защита решений, проектирование, реализация.
И вот смотрите... Многие думают, что архитектура — это архитектура кода. Паттерны, классы, модули. Но это не так.
Когда тебе нужно объяснить команде что и как будем делать, когда сервера еще нет, а решения принимать надо — расписывать детали реализации бессмысленно.
Тут важно отодвинуться назад и посмотреть на картину целиком. Понять, как фича встраивается в общую систему.
Только после этого можно переходить к деталям.
🔸Уровень 1: System Context
Любая компания — это система. Набор элементов (отделов, команд, unit'ов), которые взаимодействуют между собой ради глобальной миссии. Для игровой компании — развлечение пользователя.
Для контекста, перечитай (А|а)рхитектура.
На уровне системы нам важно отобразить:
— Пользователя и его способ взаимодействия с системой
— Ключевые элементы, благодаря которым фича будет работать
При этом нас НЕ интересуют детали реализации и конкретные технологии.
🔸Пример: мобильная игра
Общий вопрос для начала:
— Пользователь: игрок (Gamer)
— Точка взаимодействия: мобильное приложение (Game)
У любой игры среднего размера (100к+ скачиваний) есть:
▫️ Tech Monitoring — Firebase Crashlytics, Unity Cloud Diagnostics, Sentry
▫️ Analytics — Google Analytics, Facebook, AppsFlyer
▫️ Game Data Service — админка с доступом к данным пользователя. Обычно своя разработка или MBaaS (Mobile Backend-as-a-Service): Firebase/Unity Cloud Save, AWS Amplify
▫️ Data Storage — хранилище данных пользователя
▫️ CDN — Content Delivery Network для ассетов и конфигов
Из комбинации этих элементов ты можешь собрать архитектуру уровня системы для 99% мобильных игр.
см. картинку или оригинал
🔸Модель C4
Поздравляю, первый уровень модели C4 освоен .
Software System — наивысший уровень абстракции, описывающий нечто, что приносит ценность пользователям.
Это то, что строит одна команда разработки, владеет им, несет ответственность и видит внутреннюю реализацию.
Как правило, граница software system = граница команды.
И вот нюанс... Software System — это НЕ bounded contexts, НЕ product domains, НЕ tribes или squads (организационные единицы Spotify модели).
Это конкретная система, которую нужно встроить в существующий ландшафт. В моем случае — микросервис чата в инфраструктуру компании.
🔻 Минималистичное проектирование начинается с системы, а не с кода. Это экономит время на согласование и избавляет от лишней документации.
Начиная с уровня системы, мы прорабатываем value для пользователей и связи между элементами. Только после этого можно спускаться вниз к деталям.
Иначе можно утонуть в обсуждении паттернов, когда еще не понятно что вообще строим.
Это первая статья серии "Проектирование". Дальше по порядку о каждом слое: контейнеры, компоненты, код.
Угадайте какой из них стоит генерировать, а не проектировать ручками?😅
Ставь 👍 если тебе заходит такого рода контент!
Ты знаешь кому переслать эту статью 💪
#проектирование@UniArchitect
Устроился в Nexters, где сейчас переписываю внутриигровой чат со старой технологии на новую. Проектирую его как отдельный dotnet микросервис и должен встроить в существующую архитектуру.
Впереди согласование с техническим директором, бэкенд-лидом, CTO — защита решений, проектирование, реализация.
И вот смотрите... Многие думают, что архитектура — это архитектура кода. Паттерны, классы, модули. Но это не так.
Когда тебе нужно объяснить команде что и как будем делать, когда сервера еще нет, а решения принимать надо — расписывать детали реализации бессмысленно.
Тут важно отодвинуться назад и посмотреть на картину целиком. Понять, как фича встраивается в общую систему.
Только после этого можно переходить к деталям.
🔸Уровень 1: System Context
Любая компания — это система. Набор элементов (отделов, команд, unit'ов), которые взаимодействуют между собой ради глобальной миссии. Для игровой компании — развлечение пользователя.
Для контекста, перечитай (А|а)рхитектура.
На уровне системы нам важно отобразить:
— Пользователя и его способ взаимодействия с системой
— Ключевые элементы, благодаря которым фича будет работать
При этом нас НЕ интересуют детали реализации и конкретные технологии.
🔸Пример: мобильная игра
Общий вопрос для начала:
Кто пользуется системой и что является точкой взаимодействия?
— Пользователь: игрок (Gamer)
— Точка взаимодействия: мобильное приложение (Game)
Какие ключевые элементы обеспечивают работоспособность системы?
У любой игры среднего размера (100к+ скачиваний) есть:
▫️ Tech Monitoring — Firebase Crashlytics, Unity Cloud Diagnostics, Sentry
▫️ Analytics — Google Analytics, Facebook, AppsFlyer
▫️ Game Data Service — админка с доступом к данным пользователя. Обычно своя разработка или MBaaS (Mobile Backend-as-a-Service): Firebase/Unity Cloud Save, AWS Amplify
▫️ Data Storage — хранилище данных пользователя
▫️ CDN — Content Delivery Network для ассетов и конфигов
Из комбинации этих элементов ты можешь собрать архитектуру уровня системы для 99% мобильных игр.
см. картинку или оригинал
🔸Модель C4
Поздравляю, первый уровень модели C4 освоен .
Software System — наивысший уровень абстракции, описывающий нечто, что приносит ценность пользователям.
Это то, что строит одна команда разработки, владеет им, несет ответственность и видит внутреннюю реализацию.
Как правило, граница software system = граница команды.
И вот нюанс... Software System — это НЕ bounded contexts, НЕ product domains, НЕ tribes или squads (организационные единицы Spotify модели).
Это конкретная система, которую нужно встроить в существующий ландшафт. В моем случае — микросервис чата в инфраструктуру компании.
🔻 Минималистичное проектирование начинается с системы, а не с кода. Это экономит время на согласование и избавляет от лишней документации.
Начиная с уровня системы, мы прорабатываем value для пользователей и связи между элементами. Только после этого можно спускаться вниз к деталям.
Иначе можно утонуть в обсуждении паттернов, когда еще не понятно что вообще строим.
Это первая статья серии "Проектирование". Дальше по порядку о каждом слое: контейнеры, компоненты, код.
Угадайте какой из них стоит генерировать, а не проектировать ручками?
Ставь 👍 если тебе заходит такого рода контент!
Ты знаешь кому переслать эту статью 💪
#проектирование@UniArchitect
Please open Telegram to view this post
VIEW IN TELEGRAM
👍89🔥20
Unite 2025
Черт, сколько раз я пытался попасть на Unite. То COVID все отменял, то логистика не складывалась, то работа не отпускала. За 9 лет на Unity — ни разу не был на их главной конференции.
Но в этом году звезды наконец сошлись. Добрые люди раздобыли для меня инвайт на Unite 2025, и что самое крутое — меня не отправляет компания😊
Это значит никакого "обязательного минимума" от работодателя, никаких отчетов о ROI для бизнеса. Только чистый контент для канала и максимум полезной информации для вас.
🔻19 и 20 Ноября я буду на Unite 2025 в Барселоне, где соберется вся команда Unity и ключевые разработчики индустрии.
Для тех кто будет на конференции — пишите в личку, встретимся офлайн.
Для всех остальных — у меня есть оборудование (микрофон, стабилизатор и телефон), чтобы делать качественные сторис прямо с места событий. Буду рассказывать о докладах, показывать атмосферу, и самое главное — могу задать твои вопросы команде Unity напрямую.
Потому предложение:
🔸 От меня — качественный контент без воды о том как проходит Unite, короткие summary докладов, закулисье конференции + я задам твои вопросы команде Unity и сниму их ответы
🔸 От вас — Boost'ы канала
https://news.1rj.ru/str/UniArchitect?boost
Чтобы я мог публиковать больше сторис в день (лимит зависит от уровня канала).
Не стесняйтесь boost'ануть по максимуму — это конвертирует фичу телеги во что-то реально полезное для всех🫡
🔻И самое интересное:
Напиши в комментариях какой вопрос ты бы хотел задать команде Unity. Я соберу самые интересные и постараюсь получить ответы от первоисточника.
Может это будет про будущее DOTS, или про планы по улучшению производительности, или про новые фичи которые ждем годами — пиши что волнует.
Ты знаешь кому переслать этот пост 💪
#unite2025
Черт, сколько раз я пытался попасть на Unite. То COVID все отменял, то логистика не складывалась, то работа не отпускала. За 9 лет на Unity — ни разу не был на их главной конференции.
Но в этом году звезды наконец сошлись. Добрые люди раздобыли для меня инвайт на Unite 2025, и что самое крутое — меня не отправляет компания
Это значит никакого "обязательного минимума" от работодателя, никаких отчетов о ROI для бизнеса. Только чистый контент для канала и максимум полезной информации для вас.
🔻19 и 20 Ноября я буду на Unite 2025 в Барселоне, где соберется вся команда Unity и ключевые разработчики индустрии.
Для тех кто будет на конференции — пишите в личку, встретимся офлайн.
Для всех остальных — у меня есть оборудование (микрофон, стабилизатор и телефон), чтобы делать качественные сторис прямо с места событий. Буду рассказывать о докладах, показывать атмосферу, и самое главное — могу задать твои вопросы команде Unity напрямую.
Потому предложение:
🔸 От меня — качественный контент без воды о том как проходит Unite, короткие summary докладов, закулисье конференции + я задам твои вопросы команде Unity и сниму их ответы
🔸 От вас — Boost'ы канала
https://news.1rj.ru/str/UniArchitect?boost
Чтобы я мог публиковать больше сторис в день (лимит зависит от уровня канала).
Не стесняйтесь boost'ануть по максимуму — это конвертирует фичу телеги во что-то реально полезное для всех
🔻И самое интересное:
Напиши в комментариях какой вопрос ты бы хотел задать команде Unity. Я соберу самые интересные и постараюсь получить ответы от первоисточника.
Может это будет про будущее DOTS, или про планы по улучшению производительности, или про новые фичи которые ждем годами — пиши что волнует.
Ты знаешь кому переслать этот пост 💪
#unite2025
Please open Telegram to view this post
VIEW IN TELEGRAM
Telegram
Unity Architect: архитектура unity проектов
Проголосуйте за канал, чтобы он получил больше возможностей.
1🔥54👍13
This media is not supported in your browser
VIEW IN TELEGRAM
CoreCLR в Unity быть
Другой вопрос когда и в каком виде.
У ребят есть планы завозить новый backend постепенно.
Как мне показалось, процесс будет похож на то что мы видели с Burst, Jobs и Entities.
Сначала все вышло в виде preview пакета в который постепенно завозилась новая функциональность в течении ... 4-5 лет, я уже и не помню.
Т.е. ещё раз, если и завезут, то точно постепенно и с постепенной докаткой фичей, совместимости и фиксов.
Что будет с mono не сказали.
Но я бы поставил 100€, что отключать старый backend не будут, как не убрали GameObject'ы заместив их ECS системой.
А что вы думаете, дайте знать в комментариях, а я пойду помучаю подробностями людей из unity🤓
#unite2025
Другой вопрос когда и в каком виде.
У ребят есть планы завозить новый backend постепенно.
Как мне показалось, процесс будет похож на то что мы видели с Burst, Jobs и Entities.
Сначала все вышло в виде preview пакета в который постепенно завозилась новая функциональность в течении ... 4-5 лет, я уже и не помню.
Т.е. ещё раз, если и завезут, то точно постепенно и с постепенной докаткой фичей, совместимости и фиксов.
Что будет с mono не сказали.
Но я бы поставил 100€, что отключать старый backend не будут, как не убрали GameObject'ы заместив их ECS системой.
А что вы думаете, дайте знать в комментариях, а я пойду помучаю подробностями людей из unity
#unite2025
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥19👍5🤷♂4
HTTP/2 в Unity 6.3
Наконец-то🫡
Первую половину этого года я занимался как раз оптимизацией первой загрузки огромного и старого приложения.
Если коротко, там на старте качалось около 700 ассетов размером от 5kb до 5mb.
Около 150mb в общем.
И основная гипотеза была получении fast win за счет перехода с UnityWebRequest на BestHTTP, который поддерживает http/2.
Основная разница, которая полезна в играх:
1⃣ Размер запроса для мелких запросов меньше. HTTP/2 позволяет переиспользовать одно TLS-соединение для множества HTTP запросов к одному домену. То есть публичный ключ/сертификат и установка сессии TLS происходят один раз, а не для каждого запроса.
2⃣ И второй важный момент - запрос на DNS сервер делается всего 1 раз для одного домена вместо похода каждый раз.
На слайде ребята упомянули улучшение перфа на серверной стороне ... имеет место 100%, но для нас, unity разработчиков, есть хороший повод попробовать принести value в скорости загрузки наших игр😊
Не уверен, но по секрету, я для unity команды делал закрытый Proof of Concept с тестами скорости загрузки через http/1 и http/2.
И unity приняли эту информацию т.к. цифры оказались убедительными.
Так что есть не иллюзорный шанс, что к появлению этой фичи я приложил руку🥰
Офигеть ... новый пункт в резюме получается🤣
#unite2025
Наконец-то
Первую половину этого года я занимался как раз оптимизацией первой загрузки огромного и старого приложения.
Если коротко, там на старте качалось около 700 ассетов размером от 5kb до 5mb.
Около 150mb в общем.
И основная гипотеза была получении fast win за счет перехода с UnityWebRequest на BestHTTP, который поддерживает http/2.
Основная разница, которая полезна в играх:
1⃣ Размер запроса для мелких запросов меньше. HTTP/2 позволяет переиспользовать одно TLS-соединение для множества HTTP запросов к одному домену. То есть публичный ключ/сертификат и установка сессии TLS происходят один раз, а не для каждого запроса.
2⃣ И второй важный момент - запрос на DNS сервер делается всего 1 раз для одного домена вместо похода каждый раз.
На слайде ребята упомянули улучшение перфа на серверной стороне ... имеет место 100%, но для нас, unity разработчиков, есть хороший повод попробовать принести value в скорости загрузки наших игр
Не уверен, но по секрету, я для unity команды делал закрытый Proof of Concept с тестами скорости загрузки через http/1 и http/2.
И unity приняли эту информацию т.к. цифры оказались убедительными.
Так что есть не иллюзорный шанс, что к появлению этой фичи я приложил руку
Офигеть ... новый пункт в резюме получается
#unite2025
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥43👍18🤯5
Оптимизации: рекомендации от Unity
Мне бы очень хотелось поделиться с вами какими-то советами по оптимизации, что я услышал на докладах, но наверное в действие вступает проклятие знаний и мне кажется что все это я уже знаю и пробовал.
Вот текстовая выжимка советов, что рекомендуют сами unity и другие разработчики:
1⃣ Отключайте Domain Reload для более быстрого запуска приложения.
Если есть баги связанные с сохранением старых значений в
Не забудьте
2⃣ Unity постоянно улучшают тулзы для профайлинга, он остановится проще и более информативным.
Чекните свежие версии 6.2, 6.3 (сейчас в бете), они добавили Highlights, которые помечают "долгие" кадры на которые стоит обратить внимание.
https://unity.com/features/profiling
3⃣ Если проект долго компилируется, можно при помощи Compilation Visualizer можно посмотреть порядок и время компиляции каждой asmdef в проекте.
Но скажу честно, сделать что-то с временем компиляции сложно.
Нужно либо значительно снижать количество asmdef в проекте, либо уменьшать количество кода😅
4⃣ Контролируйте и удаляйте неиспользуемые shader variants и keywords.
Для этого можно использовать UnityDataTools - удобная тулза, которая распаковывает все ассеты из билда.
В случае если не удается избежать большого количества вариантов, прогревайте ваши шейдеры, чтобы избежать спайков на
5⃣ Project Auditor станет частью unity.
Это пакет, который анализирует ассеты, код, шейдеры, настройки и подсказывает на что нужно обратить внимание.
Эта тулза изначально была разработана одной из unity команд, которая отвечает за анализ и предоставлению рекомендаций по улучшению проекта.
Такая техническая консультация для пользователей enterprise версий.
Я это к тому что советы и рекомендации, которые вы там увидите, я видел во многих репортах от unity об анализе проектов😅
Да вот и все, каких-то новых открытий лично для меня не было.
База базовая. Или нет🤔
Дайте знать в комментариях!
Ставь 👍, если тебе по кайфу такая движуха
#unite2025
Мне бы очень хотелось поделиться с вами какими-то советами по оптимизации, что я услышал на докладах, но наверное в действие вступает проклятие знаний и мне кажется что все это я уже знаю и пробовал.
Вот текстовая выжимка советов, что рекомендуют сами unity и другие разработчики:
1⃣ Отключайте Domain Reload для более быстрого запуска приложения.
Если есть баги связанные с сохранением старых значений в
static переменных, делайте статический метод с атрибутом InitializeOnLoadMethod.Не забудьте
#if UNITY_EDITOR обернуть, иначе сборка билда упададет.2⃣ Unity постоянно улучшают тулзы для профайлинга, он остановится проще и более информативным.
Чекните свежие версии 6.2, 6.3 (сейчас в бете), они добавили Highlights, которые помечают "долгие" кадры на которые стоит обратить внимание.
https://unity.com/features/profiling
3⃣ Если проект долго компилируется, можно при помощи Compilation Visualizer можно посмотреть порядок и время компиляции каждой asmdef в проекте.
Но скажу честно, сделать что-то с временем компиляции сложно.
Нужно либо значительно снижать количество asmdef в проекте, либо уменьшать количество кода
4⃣ Контролируйте и удаляйте неиспользуемые shader variants и keywords.
Для этого можно использовать UnityDataTools - удобная тулза, которая распаковывает все ассеты из билда.
В случае если не удается избежать большого количества вариантов, прогревайте ваши шейдеры, чтобы избежать спайков на
Instantiate.5⃣ Project Auditor станет частью unity.
Это пакет, который анализирует ассеты, код, шейдеры, настройки и подсказывает на что нужно обратить внимание.
Эта тулза изначально была разработана одной из unity команд, которая отвечает за анализ и предоставлению рекомендаций по улучшению проекта.
Такая техническая консультация для пользователей enterprise версий.
Я это к тому что советы и рекомендации, которые вы там увидите, я видел во многих репортах от unity об анализе проектов
Да вот и все, каких-то новых открытий лично для меня не было.
База базовая. Или нет
Дайте знать в комментариях!
Ставь 👍, если тебе по кайфу такая движуха
#unite2025
Please open Telegram to view this post
VIEW IN TELEGRAM
👍71🔥16
Ищешь работу?
Я полтора года проработал в компании Datasakura, где работал над:
🔸Cut The Rope Daily: 1M+ скачиваний и фичеринг с Netflix🤯
🔸Overcrowded: Tycoon: 5M+ скачиваний
Это было отличное время, когда тебе как специалисту доверяют и не мучают кучей созвонов и бюрократией.
И сейчас они к себе набирают сильных, самостоятельных и ответственных unity разработчиков middle+ и senior уровня🫡
🔹Что будете делать?
Вы будете становиться частью разных команд в разных компаниях и разрабатывать проекты с нуля и поддерживать уже имеющиеся проекты.
Я знаком с CEO, мы в хороших отношениях и он по братски попросил закинуть новость в канал, чтобы ускорить набор людей на новый проект🫡
🔻Я знаю что на меня подписано много классных и сильных специалистов, так что если вы вдруг ищете работу, отправляйте ваше CV @mary_yad с текстом:
Не разработчик, но работаешь с unity?
— Не беда, зайди на карьерную страницу, может там что-то подходящее найдешь🫡
И надеюсь что у вас получится попасть в замечательную компанию🥄
Я уже не работаю там, но буду рад ответить на любые вопросы в комментариях 👍
#рекомендации@UniArchitect
Я полтора года проработал в компании Datasakura, где работал над:
🔸Cut The Rope Daily: 1M+ скачиваний и фичеринг с Netflix
🔸Overcrowded: Tycoon: 5M+ скачиваний
Это было отличное время, когда тебе как специалисту доверяют и не мучают кучей созвонов и бюрократией.
И сейчас они к себе набирают сильных, самостоятельных и ответственных unity разработчиков middle+ и senior уровня
🔹Что будете делать?
Вы будете становиться частью разных команд в разных компаниях и разрабатывать проекты с нуля и поддерживать уже имеющиеся проекты.
Я знаком с CEO, мы в хороших отношениях и он по братски попросил закинуть новость в канал, чтобы ускорить набор людей на новый проект
🔻Я знаю что на меня подписано много классных и сильных специалистов, так что если вы вдруг ищете работу, отправляйте ваше CV @mary_yad с текстом:
Я классный middle+/senior разраб на unity. Пришел по рекомендации от Лёши, давайте попробуем поработать вместе 😊
Не разработчик, но работаешь с unity?
— Не беда, зайди на карьерную страницу, может там что-то подходящее найдешь
И надеюсь что у вас получится попасть в замечательную компанию
Я уже не работаю там, но буду рад ответить на любые вопросы в комментариях 👍
#рекомендации@UniArchitect
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥25👍8
YouTube
Ярослав Шабанец: Клиентская архитектура корпораций
Ярослав Шабанец — клиентский архитектор в компании Playtika.
Подписывайся на мой блог в Telegram: https://news.1rj.ru/str/+VAbytHEBGYMzYjAy
На #unite2025 я времени зря не терял и успел записать несколько интервью с разными интересными людьми.
Именно под его руководством…
Подписывайся на мой блог в Telegram: https://news.1rj.ru/str/+VAbytHEBGYMzYjAy
На #unite2025 я времени зря не терял и успел записать несколько интервью с разными интересными людьми.
Именно под его руководством…
Интервью:
Клиентская архитектура корпораций
На unite 2025 я времени зря не терял и успел записать несколько интервью с разными интересными людьми.
В первом интервью я общался с Ярославом Шабанцом — клиентский архитектор в компании Playtika.
Именно под его руководством получилось "уговорить" Unity добавить в движок поддержку HTTP/2 для UnityWebRequest😈
👇👇👇
Ссылка на видео
👆👆👆
Прикольно замечать как одного уровня профессионалы с разным опытом и бэкграундом склонны приходить к одинаковым или похожим решениям.
Может показаться что мы заранее договорились о том, что и как мы будем отвечать, но еще задолго до интервью, на некоторые темы затронутые темы я писал посты:
🔸 СТРУКТУРА ПРОЕКТА
🔸 СТРУКТУРА СБОРОК
🔸 (А|а)рхитектура
🔸 ПРОЕКТИРОВАНИЕ: С ЧЕГО НАЧИНАТЬ
Приятного просмотра🫡
Ты знаешь кому переслать этот пост 👍
#unite2025@UniArchitect
#интервью@UniArchitect
Клиентская архитектура корпораций
На unite 2025 я времени зря не терял и успел записать несколько интервью с разными интересными людьми.
В первом интервью я общался с Ярославом Шабанцом — клиентский архитектор в компании Playtika.
Именно под его руководством получилось "уговорить" Unity добавить в движок поддержку HTTP/2 для UnityWebRequest
👇👇👇
Ссылка на видео
👆👆👆
Прикольно замечать как одного уровня профессионалы с разным опытом и бэкграундом склонны приходить к одинаковым или похожим решениям.
Может показаться что мы заранее договорились о том, что и как мы будем отвечать, но еще задолго до интервью, на некоторые темы затронутые темы я писал посты:
🔸 СТРУКТУРА ПРОЕКТА
🔸 СТРУКТУРА СБОРОК
🔸 (А|а)рхитектура
🔸 ПРОЕКТИРОВАНИЕ: С ЧЕГО НАЧИНАТЬ
Приятного просмотра
Ты знаешь кому переслать этот пост 👍
#unite2025@UniArchitect
#интервью@UniArchitect
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥19👍13
YouTube
Dzmitry Bazyleu: Архитектура Open Source Проектов
Dzmitry Bazyleu - разработчик плагина UniState, который имеет более 200⭐️ на GitHub.
Подписывайся на мой блог в Telegram: https://news.1rj.ru/str/+-kA-r9nWBvI2NTBi
Второе интервью, которое я успел снять на #Unite2025. На этот раз поговорили о том как создать, сколько…
Подписывайся на мой блог в Telegram: https://news.1rj.ru/str/+-kA-r9nWBvI2NTBi
Второе интервью, которое я успел снять на #Unite2025. На этот раз поговорили о том как создать, сколько…
Интервью:
Архитектура Open Source проектов
Второе интервью, которое я успел записать на Unite 2025.
На этот раз пообщался с Dzmitry Bazyleu — разработчик плагина UniState 200+⭐️ на GitHub.
Я постарался задавать вопросы, которые редко звучат в инфо пространстве, но которыми начинаешь задаваться когда ведешь разработку своего Open Source проекта:
🔸Как стартануть и не забросить open source проект?
🔸Какие архитектуреные решения нужно принять при старте open source проекта?
👇👇👇
Ссылка на видео
👆👆👆
У меня так же есть пара прикольных проектов в Open Source, где есть все элементы, которые мы обсудили с Димой:
🔸FastMigrations.Json.Net - плагин для миграции json файлов
🔸Unity Empty Project Template - шаблон пустого unity проекта
Ставь 👍 если тебе по кайфу такая движуха
#unite2025
#интервью@UniArchitect
Архитектура Open Source проектов
Второе интервью, которое я успел записать на Unite 2025.
На этот раз пообщался с Dzmitry Bazyleu — разработчик плагина UniState 200+⭐️ на GitHub.
Я постарался задавать вопросы, которые редко звучат в инфо пространстве, но которыми начинаешь задаваться когда ведешь разработку своего Open Source проекта:
🔸Как стартануть и не забросить open source проект?
🔸Какие архитектуреные решения нужно принять при старте open source проекта?
👇👇👇
Ссылка на видео
👆👆👆
У меня так же есть пара прикольных проектов в Open Source, где есть все элементы, которые мы обсудили с Димой:
🔸FastMigrations.Json.Net - плагин для миграции json файлов
🔸Unity Empty Project Template - шаблон пустого unity проекта
Ставь 👍 если тебе по кайфу такая движуха
#unite2025
#интервью@UniArchitect
👍34🔥10💯4💩1
CoreCLR в Unity - это круто🫡
Ты написал программу на C#, скомпилировал, получил .exe. Запускаешь — а Windows говорит "requires .NET Runtime". Почему?
Потому что C# компилируется не в машинный код, а в IL.
Windows не умеет его исполнять напрямую.
Нужен "движок исполнения" — runtime, который ты устанавливаешь отдельно (или он идёт bundled с приложением).
Runtime берёт IL и превращает в работающую программу.
Он определяет как каждый объект размещён в памяти, когда эта память освобождается, как вызываются виртуальные методы, как работают generics.
🔸Ключевые компоненты
▫️ Type System — хранит информацию о типах в памяти. Layout объекта: сначала Object Header (индекс SyncBlock для lock/hash), затем указатель на MethodTable.
Пример:
Если интерфейс в списке — true. Для классов ещё проще: проход по цепочке Parent MethodTable.
Всё это O(1) или O(глубина наследования).
▫️ Virtual Machine (Execution Engine) — сердце runtime. Управляет потоками, загрузкой типов, виртуальными вызовами, координирует все подсистемы
▫️ JIT Compiler — компилирует IL в машинный код
▫️ Garbage Collector — управляет памятью, решает когда освобождать объекты
▫️ Interop — мост между managed и native кодом
🔸Почему это важно для Unity. Domain Reload.
Меняешь скрипт — Unity перезагружает весь managed домен. Выгружает ВСЕ сборки, пересоздаёт ВСЕ типы. На большом проекте это десятки секунд после каждого изменения.
CoreCLR предоставляет AssemblyLoadContext (ALC) — механизм изоляции сборок. Как это работает:
🔹Default ALC загружает framework и core assemblies — они живут всё время
🔹Custom ALC может загружать пользовательские сборки изолированно
🔹Collectible ALC позволяет выгружать сборки когда они больше не нужны
Т.е. вместо "выгрузить всё и загрузить заново" можно:
🔻 Вот и 1 пункт почему переход на CoreCLR это круто - время Domain Reload может снизится в десятки или сотни раз, что == увеличению скорости итерации😎
Дальше — как устроены Mono, IL2CPP и CoreCLR изнутри.
Ставь 👍 если тебе заходит такого рода контент!
Ты знаешь кому переслать эту статью 💪
#unite2025@UniArchitect
#проект_в_разработке@UniArchitect
Ты написал программу на C#, скомпилировал, получил .exe. Запускаешь — а Windows говорит "requires .NET Runtime". Почему?
Потому что C# компилируется не в машинный код, а в IL.
Windows не умеет его исполнять напрямую.
Нужен "движок исполнения" — runtime, который ты устанавливаешь отдельно (или он идёт bundled с приложением).
Runtime берёт IL и превращает в работающую программу.
Он определяет как каждый объект размещён в памяти, когда эта память освобождается, как вызываются виртуальные методы, как работают generics.
🔸Ключевые компоненты
▫️ Type System — хранит информацию о типах в памяти. Layout объекта: сначала Object Header (индекс SyncBlock для lock/hash), затем указатель на MethodTable.
Пример:
obj is IMyInterface. Runtime берёт MethodTable объекта (первое поле после header), смотрит в Interface Map — массив интерфейсов которые тип реализует.Если интерфейс в списке — true. Для классов ещё проще: проход по цепочке Parent MethodTable.
Всё это O(1) или O(глубина наследования).
▫️ Virtual Machine (Execution Engine) — сердце runtime. Управляет потоками, загрузкой типов, виртуальными вызовами, координирует все подсистемы
▫️ JIT Compiler — компилирует IL в машинный код
▫️ Garbage Collector — управляет памятью, решает когда освобождать объекты
▫️ Interop — мост между managed и native кодом
🔸Почему это важно для Unity. Domain Reload.
Меняешь скрипт — Unity перезагружает весь managed домен. Выгружает ВСЕ сборки, пересоздаёт ВСЕ типы. На большом проекте это десятки секунд после каждого изменения.
CoreCLR предоставляет AssemblyLoadContext (ALC) — механизм изоляции сборок. Как это работает:
🔹Default ALC загружает framework и core assemblies — они живут всё время
🔹Custom ALC может загружать пользовательские сборки изолированно
🔹Collectible ALC позволяет выгружать сборки когда они больше не нужны
Т.е. вместо "выгрузить всё и загрузить заново" можно:
Cоздать новый ALC → загрузить изменённую сборку → переключить ссылки → выгрузить старый ALC. Framework, Unity assemblies, неизменённые скрипты остаются на месте.
🔻 Вот и 1 пункт почему переход на CoreCLR это круто - время Domain Reload может снизится в десятки или сотни раз, что == увеличению скорости итерации
Дальше — как устроены Mono, IL2CPP и CoreCLR изнутри.
Ставь 👍 если тебе заходит такого рода контент!
Ты знаешь кому переслать эту статью 💪
#unite2025@UniArchitect
#проект_в_разработке@UniArchitect
Please open Telegram to view this post
VIEW IN TELEGRAM
👍191🔥9💩2
Mono vs CoreCLR
Последние несколько лет я много писал серверного кода на dotnet, и меня постоянно радовала скорость итерации.
Делаешь изменение — почти моментально получаешь отклик. В Unity это всегда боль.
Я постоянно стараюсь работать так, чтобы как можно реже триггерить Domain Reload.
Эта штука на каждое, даже мелкое изменение отнимает десятки секунд.
Если взять обычный день и просто посчитать время на ожидание — легко набегут десятки минут.
🔸Почему так происходит?
Редактор Unity на всех платформах работает на Mono — старом кроссплатформенном runtime. В его основе лежит JIT-компиляция.
Когда вызывается твой метод первый раз, туда прописан вызов JIT-компилятора.
Он берёт IL-код метода, конвертирует в Mono IR (внутреннее представление Mono), оптимизирует, и только после этого генерирует инструкции для конкретного процессора.
Казалось бы, при чём тут мы? А при том, что Mono JIT — операция не бесплатная. И в редакторе она обходится очень дорого.
🔸Domain Reload
Его порядок работы примерно такой:
1️⃣ Находим все MonoBehaviour и вызываем OnDisable/OnDestroy
2⃣ Выгружаем все *.dll движка и наши
3⃣ Освобождаем GC Handles и выгружаем Domain
4⃣ Создаём новый Domain и загружаем все *.dll движка
5⃣ Загружаем все *.dll игрока
6⃣ Запускаем скрипты с [InitializeOnLoad]
7⃣ На пересозданных MonoBehaviour вызываем Awake/OnEnable
На моём проекте Magic Battle Arena (~100к строк кода, 149 сборок) эти 7 пунктов занимают 12 секунд.
Угадайте какая операция самая долгая?
Mono JIT — примерно 5.5 секунд в сумме.
Это происходит потому, что мы вынуждены полностью выгрузить ВСЕ *.dll (для которых методы уже скомпилированы) и перекомпилировать их заново.
🔸Почему это нельзя исправить в Mono
Проблема фундаментальная. В Mono нет механизма hot swap для сборок. Нельзя сказать "выгрузи только эту dll и загрузи новую версию".
Только полная перезагрузка домена.
CoreCLR решает это через AssemblyLoadContext, см. прошлый пост
🔸RyuJIT vs Mono JIT
Но даже если Unity не реализует hot reload, сам JIT-компилятор CoreCLR (RyuJIT) работает иначе.
Mono JIT — однопроходный. Скомпилировал метод один раз — живи с этим. Хочешь лучше? Используй AOT.
RyuJIT поддерживает Tiered Compilation:
🔹Tier 0: быстрая компиляция без оптимизаций (для быстрого старта)
🔹Tier 1: метод был вызван более 30 раз и более? — Оптимизируем его
Т.е. при Domain Reload методы сначала компилируются максимально быстро, а потом в фоне докомпилируются с оптимизациями.
Время ожидания сокращается, performance не страдает.
Но выиграем мы от смены JIT компилятора, я уверен не так много, как c перехода с Domain Reload на Code Reload.
🔻Мой прогноз:
Время Domain Reload снизится минимум на 75%.
В моём примере — с 12 секунд до 3. Останутся только вызовы Awake/Destroy и десериализация состояния сцен.
Проверим в2025 2026 или 2027 году 🤣
Теперь ты знаешь что загадать на Новый Год😊
Ставь 👍 если тебе заходит такого рода контент!
Ты знаешь кому переслать эту статью 💪
#unite2025@UniArchitect
#проект_в_разработке@UniArchitect
Последние несколько лет я много писал серверного кода на dotnet, и меня постоянно радовала скорость итерации.
Делаешь изменение — почти моментально получаешь отклик. В Unity это всегда боль.
Я постоянно стараюсь работать так, чтобы как можно реже триггерить Domain Reload.
Эта штука на каждое, даже мелкое изменение отнимает десятки секунд.
Если взять обычный день и просто посчитать время на ожидание — легко набегут десятки минут.
🔸Почему так происходит?
Редактор Unity на всех платформах работает на Mono — старом кроссплатформенном runtime. В его основе лежит JIT-компиляция.
Когда вызывается твой метод первый раз, туда прописан вызов JIT-компилятора.
Он берёт IL-код метода, конвертирует в Mono IR (внутреннее представление Mono), оптимизирует, и только после этого генерирует инструкции для конкретного процессора.
Казалось бы, при чём тут мы? А при том, что Mono JIT — операция не бесплатная. И в редакторе она обходится очень дорого.
🔸Domain Reload
Его порядок работы примерно такой:
1️⃣ Находим все MonoBehaviour и вызываем OnDisable/OnDestroy
2⃣ Выгружаем все *.dll движка и наши
3⃣ Освобождаем GC Handles и выгружаем Domain
4⃣ Создаём новый Domain и загружаем все *.dll движка
5⃣ Загружаем все *.dll игрока
6⃣ Запускаем скрипты с [InitializeOnLoad]
7⃣ На пересозданных MonoBehaviour вызываем Awake/OnEnable
На моём проекте Magic Battle Arena (~100к строк кода, 149 сборок) эти 7 пунктов занимают 12 секунд.
Угадайте какая операция самая долгая?
Это происходит потому, что мы вынуждены полностью выгрузить ВСЕ *.dll (для которых методы уже скомпилированы) и перекомпилировать их заново.
🔸Почему это нельзя исправить в Mono
Проблема фундаментальная. В Mono нет механизма hot swap для сборок. Нельзя сказать "выгрузи только эту dll и загрузи новую версию".
Только полная перезагрузка домена.
CoreCLR решает это через AssemblyLoadContext, см. прошлый пост
🔸RyuJIT vs Mono JIT
Но даже если Unity не реализует hot reload, сам JIT-компилятор CoreCLR (RyuJIT) работает иначе.
Mono JIT — однопроходный. Скомпилировал метод один раз — живи с этим. Хочешь лучше? Используй AOT.
RyuJIT поддерживает Tiered Compilation:
🔹Tier 0: быстрая компиляция без оптимизаций (для быстрого старта)
🔹Tier 1: метод был вызван более 30 раз и более? — Оптимизируем его
Т.е. при Domain Reload методы сначала компилируются максимально быстро, а потом в фоне докомпилируются с оптимизациями.
Время ожидания сокращается, performance не страдает.
Но выиграем мы от смены JIT компилятора, я уверен не так много, как c перехода с Domain Reload на Code Reload.
🔻Мой прогноз:
Время Domain Reload снизится минимум на 75%.
В моём примере — с 12 секунд до 3. Останутся только вызовы Awake/Destroy и десериализация состояния сцен.
Проверим в
Теперь ты знаешь что загадать на Новый Год
Ставь 👍 если тебе заходит такого рода контент!
Ты знаешь кому переслать эту статью 💪
#unite2025@UniArchitect
#проект_в_разработке@UniArchitect
Please open Telegram to view this post
VIEW IN TELEGRAM
👍81🔥8💯2
ПРОЕКТИРОВАНИЕ: КОНТЕЙНЕРЫ
Многие хотят попробовать себя в роли архитекторов, но не очень понимают с чего начать.
Много раз видел как программисты, желая показать "архитектуру", отдавали схемы классов и связей между ними, думая что этого достаточно.
Проблема в том, что схема классов — это уровень кода. Самый последний уровень, который избыточен и не нужен.
Начинать проектирование с него — всё равно что строить дом, начиная с выбора дверных ручек.
В прошлой статье мы разобрали первый уровень модели C4 — System Context.
Он общий почти для всех игр на Unity, достаточно абстрактный и содержит мало конкретики.
Сегодня поговорим про второй уровень — контейнеры.
🔸Что такое контейнер
Контейнер в модели C4 (никак не связано с Docker!) — это приложение или хранилище данных. То, что должно быть запущено для работы всей программной системы.
Ключевой критерий: контейнер — это независимо деплоемая единица.
Примеры контейнеров:
▫️ Серверное приложение — http или любой другой сервер с логикой системы
▫️ Клиентское web-приложение — админка для управления данными пользователей
▫️ Мобильное приложение — бинарник, который пользователь скачивает на телефон
▫️ База данных — SQL или NoSQL решение для хранения данных игроков
Т.е. после того как у тебя готов общий уровень системы, ты определяешься какие элементы будут публиковаться и деплоиться независимо друг от друга.
Берёшь каждый элемент системы и разбиваешь его на отдельные деплоемые части.
🔸Пример: сервер для маленького проекта
Вот как бы я принимал решение о том, как сделать небольшой игровой сервер (< 100k скачиваний и 1k DAU).
Прикинем нагрузку. RPS на таких объёмах будет достаточно низкий:
Одного экземпляра http сервера на любой технологии будет более чем достаточно.
Значит всё серверное приложение — это 1 docker image, который можно опубликовать в Yandex/Google/Amazon Compute Cloud.
Сделав так для каждого элемента системы, ты получаешь понимание какие части как будут деплоиться.
Это формирует достаточное понимание того, как вся система будет функционировать.
🔸Практические рекомендации
🔹 На крупных проектах может быть огромное количество элементов. Нет смысла упарываться в детализацию всех контейнеров всех элементов системы. Указывай только то, что нужно конкретному проектируемому элементу. Зависимости вне твоей зоны ответственности уточнять не нужно.
Пример из Hero Wars: для чата мы используем MQTT сервис, на топики которого подписывается клиент чтобы получать новые сообщения. Когда я проектировал чат, я не уточнял из чего состоит MQTT сервис и что он использует внутри — это избыточно и вне моей зоны ответственности.
🔹 На этом этапе полезно прописывать технологии, если они важны для проектируемого сервиса.
Для того же чата на серверной стороне для общения сервисов между собой используется Kafka.
Решение о том как организовано взаимодействие сервисов уже принято — указываем конкретную технологию, упрощаем схему и делаем её более информативной.
🔹 Unity-клиент на этом уровне детально не проектируется.
Любое Unity приложение — это монолит и всего 1 деплоемый unit.
Максимум что можно указать на схеме — платформы куда деплоимся. Но в большинстве случаев это избыточно.
🔻Проектирование можно и нужно начинать с двух простых шагов: сначала система и её ключевые элементы, затем уточнение каждого элемента деплоемыми unit'ами и технологиями.
Так ты получаешь не просто каркас, а полноценное верхнеуровневое понимание функционирования всего приложения.
Это вторая статья серии про проектирование. Дальше: компоненты и код.
Ставь 👍 если тебе заходит такого рода контент!
Ты знаешь кому переслать эту статью 💪
#проектирование@UniArchitect
Многие хотят попробовать себя в роли архитекторов, но не очень понимают с чего начать.
Много раз видел как программисты, желая показать "архитектуру", отдавали схемы классов и связей между ними, думая что этого достаточно.
Проблема в том, что схема классов — это уровень кода. Самый последний уровень, который избыточен и не нужен.
Начинать проектирование с него — всё равно что строить дом, начиная с выбора дверных ручек.
В прошлой статье мы разобрали первый уровень модели C4 — System Context.
Он общий почти для всех игр на Unity, достаточно абстрактный и содержит мало конкретики.
Сегодня поговорим про второй уровень — контейнеры.
🔸Что такое контейнер
Контейнер в модели C4 (никак не связано с Docker!) — это приложение или хранилище данных. То, что должно быть запущено для работы всей программной системы.
Ключевой критерий: контейнер — это независимо деплоемая единица.
Примеры контейнеров:
▫️ Серверное приложение — http или любой другой сервер с логикой системы
▫️ Клиентское web-приложение — админка для управления данными пользователей
▫️ Мобильное приложение — бинарник, который пользователь скачивает на телефон
▫️ База данных — SQL или NoSQL решение для хранения данных игроков
Т.е. после того как у тебя готов общий уровень системы, ты определяешься какие элементы будут публиковаться и деплоиться независимо друг от друга.
Берёшь каждый элемент системы и разбиваешь его на отдельные деплоемые части.
🔸Пример: сервер для маленького проекта
Вот как бы я принимал решение о том, как сделать небольшой игровой сервер (< 100k скачиваний и 1k DAU).
Прикинем нагрузку. RPS на таких объёмах будет достаточно низкий:
1000 [игроков] / 24 [ч] / 60 [мин] / 60 [сек] ≈ 0.01 req/sec
Одного экземпляра http сервера на любой технологии будет более чем достаточно.
Значит всё серверное приложение — это 1 docker image, который можно опубликовать в Yandex/Google/Amazon Compute Cloud.
Сделав так для каждого элемента системы, ты получаешь понимание какие части как будут деплоиться.
Это формирует достаточное понимание того, как вся система будет функционировать.
🔸Практические рекомендации
🔹 На крупных проектах может быть огромное количество элементов. Нет смысла упарываться в детализацию всех контейнеров всех элементов системы. Указывай только то, что нужно конкретному проектируемому элементу. Зависимости вне твоей зоны ответственности уточнять не нужно.
Пример из Hero Wars: для чата мы используем MQTT сервис, на топики которого подписывается клиент чтобы получать новые сообщения. Когда я проектировал чат, я не уточнял из чего состоит MQTT сервис и что он использует внутри — это избыточно и вне моей зоны ответственности.
🔹 На этом этапе полезно прописывать технологии, если они важны для проектируемого сервиса.
Для того же чата на серверной стороне для общения сервисов между собой используется Kafka.
Решение о том как организовано взаимодействие сервисов уже принято — указываем конкретную технологию, упрощаем схему и делаем её более информативной.
🔹 Unity-клиент на этом уровне детально не проектируется.
Любое Unity приложение — это монолит и всего 1 деплоемый unit.
Максимум что можно указать на схеме — платформы куда деплоимся. Но в большинстве случаев это избыточно.
🔻Проектирование можно и нужно начинать с двух простых шагов: сначала система и её ключевые элементы, затем уточнение каждого элемента деплоемыми unit'ами и технологиями.
Так ты получаешь не просто каркас, а полноценное верхнеуровневое понимание функционирования всего приложения.
Это вторая статья серии про проектирование. Дальше: компоненты и код.
Ставь 👍 если тебе заходит такого рода контент!
Ты знаешь кому переслать эту статью 💪
#проектирование@UniArchitect
👍41🔥21
CORECLR VS IL2CPP
Это последняя статья из цикла: "CoreCLR - это круто", где я стараюсь рассказать про основные, важные изменения, которые CoreCLR может превнести.
Предыдущие статьи: раз, два.
На этот раз поговорим про различия в runtime'ах, которые непосредственно исполняются на пользовательских девайсах (а не в редакторе, как в прошлых статьях).
🔸VTable
Когда вызываешь виртуальный метод, runtime должен понять какой именно код исполнить.
У базового класса и наследника методы разные, но вызов📞 выглядит одинаково.
VTable — это массив указателей на методы. Каждый тип хранит свою таблицу.
Вызов виртуального метода = взять указатель из таблицы по номеру слота и сделать jmp на значение указателя в слоте.
🔸Где IL2CPP добавляет работы
В CoreCLR vtable — просто массив указателей на код. 8 байт на слот.
В IL2CPP каждый слот содержит ДВА указателя: на код и на метаданные. 16 байт.
Зачем? IL2CPP — это AOT. Нет JIT, который достроил бы информацию в runtime. Всё предсгенерировано заранее.
Но главное размер. CoreCLR разделяет информацию о типе на "горячую" (MethodTable — только для исполнения) и "холодную" (EEClass: reflection, interop).
При виртуальном вызове CPU загружает в кэш только MethodTable.
IL2CPP держит всё в одной Il2CppClass — 200+ байт.
При частых вызовах методов разных типов процессор постоянно выгружает одни данные из кэша и загружает другие.
Отсюда и сложно писать производительный код без Burst: ты теряешь контроль над тем, что по факту у тебя исполняется на устройстве😬
🔸Interface Dispatch — тут разница огромная
Интерфейсы сложнее классов. Один тип может реализовать много интерфейсов, и runtime должен найти нужную реализацию по указателю на интерфейс.
IL2CPP хранит массив interfaceOffsets — пары "указатель на интерфейс + смещение в vtable".
При каждом вызове метода интерфейса il2cpp идёт циклом по этому массиву, сравнивая указатели:
Линейный поиск короче.
Можешь посмотреть сам, файл:
Т.е. если тип реализует 5 интерфейсов — в среднем 2-3 сравнения указателей. 20 интерфейсов — ~10 сравнений.
С одной стороны копеечки, а с другой часто от других разрабов слышу что это всегда jmp на указатель с кодом🤔
CoreCLR же использует Virtual Stub Dispatch.
При первом вызове генерируется stub — кусок машинного кода, который запоминает результат поиска.
Все последующие вызовы — один jmp без цикла. O(1).
Т.е. IL2CPP платит за каждый interface-вызов, CoreCLR — только за первый.
🔸GC
IL2CPP сидит на Boehm GC — консервативный сборщик без поколений и без уплотнения памяти. Объекты никогда не перемещаются. При долгих сессиях память фрагментируется, для аллокации идет поиск "дырок" в free list.
И тут можно долго говорить о различиях, но самое крутое — это наличие Background GC в CoreCLR.
Если эту штуку смогут хотябы частично адаптировать под unity будет пушка бомба.
Меньше заботы о spike'ах при работе GC это всегда приятно😊
И вот тут прикольно:
Большая часть "рекомендаций" с оптимизациями и уменьшению аллокаций с переходом CoreCLR могут кардинально измениться и начнется снова рассвет полезных постов с лайфхаками в соц. сетях😬
🔻 Для тех кто задавался вопросом: "Чего так все с этим CoreCLR бегают?", мой короткий ответ:
Ну и просто если у unity получится, unity ведь один из самых часто-используемых движков и успех может значительно укрепить доверие компаний и разработчиков.
Но, мне кажется, у них значительно лучше получается делать как раз наоборот🤣
Ставь 😁 если задушил жестко и надо проще или 👍 если все норм и тебе заходит такой контент!
#unite2025@UniArchitect
#проект_в_разработке@UniArchitect
Это последняя статья из цикла: "CoreCLR - это круто", где я стараюсь рассказать про основные, важные изменения, которые CoreCLR может превнести.
Предыдущие статьи: раз, два.
На этот раз поговорим про различия в runtime'ах, которые непосредственно исполняются на пользовательских девайсах (а не в редакторе, как в прошлых статьях).
🔸VTable
Когда вызываешь виртуальный метод, runtime должен понять какой именно код исполнить.
У базового класса и наследника методы разные, но вызов
VTable — это массив указателей на методы. Каждый тип хранит свою таблицу.
Вызов виртуального метода = взять указатель из таблицы по номеру слота и сделать jmp на значение указателя в слоте.
🔸Где IL2CPP добавляет работы
В CoreCLR vtable — просто массив указателей на код. 8 байт на слот.
В IL2CPP каждый слот содержит ДВА указателя: на код и на метаданные. 16 байт.
Зачем? IL2CPP — это AOT. Нет JIT, который достроил бы информацию в runtime. Всё предсгенерировано заранее.
Но главное размер. CoreCLR разделяет информацию о типе на "горячую" (MethodTable — только для исполнения) и "холодную" (EEClass: reflection, interop).
При виртуальном вызове CPU загружает в кэш только MethodTable.
IL2CPP держит всё в одной Il2CppClass — 200+ байт.
При частых вызовах методов разных типов процессор постоянно выгружает одни данные из кэша и загружает другие.
Отсюда и сложно писать производительный код без Burst: ты теряешь контроль над тем, что по факту у тебя исполняется на устройстве
🔸Interface Dispatch — тут разница огромная
Интерфейсы сложнее классов. Один тип может реализовать много интерфейсов, и runtime должен найти нужную реализацию по указателю на интерфейс.
IL2CPP хранит массив interfaceOffsets — пары "указатель на интерфейс + смещение в vtable".
При каждом вызове метода интерфейса il2cpp идёт циклом по этому массиву, сравнивая указатели:
if (interfaceOffsets[i].interfaceType == declaringInterface)
Линейный поиск короче.
Можешь посмотреть сам, файл:
ClassInlines.h в исходниках il2cpp.Т.е. если тип реализует 5 интерфейсов — в среднем 2-3 сравнения указателей. 20 интерфейсов — ~10 сравнений.
С одной стороны копеечки, а с другой часто от других разрабов слышу что это всегда jmp на указатель с кодом
CoreCLR же использует Virtual Stub Dispatch.
При первом вызове генерируется stub — кусок машинного кода, который запоминает результат поиска.
Все последующие вызовы — один jmp без цикла. O(1).
Т.е. IL2CPP платит за каждый interface-вызов, CoreCLR — только за первый.
🔸GC
IL2CPP сидит на Boehm GC — консервативный сборщик без поколений и без уплотнения памяти. Объекты никогда не перемещаются. При долгих сессиях память фрагментируется, для аллокации идет поиск "дырок" в free list.
И тут можно долго говорить о различиях, но самое крутое — это наличие Background GC в CoreCLR.
Если эту штуку смогут хотябы частично адаптировать под unity будет пушка бомба.
Меньше заботы о spike'ах при работе GC это всегда приятно
И вот тут прикольно:
Большая часть "рекомендаций" с оптимизациями и уменьшению аллокаций с переходом CoreCLR могут кардинально измениться и начнется снова рассвет полезных постов с лайфхаками в соц. сетях
🔻 Для тех кто задавался вопросом: "Чего так все с этим CoreCLR бегают?", мой короткий ответ:
Та прост эта штука может оч сильно изменить подход к тому как мы привыкли писать код под unity.
Ну и просто если у unity получится, unity ведь один из самых часто-используемых движков и успех может значительно укрепить доверие компаний и разработчиков.
Но, мне кажется, у них значительно лучше получается делать как раз наоборот
Ставь 😁 если задушил жестко и надо проще или 👍 если все норм и тебе заходит такой контент!
#unite2025@UniArchitect
#проект_в_разработке@UniArchitect
Please open Telegram to view this post
VIEW IN TELEGRAM
👍93
Хочешь делать игры, но не знаешь, как получить инвестиции
По своему опыту скажу, что на старте в геймдеве сложнее всего не собрать первый билд, а понять, как развивать проект, искать команду и выходить с предложением к инвесторам. Идей может быть много, но найти того, кто в них поверит – нетривиальная задача.
Можно попробовать реализовать задуманное самостоятельно, но вероятность успеха будет не слишком высокой. Неплохая альтернатива – нетворкинг, но процесс может растянуться на неопределенный срок. И третий вариант - поучаствовать в акселераторе. Сейчас вот открыли опен-колл на седьмой сезон «Фабрики видеоигр» от Московского кластера видеоигр. Можно подать заявку с идеей игры, прототипом или готовой демо-версией, причем и соло-разработчикам, и небольшим командам, и студиям.
Что внутри акселератора?:
🔸 индивидуальные встречи-консультации с топ-разработчиками и игровыми продюсерами;
🔸 онлайн-программа и доработка прототипа с менторами;
🔸 помощь в упаковке билда и подготовка к встрече с инвесторами.
Финалом станет питчинг, где лучшие проекты получат финансирование на дальнейшую разработку. За время работы «Фабрики» инди-студии привлекли уже свыше 180 млн рублей инвестиций. Многим помогли вывести проекта за пределы локального рынка.
Если хочешь послушать не только мои советы по разработке игр, то заявку можно подать до 13 февраля. Жаль, конечно, что в свое время в сибирской глубинке таких возможностей у меня не было. Много шишек бы не набил.
@UniArchitect #акселератор
По своему опыту скажу, что на старте в геймдеве сложнее всего не собрать первый билд, а понять, как развивать проект, искать команду и выходить с предложением к инвесторам. Идей может быть много, но найти того, кто в них поверит – нетривиальная задача.
Можно попробовать реализовать задуманное самостоятельно, но вероятность успеха будет не слишком высокой. Неплохая альтернатива – нетворкинг, но процесс может растянуться на неопределенный срок. И третий вариант - поучаствовать в акселераторе. Сейчас вот открыли опен-колл на седьмой сезон «Фабрики видеоигр» от Московского кластера видеоигр. Можно подать заявку с идеей игры, прототипом или готовой демо-версией, причем и соло-разработчикам, и небольшим командам, и студиям.
Что внутри акселератора?:
🔸 индивидуальные встречи-консультации с топ-разработчиками и игровыми продюсерами;
🔸 онлайн-программа и доработка прототипа с менторами;
🔸 помощь в упаковке билда и подготовка к встрече с инвесторами.
Финалом станет питчинг, где лучшие проекты получат финансирование на дальнейшую разработку. За время работы «Фабрики» инди-студии привлекли уже свыше 180 млн рублей инвестиций. Многим помогли вывести проекта за пределы локального рынка.
Если хочешь послушать не только мои советы по разработке игр, то заявку можно подать до 13 февраля. Жаль, конечно, что в свое время в сибирской глубинке таких возможностей у меня не было. Много шишек бы не набил.
@UniArchitect #акселератор
👍3🔥2
ПРИЧИНА ПРОВАЛА ПРОЕКТОВ
В Magic Battle Arena мы с партнером привлекли pre-seed раунд с runway на 1 год 2 месяца.
Я уже рассказывал об этом: раз, два, три
Думали — хватит. Рассчитывали 8 месяцев на MVP, 4 месяца на итерации.
По факту 4 месяцев хватило только начать улучшать метрики. Нужно было runway минимум в 2 раза больше.
Неверная оценка сроков стала краеугольной ошибкой, которая привела к закрытию компании.
А вот смотрите что говорит наука.
🔸Исследование 2019 года: качество кода не при чем
В 2019 году исследователи проанализировали 2171 публикацию с 1990 по 2017 год по теме провала ПО. Из них отобрали 68 наиболее релевантных и тщательно изучили.
Задача: выявить и ранжировать факторы провала IT проектов.
Как думаете, насколько техническое качество кода оказалось важным?🤓
Insignificant — ничтожно малым. Из 13 выявленных факторов technology illiteracy попала в самый низ.
А вот главный фактор:
▫️ Wrong estimation of time and cost — неверная оценка времени и стоимости
▫️ 43 из 68 исследований указали на это как основную причину провала
🔸Другое исследование: откуда берется неверная оценка?
Исследователи из Aalto University в 2014 году провели анализ корневых причин 4 случаев провала в продуктовых компаниях. Для каждого кейса строили диаграмму причинно-следственных связей — от 130 до 185 причин.
Три основные связи повторялись в 3 из 4 кейсов:
▫️ Weak Task Backlog — расплывчатые требования, неверные приоритеты
▫️ Lack of Cooperation — между отделами теряется информация, нужная для реализации и тестирования
▫️ Lack of Software Testing Resources — менеджмент недовыделяет ресурсы на тестирование
И две из трех цепочек как раз проходят через Sales & Requirements.
▫️Расплывчатые спецификации → слабый backlog → неверные приоритеты.
▫️Недостаток коммуникации → потеря информации → разработчики и тестировщики не понимают что делать.
Требования — точка, где теряется критическая информация.
🔹На Combat Quest я это ощутил на себе.
Настраивал процессы с нуля. В GD-документах постоянно пропускали краевые случаи — альтернативные сценарии использования, граничные случаи, обработку ошибок.
Результат: расширение сроков, переработки, выгорание команды😵
Код был нормальный. Проблема была в том, что мы не прогоняли сценарии использования.
▪️Тут окно нужно добавить — плюс 10 дней.
▪️Там забыли что игра делает мягкую перезагрузку при исключении.
▪️Не учли что игрок в метро и запрос обрабатывается с задержкой.
▪️Где-то просто не прописали полный список фичей и срочно добивали потом.
Именно 👆 поток нескончаемых доработок, на моем опыте, в итоге постоянно двигал deadline'ы.
🔸Сначала требования, потом диаграммы
В комментариях к статьям про проектирование правильно подмечали — первыми идут требования.
Исследования это подтверждают — 43 из 68 указали на размытые требования как корень неверной оценки.
Посмотрите на картинку из поста с определением архитектуры — именно видение заказчиков (= требования) формирует описание архитектуры и финальную систему.
Модель C4 — система и контейнеры — помогает зафиксировать требования визуально.
Показать заинтересованным сторонам что будет построено, какие элементы задействованы, как они связаны.
Но диаграмма без требований — просто картинка.
🔻 Потому оч важно выработать привычку:
😅
А о том, что должно быть в документе с требованиями — обсудим в следующей статье серии.
Ставь 👍 если тебе заходит такого рода контент!
#проектирование@UniArchitect
В Magic Battle Arena мы с партнером привлекли pre-seed раунд с runway на 1 год 2 месяца.
Я уже рассказывал об этом: раз, два, три
Думали — хватит. Рассчитывали 8 месяцев на MVP, 4 месяца на итерации.
По факту 4 месяцев хватило только начать улучшать метрики. Нужно было runway минимум в 2 раза больше.
Неверная оценка сроков стала краеугольной ошибкой, которая привела к закрытию компании.
А вот смотрите что говорит наука.
🔸Исследование 2019 года: качество кода не при чем
В 2019 году исследователи проанализировали 2171 публикацию с 1990 по 2017 год по теме провала ПО. Из них отобрали 68 наиболее релевантных и тщательно изучили.
Задача: выявить и ранжировать факторы провала IT проектов.
Как думаете, насколько техническое качество кода оказалось важным?
А вот главный фактор:
▫️ Wrong estimation of time and cost — неверная оценка времени и стоимости
▫️ 43 из 68 исследований указали на это как основную причину провала
🔸Другое исследование: откуда берется неверная оценка?
Исследователи из Aalto University в 2014 году провели анализ корневых причин 4 случаев провала в продуктовых компаниях. Для каждого кейса строили диаграмму причинно-следственных связей — от 130 до 185 причин.
Три основные связи повторялись в 3 из 4 кейсов:
▫️ Weak Task Backlog — расплывчатые требования, неверные приоритеты
▫️ Lack of Cooperation — между отделами теряется информация, нужная для реализации и тестирования
▫️ Lack of Software Testing Resources — менеджмент недовыделяет ресурсы на тестирование
И две из трех цепочек как раз проходят через Sales & Requirements.
▫️Расплывчатые спецификации → слабый backlog → неверные приоритеты.
▫️Недостаток коммуникации → потеря информации → разработчики и тестировщики не понимают что делать.
Требования — точка, где теряется критическая информация.
🔹На Combat Quest я это ощутил на себе.
Настраивал процессы с нуля. В GD-документах постоянно пропускали краевые случаи — альтернативные сценарии использования, граничные случаи, обработку ошибок.
Результат: расширение сроков, переработки, выгорание команды
Код был нормальный. Проблема была в том, что мы не прогоняли сценарии использования.
▪️Тут окно нужно добавить — плюс 10 дней.
▪️Там забыли что игра делает мягкую перезагрузку при исключении.
▪️Не учли что игрок в метро и запрос обрабатывается с задержкой.
▪️Где-то просто не прописали полный список фичей и срочно добивали потом.
Именно 👆 поток нескончаемых доработок, на моем опыте, в итоге постоянно двигал deadline'ы.
🔸Сначала требования, потом диаграммы
В комментариях к статьям про проектирование правильно подмечали — первыми идут требования.
Исследования это подтверждают — 43 из 68 указали на размытые требования как корень неверной оценки.
Посмотрите на картинку из поста с определением архитектуры — именно видение заказчиков (= требования) формирует описание архитектуры и финальную систему.
Модель C4 — система и контейнеры — помогает зафиксировать требования визуально.
Показать заинтересованным сторонам что будет построено, какие элементы задействованы, как они связаны.
Но диаграмма без требований — просто картинка.
🔻 Потому оч важно выработать привычку:
При чтении документов прокручивать варианты, когда что-то идет не по плану. Проговаривать их с командой и закладывать буфер при оценке.Ну или прогонять сценарии через GPT — ТОП вариант
А о том, что должно быть в документе с требованиями — обсудим в следующей статье серии.
Ставь 👍 если тебе заходит такого рода контент!
#проектирование@UniArchitect
Please open Telegram to view this post
VIEW IN TELEGRAM
4👍59🔥10