Unity Architect: архитектура unity проектов

AI НЕ ДЕЛАЕТ ВАС ПРОДУКТИВНЕЕ Незыблемый факт: AI уже очень хорош в маленьких задачах. Написать плагин, скрипт, небольшую tool'у, UI для UnityEditor окна, вытащить текст из аудио, накидать интеграцию с Google Sheets — вот здесь он реально экономит время. У меня таких историй уже пачка: — история буфера обмена на macOS — парсинг локализаций из Google Sheets в MySQL — извлечение текста из аудиозаписей — терминальный чат для тестирования внутриигрового чата — интеграция BenchmarkDotNet в Unity И тут спорить бессмысленно: да, это ускоряет. Многие мелкие автоматизации можно сделать буквально за 1 промпт. Когда раньше, я даже не брался за это, т.к. на отладку и написание могло уйти полдня-день. 🔸Проблема - большой production Когда я работал в Playtika, уже тогда менеджмент пытался понять, как ускорить процессы разработки через AI. Но модели упирались в контекст. Они могли решить локальную задачу, но плохо держали систему целиком. Сейчас модели стали намного сильнее. Контекст вырос. Opus уже технически способен написать кусок фичи почти полностью. Но я всё равно не готов просто взять и запушить это в большой production-проект. Почему? Потому что в проекте на сотни тысяч строк AI все равно не хватит контекста, чтобы изучить и прочитать все что есть, из-за этого: 🔹Генерируется функционал, который уже есть в проекте 🔹Системы используются не правильно или не полностью 🔹Агент может посчитать, что функция в другой системе написана не правильно и "исправить". И кажется что сделано много, так много кода и анализа никто бы из нас быстро не делал. Но из-за того что это нужно потом вычитать внимательно, проверить и/или переписать, общее время на разработку может только увеличится. 🔸И это не только мое наблюдение METR проверили это на 16 опытных open-source разработчиках, которые в среднем 5 лет работали на своих репозиториях. Результат: с AI они стали медленнее на 19% 🤯 При этом ожидания до начала эксперимента были: ускорение на 24% А после, разрабы думали что AI их ускорил на 20%. Т.е. человек делает больше и из этого создается эффект ускорения. И эти результаты нужно поправлять за Echoes of AI, где: на чужой кодобазе среднего размера AI действительно ускорял — медианное время падало на 30.7%. Т.е. получается примерно такой парадокс: 🔹 Если проект маленький или среднего размера, то с AI можно в среднем получать +30% к продуктивности 🔹 Если проект большой или огромный, то важно выделять места, где AI может быть полезен, но не отдавать все ему на откуп. Несоблюдние баланса = +20% к времени выполнения задачи. Этот вывод я и сам ощущаю, когда иной раз проще самому написать, чем промптить, а потом ходить и все переписывать. Это может показаться бредом, если опираться на новостной фон и хайпа вокруг AI. Но это отлично согласовывается даже с тем, что я писал еще до AI хайпа: Природа разработки ПО - это перенос информации из мира реального в мир абстрактный. Где человек играет ключевую и незаменимую роль. А скорость переноса ограничена особенностями мозга и ростом синаптических связей. Что ограничено естественным жизненным циклом организма. И это естественное ограничение продуктивности. И даже когда скорость написания кода стремится к бесконечности, проекты НЕ стало разрабатывать быстрее или дешевле. 🔸Функция снижения AI-продуктивности Точных цифр нет, но если накидать порядок величин, но вот моё предположение. Будет интересно вернуться к нему через пару лет 😬 Пусть: x — текущий размер проекта в kLOC, y — прирост продуктивности в %, Smin — kLOC-min, минимальный размер проекта, когда появляется сложность, Smax — максимальный размер проекта, когда эффект от AI = 0 Тогда формула снижения влияния AI на продуктивность будет выглядеть примерно так: y ≈ Smin · ln(Smax / x) kLOC | эффект ------+------- 5 | +23% 50 | +12% 500 | 0% 🔻Проще запомнить: продуктивность падает примерно на ~3-5% на каждое удвоение размера проекта. Ставь 👍 если тебе заходит такого рода контент! Ты знаешь кому переслать эту статью 💪 #ai@UniArchitect

