💡Как пройти Code Review? Советы 6–10

Как эффективно проходить собеседования? Часть 2

✏️ Совет 6: Соблюдайте код-стиль
Покажите, что умеете писать чистый код. Я рекомендую:

* Код-конвенции Microsoft
* Гайд Unity: Code Style Tips
* Если работаете в Rider, настройте подсказки Code Style для упрощения работы

🏗️ Совет 7: Архитектура имеет значение
Покажите своё мастерство! 😎

* Проект можно немного "переусложнить", чтобы лучше показать навыки. Иначе зачем это все нужно?
* Следуйте принципам SOLID, KISS, DRY. Использовать их в реальных проектах это отедльный разговор, но владеть ими нужно
* Не используйте Singlton. Это сразу отказ. Почему? Потому, что его знают все, а создать архитектуру без него умеет не каждый

🔍 Совет 8: Упрощайте complexity
Чем проще понять код, тем лучше:

Подробнее про complexity: здесь
Также есть книжка Роберта Мартина "Чистый код"

✂️ Совет 9: Не переусердствуйте с комментариями
Код должен быть понятным без комментариев.

Советы:
* Не используйте summary. Они уместны в публичных методах в библиотеках
* Разбейте сложные части на методы или классы.
* Используйте понятные названия перменных и методов

💪 Совет 10: Не расстраивайтесь при отказе
Отказ — это шанс для роста! 📚

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


Кстати, вот пример моего тестового проекта: GitHub

Был ли какой-то совет для вас полезен? Делитесь в комментариях! 👇

💡 Как пройти техническое собеседование?
Как эффективно проходить собеседования? Часть 3

Техническое собеседование – это момент истины. Его цель – понять, хватит ли ваших навыков для проекта. Как подготовиться и пройти его максимально успешно?

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

Из чего состоит техническое собеседование?

1️⃣ Рассказ кандидата о предыдущем опыте работы
⏱ 10–15 минут
Перед собеседованием я уже изучаю CV кандидата, но прошу повторить информацию, с фокусом на технические детали. Расскажите о своей роли, инструментах и задачах. Помните: чем больше деталей вы дадите, тем меньше будет технических вопросов.

2️⃣ Технические вопросы
⏱ 40–50 минут
На этом этапе я оцениваю знания кандидата по ключевым навыкам:

Unity 3D/2D
Physics
UI
Shaders
Оптимизация
Архитектура
C#
Assets/SDK
Network

💡 Важно: если вы активно помогаете интервьюеру разобраться в ваших знаниях, это большой плюс!

3️⃣ Вопросы кандидата
⏱ 5 минут
Если у вас есть вопросы о работе, задавайте их – это показывает ваш интерес.


6 советов, как успешно пройти техническое интервью

1️⃣ Используйте деловой язык.
Стиль общения имеет значение. Если интервьюер смягчает тон, вы можете немного адаптироваться, но сохраняйте профессионализм.

2️⃣ Подробно отвечайте на вопросы.
Вы пришли не «сдать экзамен», а показать свои сильные стороны. Не заставляйте вытягивать из вас информацию.

3️⃣ Отвечайте по делу.
Не уходите в сторону от заданного вопроса. Это снижает доверие к вашим знаниям.

4️⃣ Не говорите «я не знаю».
Если вы не уверены, попробуйте рассуждать. Это лучше, чем просто признать незнание, и добавляет вам баллы.

5️⃣ Не используйте шпаргалки.
«Подсматривание» легко заметить, и это вызовет дополнительные, сложные вопросы. Лучше честно показать свой уровень.

6️⃣ Спросите обратную связь.
Вопрос «Как я себя показал?» может быть полезен, если компания обычно не дает фидбэк. Это ваш шанс узнать, что подтянуть.

💬 Делитесь своими впечатлениями от собеседований в комментариях! А в следующем посте я подробно расскажу о том как проходить live coding интервью.

📌 Подписывайтесь на канал, чтобы не пропустить новые советы!

Мой первый Game Jam за 10 лет 🎮

10 лет назад я последний раз участвовал в хакатоне. Тогда мы с командой сделали VR-приложение для детейлинга автомобилей и заняли первое место. Это был невероятный опыт, но с тех пор я полностью углубился в работу, и времени на Game Jam у меня просто не находилось.

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

🔘 Я выбрал -1 Button Game Jam! Его концепция показалась мне очень интересной: разработать игру, где всё управление происходит через одну кнопку.

