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