UNITY BUILD PIPELINE ПО КИРПИЧИКАМ Полгода назад я решил попробовать активность в блоге, где я сначала долго и кропотливо собираю информацию по какой-то технической теме, а после этого рассказываю ее в онлайн формате. В прошлый раз мы разбирали детали устройства Asset Bundles, где от участников я получил максимально положительные отзывы: Самый большой вау-эффект был именно от осознания того, что работа с любыми ассетами в Unity устроена похожим образом и AssetBundle не исключение а дополнение для этого. Плюс само по себе разбор формата файлов раскрывает уйму возможностей: можно писать свои патчеры или шифраторы/дешифраторы. Занятие было записано и выложено в закрытую группу вместе со всеми материалами: исходники, текстовые разборы — всё, что было нарыто в процессе подготовки. Всегда под рукой, чтобы в любой момент вернуться и вспомнить детали. Потому я решил повторить формат и провести занятие по теме сборки и компиляции проекта в Unity — то, что отнимает у нас, разработчиков, времени в разы больше, чем любая работа AI-агента 😬 🔸Что внутри: ▫️Asset Pipeline — через какие ключевые шаги проходит ассет перед тем как попасть в сборку ▫️Bee Frontend и Bee Backend — как пошагово компилируются сотни сборок в проекте без csproj и sln файлов ▫️Tundra и Directed Acyclic Graph — за счет чего обеспечивается быстрая incremental сборка ▫️Domain Reload — из каких шагов состоит и в деталях разберемся почему отнимает так много времени Я уже проводил занятие на эту тему для участников курса в начале этого года. Тогда я успел сделать компиляцию editor скриптов без Unity. 🔻В это раз я подготовил проект на dotnet, который собирает проект под windows асинхронно 🤯 Т.е. он не блокирует редактор: обновил класс -> запустил скрипт -> билд делается на заднем фоне не блокируя работу в редакторе 🔸Формат — 11 июля, 14:00 МСК — Онлайн в Zoom — После занятия в закрытую Telegram группу будут выложены: запись, текстовые материалы и исходный код программ-примеров — Доступ к группе и материалам остаётся навсегда — Вопросы можно задать в любой момент в приватном чате 🔻Это не пересказ документации. Это разбор того, что происходит под капотом — на уровне, который не найти в гайдах и туториалах. Занятие закончено, пришло 20 человек, всем спасибо 🥰 #курс@UniArchitect

