Всем привет!
На хабре вышла моя новая статья про процесс автоматизации CI/CD в Unity

Автоматизируй всё! Настройка CI-CD в Unity для ленивых (и умных) разработчиков. Часть первая

3 приёма, которые мгновенно сделают ваш код чище! 🚀

На этой неделе провел серию код ревью и решил сформировать 3 простых, но мощных совета, чтобы ваш код был читаемым и поддерживаемым!

✅ 1. Разбивайте сложные лямбда-выражения
Лямбда-методы удобны, но слишком сложные выражения ухудшают читаемость.

🔴 Плохо:

var evenNumbers = numbers
    .Where(n => n % 2 == 0)
    .Select(n => n * n)
    .OrderByDescending(n => n)
    .ToArray();

🟢 Хорошо (разбиваем на методы):

private bool IsEven(int number) => number % 2 == 0;
private int Square(int number) => number * number;

var evenNumbers = numbers
    .Where(IsEven)
    .Select(Square)
    .OrderByDescending(n => n)
    .ToArray();

Теперь код понятнее и легче отлаживать.

---

✅ 2. Используйте ранний return вместо вложенных if-else
Чем меньше вложенность, тем чище код.

🔴 Плохо:

public void Attack(int damage)
{
    if (damage > 0)
    {
        health -= damage;
        if (health <= 0)
        {
            Die();
        }
        else
        {
            Debug.Log("Player took damage");
        }
    }
    else
    {
        Debug.Log("Invalid damage value");
    }
}

🟢 Хорошо:

public void Attack(int damage)
{
    if (damage <= 0)
    {
        Debug.Log("Invalid damage value");
        return;
    }

    health -= damage;
    if (health <= 0)
    {
        Die();
        return;
    }

    Debug.Log("Player took damage");
}

Ранний return делает код проще и понятнее.

---

✅ 3. Избегайте глубокой вложенности логики
Чем меньше if в if, тем лучше.

🔴 Плохо:

public void ProcessEnemies(List<Enemy> enemies)
{
    foreach (var enemy in enemies)
    {
        if (enemy.IsAlive)
        {
            if (enemy.DistanceToPlayer < 10)
            {
                if (enemy.HasWeapon)
                {
                    enemy.Attack();
                }
            }
        }
    }
}

🟢 Хорошо (разбиваем на методы):

public void ProcessEnemies(List<Enemy> enemies)
{
    foreach (var enemy in enemies)
    {
        HandleEnemy(enemy);
    }
}

private void HandleEnemy(Enemy enemy)
{
    if (!enemy.IsAlive)
        return;
    
    if (enemy.DistanceToPlayer >= 10)
        return;
    
    if (!enemy.HasWeapon)
        return;
    
    enemy.Attack();
}

Теперь основная функция короткая, а обработка вынесена в отдельный метод.

---

💡 Вывод:
✅ Разбивайте сложные выражения на методы
✅ Используйте ранний return, чтобы избежать лишних if-else
✅ Минимизируйте вложенность для лучшей читаемости

Используете ли вы эти методы на практике или они для вас вновинку?
Поделитесь в комментариях👇

🍊"Сочность ревью"

Всем привет! 👋

На работе ломаем голову, как найти крутого программиста, который умеет быстро и качественно собирать прототипы и придавать им тот самый "вау-эффект".

💡 И тут родилась идея — "Сочность ревью".
Суть простая: нужен программист, который сможет на лету настраивать "сочность" игры, используя готовые ассеты. 🎨✨

🛠️ Идея тестового задания:
Хотим проверить навык через лайвкодинг — чтобы кандидат показал, как он видит и делает эффект по-настоящему вкусным.

Пример задания:

На сцене — пол из кубов (100x100) и круг, который прыгает по этим кубам.
Нужно сделать эффект на кубах и круге при приземлении — чтобы выглядело сочно! 🍑💥
🔥 Вопрос к вам:

Как вам такое тестовое? Подходит для проверки скиллов?
И... может, кто-то хочет попробовать себя в этом задании just for fun? 😉

Ставьте 🍓 если идея огонь и 💩 если идея не очень
А если хотите попробовть, то пишите в комменты или в личку!

💡 Немного мыслей с текущего Game Jam'а

Сейчас менторю команды на гейм джеме и решил поделиться наблюдениями. Плюс вспомнил прошлый джем, где участвовал как разработчик.

🎮 1. Игровые движки
Примерно 40% проектов делают на Unreal Engine 5 и около 30% — на Unity (субъективно, джем ещё идёт). Часто вижу проекты на Godot, а также на менее популярных движках вроде Phaser.

🐍 2. Godot
Удивило, сколько новичков выбирают Godot. Кажется, даже больше, чем Unity и Unreal вместе. У движка явно светлое будущее — ждём волну новых инди-игр на нём.

👥 3. Роли участников
Очень много ребят в сфере UI/UX и 2D арта, да и саунд-дизайнеров хватает. А вот разработчиков явно не хватает — многие команды страдают от нехватки кодеров.

🤖 4. Все используют AI
Художники и саунд-дизайнеры активно юзают ChatGPT для генерации простых скриптов. Этого хватает для базовых механик в хоррорах или простых third-person играх.

