Unity Tech Дед: Борис Романчиков

🛠 Как Astra меняет мой подход к разработке

В последнее время много экспериментировал с Astra. И, на мой взгляд, она довольно сильно меняет подход к работе.

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

Покажу на двух примерах из Bioneers.

1. Прототип логистики за сутки

По отзывам игроков у нас была проблема с логистикой: она непонятна и плохо контролируется.

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

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

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

Но решил попробовать Astra. И за сутки сделал рабочий прототип.

Да, съел все лимиты, купил подписку за $200 и даже там упёрся в ограничения 😅

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

После этого написал GDD и приложил прототип как референс. Теперь разработчик и QA могут сами собрать нужную ситуацию и посмотреть ожидаемый результат.

2. Древо эволюции до готовности механик

Мне нужно было спроектировать близкое к финальному древо эволюции: технологии, ресурсы, зависимости, баланс.

Раньше я бы ждал реализации, потом шёл в Unity и всё настраивал.

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

Причём делать это можно ещё до того, как сами механики готовы в игре.

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

И для меня это ТЗ нового уровня.

Я сейчас рассказываю со стороны game design, но как разработчику мне такой формат тоже очень нравится.

Приходит геймдизайнер, даёт короткое описание и прототип: «Смотри, механика должна работать вот так».

Можно пощупать, поменять параметры, проверить разные ситуации. Уже гораздо проще понять взаимодействие сущностей, декомпозировать задачу и потом проверить результат в реальной игре.

Текст всё ещё нужен. Но сколько обсуждений и уточнений можно сэкономить, когда рядом есть работающий пример.

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

Bioneers Closed Demo — финальные результаты первых 48 часов

Подвели итоги первых 48 часов Closed Demo. И результаты получились действительно сильными.

За это время у нас:
— 250 уникальных игроков
— 174 заполненных feedback form
— 3 ч 4 мин среднего времени игры
— 4.48/5 общая оценка игры
— 4.49/5 оценка core gameplay
— 4.89/5 желание вернуться
— +1000 новых Wishlist

Но самое интересное — что стоит за этими цифрами.

1. Среднее время игры — около 200% от количества контента

Для демо очень хорошим результатом можно считать среднее время игры около 80% от доступного контента. Для нас это было бы примерно 1 ч 15 мин. Фактический результат — 3 ч 4 мин.

То есть игроки проводят в Bioneers примерно 250% времени относительно объёма уникального контента.
И для меня это один из самых важных результатов тестирования.

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

В среднем получилось 2.4 запуска на игрока.

Фактически люди уже готовы играть в наш core loop даже после того, как новый контент закончился.

2. Средняя оценка — 4.5/5

Для Demo оценка 4+ — уже хороший показатель.

У нас:
— 4.48/5 общее впечатление
— 4.49/5 core gameplay
— 4.89/5 желание вернуться

Причём 156 из 174 игроков поставили желанию вернуться 5/5.

Это не значит, что игра идеальна. Feedback довольно чётко показывает проблемы в game design, balance, UX и micromanagement.

Но самое важное — игроки позитивно оценивают сам фундамент игры.

Нам не нужно переделывать core gameplay. Нам нужно его улучшать, балансировать и развивать.

3. За время Demo мы получили +1000 Wishlist

И это особенно интересно, потому что Closed Demo было ограничено примерно 250 игроками.

То есть рост Wishlist значительно превышает количество участников тестирования.

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

При этом 99% участников feedback form уже добавили игру в Wishlist или собираются это сделать.

⸻

Вся аналитика первых 48 часов показывает очень хорошую динамику.

Это очень сильный результат для первого Closed Demo и высокий задел для будущего проекта.

Так что ждем продолжения! 🫡

Bioneers вышел в закрытое тестирование!

Ровно год назад началась разработка игры, а сегодня первые игроки наконец получили доступ к закрытой Demo.

Впереди сбор фидбека, исправление багов и много работы до публичного релиза.

Но важный milestone пройден и в Bioneers уже играют реальные игроки

А если тоже хотите получить ключик и поиграть, то напишите мне в личку @romanchikov и я дам вам один

Почему никто не использует Test-Driven Development в геймдеве?

Разбирал тут наши старые документы и наткнулся на тест-кейсы, которые мы писали, когда я пытался внедрять TDD в разработку.