ПРОКЛЯТИЕ ПЕРЕИСПОЛЬЗУЕМОСТИ Делюсь болью. Я последние 5 лет на разных уровнях у разработчиков, лидов и техдиректоров, активно встречаю такой паттерн: Ну давай просто выделим общее и переиспользуем это в другой системе/проекте. Мы ведь уже написали систему перемещения для ботов, давайте для игрока её тоже переиспользуем. У нас ведь уже есть backend-сервис по обработке match-3 логики, давайте его же тупо используем в другой игре 😵 Может казаться, что нужно просто скопировать/вставить решения из одного места или создать общий класс. И черт, это не работает нормально в большинстве случаев. 🔸 Если вы делаете что-то общее, то сначала нужно понять, какие зависимости это общее в себя принимает и отдаёт Если вы сделаете прямой copy/paste, придётся писать кучу обёрток, чтобы подружить новую систему с текущей. Поэтому чтобы действительно такое было возможно, нужно заранее проектировать не только саму систему абстрактно, но и её зависимости 🤯 А это значит, что нужно изначально планировать проектирование ключевых абстракций проекта. Например: 🔹 Весь cross-cutting context. Логирование, конфиги, аналитика, обработка ошибок. Либо придётся кучу мест рефакторить, либо заранее согласовывать единое API для переиспользования между проектами. 🔹 Коммуникация с сервером — пример посложнее. Но суть простая: вы не хотите при переносе дублировать логику обработки ошибок, контрактов взаимодействия и тянуть лишние транзитивные зависимости (другой HTTP-плагин, например). И это важно тупо потому, что это заставляет поддерживать задублированные решения по проекту 🤢 🔹 Изменился формат логирования или когда логи пишутся, а когда нет 🔹 Добавился новый обработчик исключений, формат контракта или обработка краевого случая Вот иди свищи по проекту 10 копий и вкостыливай фикс и туда. При этом ладно этот фикс в коде, ха, это ещё изи, а если ты решил общий микросервис такой выделить… 🔻Чем больше расстояние между зависимостями — тем сложнее и дороже в них вносить изменения. 🔸 Не всё, что кажется общим, таковым является Избитый троп: Ну тут сделаем абстрактно, чтобы другие системы, вдруг, взяли и переиспользовали эту логику. Ну нет, это не работает. Если заранее не понимать, как именно система будет переиспользоваться, и не переиспользовать сразу — оно не будет работать. Это происходит из одного простого факта: 🔹 Скорость изменения требований разная для каждой из систем. То, что вчера виделось как общее, сегодня жёстко заточено под что-то конкретное, т.к. переиспользуемость стоит времени, сил, денег и тщательного планирования. Или по другому: То что вчера казалось легко можно переиспользовать, сегодня требует узкого и конкретного решения. Так что всё, пожалуйста, я снимаю со всех, кто читает этот пост, «проклятие переиспользуемости» 😘 С этого момента вы можете не писать системы так, чтобы вдруг когда-то их кто-то использовал и сократил себе время. 🔻 Наконец-то можно писать системы, которые заточены на выполнение своей задачи и не раздувают сложность проекта на ровном месте. Но если переживаете, вот правило трёх: Пока система или её часть не переиспользуется как минимум в трёх независимых местах — ничего общего выделять не нужно. А если есть требование — выровняйте уровень знаний, покажите цену такого решения, сделайте #проектирование@UniArchitect, внедрите и пользуйтесь на здоровье, все только спасибо скажут. Ставь 👍 если тебе заходит такого рода контент! Ты знаешь кому переслать эту статью 💪 #проект_в_разработке@UniArchitect