💬 А что вы думаете по этому поводу? Повлиет ли такое соотношение на игровую индустрию в ближайшее 3-5 лет?

🔧 Как я упрощаю рефакторинг

Последние пару недель я активно рефакторю систему для HTTP-запросов в нашем проекте. Хочу поделиться несколькими советами, которые помогают делать это чисто и безопасно.

🎯 Совет 1. 1 коммит — 1 правка
🔹 Внесли изменения
🔹 Проверили, что ничего не сломалось
🔹 Закоммитили

🎯 Совет 2. Атомарные изменения
Каждый коммит должен содержать 1 логически завершённое изменение.
Пример:
Вынесли код в отдельный метод — уже повод для коммита.
Допускаю объединение нескольких стилистических изменений в один коммит, но логические изменения лучше разделять.

🎯 Совет 3. Чётко ставьте цель коммита
Пример:
🔹 Коммит 1: Вынести обработку ошибок в отдельный класс.
🔹 Коммит 2: Разделить обработку ошибок на классы с общим интерфейсом.

🎯 Совет 4. Автотесты — если возможно
Покрытие рефакторинга тестами сильно упрощает жизнь.
⚠️ У меня редко получается писать тесты до начала рефакторинга, но если код позволяет — очень советую.

✅ Плюсы подхода:
🔹 Фокусируетесь на каждом этапе, а не рефакторите всё подряд.
🔹 Можно в любой момент прервать работу, завершив текущий коммит.
🔹 Держите в голове меньше контекста.
🔹 Легче понять, где что сломалось, так как каждая правка — отдельная итерация.

🔥 5 советов, как писать код быстрее

Хотите ускорить свою работу в коде? Вот 5 приёмов, которые помогают мне писать быстрее и эффективнее.


🚀 Совет 1. Используйте HotKeys в Rider или Visual Studio

Чем меньше вы используете мышку, тем быстрее работаете. Горячие клавиши позволяют мгновенно переключаться между вкладками, перемещаться по коду, быстро выполнять рефакторинг и автодополнение.

Я предпочитаю Rider — он удобнее, на мой взгляд. Но знаю ребят, которые любят Visual Studio. Главное — выучить основные HotKeys и активно использовать их в работе.

Полезные комбинации в Rider:
🔹 Ctrl + Shift + R — рефакторинг кода
🔹 Alt + Enter — быстрые исправления
🔹 Shift + Shift — глобальный поиск

В Visual Studio тоже есть мощные комбинации, например:
🔹 Ctrl + D — дублирование строки
🔹 Ctrl + K, Ctrl + D — автоформатирование кода

Советую посмотреть обучающие видео на Youtube и потратить несколько дней на их изучение


🤖 Совет 2. AI-ассистент — must-have

Современные инструменты на базе ИИ значительно ускоряют написание кода. Я уже несколько лет использую GitHub Copilot, и он экономит уйму времени.

Как помогает Copilot:
🔹Генерирует повторяющиеся конструкции (геттеры, сеттеры, циклы и т. д.)
🔹Подсказывает возможные решения, основываясь на контексте кода

Также можно использовать ChatGPT для генерации кода, объяснения алгоритмов и поиска оптимальных решений.


📌 Совет 3. "Live Templates" — код за секунды

Live Templates — это готовые заготовки кода, которые можно вставлять по коротким командам. Они особенно полезны для шаблонных конструкций, которые приходится писать часто.

Примеры:
🔹 prop → public int MyProperty { get; set; }
🔹 for → for (int i = 0; i < length; i++) { }
🔹 ctor → создание конструктора класса

В Rider можно создавать свои шаблоны. Например, если вы часто пишете "[field: SerializeField] public type Type { get; private set; }", можно использовть шаблон sprop, который автоматически развернётся в этот код


⌨ Совет 4. Навык слепой печати

Если вы печатаете вслепую, то не тратите время на поиск клавиш, а концентрируетесь на коде. Это значительно ускоряет процесс.

Лет 5 назад я целенаправленно выучил слепую печать на русском и английском. Сейчас я даже не задумываюсь о наборе текста, и это повышает продуктивность.

Как научиться?
🔹 Сайты типа https://klavogonki.ru помогут натренировать навык.
🔹 Практика каждый день хотя бы 10 минут

У меня скорость печати - 300 символов на Русском и 200 на Английском
👇Пишите в комментариях вашу скорость!


🎛 Совет 5. Программируемая клавиатура

Я использую Moonlander, и это одна из лучших инвестиций в продуктивность. Можно настроить кастомные слои для разных задач, что значительно ускоряет работу.

Как это помогает?
🔹 Первый слой — стандартное управление, клавиши WASD
🔹 Второй слой — стрелки навигации (без отрыва от основной позиции)
🔹 Третий слой — перемещение по методам в Rider
🔹 Четвёртый слой — управление вкладками, перемещение блоков кода

Такая настройка позволяет снизить нагрузку на пальцы и ускорить работу с кодом.

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

Всем привет!
Выпустил вторую часть про CI/CD где в формате туториала показываю как сделать сборку через Unity Cloud Build
https://habr.com/ru/articles/891160/