Забавно, что в какой-то момент я параллельно пробовал использовать Test-Driven Development сразу в двух сильно разных проектах: в Bioneers и в одном проекте в Datasakura — условно MMO RPG.

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

Но в геймдеве всё оказалось сложнее.

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

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

В итоге продробнее расписал свои мысли в статье на Habr

Как оформить CV разработчику. Часть 2

Если коммерческого опыта мало, можно указать pet-проекты, учебные проекты, open-source, свои игры, прототипы, GitHub, Steam-страницы, видео геймплея. Это не полностью заменяет коммерческий опыт, но точно лучше, чем пустое место.

4. Достижения, а не только обязанности

Одна из частых проблем CV — человек описывает только обязанности.

Плохо:

Работал над мультиплеером.
Фиксил баги.
Делал UI.
Участвовал в разработке проекта.

Лучше:

Отвечал за мультиплеерный модуль в Unity-проекте: переработал сетевую архитектуру, вынес логику в отдельные сервисы, добавил тесты на ключевые сценарии и снизил количество критичных багов перед релизом.

Или:

Ускорил разработку фич за счет внедрения базовой архитектуры, код-ревью и переиспользуемых компонентов UI.

Важно писать так, чтобы было понятно и HR, и техническому специалисту. Не нужно превращать CV в техническую документацию, но и слишком общие формулировки не помогают.

5. Ссылки на проекты

Если у вас есть GitHub, LinkedIn, портфолио, Steam-страница, App Store, Google Play, видео геймплея, статьи или посты — добавляйте.

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

6. Желтые флаги

Желтые флаги — это не автоматический отказ. Это повод задать уточняющий вопрос.

К таким вещам я бы отнес:

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

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

Например, если был перерыв — можно написать, чем вы занимались: учеба, свой проект, релокация, семейные обстоятельства, запуск стартапа.

Если был фриланс — объясните почему совмещали его с основной работой и какие есть гарантии, что фриланс не помешает основной работе в компании

Если было несколько коротких мест работы — важно объяснить, что произошло, чтобы это не выглядело как риск конфликтности или нестабильности.

7. Что точно должно быть в CV разработчика

Минимальный набор, который я ожидаю увидеть:

ваша специализация;
ключевой стек;
коммерческий опыт;
последние 2–3 места работы с подробным описанием;
конкретные достижения;
ссылки на проекты или портфолио;
уровень английского;
локация и желаемый формат работы;
актуальные контакты.

10. Что лучше убрать

Я бы убирал из CV все, что не помогает принять решение пригласить вас на интервью.

Например:

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

Если хотите написать про soft skills, лучше показывать их через опыт.

Не “коммуникабельный”, а “синхронизировал работу команды из 5 разработчиков, проводил code review и помогал джунам с декомпозицией задач”.

И главный совет: смотрите на CV не как на формальность, а как на инструмент продажи вашего опыта.

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

Если вы хотите проверить свое CV, то самый лучший вариант показать его другу/знакомому, дать ему 30 секунд на ознакомпление и спросить на что он обратил внимание


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

Как оформить CV разработчику. Часть 1

Хочу начать с важной ремарки: я не профессиональный HR, поэтому воспринимайте эти советы как личное мнение человека, который регулярно смотрит CV разработчиков.

Я могу быть не прав или обращать внимание не на те вещи, на которые обращает внимание профессиональный HR. Но я тоже участвую в оценке кандидатов и часто смотрю CV уже с позиции CTO / техлида / нанимающего менеджера.

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

CV должно за короткое время ответить на несколько вопросов:

Кто вы как специалист?
Какой у вас релевантный опыт?
С каким стеком вы реально работали?
Какие задачи вы решали?
Почему вам можно доверить работу?

Когда ваше CV смотрят:

1. Во время отклика на вакансию
2. Перед или во время HR-интервью
3. Перед или во время технического интервью
4. Перед или во время финального интервью

Соответственно, ваше CV должно быть понятно не только HR, но и техлиду, менеджеру проекта, CTO или CEO.

У каждого из них разный фокус. HR хочет быстро понять, подходите ли вы под базовые требования. Техлид смотрит на стек, опыт и уровень самостоятельности. Менеджер или CEO оценивает, насколько вам можно доверить проект, команду или важный участок работы.

Что происходит после того, как ваше CV попало к HR?

Обычно есть два варианта.

