Яковлев Илья | Всё про Unity-разработку

🧐 CI/CD с чего начать и кому он нужен? Недавно выходил пост о кастомной сборке билда через скрипт, который очень упрощает тестирование билдов и там вы просили подробнее начать раскрывать тему CI/CD - поэтому начинаем:) CI/CD (Continuous Integration / Continuous Delivery) - это некоторый набор инструментов, который позволяет автоматизировать процесс сборки вашего билда и доставки его до сторов, либо же до вашего телеграмма как вариант:) ❗️ Т.е. до внедрения CI/CD пайлпайн сборки билда и его тестирования примерно такой: - вы запускаете сборку билда (дай бог без ошибок) - 20-30 минут ждете сборку (и ничего не делаете в этот момент) - Потом отправляете команде как вариант для тестирования (и дай бог, чтобы все были на месте и эта история не растянулась на часы) - Потом уже думаете выкладывать в стор или собирать новый билд (привет все заново) А представьте, что выделаете билд и под ПК и под Андроид, например, а если еще addressables используете или тесты?) Сразу умножаем затраты времени в несколько раз ✔️ После внедрения CI/CD: - сделали коммит, и пошли дальше делать задачи, пока в облаке собирается билд, собирается контент и автоматически, например все заливается на облако, отправляется команде через бота в ТГ или сразу в магазин Т.е. эта история про то, что вы экономите тонну времени и сил, как своих (в первую очередь своих), так и команды 🔣 Кому это может быть полезно? Да на самом деле всем, кто не просто развлекается в редакторе, а делает игру, которую собирается билдить и выпускать. Один раз повозиться с настройкой CI/CD и спокойно дальше автоматизировать сборку билда и отсылку его себе в тг будет полезно даже для одиночки 🔣 С чего можно начать? На самом деле основных варианта я вижу 2: 1) Unity CI/CD - решение от самих юнитеков. Из плюсов довольно просто интегрируется с юнькой, но при этом есть ограничения по кастомизации. Можно попробовать бесплатно, но все таки, чтобы более менее нормально работать нужно будет платить денежки 2) CI/CD на Gihub actions - как по мне самый интересный вариант, опять же довольно не сложный по настройке, можно писать кастомные пайплайны сборок + можно жить даже бесплатно (по крайней мере если у вас нет сборок на 10 платформ параллельно и не сильно большая команда). Там есть и бесплатное харнилище под созданные сборки и под кэш для ускорения сборок, так что я бы наверное советовал глянуть в эту сторону. Получите и довольно полный опыт настройки CI/CD и при этом не потеряете сильно в удобстве Есть и более продвинутые системы по типу team city или jenkins, но на самом деле я бы не лез туда, т.к. там очень много кастомизации и надо за всем следить, если у вас нет отдельных ресурсов под настройку и поддержку этого дела, то стоит скипнуть p.s. если хочется продолжения этой темы, то ставьте 🔥:)

К вам вопросик по предстоящему ролику:) Реакций собрали много - получается делаю материал) План такой, что разберем сначала теоретически в чем вообще суть и какие проблемы разработки игры ECS помогает решить + будем на практике разбирать примеры в сравнении с ООП реализацией, чтобы было чему именно надо щелкнуть в голове Будем разбираться на примере фреймворка Entitas ECS - как по мне самый лучший вариант, чтобы начать разработку в этой парадигме и реально ускорить/упростить производство игры + уже 100 раз обкатан в продакшене (да, знаю, что он может быть не такой максимально производительный как некоторые другие реализации, но чаще всего сверх производительности в замен удобству никому и не надо, да и перейти на другой ECS фреймворк, понимая суть работы не так сложно) + мы на проектах также его используем 😅DOTS от юнити брать не хочу, т.к. он постоянно допиливается + в течении 2-3 лет я так понимаю юнитеки там снова все переделают чертовой бабушке Единственное у меня есть вопрос к вам: 🔣 Хочется по длиннее ролик (с установкой фреймворка/генератора кода, немного по больше механик/объяснений), или по короче (минут 15-20 сравнить основные аспекты)?

Ребят, хотите видос по смене мышления с ООП на ECS? Т.е. как переключиться на ECS после ООП, аналогии между подходами, как одно и то же реализуется в двух подходах возможно и тп. В общем некоторое введение в ECS, чтобы можно было стартовать с каким-то пониманием происходящего? да - 🔥 лучше другую тему - 👎