AI КАК РЕДАКТОР, А НЕ АВТОР Это вторая статья из серии про AI. Первая тут. Когда я запускал блог, одной из самых неприятных задач было не “придумать тему”. Тем обычно много. Сложнее было разложить мысль компактно, без каши в предложениях, и так, чтобы опытному читателю не хотелось закрыть пост на третьей строке со словами “господи, что я читаю” 😅 И первое место, где AI меня реально вытащил — это не код. Это текст. 🔸Блог Почти каждая статья проходила через ChatGPT: — проверить стилистику — поправить грамматику — найти кривые формулировки — предложить другой способ сказать ту же мысль И вот последнее оказалось важнее, чем кажется. Потому что иногда мысль вроде нормальная, но звучит так, будто её три раза уронили по дороге. У каждого автора есть набор любимых речевых конструкций. Одни и те же связки, одни и те же обороты, один и тот же способ подводить к выводу. С одной стороны — это стиль. С другой — если не обновлять этот пул, текст начинает звучать как пережёванная версия самого себя. У меня это особенно заметно, потому что я довольно быстро нахожу первичную формулировку мысли, но намного хуже умею посмотреть на неё под другим углом. Я уже писал про это в статье Проклятие знаний: когда мысль у тебя в голове собрана, очень легко забыть, что то, что очевидно для тебя может быть не очевидно для читателя. 🔹Курс Вторая большая область — подготовка курса. Первые 3 месяца я собирал материал руками. Ночью, когда жена уходила спать, я садился за комп, шёл в Google, читал научные статьи, разбирался, что там вообще написано, и складывал всё в Notion. Не просто “ссылка на источник”, а: — какая мысль откуда взята — где её нужно использовать — в каком порядке она должна идти — что нельзя исказить при пересказе Так была сделана почти половина курса. А потом появились reasoning-модели, которым можно скормить большой промпт, файлы и дать 40 минут подумать. И здесь AI стал не автором, а независимым валидатором: правильно ли я понял источник, не перепутал ли причинность, не натянул ли вывод на свою картину мира, потому что очень хочется, выдать желаемое за действительное 😅 Вот это оказалось прям ценно. Потому что найти источник — не самая сложная часть. Сложная часть — прочитать, правильно понять, а потом донести мысль так, чтобы не исказить исходный смысл. 🔸И это хорошо ложится на исследования В SAP/HPI исследовании про опыт разработчиков с GenAI есть важный практический вывод: когда человек использует один режим работы с AI — только chat или только in-code — нагрузка падает. Когда начинает метаться между режимами, выигрыш пропадает. А ещё точнее в ту же точку попадает свежий RCT Anthropic про формирование навыков. Исследование про код, но механизм универсальный: когда человек полностью отдаёт задачу AI, у него растёт ощущение продуктивности, но проседает понимание, чтение и отладка — причём без реального выигрыша по скорости. А те, кто работает с AI вовлеченно, спрашивая объяснения, а не готовый ответ, понимание сохраняют. С текстом у меня работает так же. AI полезен, когда у него понятная роль: редактор, переформулировщик, валидатор или исследователь. А промпт формируется несколькими итерациями, где я подробно рассказываю куда нужно капнуть, что взять и как преобразовать. Но если прописать “давай классную статью по архитектуре”, на выходе очень быстро получается стерильный AI-slop/мусор 🤢 🔻 AI хорошо снижает стоимость итерации мысли. Но мысль всё равно должна быть твоя. Иначе вместо авторского текста/кода получится гладкая, правильная и абсолютно мёртвая жвачка. Понимаю, тема уже успела обрасти мхом и противоречивыми заявлениями, но я стараюсь, прагматично исследовать эту тему. Дайте знать в комментах что вы думаете 🫡 Ставь 👍 если тебе заходит такого рода контент! #ai@UniArchitect

Запись: архитектура проекта уровня Gardenscapes На 4 часа вчера засиделся чтобы выдать и показать весь материал что я подготовил 😬 В следующий раз буду значительно сокращать, та же БД и зарисовки вручную я думаю были лишними. Но мне просто хотелось показать как с диграммами можно удобно работать самому и что это не сложно 😊 Я сам кайфанул, очень много рассказал, почти каждый важный момент прокомментировал и дал прям подробную картину как архитектура таких проектов может выглядеть 🤓 Так что рекомендую посмотреть в записи, на х2 очень даже комфортно 🫡 Ссылка на запись Спасибо так же за активность в чате, вопросы были крутые, а атмосфера ламповая 🍻 Пишите тут как вам стрим и что нужно ещё улучшить? Ставь 👍 если тебе по кайфу такая движуха @UniArchitect

Проектируем проект уровня Gardenscapes Я не просто так задавал в канале вопросы про стрим 🤓 В эту Субботу, 13.06.2026 в 14:00 МСК не планируйте ничего. Потому что в это время в режиме реального времени будем пытаться запроектировать проект масштаба Gardenscapes 🤯 Формат будет примерно такой: 🔸Начало и предисловие 🔸Задание ограничений (иначе в 2 часа не уложимся) 🔸Проектирование уровня систем, контейнеров и компонентов по C4 Стрим будет на youtube 😊 Я прислушался к результатам опросов и составил материал так, чтобы примерно 60% мы проектировали, 10% я показывал слайды и 30% уделял примерам в коде. Я носил идею этого стрима еще с момента когда вел курс, это была одна из рекомендаций одного из учеников 🫡 🔻Так что: Если тебе по кайфу такая движуха, кликай по кнопке ниже и бот отправит тебе напоминание и ссылку на стрим за 10 минут до его начала 🛞 До встречи! @UniArchitect