Решил отделить создание сборки в отдельную статью, так как вместе с интеграцией в Team City получается довольно много информации. И в третьей часте уже расскажу про интеграцию Unity Cloud build и Team City

🔥 Автоматизируй заливку сборки в Testflight

Делюсь с вами скриптом для автоматической заливки сборки в Testfligh через Unity cloud build

Как его настроить:

Часть 1. Создаем shell script
Шаг 1.
В папке с проектом, там, где находится папка Assets, Library создаем папку "Scripts"

Шаг 2.
В папке "Scripts" создаем файл с именем "upload_to_testflight.sh"

Шаг 3.
Добавляем Shell script

#!/bin/bash

#Unload to testflight
echo "Uploading IPA to Appstore Connect..."

#Path is "/BUILD_PATH/<ORG_ID>.<PROJECT_ID>.<BUILD_TARGET_ID>/.build/last/<BUILD_TARGET_ID>/build.ipa"
path="$WORKSPACE/.build/last/$BUILD_TARGET_ID/build.ipa"

if xcrun altool --upload-app -f $path -t ios -u $ITUNES_USERNAME -p $ITUNES_PASSWORD ; then
    echo "Upload IPA to Appstore Connect finished with success"
else
    echo "Upload IPA to Appstore Connect failed"
fi

Часть 2. Добавляем скрипт в Post-build scripts в testflight сборке

Шаг 1.
Заходим в настройки конфигурации билда => Advanced settings => Script hooks

Шаг 2.
В поле Post-build script добавляем поле "Scripts/upload_to_testflight.sh"


Часть 2. Настраиваем параметры в UnityCloud build

Шаг 1.
Заходим в настройки конфигурации билда => Advanced settings => Environment Variables

Шаг 2.
Добавляем переменную с именем "BUILD_TARGET_ID", в качестве значение указываем название конфигурации, которую вы редактируете

Шаг 3.
Добавляем переменную с именем "ITUNES_USERNAME", в качестве значение указываем вашу почту, с коротой у вас есть доступ к appstoreconnect

Шаг 4.
Добавляем переменную с именем "ITUNES_PASSWORD", в качестве значение указываем вашу пароль приложения, не путать с личным паролем

Создать пароль приложения можно тут https://appleid.apple.com/
для этого
1. Заходим в аккаунт
2. Нажимаем пароли приложения (App specific passwords)
3. Идем по шагам и получаем ваш пароль. Сохраните его, он вам может потребоваться в будущем
4. Именно этот пароль нужно добавить в поле "ITUNES_PASSWORD"

Если вы все сделали правильно, то после сборки запуститься скрипт, который зальет вашу сборку в testflight

FAQ

1. Если у вас есть мак с установленным Xcode, то локально проверить параметры можно с помощью этого кода
xcrun altool --validate-app -f <Путь к IPA сборке> -t ios -u <email для доступа к appstoreconnect> -p <пароль приложения>

2 Можно добавить код, для нотификаци, например в Discord, тогда скрипт будет выглядеть так

#!/bin/bash

DISCORD_WEBHOOK_URL="https://discord.com/api/webhooks/{WEBHOOK_ID}/{WEBHOOK_TOKEN}"

#Unload to testflight
echo "Uploading IPA to Appstore Connect..."

#Path is "/BUILD_PATH/<ORG_ID>.<PROJECT_ID>.<BUILD_TARGET_ID>/.build/last/<BUILD_TARGET_ID>/build.ipa"
path="$WORKSPACE/.build/last/$BUILD_TARGET_ID/build.ipa"

if xcrun altool --upload-app -f $path -t ios -u $ITUNES_USERNAME -p $ITUNES_PASSWORD ; then
    echo "Upload IPA to Appstore Connect finished with success"
    MESSAGE="✅ Deploy to testflight success: $BUILD_TARGET_ID#$UCB_BUILD_NUMBER!"
else
    echo "Upload IPA to Appstore Connect failed"
    MESSAGE="❌ Deploy to testflight failed: $BUILD_TARGET_ID#$UCB_BUILD_NUMBER!"
fi

# Отправка уведомления через curl
curl -H "Content-Type: application/json" \
     -X POST \
     -d "{\"content\": \"$MESSAGE\"}" \
     "$DISCORD_WEBHOOK_URL"

{WEBHOOK_ID} — уникальный идентификатор вебхука
{WEBHOOK_TOKEN} — секретный токен, который нужен для отправки сообщений

Возможно мог упустить какие-то детали или нюансы, тогда пиши в комментариях, разберем и дополню пост 👇

А если было полезно то ставьте 🔥. Ваш фидбек очень важен для меня и дает мотивацию делать больше полезных постов и понимать, что вам интересно

Мнение подписчиков. Какой ECS-фреймворк выбрать в 2025 году?

Привет, разработчики! У меня назрел интересный вопрос: если делать игру на ПК, похожую на Factorio, где очень много объектов и ключевой момент — высокая производительность, какой ECS-фреймворк использовать?

Последний раз я работал с ECS три года назад, решил обновить знания, но ресерч оказался… разочаровывающим. 😅

Разбирал такие варианты:

