Проект Chase Car Arcade 🚗

После провала Galaxy Expansion я решил попробовать другой подход — сделать игру с объемом контента только на маркетинговый креатив. Главная цель такого проекта — отснять маркетинговый креатив и проверить стоимость привлечения пользователя (CPI). На разработку игры ушло всего 2 недели.

📊 Метрики
1️⃣ CPI: >3$
2️⃣ D1: 2%

Ссылочка на Google Play

Результаты оказались неудовлетворительными, и мы решили не продолжать развитие проекта. Вместо этого я перешёл к следующей идее.

Плюсы такого подхода ✅
1️⃣ Возможность быстро проверять идеи и гипотезы.

Минусы такого подхода ❌
1️⃣ Плохой ретеншн в подобных проектах.
2️⃣ Метрики сильно зависят от качества маркетингового креатива.

Уроки из проекта Chase Car Arcade 💡
Этот подход хорош для проверки трендов или экспериментальных механик, но он имеет свои ограничения. Например, без тестирования ретеншна трудно понять долгосрочный потенциал игры.

Даже при высоком CPI проект с хорошим ретеншном может приносить доход. Поэтому чаще имеет смысл потратить чуть больше времени и ресурсов, чтобы создать игру с 10-20 минутами полноценного геймплея.

Рекомендации для Hypercasual игр
Многие продюсеры советуют:
🎯 Разрабатывать игру с минимальным, но полноценным контентом, например, 10 уровнями или 10-20 минутами геймплея.

Когда я начинал Chase Car Arcade, я знал это правило, но не понимал его на практике. Этот проект помог мне (и, надеюсь, вам) увидеть, почему важно следовать такому подходу.

Сравнение подходов
* Galaxy Expansion показал недостатки долгой разработки и большого количетва контента
* Chase Car Arcade продемонстрировал минусы минималистичного подхода.

А как вы проверяете свои идеи? Делали ли вы похожие эксперименты? 😅

На днях наткнулся на прекрасный пост про "Сочность" в играх

Оригинал тут

На мой взгляд обязательные знания для всех, кто работает в геймдев индустрии, особенно тем, кто делает прототипы
Всем советую посмотреть гифку из поста!

Это, кстати, то, что мы в первую очередь тестируем у кандидатов во время Live coding на прототипы. Потому что, часто, именно программист отвечает за "сочность"

Коротко смысл в том, что что-бы сделать игру более сочной нужно добавить для действий такие реакции
* Изменение цвета объекта
* Изменение пропорций или другая Tween анимация
* Добавление VFX
* Дрожание камеры
* Звуковой эффект
* Другие эффекты, напрмер замедление времени

Всем привет!
На хабре вышла моя новая статья про процесс автоматизации 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 проблемных мест, которые точно стоит отнести к плохим практикам

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

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