Продолжаю готовить план для стримов. Это будет серия раз в 2-3 недели, где я буду брать опубликованный проект и описывать его архитектуру с нуля, как бы я делал и проектировал. По длительности я хочу чтобы это умещалось ~2 часа на 1 проект, а потому очень важно знать какой уровень детализации будет наиболее полезен. Нюанс за который я переживаю: В код нужно погружать, рассказывать что и как устроенно. На это может уйти много времени и это скажется на динамике и полезности.

Делаю план, где буду брать игру из стора и проектировать с нуля прямо на стриме. Нужно знать чему уделить больше внимания 😊

ВЫЗВАЛ И ЗАБЫЛ В прошлой статье я разобрал что такое cross-cutting concerns — системы, которые пересекают всю кодовую базу, но не являются бизнес-логикой. Сегодня — как с ними работать на практике. 🔸Что такое "call and forget" Cross-cutting concerns — общепринятый термин. "Call and forget" — то, как я называю эти системы на практике. Название описывает паттерн использования: — Вызывающий код не ожидает возвращаемого значения — Внутреннее состояние системы не влияет на бизнес-логику вызывающего Примеры из каждого проекта: ▫️ Логирование — записал событие, пошел дальше ▫️ Аналитика — отправил трек, не ждешь ответа ▫️ Звуковая система — запустил звук, геймплей не зависит от результата ▫️ Вибрации — тактильная обратная связь, fire and forget в чистом виде ▫️ Toast'ы / Hint'ы — показал уведомление, логика продолжается Ключевое свойство: убери любую из этих систем — и геймплей не изменится. Они ортогональны бизнес-логике. 🔸Почему singleton Обслуживающий код занимает большую часть систем и "размывает" логику, которую мы хотим править. Архитектурно я хочу чтобы на это тратилось как можно меньше места в рабочих классах. Потому надо выбрать самый компактный способ связать классы друг с другом. И таковым является singleton. Т.е. часть систем в каждом проекте можно спокойно сделать как SomeSystem.Instance.DoSmth — и проект от этого только выиграет. Но с правилами. 🔸Когда singleton — проблема Проблема не в подходе, а ЧТО через него делают. Возможность вызвать бизнес-логику через глобальный доступ создает хаос связей. Любой скрипт — визуальный эффект, UI-элемент — может напрямую командовать Game, Player, Economy. Дочерние элементы обращаются к головным, образуя неконтролируемый граф зависимостей. Но "call and forget" системы по определению не возвращают управление в бизнес-логику. Связь — однонаправленная. А значит и проблем не будет, если правильно "готовить" работу с такими системами. 🔸Рецепт приготовления signleton 🔹Ингредиент 1: Явный lifecycle Singleton создается и уничтожается в выделенных фазах — там же где регистрируются зависимости в DI-контейнере. Никаких get { _instance = new Class(); return _instance; } Рядом с diContainer.Register<IMyService>().AsSingle() ты так же явно прописываешь AudioService.Instance = new AudioService(). Один файл, одно место, полный контроль. Я подробно разбирал Composition Root и фазы RRR в статье про DI, а проблемы с порядком инициализации — в статье про точку входа. 🔹Ингредиент 2: Доступ через интерфейс Singleton отдает не конкретный класс, а интерфейс. Т.е. публичное свойство IAudioService, а не AudioService. Первая причина — тестируемость. Можешь подставить заглушку в тестах. Вторая — подмена по окружению. Для dev-окружения аналитику заменяешь на логирование, звук в тестах — на NullAudioService, вибрации на десктопе — на StubHaptic. 🔻 Архитектурные решения — это всегда компромисс. А если тебе кажется что компромисса нет, значит ты его ещё не нашел. Вот так использование не самого любимого и проблемного паттерна может помочь замедлить рост сложности проекта. Ставь 👍 если тебе заходит такого рода контент! Ты знаешь кому переслать эту статью 💪 #решения@UniArchitect