Я решил участвовать в одиночку. После большого количества общения на основной работе мне захотелось побыть наедине с идеями и полностью реализовать свой творческий потенциал. И знаете что? Мне это чертовски понравилось!

🌟 За эти несколько дней я понял несколько важных вещей:
1️⃣ Несмотря на то, что я сейчас редко пишу код, я до сих пор отлично помню, как разрабатывать игры, и делаю это очень быстро, что меня радует
2️⃣ Разрабатывать проект полностью самостоятельно — невероятное ощущение, когда ты принимаешь все решения сам.
3️⃣ Теперь я чётко понимаю, на что стоит тратить время, а что является второстепенным. Это позволяет работать эффективнее и не закапываться в детали.

Сегодня я отправил свой проект в релиз! Знакомьтесь, Dome Defence:
👉 https://romanchikov.itch.io/dome-defence

🔥 Как проходила разработка?
На старте нам предложили три темы для Jam:

1. Dome
2. Agreement
3. Bugs

Так как я работал один, бреиншторм с командой был невозможен, поэтому мне помог ChatGPT. Я сразу решил отказаться от очевидных идей вроде экшенов и аркад, потому что 90% игр на таких мероприятиях создаются именно в этом жанре. В итоге у меня осталось несколько основных концепций:
1️⃣ Пазл, где нужно менять цвет объекта нажатием кнопки.
2️⃣ Пазл с механикой изменения гравитации.
3️⃣ Idle-игра или кликер.

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

💻 Вот как прошли четыре дня разработки:

Первый день: генерировал идеи, создал проект, добавил все необходимые ассеты, настроил графику и сделал логику движения врагов.
Второй день: закончил всю основную механику — всю логику врагов, юнитов, базы, прокачки и так далее.
Третий день: занимался балансом волн, добавлением контента, созданием различных типов врагов, прокачки и мелкой полировкой.
Четвёртый день: дал своим друзьям игру на тесты, исправил найденные баги, довёл до ума финальные детали и оформил страницу проекта на itch.io.
На всю разработку ушло около 40–50 часов.

💡 Какие планы дальше?
Победа? 😅 Ну, конечно, было бы приятно, но в этом Game Jam нет призового фонда и наград. Поэтому я хочу адаптировать игру для мобильных платформ, найти издателя и протестировать её на реальном рынке.

Вот так прошли мои игровые каникулы. А вы уже поиграли в Dome defence? Как вам? Делитесь в комментариях! 💬

✅ Live coding — что это и как его пройти?

Как эффективно проходить собеседования? Часть 4

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

Кроме того, такая практика помогает оценить:

* Умение создавать прототипы с нуля
* Скорость и эффективность работы

⚡ Почему мы выбрали live coding

Мы недавно ввели эту практику в нашей компании, и теперь не представляем, как обходились без неё раньше.

—
Как проходит live coding у нас?

1. Перед началом интервью мы просим кандидата скачать заранее подготовленный тестовый проект, чтобы не тратить время на настройку.
2. На интервью я трачу 10-15 минут на вводную часть.
3. Затем даю кандидату задание, рассчитанное на 2 часа.

Правила:

1. Можно гуглить и использовать AI.
2. Разрешено использовать и добавлять любые ассеты.
3. Код может быть «грязным» — архитектура и качество не оцениваются.

Критерии оценки:

1. Финальное качество игры. Игра не должна содержать багов, анимации и игровые элементы должны выглядеть «sочно». Мы оцениваем продукт глазами игрока, а не разработчика.
2. Скорость работы. Оценивается, сколько заданий кандидат успевает выполнить и как быстро. Также фиксируем, на что он тратит больше времени.
3. Навыки. Как кандидат пишет код, пользуется ли AI и горячими клавишами, какие плагины редактора применяет, как быстро ориентируется в Unity.

Красные флаги на собеседовании:

1. Низкое качество проекта. Нет анимаций, плавных переходов, игровых «фишек».
2. Чрезмерное использование ChatGPT. Особенно там, где быстрее написать код вручную.
3. Ненужные задачи. Написание «чистого» кода, рефакторинг, уборка проекта.
4. Хаотичность. Переход от одного задания к другому без завершения текущего.

Live coding — отличный способ показать свои сильные стороны! Но помните: главное — результат, а не идеальная архитектура.