Первый вариант — CV автоматически импортируется в HR-платформу. Например, в DS мы используем HuntFlow. Такие системы вытаскивают информацию из CV и раскладывают ее по блокам: опыт работы, ключевые навыки, образование, контакты и так далее.

Это удобно для ревьюера, потому что все кандидаты отображаются в едином формате. Также такие платформы хорошо импортируют данные из LinkedIn, hh.ru и похожих сервисов.

Например, у меня иногда нет доступа к оригинальному PDF-файлу. Я вижу только информацию, которая была импортирована в HR-платформу. Поэтому важно, чтобы CV было не только красивым, но и нормально парсилось.

Второй вариант — человек смотрит ваш PDF-файл напрямую. И вот тут уже огромное значение имеет форматирование. CV должно быть легко читать и быстро сканировать глазами.

На мой взгляд, LinkedIn и hh.ru из коробки дают достаточно удобный и читаемый формат. Я бы советовал завести LinkedIn, регулярно его обновлять и использовать как основу для CV.

Первое чтение CV часто занимает не несколько минут, а 20–30 секунд. Поэтому самое важное должно быть видно сразу: ваша роль, стек, годы опыта, последние проекты, достижения и контакты.

На что я обращаю внимание в CV разработчика

1. Общая читаемость

CV должно быть простым, структурированным и понятным.

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

Хорошее CV легко просканировать глазами. В нем понятные заголовки, нормальные отступы, аккуратные списки и нет огромных полотен текста.

2. Фотография

Фотография не обязательна, но если вы ее добавляете, она должна работать на ваш профессиональный образ.

Лучше нейтральное или полуофициальное фото, чем случайная фотография с вечеринки, отпуска или бара.

CV может смотреть CEO, CTO или будущий руководитель. Это люди, которые оценивают не только навыки, но и общее впечатление: можно ли доверить человеку работу, команду, проект или коммуникацию с заказчиком.

Если есть возможность, я бы рекомендовал один раз сделать несколько нормальных профессиональных фотографий и использовать их в CV, LinkedIn, Telegram, рабочих аккаунтах и так далее.

3. Опыт работы

Самый важный блок в CV — это опыт.

Я бы рекомендовал подробно описывать последние 2–3 места работы, а более старый опыт оставлять коротко.

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

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

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

Всем привет! Не теряйте. Пост про CV почти дописал, в ближайшее время опубликую

Сопроводительное письмо как способ выделиться

Мой прошлый пост собрал рекордное количество реакций. Это радует и реально мотивирует делать новые посты.

Начал писать пост про CV, но понял, что сначала сделаю пост про сопроводительное письмо.
Отнеситесь к нему как к единственному тексту, который вообще кто-то будет читать.

Самое ужасное сопроводительное письмо за мой опыт найма выглядит так:

Здарова. Вакансия актуальна?

Скажу честно, я даже не отвечаю таким кандидатам.

А вот пример одного из лучших сопроводительных писем на мою вакансию в Bioneers:

Привет! Увидел вакансию Unity-разработчика и заинтересовался проектом
Мой техстек кажется релевантным вашим требованиям, а сам проект я раньше видел на Reddit.

У меня 5+ лет опыта работы Unity-разработчиком. В своё время любил играть в детище Уилла Райта — Spore. Про Factorio слышал, но не играл (но это легко исправить, так как я с детства плотно подсел на игры :D).

Было бы клево поработать вместе =)

Техстек:
Unity, C#, ООП, SOLID
ECS (Morpeh), Zenject
REST API (BestHTTP)
Git, Rider, Addressables, Profiler, Unit Tests
Firebase, AppsFlyer, Crashlytics

Подробнее в CV: «ссылка»

Давайте разберу его по частям:

1. Одно сообщение, сразу CV в формате PDF в аттаче.
Нет потока сообщений, а всю информацию можно легко добавить на страницу кандидата.

2. Текст разбит на абзацы.
Такое письмо легко читать, и сразу видны ключевые моменты.

3. Немного конкретики про проект, плюс информация о том, что человек видел проект ранее.
Как минимум мне приятно, что это не просто отклик, а что человеку интересен мой проект. Пусть в реальности это не так и вам просто нужна работа, но это ведь цепляет.

4. Сразу коротко указан техстек.
Можно понять, с чем кандидат уже работал, а что ему придётся подучить.