UI Toolkit стал лучше? Наверное одна из моих самых нелюбимых частей разработки игры - это верстка интерфейсов на наших любимых канвасах. Каждый раз это ощущается как прохождение через боль (немного преувеличиваю, конечно, но процесс не самый приятный) 🧐 И вот вроде есть UIToolkit, который должен эти проблемы решить и сделать верстку UI понятной и удобной, но я никак не решаюсь его тянуть где-нибудь в продакшн. Он постоянно кажется недоработанным (как и DOTS, NetCodeForGO и тд. СПАСИБО ЮНИТИ). Однако начиная с версии 6.4 там много чего приятного добавили в виде UI шейдеров, нормальную поддержку world canvas'ов, даже поддержку SVG! И я это все попробовал - в целом круто, однако смотришь потом треды тематические и понимаешь, что при глубоком использовании снова вылезает куча проблем и недоработок В связи с чем хотелось бы у вас узнать ребят, кто уже реально тянул к себе в проект этот пакет (именно в геймплей, а не для редактора) и как оно ощущается/работает в долгосроке?

🧐 Как ПРАВИЛЬНО начинать пользоваться нейронками в разработке игр? Хочется, чтобы вы, ребят, переставали бессмысленно вайбкодить недоделанные игрульки как было в одном из моих забавных недавних роликов и смотрели на агентов уже все таки больше как на реальный инструмент разработки умножающий ваши имеющиеся навыки Поэтому выложил новый видосик, где разбираю первые основные шаги, которых ОБЯЗАТЕЛЬНО надо придерживаться, чтобы стартовать освоение этого инструмента + делюсь опытом из студии 👀 Смотреть тут -> https://www.youtube.com/watch?v=5EBTIKAV05k p.s. отпишитесь в комментариях, как вам такой формат видосов, где я прям вживую показываю/рассказываю те или иные штуки?) ❗️ p.s.s. ОБЕЩАННЫЕ ФАЙЛЫ ИЗ ВИДОСА В КОММЕНТАРИЯХ К ЭТОМУ ПОСТУ ❗️

Сборка билда - тоже искусство:) ❓ Какая проблема Если ты собираешь игру через File → Build Settings → Build и выбираешь все руками - рано или поздно ты что-нибудь забудешь. Не ту платформу выбрал, не тот профиль аддрессейблов, забыл переключить подпись с дебажной на релизную и тп. И узнаешь об этом, когда билд уже улетит на стор или что-то в этом духе. А когда вы небольшой командой работаете, где каждому разрешено билд собирать, то подобных рассинхронов может быть еще больше ✔️ Возможное решение Так вот - всё это можно описать скриптом. Один метод, который сам проходит все шаги сборки в правильном порядке, а ты лишь нажимаешь на кнопку 😎 Из чего вообще может состоять сборка? Если разложить кнопку Build на шаги, получается примерно так: 👉 Какие сцены кладём в билд 👉 Под какую платформу собираем (Android / Windows / …) 👉 Какие настройки игрока ставим (бэкенд, архитектура, подпись) 👉 Куда и под каким именем складываем готовый файлик 👉 И все что душе угодно под ваш проект (сборка addressables, проверка каких-нибудь ассетов, штук зависимых от площадки под выкладку) Самое главное - это вызов BuildPipeline.BuildPlayer. Ему отдаёшь структурку со всеми параметрами и все - билд собирается, примерно вот так: //какие-то валидации, сборка addressables, проверки контента var options = new BuildPlayerOptions { scenes = GetEnabledScenes(), // список сцен target = BuildTarget.Android, // платформа locationPathName = GetOutputPath(), // куда положить options = BuildOptions.Development }; BuildPipeline.BuildPlayer(options); //делаем билд Т.е. это уже часть рабочего билда с помощью кода. Вешаешь сверху атрибут [MenuItem("Build/Android")] - и у тебя в Unity появляется свой пункт меню, который собирает игру одной кнопкой, всегда одинаково (ну и понятно кастомизировать как угодно этот процесс тоже можно) 🧐 Зачем это надо? 👉 Повторяемость. Скрипт не забывает шаги и не зависит от того, что ты вчера натыкал в инспекторе. 👉 Потом этот же процесс можно использовать для CI/CD (кстати если не знаете что это и зачем - пишите в комменты, тоже отдельным постом расскажу) 👉 Релиз и дев билды в один клик. Дев - с профайлером и дебажной подписью, релиз - с боевой (руками ничего не забудешь переключить) Поддержите 🔥, если интересна тема или какие-то более конкретные примеры, потому что на самом деле есть много чего еще интересного #разработка_на_практике #лайфхаки