🚀 Напишите в комментариях проходили ли вы собеседование в формате live coding и понравлся ли вам такой формат?

Хотел поделиться с вами радостной новостью!
Вышла моя статья на хабре

Прочитать ее можно по ссылке
Как пройти собеседование на Unity-разработчика: мнение лида

Мой дебют на Хабре прошел с максимально "успешно"
Карма понижена до -2, а рейнтинг понижен до -6

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

Я перевел статью в режим черновика и она будет временно не доступна до тех пор, пока я не сделаю работу над ошибками

Отредактировал статью и сделал ее публичной
Как пройти собеседование на Unity-разработчика: мнение лида

Основный контент и смысл остался тот же. Я не менял советы или важные пункты
Что поменял:
* Добавил пояснение и ремарки к некоторым пунктам, которые вызвали вопросы
* Сильно дополнил процесс связанный с Live coding, добавил больше деталей и нюансов. Постарался ответить на вопрос, почему 2 часа это нормально
* Добавил часть P.S. для тех, кто мог не правильно понять мой основный посыл

Пойду ставить свечку за мой рейтинг!

🎮 Что должен уметь разработчик игр?

💬 Ответ: то, что требует от него компания

На этом можно было бы закончить пост, но хочется копнуть глубже. Ведь понятие "разработчик игр" не ограничивается одной компанией, и у каждого своё представление о том, что это значит

Например, как бы вы ответили на вопрос:
Должен ли Unity-разработчик уметь писать шейдеры?
Свои ответы оставляйте в комментариях, а мы продолжаем 👇


Я работаю лидом в аутсорсинговой и аутстафинговой компании, специализирующейся на разработке игр в Unity. Наши проекты — от прототипов до сложных мультиплеерных игр на этапе liveops. В команде более 10 Unity-разработчиков, и их навыки сильно различаются: кто-то хорош в архитектуре, а кто-то — в создании прототипов.

Здесь возникает проблема: если клиент приходит с уникальным проектом, предсказать его требования заранее практически невозможно. Найм кандидата занимает, в среднем, месяц, а клиенты хотят начинать работу уже на следующей неделе. Да и нанимать кандидата под конкретный проект, который закончится через 3-6 месяцев не выгодно ни кандидату ни нам.


А теперь важный вопрос:
Какими компетенциями должен обладать Unity-разработчик?

Вот расширенный список навыков, которые пригодятся в работе

(50%) означает, что 50% проектов в нашей компании, а также в проектах, которых я принимал участие требовали наличие этого навыка.
Проценты несут ознакомительный характер и отражают мой опыт. Опыт вашей компании будет отличатся. Вы можете менять или объединять пункты исходя из специфики вашей
* - помечены темы, которые мы спрашиваем на собеседовании

🎯 Знание движка Unity* (100%)
Базовые знания Unity: MonoBehaviour, Корутины, отличие Update от FixedUpdate, NavMesh, Animator, Поиск пути, Опыт написание кастомного редактора,

🎯 Unity 3d* (70%)
Что такое Mesh и из чего состоит 3d модель, Оптимизация 3d игр, скелетная анимация

🎯 Unity 2d* (30%)
Понимание Sprite и Sprite Atlas, Скелетная анимация в 2d, В чем основное отличие Unity 2d проектов от Unity 3d

🎯 Physics* (20%)
Теоретическое знание кинематики

🎯 Unity UI* (80%)
Canvas, Layout group, как верстать адаптивный интерфейс, Safe Area
Оптимизация и производительность

🎯 Шейдеры и графика* (5%)
Какие есть пространства в Unity, Shaderlab, Shader graph, Renderer Pipelines, Post Processing, Draw calls

🎯 Оптимизация и профайлинг* (70%)
Big O notation, Profiler, Deep profiling, Frame debugger, Memory profiling, Profiling on device

🎯 Архитектура* (100%)
Паттерны, SOLID, Реактивное программирование, MV* шаблоны, организация данных

🎯 C#* (100%)
Тут много всего. Некоторые темы: ООП, абстрактный класс и интерфейс, атрибуты, Reflection, GC

🎯 Assets* (90%)
Zenject, VContainer, UniRx, Odin, UniTask, Addressables

🎯 Разработка под PC (5%)
Управление джойстиком, Особенности реализации под конкретную платформу (Steam, Epic games)