Ставьте ❤️и я выпущу следующий пост про CV
Пишите в комментариях варианты как можно еще улучшить сопроводительное письмо

Почему 80% разработчиков не доходят даже до интервью?

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

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

Процесс интервью:
1. CV
2. Опросник
3. Тестовое задание
4. Интервью
5. Тех интервью

На мою вакансию откликнулось 70 человек, что превзошло мои ожидания в 3 раза. Поэтому, мне пришлось максимально автоматизировать процесс и подключить своего бота OpenClaw для помощи.

Этап CV. 70 человек
На просмотр CV кандидата я тратил менее 1 минуты. Сами понимаете, 70 человек — это уже 70 минут, поэтому правду говорят HR, что без грамотного CV на вас могут просто не обратить внимание. Далее я отдавал CV нейронке для автоматического ревью и создания страницы кандидата. Нейронка ставила скор от 1 до 5 на основе CV. Те кандидаты, что получали менее 2 баллов или у кого не было 2-х лет опыта, сразу получали отказ, остальные проходили на следующий этап.

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

Этап опросника. 40 человек
Поскольку откликов было много, я принял решение сделать опросник. В опроснике просил оценить уровень от 1 до 5 по техническим навыкам, а также задавал несколько релевантных для нас вопросов, например, ожидаемый уровень ЗП и наигранность в игры автоматизации.

На основе опросника нейронка генерировала скор от 1 до 5. У кандидатов, которые сами себе поставили менее 3 баллов, спрашивал, точно ли они хотят делать тестовое, так как по их оценке есть шанс не пройти тех интервью.

Удивительно, но у многих кандидатов уровень в опроснике совпал с уровнем, который я поставил при code review.

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

Тестовое задание я также прогонял через нейронку, которая формировала черновой отчёт и на основе моих критериев оценивала кандидатов. Далее я самостоятельно проводил ревью тестовых и корректировал отчёт уже на основе своего опыта. По результатам оценил кандидатов от 1 до 5, и те, кто получили 3.5 балла, не прошли на дальнейший этап.

Этап интервью. 16 человек

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

Этап тех интервью. 8 человек

Тут всё по классике. Задаю технические вопросы и оцениваю уровень кандидата от 0 до 100%.

Если было полезно, то ставьте ❤️
Если наберем хорошее количество лайков, то сделаю пост с рекомендациями по оформлению CV и как подготовиться к интервью

Ищем Unity-разработчика к нам в Bioneers

Всем привет! Наш проект растет, в связи с этим ищем активного и талантливого разработчика к нам в команду

Описание вакансии:

Unity-разработчик (Middle) — Bioneers

Мы делаем Bioneers — игру про живые клетки и биологические системы. Вдохновлялись Factorio и Spore: строишь клеточные организмы, настраиваешь цепочки ресурсов, наблюдаешь как всё работает (или ломается). Это не мобилка и не казуалка — это настоящий PC-проект с глубоким геймплеем.

Мы стартап. Маленькая команда из 6 человек: CTO, 2 программиста, дизайнер, геймдизайнер и маркетинг-менеджер. Платим честно, но не как корпорация. Зато у нас:

— Возможность реально влиять на продукт, а не закрывать тикеты
— Работа с современным стеком (Unity 6, ECS/DOTS, R3, UniTask)
— Менторство и профессиональный рост. Очень сильная команда разработки
— Удалёнка

Что будешь делать:

— Геймплей на DOTS (Unity DOTS): системы, компоненты, аспекты
— UI на MVVM + R3
— Писать чистый, поддерживаемый код в модульной архитектуре
— Участвовать в code review
— Придумывать решения, а не только реализовывать чужие
— Возможность влиять на геймдизайнерские решения


Что нужно:

— Unity + C# (2+ года коммерческого опыта)
— Понимание ECS концепций (или готовность быстро вникнуть)
— Опыт с UI: Canvas, привязка данных, реактивность
— Умение читать чужой код и работать в команде
— Желание учиться — это главное

Будет плюсом:

— Опыт с Unity DOTS
— Знание R3 / UniRx / реактивного программирования
— Опыт с ScriptableObject-based архитектурой
— Git (merge, rebase, code review через PR)

Очень желательно:

— Наигранность в Factorio, Satisfactory, Shapez, Dyson Sphere Program или другие игры в жанре автоматизации. Если ты понимаешь кайф от идеально работающей конвейерной линии — нам по пути.