2 главных понятия сейчас, чтобы начать НОРМАЛЬНО работать с ИИ агентом Давайте по немногу разбираться и с этой темой - все таки стараемся развиваться во все стороны:) Поддержите 🔥 если подобные посты будут интересны 🔣Рабочий контекст Само по себе программирование агент знает неплохо (т.е. код понятное дело он писать умеет) - но про ВАШ проект он не знает ровным счётом ничего. Ни вашу архитектуру, ни ваш стек, ни общую суть игры с ее масштабом. Поэтому любую поставленную задачу ИИ будет решать "угадывая" то, как решение встроить к вам в игру и какое решение вообще выбрать. Соответственно ваша первостепенная задача - это дать контекст агенту, т.е. дать необходимую информацию для того, чтобы он мог ориентироваться в вашем проекте: стэк, структура папок, важные принятые решения, масштаб проекта и так далее далее. Обычно это задается md файликами (в claude code, например - это claude.md + rules), где описывается все выше озвученное. И после этого шага ИИ уже становится не слепым котенком, а плюс минус готовым к бою инструментом 🔣Контекстное окно Это некая "оперативка" агента — то, что он держит в голове прямо сейчас в рамках начатого чата. И сюда влезает ВСЁ: ваши сообщения, его ответы, файлики, которые он прочитал, ошибки, которые вы ему накидали. Т.е. некоторый общий стол ограниченного размера, на котором раскидана вся информация в рамках чата Что важно понять: окно не резиновое. Когда оно забивается, то агент начинает делать откровенный бред. Поэтому в длинной переписке агент вдруг забывает с чего всё начиналось, противоречит сам себе и фантазирует. Соответственно такое контекстное окно есть у каждого нового чата свое (хотя там и более сложные схемы с субагентами есть, но не суть) и тут важно за ним следить. Обычно если оно забивается больше чем на 50% я уже стараюсь прыгать в новый чат, потому что деградация на самом деле начинается еще до полной забивки. И вообще стараюсь придерживаться правила 1 задача - 1 чат. Если решение задачи слишком длинное, то процентах на 70 я собираю всю информацию в сжатом виде (в claude code команда /compact как вариант) и перехожу в новый чат (это хуже чем одна задача на чат, но вариантов нет, а это единственный рабочий варик) Так вот внедрив хотя бы эти две вещи в свое понимание работы с агентом вы уже сильно улучшите качество работы 😎

🔥 Мысли данными при разработке игры! 🔥 На сообщении выше вы накидали кучу реакций, поэтому записал ролик на тему того, как мыслить данными при разработке игр и почему это вообще важно) Немножко теории + 3 практических небольших кейса, раскрывающих ситуацию! Смотреть тут -> https://www.youtube.com/watch?v=horzPtSCS4M Приятного просмотра😍

Одна из самых дорогих архитектурных ошибок, которую я вижу у разработчиков - думать логикой, а не данными. #разработка_на_практике Немножко поясню:) Любая игра — это набор данных (состояние): позиция, скорость, HP, предметы в инвентаре. Вот это все, скажем так - истина, она просто есть. А есть куча всего остального — анимация движения, полоска здоровья, иконка кулдауна, механика смерти и тд. - это все не истина, а следствие наших данных. Всё это в любой момент можно пересчитать из состояния. 🧐 И типичная ошибка вот в чём: мы каждым действием в игре руками дёргаем не только состояние, но и все следствия. Нанесли урон — и тут же побежали обновлять HP-бар. Добавили хил — снова не забудь обновить бар. Потом какой-нибудь сброс здоровья делаем на чекпоинте… (догадайтесь что надо сделать). Т.е. каждое новое действие в игре надо подружить со всеми следствиями и ничего не упустить. Получается паутина, где баг с рассинхроном данных и приуроченных к ним механик — просто вопрос времени. А думать данными — значит перевернуть это. Истина одна — само здоровье. Меняем только его, а хп бар, механика смерти, какие-то условия победы, завязанные на здоровье — пусть сами читают это значение и подстраиваются. Им вообще неважно, почему оно поменялось — урон, хил, что угодно. Важно только то, что данные поменялись. Синхронизировать руками нечего — а значит, и забыть нечего) Более того, если мы придерживаемся подхода с ориентированием на данные, то практически бесплатно получаем какие-нибудь сохранения, ведь нам просто достаточно собрать все кусочки в файлик, и потом загрузить его обратно, а все привязанные к данным следствия будут пересчитываться автоматически ❓ Хотели бы полноценный видос на эту тему — с небольшой теорией и примерчиками?) Ставьте огонёк 🔥

Медленно, но верно наращиваем визуал для нашего пати гейма:) Вообще много чего поменялось в проекте, времени все как-то не хватает рассказывать об этом, да и дорабатывать еще много чего надо, но все же постепенно делюсь и собираю фидбек 🔥 👀 Зацените промежуточные сцены между игровыми забегами: 1-я с лягушкой для отсеивания игроков между игровыми этапами (на подобии сбрасывания игроков в fall guys) 2-я с щупалками, как бы является финальной под топ3 игрока - победителя Как вам? Буду рад реакциям и фидбеку в комментариях:)