🎯 Разработка под мобильные платформы* (85%)
Реклама, Аналитика, Конфиги, БД, Пуш уведомления

🎯 Разработка под Web (10%)
Ограничение под WebGL, особенности реализации под конкретную платформу (Yandex игры, Telegram и т. п.)

🎯 AR/VR (0%)
Особенности управление в VR. Asset VRTK, платформа Oculus

🎯 Сетевая разработка* (50%)
Rest API, Сокеты, Мультиплеерные игры, Photon, SaaS

🎯 ECS (0%)
Понимание ECS архитектуры, LeoECS, Morpeh, Entitas, DOTS, другие реализации

Разработка под PC, AR/VR, Web имеют маленький процент, так как большинство наших заказов это мобильные игры
Архитектура имеет 100%, так как она нужна везде, но для прототипов не критична. Кандидат с хорошим знанием архитектуры просто сделает прототип качественнее
ECS имеет 0% так как у нас нет проектов с таким архитектурным подходом

💡 Буду очень признателен, если вы заполните форму (1 мин) о навыках на вашем проекте

🎯 Матрица компетенций: инструмент для распределения задач

Что такое матрица компетенций?
Это простая таблица, в которой каждому разработчику оценивают навыки по 5-балльной или процентной шкале.

🛠 Зачем она нужна?
Представьте, что в вашей команде 5 Unity-разработчиков, и вы распределяете задачи на новый спринт. Можно:
1️⃣ Спросить, кто что хочет взять.
2️⃣ Довериться своему опыту.
3️⃣ Или воспользоваться матрицей компетенций — удобной "шпаргалкой", которая наглядно покажет сильные и слабые стороны каждого разработчика.

А если у вас 10 разработчиков? Удержать всю информацию в голове становится практически невозможно.

🔍 Пример матрицы компетенций

Вася Пупкин
* Unity3D: 4
* Physics: 5
* Multiplayer: 0
* Система скилов: 4
* Скорость работы: 5
* Коммуникации: 5

Фича: Скилл заморозка
* Unity3D: 5
* Physics: 0
* Multiplayer: 0
* Система скилов: 5
* Скорость работы: 5
* Коммуникации: 3

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

🎨 Лайфхаки использования
Выделяйте зелёным навыки, которые сотрудник хочет прокачивать, а красным — те, которые не вызывают интереса.
Матрица полезна не только для техлидов, но и для тимлидов или менеджеров проектов.

📈 Когда стоит внедрять матрицу компетенций?
* Команда из 3+ разработчиков.
* Много нетипичных задач или проектов.
* В принятии решений участвует несколько человек.

Простой инструмент, который экономит время и помогает эффективно управлять ресурсами команды. Попробуйте! 🚀

🛠️ Удобный способ работы с коллекциями через Builder

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

Как бы выглядел поиск этого юнита в классической реализации

private Enemy GetEnemyClassic()
{
    var size = Physics2D.OverlapCircleNonAlloc(center.position, radius, results, layerMask);
    
    for (var i = 0; i < size; i++)
    {
        var enemy = results[i].GetComponent<Enemy>();
        
        if (enemy.IsDead)
            continue;
        
        if (enemy.EnemyType != EnemyType.Melee)
            continue;

        return enemy;
    }

    return default;
}

⚠️ Минусы:

* Использование коллайдеров для Physics2D.OverlapCircleNonAlloc.
* Необходимость добавлять специальный слой на врагов (и не забывать добавлять его новым врагам).
* Дорогой вызов GetComponent<Enemy>.
* Сложность восприятия метода при чтении кода.


⚙️ Альтернативный вариант: коллекция + Builder

Я часто использую подход через коллекцию и паттерн Builder.

private Enemy GetEnemyViaBuilder() =>
    enemyCollection
        .InRadius(center.position, radius)
        .IsAlive()
        .Melee()
        .FirstOrDefault();

✅ Преимущества:

* Упрощение кода и повышение читаемости.
* Отсутствие необходимости работать с коллайдерами и слоями.
* Избавление от вызова GetComponent.

⚠️ Минусы:

* Увеличение времени разработки: требуется написать систему фильтрации и поддерживать коллекцию в актуальном состоянии.

✍️ Пример реализации коллекции

public class EnemyCollection
{
    private readonly FilterData filter = new();
    private IEnumerable<Enemy> enemies;

    public EnemyCollection(IEnumerable<Enemy> enemies)
    {
        this.enemies = enemies;
    }