1️⃣ DOTS – постоянные проблемы, нестабильность для больших проектов.
2️⃣ LeoECS – кажется, давно не поддерживается.
3️⃣ ECSLite – рабочий вариант, но разработка остановлена.
4️⃣ Morpeh ECS – активно развивается, но выглядит сырым.
5️⃣ Entitas – давно не обновлялся, что настораживает.
6️⃣ Самописный ECS – полный контроль, но сомнительное удовольствие.

А что выбрали бы вы? Может, есть годные альтернативы, о которых я не знаю? Делитесь мнениями в комментах! 👇

🚀 Как построить свой Git workflow

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

🛠 Часть 1. Базовый подход

Тут все очень просто: на проекте есть одна ветка, и все коммиты идут только в нее. Часто в качестве такой ветки используется main (или master) либо dev (или develop).

✅ Если на проекте работает один программист и нет требований к постоянной поставке билдов, можно остановиться на этом.

Очень много мобильных прототипов на этапе первого маркетингового теста используют именно этот Git workflow, и нет необходимости делать что-то сложнее.

👥 Часть 2. Работа в команде

Давайте представим ситуацию, когда на проект пришел еще один программист, и работать в одной ветке стало неудобно. Тогда нам на помощь приходит подход с созданием фича-веток.

🎯 Первое, что нужно сделать, — это определить, какая ветка будет основной рабочей. Практически во всех случаях стоит использовать dev. Однако, если в команде есть, например, художники, которым сложно работать с Git, можно сделать исключение и использовать main как основную ветку, в которую они будут добавлять свои наработки.

🔀 От основной ветки создается отдельный бранч с названием фичи, например, double-jump. Разработчик, ответственный за эту фичу, работает в данной ветке, а затем выполняет merge в основную. Чтобы было понятно, кто отвечает за ветку, можно добавлять ник разработчика в название, например: Boris-double-jump.

🛡 Как только фича готова, она отправляется на код-ревью и тестирование. После успешного прохождения этих этапов она мержится в основную рабочую ветку. При таком подходе в dev (или main) всегда находятся только проверенные фичи с минимальным количеством багов.

Иногда несколько разработчиков работают над одной фичей, например, из-за сжатых сроков. Такой подход нежелателен, но если избежать его невозможно, стоит использовать Trunk-Based Development. В этом случае все разработчики работают в одной ветке либо создают короткоживущие ветки и часто выполняют merge. Такой подход требует микроменеджмента и частой синхронизации действий, особенно в Unity, где сложны слияния сцен и префабов.

🚢 Часть 3. Периодическая поставка билдов

Если к предыдущему подходу добавить требование о периодической поставке билдов, процесс будет следующим:

1️⃣ Когда проект готов к релизу, dev вливается в main, и создается сборка.
2️⃣ После успешного прохождения тестов на последнем коммите ставится тег (например, 1.0.1), а если сборка не прошла тестирование, баги исправляются прямо в main.
3️⃣ main вливается обратно в dev.

🏷 Тегирование необходимо для возможности быстрого выпуска хотфиксов. Если в продакшене найден критический баг, создается новая ветка от коммита с этим тегом, например, hotfix-1.0.2, где исправляется ошибка и затем создается новая сборка.

🔄 Часть 4. Периодическая поставка разных билдов

Теперь представим, что необходимо вести параллельную разработку нескольких билдов с разными фичами. Для этого добавляются релизные ветки.

1️⃣ После прохождения всех тестов фичи 1 она мержится в dev, затем создается ветка RC-1.0.3-IOS, где RC — release candidate.
2️⃣ Аналогично, после тестирования фичи 2 создается другая ветка RC-1.0.3-WebGL.
3️⃣ Баги фиксируются в соответствующих RC-ветках. Если найден общий баг, его можно перенести в другую RC-ветку с помощью cherry-pick.
4️⃣ После выпуска релизной версии ставится тег, и ветка мержится в main и dev.

Если было полезно то ставьте 🔥, а если возникли вопросы, то их можно задать в комментариях👇

P.S Один из подписчиков дал хороший совет: вместо того, что бы добавлять префикс в виде имени лучше использовать папку. Тоесть вместо "Boris-double-jump" использовать "Boris/double-jump"

Расскажу про свой пет-проект, который сейчас в активной разработке.

🔧 Предыстория
Раньше я делал свои проекты под мобильный рынок, но быстро понял — конкуренция там бешеная, и без крупных бюджетов туда лезть сложно. Поэтому решил переориентироваться на ПК.

Провёл маркетинговое исследование, сделал SWOT-анализ, и на выходе у меня осталось два направления, в которых можно реально выстрелить:

* Выживачи с крафтом
* Автоматизация

Сгенерировал несколько концептов, и один из них "запал" не только мне, но и моим друзьям. Именно его я и решил развивать.

🎮 Об игре
Factorio, но про живой организм.

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


👨‍💻 Сейчас в команде два человека: я и сеньор-разработчик.
🔍 Мы ищем Senior или Lead концепт-художника, который поможет сформировать визуальный стиль и довести игру до первых маркетинговых тестов.
💸 Рассматриваем как оплату по часам, так и формат на энтузиазме с возможным RevShare.

📩 Если вы художник (или знаете такого), пишите в личку: @romanchikov — обсудим.