Условия:

— Полная удалёнка
— Full-time
— Оплата по результатам собеседования (стартап, не корпорация — но растём вместе)

Писать: @romanchikov
Приложите CV к отклику — так мы быстрее ответим

CI/CD автоматизация для Unity-проекта за один вечер

Расскажу как мы с AI-ассистентом (Open Claw) за вечер настроили полный цикл автоматизации для нашего Unity-проекта Bioneers.

Задача: каждый Pull Request в dev должен автоматически проходить ревью, собираться в Unity Cloud Build, а связанные задачи в ClickUp переходить в QA.

Что получилось:

Разработчик создаёт PR в dev. Дальше всё происходит само:

1. Code Review
AI читает diff, загружает .editorconfig проекта и правила ревью, специфичные для нашей архитектуры (ECS, MVVM, Service Locator). Оставляет inline-комментарии прямо в GitHub. Не абстрактные "используйте SOLID", а конкретные: "этот GetComponent вызывается в Update, закешируй в Awake", "тут race condition с UniTask".

Это не замена живому ревью. Но 80% типовых замечаний ловит до того, как я открою PR.

2. Unity Cloud Build
При новом PR автоматически клонируется конфиг сборки windows-dev, подменяется ветка на ветку PR, запускается билд. При пуше новых коммитов запускается новый билд. При мерже конфигурация удаляется. Никакого мусора.

3. ClickUp
Если в коммите или описании PR есть ссылка на задачу ClickUp, задача автоматически переходит в статус QA, а в комментарий пишется ссылка на билд.

Разработчику достаточно написать в коммите https://app.clickup.com/t/taskid или CU-taskid.

Технически это Node.js прокси на 120 строк, который принимает GitHub webhooks и:

• отправляет промпт на ревью AI-агенту
• дёргает Unity Cloud Build API для создания/удаления конфигов
• парсит коммиты через GitHub API, находит ClickUp ссылки и обновляет задачи

Что это даёт команде:

• Разработчик получает первый фидбек по коду через 2-3 минуты после пуша
• QA видит задачу в нужном статусе с готовым билдом
• Я не трачу время на тривиальные замечания в ревью
• Нет ручного создания билдов в Unity Dashboard

Что не работает:

• AI не заменяет архитектурное ревью. Логику бизнес-процессов и "а нужна ли вообще эта фича" он не ловит

Весь пайплайн запустили за вечер

Code Review тестового задания с помощью Claude Code

Я раза три пытался автоматизировать Code Review для новых кандидатов к нам в компанию. На прошлой неделе наконец получилось сделать более-менее адекватный результат.

Скажу сразу — это не тот кейс, когда AI делает автоматический Code Review при merge request. Это кейс ревью тестового задания. И разница принципиальная: при MR модель учится на контексте существующего проекта, а в тестовом задании этого контекста нет. Модель смотрит код «с нуля», как и ревьюер.

Раньше я пробовал скормить ChatGPT ссылку на гит — получал практически неинформативный фидбек. Попытки подстроить промт не увенчались успехом. Сейчас я использую Claude Code с моделью Sonnet 4.6, которая как модель сильнее и позволяет очень гибко настроить контекст.

Как это работает:

1. Кандидат выполняет наше тестовое задание и скидывает ссылку на гит
2. Я запускаю shell script
3. Script стартует Claude Code в заранее настроенном окружении
4. На выходе — отчёт в формате .md
5. На основе отчёта я провожу ручной Code Review, валидирую и финализирую

Как я это сделал:

Через Claude Code создал отдельную папку с проектом и окружением. Добавил туда документацию с нашим тестовым заданием и скормил все свои прошлые отчёты по кандидатам. Модель обучилась на моих ревью и сгенерировала себе правила, которые я потом отредактировал и структурировал вручную.

Результат:

— Время ревью снизилось с 30 до 10–15 минут
— Качество отчёта выросло (модель ловит то, что я мог пропустить по невнимательности)
— Итоговый отчёт я всё равно ревьювлю вручную, но экономлю время на онбординге в проект кандидата и на написании финального текста

Пример автоматического отчёта своего тестового приложу в комментариях 👇

📚 Рецензия на книгу «Основы создания успешных инди-игр»

Начинаем год с полезного чтения.
И первой книгой в списке стала работа Влада Маргульца — «Основы создания успешных инди-игр».