АРХИТЕКТУРА БЛОГА Чем дольше ты в разработке, тем отчётливее чувствуешь — уровень материала в интернете не растёт вместе с тобой. "Рекомендации", "лайфхаки", "советы" по C# и Unity — это цикл самодублирующейся информации, который просто ходит по кругу. И что ещё хуже — почти всё что можно найти публично, плохо проверяется авторами или намеренно искажается. Приходится постоянно перепроверять. Я Лёша. 11 лет в Unity, 7 из них коммерческих. Самоучка без наставников — всё из книг, научных статей и анализа реального опыта. Вот не многие из проектов, где довелось работать: ▫️ Hero Wars: Alliance ▫️ WSOP ▫️ Cut The Rope: Daily ▫️ Combat Quest ▫️ А так же делал свою игровую студию Silverfox Games (вся история в статьях: раз, два, три) Сейчас на вольных хлебах, полностью сосредоточен на блоге и подготовке онлайн-версии курса по архитектуре. 🔸Зачем этот блог Мне захотелось создать место, где подача материала сконцентрирована на проверяемости источников и высоком качестве. С фокусом на разработчиков, кто уже несколько лет создаёт и работает проекты на Unity. Не пересказ документации и "10 советов для новичка". А выстроенная цепочка, где каждая статья — один маленький пазл в общую картину мира разработки. Прежде чем раскрыть объёмную тему, я стараюсь выровнять кривые обучаемости между мной и читателем. Чтобы итоговый материал не казался придумкой автора, а лаконично являлся следствием из ранее прочитанного. 🔸Что почитать Чтобы лучше понять о чем я пишу и в каком стиле, я постарался собрать все статьи в один список и разбил их по категориям. Чем ниже статья в списке, тем лучше она раскроется, если вы прочитали предыдущие статьи 🥄 🔹Фундамент — почему всё устроено так, как устроено ▫️ Мы инженеры, не художники ▫️ Второй закон инженерной разработки ▫️ Когнитивная сложность ч.1 и ч.2 ▫️ Невыразительность ▫️ Продуктивность ▫️ Проклятие знаний ▫️ Полиморфизм системы ▫️ Инкапсуляция ▫️ Причина и следствие 🔹Архитектура — от определения к проектированию ▫️ (А|a)рхитектура ▫️ Когда задумываться об архитектуре ▫️ Проектирование: система ▫️ Проектирование: контейнеры ▫️ Причина провала проектов ▫️ Требования 🔹Практика — код и инструменты ▫️ SOLID и KISS, DRY, YAGNY — критика ▫️ DI ▫️ Точка входа и инициализация ▫️ Конфиги ч.1 и ч.2 ▫️ Порты и адаптеры ▫️ Кодогенерация ▫️ MV* 🔹Под капотом Unity ▫️ UnityEngine.Object == null ▫️ Reverse Engineering ▫️ Качаем файлы быстрее и HTTP/2 ▫️ CoreCLR: основы, CoreCLR vs Mono, CoreCLR vs IL2CPP 🔸Видео на YouTube ▫️ Архитектура конфигов ▫️ Многослойная архитектура ▫️ Dzmitry Bazyleu: Архитектура Open Source Проектов ▫️ Ярослав Шабанец: Клиентская архитектура корпораций 🔸Open Source ▫️ Unity Empty Project Template — шаблон пустого Unity проекта с готовой структурой папок ▫️ FastMigrations.Json.Net — миграция json файлов, в 5-7 раз быстрее аналога 🔻 Этот блог — не набор случайных статей. Это выстроенная цепочка причин и следствий. Регулярно читая статьи — ты получаешь полную картину, основанную не на чьих-то мнениях, а на проверяемых источниках и реальном опыте. 🔸Ваш последний курс по архитектуре Мой образовательный продукт, над которым я работал последние 2.5 года: — 9 месяцев собирал материал — 11 месяцев вел занятия для middle/senior/lead разработчиков — 6 месяцев монтировал и загружал на платформу И все это чтобы: 🔹Полностью закрыть фундамент по архитектуре приложений на Unity. Сейчас он находится в состоянии soft launch, но если хочется узнать подробнее, кликай по кнопке ниже, забирай полезный материал со ссылкой на сайт, где ты сможешь узнать подробнее. Спасибо большое что читаете 😊 Ставь 👍 если тебе заходит такой подход! @UniArchitect