✨ Также будем рады программистам, геймдизайнерам и просто энтузиастам, которым интересно поучаствовать в проекте. Присоединяйтесь — всё обсудим, и найдём для вас роль.

⏱️ Автоматизация AI процессов в геймдеве!

Не секрет, что AI уже прочно внедрился в геймдев и у него есть множество интересных кейсов

Кстати вот некоторые примеры использования AI, которые меня впечатлили:
1. Создание Spline анимаций с помощью AI. Смотреть видео
2. Кейс от Unity для создания валидных уровней для Match 3. Смотреть видео

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

Пример: создание 3D модели персонажа для игры по описанию.

Процесс будет выглядеть так:

1. Мы пишем короткое описание персонажа.
2. ChatGPT генерирует промт для Midjourney.
3. Midjourney создает изображение персонажа.
4. ChatGPT (или Stable Diffusion) генерирует изображение с 3-х сторон.
5. Kling создает видео с персонажем со всех сторон.
6. Trellis создает 3D модель на основе этого изображения.
Пример такого видео прилагаю к посту

Согласитесь делать каждый раз все эти шаги вручную, а еще ждать генерации никому не хочется, а хочется сразу получить результат, поэтому процесс нужно автоматизировать.
Но как же его автоматизировать? Существуют платформы как раз для автоматизации AI процессов, например https://n8n.io. Это платформа, которая позволяет организовать и автоматизировать различные рабочие процессы с множеством готовых шаблонов. Я взял за основу шаблон: "General 3D Presentation Workflow with Midjourney, GPT-4o-image и Kling APIs".

Теперь представьте, что мы не хотим одну, а несколько 3D моделей с хорошим качеством, чтобы выбрать лучшую.

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

А дальше можно запустить 20-30 таких процессов сразу, и на выходе получить несколько готовых 3D моделей, которые будут автоматически сохранены в Google Drive или отправлены, например, в Телеграм или Discord.

Делитесь в коментариях вашими интересными кейсами применения AI👇

🎙 Софт скиллы для разработчика

Честно говоря, всё чаще замечаю, что значительная часть моей работы — это не код, а коммуникация:
созвоны внутри команды, обсуждения с лидами, митинги с другими отделами. И именно в такие моменты становится особенно заметна разница между людьми с хорошими софт скиллами и теми, кому их не хватает.

💡 В отличие от хард скиллов, софт скиллы — это навыки общения, которые важны не только в работе, но и в жизни.

Вот ключевые навыки, которые мне особенно помогают:

🔹 Проактивность
Не жди, пока кто-то даст тебе задачу или укажет на проблему.
📌 Пример: Ты заметил, что билд стал дольше собираться после недавнего обновления. Вместо того чтобы ждать, пока кто-то начнёт жаловаться, ты сам анализируешь логи, находишь узкое место и предлагаешь решение на синке. Это сразу поднимает твой авторитет в команде.

🔹 Конструктивное решение конфликтов
Конфликты бывают даже в самых дружных командах. Главное — не ссориться, а решать.
📌 Пример: Тебе не нравится, что продакт добавляет фичу, которую нужно сделать еще вчера. Вместо того чтобы злиться, ты договариваешься с ним, что фича будут сделана, но после обязательно проведем рефакторинг этой фичи. Проблема решена, отношения не испорчены.

🔹 Умение просто объяснить сложное
Часто приходится доносить технические детали до нетехнических коллег.
📌 Пример: Продакт спрашивает, почему нельзя “просто сделать мультиплеер за неделю”. Вместо “это невозможно” ты говоришь: "Чтобы игроки могли подключаться друг к другу и видеть действия в реальном времени, нужно реализовать систему синхронизации и авторизации. Можно сделать ее за неделю с готовыми решениями, но все будующие фичи будут разрабатываться дольше"

🔹 Сфокусированность на результате
Важно не просто “делать задачи”, а помнить про конечную цель.
📌 Пример: ты заметил, что фича, над которой работает команда, не даст пользы без аналитики. Вместо того чтобы «просто сделать задачу», ты обсуждаешь с продактом и предлагаешь доработать ТЗ, добавив аналитику. В итоге — выкатили фичу, которая реально помогает принимать решения.

🔹 Тайм-менеджмент
Умение организовать своё время — ключ к стабильной работе и отсутствию переработок.
📌 Пример: ты разбиваешь задачи на короткие интервалы, приоритизируешь по важности, оставляешь буферы под форс-мажоры и ставишь напоминания.

Есть еще персональные навыки общения, которые часто называют харизмой. С ними ситуация чуть сложнее, но их тоже можно прокачать. Я рекомендую 2 книги, которые мне очень помогли в свое время:

1. Дейл Карнеги — Как завоёвывать друзей и оказывать влияние на людей
Классика, которая учит слушать, говорить и вызывать симпатию.

2. Лейл Лаундес — Как говорить с кем угодно и о чём угодно
Более практическая книга, особенно полезна интровертам.

Мне действительно хочется больше говорить о софт скиллах, ведь они влияют на карьеру не меньше, чем ваш код.
Если тема вам интересна — поддержите пост реакцией ❤️ или комментарием. Тогда я подготовлю ещё пару разборов по конкретным ситуациям из жизни

🎮 Unity и WebGL