Совокупная оценка: 8/10

Честно говоря, я часто отношусь к таким книгам с большим скепсисом. В целом решил прочитать её только потому, что она бесплатно доступна в ЛитРес по подписке.

Короткое overview

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

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

Из минусов: книга затрагивает много тем, но понемногу, поэтому не стоит ожидать глубокого погружения в отдельные аспекты.

Моё личное мнение

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

На этом минусы, пожалуй, заканчиваются.

Главы 2–6 — это чистый опыт, который я во многом прожил на себе. Я на 100% согласен с большинством мыслей и советов автора.
Главы 7–10 мне ещё только предстоят, но они уже дали лучшее понимание того, что меня ждёт дальше, и заставили задуматься над парой важных моментов.

Если честно, кажется, что если бы я сам сел писать книгу, то написал бы её примерно в таком же ключе 😀

👍 Поставьте лайк, если вам зашёл такой формат
и если вам было бы интересно видеть больше рецензий на книги про геймдев.

Топ 5 цитат уходящего 2025 года 🎄✨

Последний день года идеальное время, чтобы подвести итоги. И я хочу сделать это в формате цитат, которыми можно описать прошедший 2025-й.

Но перед тем как начать, огромное спасибо всем подписчикам канала за вашу поддержку, за реакции, за то, что читаете мои посты и идёте рядом. ❤️
И я хочу пожелать вам, пожалуй, самого главного: сделать игру мечты и заработать на ней $1 000 000


Цитата 1. «Бизнесмен — это тот, кто не любит день зарплаты»

За 2025 год команда Bioneers выросла до 10 человек. Я вообще не ожидал, что смогу собрать вокруг себя столько талантливых людей, которые помогут сделать лучшую игру 2026 года (по моему личному мнению 😄). И, чувствую я, мы будем еще расти и минус на моем банковском счете превратится в плюсы в количестве вишлистов


Цитата 2. «Хороший продукт сам себя продаёт»

У моей жены 5 лет опыта в SMM, и я очень долго уговаривал её подключиться к ведению соцсетей Bioneers.

И вот настал тот день: она выложила видео в Instagram и оно собрало 1 000 000 просмотров.
До этого её личный рекорд был 200к.
А ещё ранее этот же ролик у нас собрал 500к просмотров на YouTube.

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


Цитата 3. «Недостаточно сочно!»

В начале года на основной работе в DataSakura мы потеряли несколько клиентов из-за того, что игры получились недостаточно “сочными”.

Это стало триггером для важных изменений в процессе найма и отбора кандидатов.
А фраза «недостаточно сочно!» — превратилась в локальный мем компании 😅


Цитата 4. «Программист отличается от лампочки тем, что продолжает работу, когда перегорел»

2025 тяжёлый год для рынка мобильного геймдева. Мы в DataSakura как аутсорс-команда прочувствовали это очень сильно: пришлось модернизировать процессы, перестраивать подходы и адаптироваться под реалии рынка, чтобы оставаться на плаву.

Параллельно формирование команды и процессов в Bioneers.
И в итоге среднее рабочее время в этом году 12 часов в день.
Похоже, доход от Bioneers я буду складывать в мешочки под глазами 😂

Но самое главное: когда есть цель и желание — можно работать и по 12 часов.


Цитата 5. «Шляпа, причёска, тату»

Как-то слушал подкаст про полезные привычки и там автор рассказал фреймворк принятия решений: Hat, Haircut, Tattoo. Мне очень зашла эта идея.

🎩 Шляпа — решения, которые нужно принимать быстро (идеально — довести до привычки).
Шляпу легко снять и надеть другую. Проще сделать, чем думать. Ошибся — переделал.

💇‍♂️ Причёска — решения, над которыми стоит подумать, но не слишком долго.
Если не понравилось — через пару месяцев можно поменять. Исправить займет время, но это не критично.

🖋 Тату — решения на годы вперёд.
Это то, что дорого/сложно/почти невозможно переделывать. Тут нужно собрать максимум информации, продумать риски и принять решение один раз.


Всех с наступающим новым годом! И хорошо провести праздники! 🎅

Сегодня Bioneers преодолел 20к вишлистов, а точнее уже 21к

Выпустили ролик в Инстаграме, который стабильно собирает по 100k просмотров в день и уже достиг 600k. Есть шанс дойти до 1 млн.

