Всем привет!

Я Борис и я Unity tech дед (ну, или tech lead 😉)

Ну что ж, ребятки, усаживайтесь поудобнее — расскажу вам сказочку про умного и хитрого разработчика по имени Борис. Давным-давно, в далеком 2012 году, когда компьютеры были большими, а игры — еще больше, жил-был в Москве молодой парень Борис. И вот однажды открыл он для себя волшебный мир Unity, и с тех пор его жизнь изменилась навсегда.

Учился Борис много, внучата, не жалел ни времени, ни сил. Сначала овладел он мудростью программирования в МГТУ им. Н. Э. Баумана, а потом отправился за еще большей наукой — изучать e-commerce в Высшей школе экономики. И стал он не просто программистом, а настоящим волшебником Unity!

Прошло много-много лет, и накопил Борис целую гору опыта. Он создал сотни самых разных игр! Игры у него были на любой вкус: и для телефонов, и для компьютеров, и даже такие, где, надев волшебные очки, человек мог очутиться в виртуальном мире. Миллионы людей по всему миру скачивали его игры и радовались.

Но и это не конец его истории. Однажды Борис открыл двери в волшебную компанию DataSakura. Поработал он там некоторое время, отрастил бороду и стал дедом. И стали к нему приходить внучата за советами разными: «Дедушка Борис, а сколько времени нужно, чтобы сделать этот проект? А как лучше построить архитектуру?» И так дедушка Борис стал вести команду молодых мастеров, обучая их мудрости кода и заботясь, чтобы проекты работали гладко, быстро и без сбоев. Даже когда появлялись сложные задачи, Борис всегда находил решение и вел свою команду вперед!

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

Вот так и стал дед Борис настоящим волшебником программирования!


А теперь серьезно:

Я, конечно, не дед — мне 30 лет, но в Unity и геймдеве я уже давно. В 2012 году я впервые познакомился с Unity, а в 2014 устроился на свою первую работу в этой сфере

За 12 лет я создал сотни проектов и участвовал в ещё большем их числе. Только за последний год я так или иначе был задействован более чем в 20 проектах. Вот некоторые из них:
1. EvoPop (Android, IOS)
2. PPNards (Android, IOS)

Также я занимаюсь разработкой собственных игр, которые можно найти в Google Play

О чём я тут пишу:
1. О взгляде на разработку игр и геймдев с точки зрения бизнеса и менеджмента.
2. О технических советах по разработке в Unity.
3. О своих проектах и историях — в том числе, как я стал «дедом».

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

За три года в роли лида я просмотрел более 500 кандидатов на позиции мидла и сеньора, провел свыше 100 собеседований и нанял более 20 Unity-разработчиков. За это время у меня накопился значительный опыт в оценке кандидатов — я заметил множество «зеленых» и «красных» флагов, которые помогают определить подходящих людей

В этом посте я кратко расскажу о нетехнической стороне прохождения собеседований:

Цель собеседования

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

Около 20% кандидатов приукрашивают резюме, и хотя это часто выявляется в ходе собеседования, иногда ошибки обнаруживаются только после найма, когда кандидат не проходит испытательный срок. Пример из практики: один кандидат успешно прошел все этапы, и ушел с текущего места работы к нам, но через пару недель на работе стало понятно, что у него нет заявленного опыта. Это обернулось потерей времени и денег для компании и проблемами для кандидата, он остался без работы. Итог: никто не остался в выигрыше.


Этапы собеседования

1. Отправка резюме
2. Интервью с HR
3. Code Review / тестовое задание
4. Технические собеседования
5. Интервью с тимлидом

Этапы могут различаться в зависимости от компании: в крупных корпорациях вроде Google или Yandex техническое собеседование часто состоит из нескольких долгих интервью, а в стартапах можно сразу пройти интервью с лидом или CEO.


Первые шаги: отправка резюме

На этом этапе важно отправить четкое и профессионально оформленное CV. HR могут простить некоторые недочеты, если нет ярких красных флагов.
Многие компании ищут кандидатов через LinkedIn, так что старайтесь поддерживать свой профиль на высоком уровне.

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


Интервью с HR
Этот этап — знакомство компании с вами и наоборот. Основные причины, по которым HR может отклонить вас:

Объективное несоответствие вакансии (например, опыт на Python, когда требуется Unity).
Недостаточный уровень английского. У нас, например, для сеньоров требуется уровень B2.
Неуместные soft skills — например, односложные ответы или использование грубых выражений.


А в следующей части я расскажу вам про code review

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

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

Как понять уровень hard skills кандидата?
Первый этап технического интервью — это проверка кода

💻 Code Review: взгляд изнутри
Когда я провожу ревью:

* На один проект уходит около 30 минут
* За день просматриваю до 10 кандидатов
* Оцениваю по трем критериям: код-стиль, архитектура, complexity (сложность кода)
* 95% проектов я не открываю в Unity
* Если отказ, то всегда даю обратную связь


🛠️ Совет 1: Присылайте ссылку на GitLab или GitHub

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

* Потеря времени. Ревьюеру нужно потратить 5 минут из отведённых 30, чтобы скачать и разархивировать проект
* Проблемы с доступом. Часто архивы защищены, и ревьюеру приходится запрашивать доступ
* Вопросы к навыкам. А умеете ли вы вообще пользоваться Git?


📦 Совет 2: Присылайте готовый проект, а не набор скриптов

Недостатки:
* Нельзя оценить структуру проекта
* Часто нарушены принципы SOLID, а скрипты перегружены ответственностями
* Отсутствует часть кода, что не дает возможость полностью понять присланный скрипт


📄 Совет 3: Оформляйте README

README — это ваша визитная карточка. Только 5% кандидатов его делают

Что включить:
* Краткое описание проекта
* Архитектуру и структуру
* Особенности, которые вы хотите подчеркнуть
* Гифку с примером геймплея
* Ссылку на сборку (опционально)


🎯 Совет 4: Присылайте ссылку на проект, а не на профиль

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

Почему ссылка на Git профиль это плохо
* Чаще всего я выбираю самый последний проект, но он может быть слабым
* Если первые 2 проекта сложные или не подходят под критерии я запрашиваю тестовое
* Косвено, по названиям, других проектах я ищу ваши слабости, что бы за них зацепиться


⚙️ Совет 5: Используйте общепринятые фреймворки

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

* Zenject (Extenject)
* VContainer
* UniRx (R3)
* UniTask

Исключение, если вас попросили не использовать сторонние фреймворки. Лучше для таких случаев иметь отдельный проект в репозитории

Следующие советы — в следующем посте! 🚀

Какой из советов вы уже применяете? Делитесь опытом в комментариях! 👇

💡Как пройти 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️⃣ Изучайте информацию и опыт других. Чем больше учитесь на чужих ошибках, тем выше шансы их избежать.

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

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

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

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

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