Очень рад, что предыдущий пост про софт-скиллы вызвал столько интереса — уже готовлю подробный материал по теме!

А пока хочу поделиться опытом, который мы обсуждаем в команде всё чаще: насколько Unity вообще подходит для WebGL-игр?
Если коротко — подходит, но с нюансами. Делюсь личным опытом и наблюдениями


💡 Начнём с плюсов, которые на поверхности:

🔹 Лёгкий порт с мобильных платформ
Скорее всего, если у вас уже есть мобильная игра — порт на WebGL займёт минимум времени

🔹 Кроссплатформенность
Вы пишете игру один раз, а она работает везде: браузер, мобилки, ПК

🔹 Богатая экосистема
Unity-ассеты, туториалы, плагины, CI/CD — всё уже есть и хорошо работает


💡 А теперь к менее очевидной части

🔻 1. Большой размер сборки

Unity WebGL часто критикуют за вес. Но это, скорее, вопрос оптимизации, а не движка.
У нас был кейс, где коммерческий билд весил меньше 10 МБ, а в минимальный вес — всего 3.5 МБ.
Так что при желании ужимается всё.

🔻 2. Высокое потребление ресурсов

Тут всё не так однозначно
Да, Unity собирает WebGL через WebAssembly — и теоретически он работает даже быстрее JavaScript
Но на практике узкое место это архитектура Unity которая делает вычисления и рендер каждый кадр, а не по событиям

Unity UI также негативно влияет и на память, ведь в Unity для интерфейса мы используем текстуры, которые по возможности заменяем на ассеты типо TrueShadow или ProceduralImage, но в любом случае в памяти даже самый оптимизированный UI будет занимать одназначно больше места чем CSS

Плюс Unity имеет некий минимальный размер в памяти, котоый на оптимизированном, пустом проекте составил около 45 МБ, что заставляет делать серьезные оптимизации, что бы влезть в лимит памяти для мобильных устройств

🔻 3. Ограниченный доступ к системным API

Работа с файлами, буфер обмена, интеграции с внешними JS-фичами — всё это требует ручной JS-интеграции через *.jslib.
Это несложно, но утомительно. Ассетов в Asset Store, которые закрывают эти задачи “из коробки”, пока мало.


🧠 Итог:

Unity подходит для WebGL, особенно если у вас:
— уже есть мобильная игра
— сложная логика, 3D и прочий “движковый” функционал

Но если ваша цель — быстрая и лёгкая браузерная игра с акцентом на UI, есть варианты попроще.

Если было полезно — ставьте ❤️ или напишите пару слов в комментарии!
А если ты вдруг читаешь это и не поставил лайк — возможно, ты уже отлично разбираешься в Unity WebGL.
В таком случае у нас есть вакансия Middle Unity-разработчика, который займётся портированием игр на WebGL. Пиши в личку: @romanchikov

💥Найдёте все 10 ошибок?

Недавно мне попался на глаза один кусок кода и, честно говоря, почти каждая строка попадает в раздел "Так делать не нужно"

Я насчитал как минимум 10 проблемных мест, которые точно стоит отнести к плохим практикам

А ты сможешь найти их все? Пиши в комментарии, что бы вы точно поменяли в этом коде

А в следующем посте:
Я расскажу, кто первым назвал больше всего правильных пунктов и подробно разберу каждую ошибку

🧠 Разбор кода: 10 ошибок из прошлого поста

Как и обещал — делаю разбор кода с прошлой публикации. Поехали!

Ошибка 1. GameManager
Название класса не информативное. Можно очень легко понять хорошее ли название класса, метода или переменной. Для этого достаточно посмотреть на название и не изучая код понять, за что отвечает эта сущность. Название GameManager означает, что внутри этого класса может быть все что угодно.

Ошибка 2 и 3

public static event Action OnCubeSpawned = delegate { };

2. Сам класс не является статическим или синглтоном (то есть быть в единственном экземпляре), при этом эвент статический. Статический эвент только в статических классах

3. = delegate { };
Получается мы создаем пустой делегат и всегда его вызываем, что не имеет смысла. Тем более в C# принято вызывать эвенты через ?.Invoke()

Ошибка 4 и 5

private void Awake()
{
    spawners = FindObjectsOfType<CubeSpawner>();
}

4. FindObjectsOfType<CubeSpawner>();
Ну тут наверное каждый разработчких схватился за сердце, когда увидел эту строчку. Во первых тут есть скрытая зависимость и нарушение принципа D (SOLID), во вторых это тяжелая операция

5. Еще одной ошибкой является вызов в Awake()
Не даром Unity сделала 2 метода инициализации: Awake и Start, и их условное различие в том, что Awake вызывается для инициализация внутренних компонентов скрипта, а Start для внешних. Если придерживаться этого правила, то можно будет избежать багов и проверок на инициализацию компонентов. Но лучше использовать DI

Ошибка 6, 7, 8

if (Input.GetButtonDown("Fire1"))
{
 ...
}

6. Лучше использовать конструкцию if-return

if (!Input.GetButtonDown("Fire1"))
    return;

Тогда код не поменяет свою логику, а код станет читабельнее

7. "Fire1" стоит вынести в константу и использовать ее, вместо конкретной строки