И самое удивительное насколько просто и естественно идёт маркетинг.
Мы сделали новый YouTube аккаунт, выложили видео и получили 400k просмотров.
Сделали аккаунт в Инстаграме, выложили видео и получили 600k просмотров.

Это всё заставило меня ещё раз переосмыслить фразу многих опытных продюсеров:
“Нужно проверять идею и только потом делать игру.”

А вообще игра перешла в стадию стабильной и немного рутинной разработки. Мы собрали очень крутую команду, распланировали задачи, кажется, на полгода вперёд, и что-то как-то скучно стало! 😀
Сижу вот и думаю: а не вписаться ли мне в новый проект?
Видимо, так предприниматели типа Илона Маска и подсаживаются на эту «иглу» новых проектов, с которой потом не могут слезть

Сейчас еще пишу статью на хабр про автоматизацию через Stream Deck, хотел сделать пост, но понял, что формат хабр статьи будет удобнее читать, так что скоро выйдет

А также есть еще один интересный кейс, которым хочу поделиться с вами в одном из будущих постов
Нам для игры нужно сделать около 400 иконок и я хочу написать процесс, который позволить автоматизировать создание таких иконок через AI, с последующей доработкой дизайнера.
Идея скормить программе таблицу с 400 промтами и на выходе получить 400 папок по 10 изображений в каждой на Google drive

P.S а ведь первые 7 виш листов я получил именно с этого канала

🧩 Хаос в задачах и сила Definition of Done

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

Вот типичные примеры:
* Делать несколько задач параллельно вместо того, чтобы закрывать их последовательно
* Писать код “на будущее”, добавляя лишние абстракции и параметры
* Начинать задачу с неполным ТЗ
* Зависать на бесконечном ресёрче
* Лезть в рефакторинг до того, как вообще есть что рефачить

И самое интересное — у всех этих проблем одна причина и одно решение.

🎯 Простое правило

"Закрывай Definition of Done как можно быстрее"

Чтобы это сделать, нужен правильный процесс. Любая задача состоит из четырёх этапов:
1. Погружение в контекст
2. Составление Definition of Done (DoD) — чёткие условия, при которых задача считается выполненной
3. Реализация задачи так, чтобы выполнить DoD
4. Рефакторинг и приведение кода в порядок (после выполнения DoD, а не до!)

Цель всегда одна — как можно быстрее выполнить DoD, а всё остальное — вторично.

⸻

📌 Разберём несколько кейсов

🔹 Параллельная работа над задачами

Например, разработчик делает “Профиль игрока” и понимает, что нужна “Система сохранений”. Из-за соблазна делать всё сразу обе задачи уходят в работу. За второй задачей подтягивается третья и вот в In Progress половина задач из спринта, сроки расползаются, непонятно чем человек занят на самом деле

Как быть?

Если реализация сохранений не нужна для выполнения DoD по профилю,
то просто сделайте интерфейс и мок-методы.
А полноценную реализацию — в отдельную задачу.

Так мы сохраняем фокус и не расползаемся в стороны.

Опять же. Думайте как закрыть Dod как можно быстрее

⸻

🔹 Начало задачи без понятого ТЗ

Классика.
Но помним главное правило: Если DoD непонятен — задача не может быть закрыта.
А значит брать её в работу нельзя.

Задача без чёткого ТЗ = гарантированный хаос.

⸻

🔹 Рефакторинг “пока делаю фичу”

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

Я понимаю почему мы это делаем. Мы чувствуем кайф во время рефакторинга, это состояние потока и оптимизации реально доставляют нам удовольствие, но почти всегда — вредит процессу.

Рефакторинг всегда должен быть отдельной задачей с конкретным DoD.
Не частью другой задачи, а именно отдельной задачей

P.S Тут я говорю про серьезный рефакторинг, небольшой косметический рефакторинг, который не затронет логику можно сделать и в задаче. Но если он затрагивает логику, то лучше отдельно, что бы составить список пунктов QA для тестирования

⸻

✔️ Итог

Правило "Закрывай Definition of Done как можно быстрее"
• даёт прозрачность
• ускоряет разработку
• снижает количество переделок
• уменьшает хаос
• делает команду быстрее и спокойнее

И самое главное — помогает закрывать задачи быстро, чётко и без лишних движений