    public EnemyCollection IsDead()
    {
        filter.IsDead = true;
        return this;
    }
    
    public EnemyCollection IsAlive()
    {
        filter.IsDead = false;
        return this;
    }
    
    public EnemyCollection Melee()
    {
        filter.EnemyType = EnemyType.Melee;
        return this;
    }
    
    public EnemyCollection InRadius(Vector3 center, float radius)
    {
        filter.InFilterByRadius = true;
        filter.Center = center;
        filter.Radius = radius;
        return this;
    }

    public Enemy FirstOrDefault()
    {
        return Build().FirstOrDefault();
    }

    public IEnumerable<Enemy> Build()
    {
        if (filter.IsDead.HasValue)
        {
            enemies = enemies.Where(e => e.IsDead == filter.IsDead);
        }
        
        if (filter.EnemyType.HasValue)
        {
            enemies = enemies.Where(e => e.EnemyType == filter.EnemyType);
        }
        
        if (filter.InFilterByRadius)
        {
            enemies = enemies.Where(e => Vector3.Distance(filter.Center, e.transform.position);
        }

        filter.Clear();
        return enemies;
        
    }

    private class FilterData
    {
        public bool? IsDead;
        public EnemyType? EnemyType;
        public bool InFilterByRadius;
        public float Radius;
        public Vector3 Center;
        
        public void Clear()
        {
            IsDead = null;
            EnemyType = null;
            InFilterByRadius = false;
            Radius = 0;
            Center = new Vector3();
        }
    }
}

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

Напишите в комментариях ваше мнение о таком решении! 🚀

Мои неудачи

Всегда приятно говорить о достижениях и успехах, но мой 2024 год – это история неудач

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

В результате поставил себе цель – выпустить 10 игр за год
Спойлер: удалось выпустить 5 игр, а еще одна выйдет в 2025 году

Краткая история игр
1️⃣ Drill Master
Я разрабатывал эту игру параллельно с основной работой. Сидел в выходные и в свободное время в будни, но все же довел проект до маркетинговых тестов. Провел маркетинговые тесты – провал. Проект заморожен.

2️⃣ Bouncing Ball
Сделал эту игру за 7 дней, пока был в отпуске. Быстро провел маркетинговые тесты – результат снова отрицательный. Не раздумывая, выкинул проект и пошел дальше.

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

3️⃣ Galaxy Expansion
Это самая крутая игра из всех, что я сделал за год. Но на ее разработку ушло 4 месяца, что оказалось слишком долго и дорого. За это время можно было сделать 4 прототипа и протестировать их.

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

4️⃣ Chase Car Arcade
Первая игра, которую мы сделали быстро и передали на полноценный тест издательству. Результат предсказуем – игра не прошла по метрикам.

💬 К этому моменту я работал почти без выходных уже 8 месяцев. Переутомление, наложившиеся личные проблемы, а также низкая скорость работы программиста заставили меня взять паузу, расстаться с программистом и переосмыслить подход. В результате мой новый проект Draw Cooked так и остался лежать в репозитории.

💬 Я решил замедлить темп, изучить рынок и опыт других студий. Решил нанимать фрилансеров под конкретные задачи – это оказалось лучшим решением и снизило стоимость прототипа в 2-3 раза

5️⃣ Karlson. Parkour Runner
Первая игра, сделанная с командой фрилансеров. У нее были хорошие метрики, но требовалось много доработок для их улучшения. Я принял решение не вкладываться в доработки и двигаться дальше.

Чему я научился за этот год:
1️⃣ Если ты новичок без опыта продаж своих игр, начинать нужно с коротких проектов, чтобы совершать дешевые ошибки.
2️⃣ Делегируйте разработку. Если проект делаете сами, обязательно делайте паузы и смотрите на него с позиции продюсера.
3️⃣ Изучайте информацию и опыт других. Чем больше учитесь на чужих ошибках, тем выше шансы их избежать.

Поставьте ♥️, если интересно услышать про каждый проект подробнее!

Всех с наступающим годом! Желаю каждому из вас выпустить игру мечты и заработать кучу денег!

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

Поделюсь с вами полезной информацией о прохождении собеседований и расскажу про архитектурные лайфхаки

С новым годом! 🎄🎉🎁

Проект 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
* Дрожание камеры
* Звуковой эффект
* Другие эффекты, напрмер замедление времени