8. Input это отдельная ответственность, что нарушает принцип S (SOLID), такую логику нужно вынести в отдельный класс и добавить эвент на конкретное действие

Ошибка 9

currentSpawner = spawners[UnityEngine.Random.Range(0,2)];

Вот тут вообще фатальная на мой взгляд ошибка. В логике кода сильная зависимость, что размер массива равен 2, А любое изменение в количестве кубов приведет на сцене к багу.

Ошибка 10
Общий код стиль проекта отличается от Microsoft code convention
Отсутствие private, название полей без "_", отсутствие отступов, но, когда я провожу ревью, я обычно отношу эти недостатки к несущественным, так как можно довольно легко их исправить через код стиль райдера, например. Исключением является, пожалуй совсем уж странные подходы к форматированию кода, такие как венгерская нотация или форматирование через Tab как в шейдерах

А первым подписчиком, который назвал большинство ошибок был @arper
В первом комментарии приложу пример рефакторинга данного кода, без изменения архитектуры

P.S Спасибо всем, кто проявил активность в прошлом посту! А я уже дописываю пост про софт скилы

🎙Софт-скиллы разработчика

Это, пожалуй, самый трудоемкий пост на моем канале. Я собирал его несколько недель, опираясь на личный опыт и книги по теме. Материал получился объемным и, возможно, спорным, но это мой взгляд. Вместо критики прошу встать на мое место и подумать: почему я выделил именно эти советы и почему они выглядят именно так

🥇Нацеленность на результат

Успех не меряется усилиями. Он меряется результатом

Я начал свой путь разработчика в МГТУ им. Баумана, где меня окружало множество талантливых ребят, которых без сомнения можно назвать технарями от мозга костей до кончиков пальцев. Во время нашего обучения у нас был предмет под названием "Основы экономики", на который ходило от силы 20% студентов, в числе которых был и я. Главным аргументом тех, кто пропускал пары, было то, что этот предмет нам не пригодится в будущем как специалистам. Я же считал и считаю иначе, потому что большинство из нас работает в коммерческих компаниях, главная задача которых зарабатывать деньги. Любой сотрудник такой компании это часть одного большого механизма. Весь наш труд направлен на то, чтобы компания заработала деньги, из которых нам выплатят зарплату. Из этого плавно вытекает моё первое правило: "Нацеленность на результат"

Давайте разберу ситуацию из собственного опыта

Однажды мы выпустили релиз, в котором перестали работать встроенные покупки. Деньги у игроков списывались, но товары не доставлялись. Активная аудитория — более миллиона человек. Это был настоящий провал!

В 9 вечера мне позвонил менеджер на личный телефон и описал проблему. В тот момент я был на тренировке. Передо мной стоял выбор: бросить всё и срочно спасать ситуацию или ответить, что рабочий день закончился, и заняться этим завтра. Я выбрал первое, потому что руководствуюсь принципом "Нацеленность на результат"

Уже в 9:30 я сидел за компьютером, созвонился с менеджером, и мы провели на связи около восьми часов. К 5 утра мы залили билд с исправлением и попросили быструю модерацию у стора. Позже выяснилось, что проблема была на стороне бэкенда, и технически я не был виноват. Но вместо того чтобы "отмыться", я сделал всё, что мог и мы спасли проект от огромных финансовых потерь, а возможно, и от полной гибели

И это касается не только эпичных ситуаций, но и вполне бытовых

На одном из проектов QA-команда работает посменно 7 дней в неделю, чтобы обеспечивать поддержку клиентов даже в выходные. Иногда мы выкладываем сборку в пятницу, чтобы за выходные провести полное тестирование и в понедельник сделать релиз

Однажды мы поставили сборку в пятницу вечером, и она не собралась. Поскольку сборки занимают несколько часов, результат я увидел только в субботу, в пятницу ночью и весь день в субботу у меня был перелёт с длинной пересадкой. Уже в аэропорту, во время пересадки, я заметил, что сборка упала. Сидя там, я потратил около двух часов на поиск и исправление ошибки, после чего запустил новые сборки и они успешно собрались.

Команда QA провела тестирование в воскресенье, и в понедельник мы выпустили релиз, как и планировали
Поэтому правило: Нацеленность на результат прочно закрепилось в списке моих личных софт-скилов


💬 Говорите просто о сложном

Инженер — это человек, который перед тем как рассказать шутку, проводит 40-минутную лекцию, чтобы собеседник мог её понять

Если бы мне платили доллар каждый раз, когда на синке разработчик говорит: "Да у нас в классе SerializationService сериализация бинарная, а не JSON"... А, стоп, погодите мне же за это и платят. Я же перевожу с технического на менеджерский

Продактам, менеджерам, художникам не важна архитектура проекта, классы или другие технические дебри. Они в этом не разбираются и не обязаны. Поэтому важно уметь говорить о техническом без технического жаргона

Представьте, что продакт однажды скажет:
«У нас есть валидированный юзер-фидбек, метрика drop rate по воронке просела на 12%, а фича уже behind по roadmap».
Вот именно так звучим мы, когда начинаем говорить "по-своему" со всей остальной командой


🤷‍♀️ Не будьте загадкой для своей команды

Сюрпризы для дней рождения, а не для команды

Если бы меня спросили, какая главная ответственность разработчика, я бы ответил: сделать фичу вовремя
Но в реальной жизни всё сложнее. Во время разработки появляются новые вводные, задача может потребовать дополнительного изучения да и вообще, всегда найдётся миллион причин, почему всё может пойти не так

Поэтому важно, чтобы команда и, главное, руководство заранее знали, что что-то идёт не по плану. Тогда ещё можно принять решение и что-то изменить, пока не поздно

Если вы понимаете, что не успеваете, не молчите. Напишите об этом как можно раньше. Не стоит дожидаться синка и оправдываться. Почти всегда можно найти решение, как ускорить процесс заранее

Если вы не можете точно оценить задачу, выделите отдельную на исследование, ограничьте её, например, 4 часами. После этого уже можно дать более точную оценку основной задачи

А если задачу всё-таки нужно успеть в срок за счёт качества кода, то сразу после релиза поставьте задачу на рефакторинг


👔 Менеджер всегда прав!

А если не прав — см. пункт выше

Все мы знаем главное правило бизнеса: "Клиент всегда прав". Так вот, пока вы работаете в команде, вашим клиентом является ваш руководитель, будь то тимлид, менеджер или продакт

И прежде чем накидывать дизлайки, скажу: я и сам могу привести миллион примеров, когда менеджер был не прав
Но если вы будете постоянно спорить, оспаривать решения или конфликтовать, вас рано или поздно заменят на того, кто не будет. Вместо конфликта: разберитесь, почему было принято то или иное решение, и обсудите это конструктивно, аккуратно донесите свою точку зрения

Пара примеров из практики:

Однажды разработчик сделал анимацию и отправил видео в командный чат. Анимацию утвердили, и он собрал билд. В билде всё выглядело иначе. Вместо того чтобы проверить сборку, настройки или коммиты, начались споры. То, что можно было решить за 15 минут, вылилось в час обсуждений с участием всей команды. В итоге задача "подорожала" с 15 минут до 4 часов командного времени. И, неудивительно, после этого с разработчиком никто не захотел больше работать

А вот пример от моего друга и активного подписчика канала
(обращение к нему: если решишь закидать меня камнями, то лучше сделай это, пожалуйста, в каком-нибудь выживаче 😅)

Разработчика назначили на проект, где код был в удручающем состоянии. В какой-то момент он пришёл к тимлиду и резко высказался по поводу качества кода. Это задело лида, информация дошла до менеджера и разработчика сняли с проекта

Был ли прав тимлид, допустив такой код? — Нет
Был ли прав разработчик, что пришёл с претензией в такой форме? — Тоже нет
Потому что, как бы это ни звучало: менеджер всегда прав!

Кстати, именно после этого случая я ввёл у себя простое правило:
Любой член команды может придти ко мне и в любой, хоть самой резкой форме, высказать своё мнение о коде или команде


Этот пост получился очень длинным, а изложить удалось лишь малую часть той информации, что я хотел донести. Скажу честно, информации так много, что я даже задумался написать книгу по этой теме. Ну а, если вам было полезно или просто интересно, то поддержите пост реакцией ❤️

🎮 Найти работу Unity-разработчиком — всё ещё легко?

🧵 Немного личного:
Давно не выкладывал посты — почти всё свободное время уходило на пет-проект. И вот, наконец, сегодня мы отправили нашу страницу в Steam на ревью, но об этом расскажу подробнее в одном из следующих постов
Решил, что это отличный повод поделиться чем-то полезным.

Очень часто слышу мнение, что главное умение мыслить и оффер будет в кармане
К сожалению, это уже не так

📉 Ещё 2–3 года назад:
✔️ Рынок был на стороне кандидатов
✔️ Геймдев активно рос
✔️ Найти работу было относительно легко

Сейчас всё иначе:
• Рост геймдева замедлился
• Количество кандидатов растёт (новое поколение подросло)
• Зарплаты не растут, а иногда даже падают

🧠 Моё мнение основано на практике: я участвую в найме и вижу, как всё меняется. У нас в компании высокие стандарты и мы оцениваем весь стек: от мобильных SDK и WebGL до шейдеров и мультиплеера. Несмотря на это, мы стабильно нанимаем кандидатов. Но цифры говорят сами за себя

📊 Наша статистика за 2025:

Senior-разработчики
🔹 150 приглашений
🔹 49 code review — 30%
🔹 22 HR-интервью — 15%
🔹 4 тех. интервью — 2.5%
🔹 3 интервью с CEO — 2%
🔹 2 оффера — 1.5%

Middle-разработчики
🔹 80 приглашений
🔹 41 code review — 50%
🔹 21 HR-интервью — 25%
🔹 9 тех. интервью — 11%
🔹 2 интервью с CEO — 2.5%
🔹 1 оффер — 1%

🛠 Вывод:
Просто “уметь разобраться” уже недостаточно.
Нужны:
✅ Уверенные технические навыки
✅ Готовность к собеседованиям
✅ Прокачанные софт-скиллы

💬 P.S.
Будет круто, если поделитесь в комментах своими историями прохождения/проведения собесов.
Согласны ли вы с моими выводами?