Всем привет! Не теряйте. Пост про CV почти дописал, в ближайшее время опубликую
👍17🫡6❤4😴1
Как оформить 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 выглядит как понятная профессиональная история: человек работал в одной компании, получил опыт, вырос, перешел дальше, взял более сложные задачи.
Хочу начать с важной ремарки: я не профессиональный 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 выглядит как понятная профессиональная история: человек работал в одной компании, получил опыт, вырос, перешел дальше, взял более сложные задачи.
💯10👌1
Как оформить 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 секунд на ознакомпление и спросить на что он обратил внимание
Надеюсь пост был полезен, а если у вас есть вопросы или свои лайфхаки, то делитесь ими в комментариях
Если коммерческого опыта мало, можно указать 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 секунд на ознакомпление и спросить на что он обратил внимание
Надеюсь пост был полезен, а если у вас есть вопросы или свои лайфхаки, то делитесь ими в комментариях
🔥12
Почему никто не использует Test-Driven Development в геймдеве?
Разбирал тут наши старые документы и наткнулся на тест-кейсы, которые мы писали, когда я пытался внедрять TDD в разработку.
Забавно, что в какой-то момент я параллельно пробовал использовать Test-Driven Development сразу в двух сильно разных проектах: в Bioneers и в одном проекте в Datasakura — условно MMO RPG.
Изначально TDD казался мне почти идеальным подходом: сначала описываешь требования через тесты, потом пишешь код, который эти тесты проходит, а дальше спокойно рефакторишь архитектуру, не боясь всё сломать.
Но в геймдеве всё оказалось сложнее.
Игровая логика часто меняется на ходу, фичи зависят не только от кода, но и от ощущений, баланса, визуала, анимаций, таймингов и геймдизайнерских экспериментов. Поэтому классический TDD далеко не всегда ложится на разработку так красиво, как в книжках.
При этом я не считаю TDD бесполезным для игр. Наоборот, есть зоны, где он может работать очень хорошо: экономика, прогрессия, инвентарь, боёвка, расчёты урона, крафт, сохранения, симуляции и любая другая детерминированная логика.
В итоге продробнее расписал свои мысли в статье на Habr
Разбирал тут наши старые документы и наткнулся на тест-кейсы, которые мы писали, когда я пытался внедрять TDD в разработку.
Забавно, что в какой-то момент я параллельно пробовал использовать Test-Driven Development сразу в двух сильно разных проектах: в Bioneers и в одном проекте в Datasakura — условно MMO RPG.
Изначально TDD казался мне почти идеальным подходом: сначала описываешь требования через тесты, потом пишешь код, который эти тесты проходит, а дальше спокойно рефакторишь архитектуру, не боясь всё сломать.
Но в геймдеве всё оказалось сложнее.
Игровая логика часто меняется на ходу, фичи зависят не только от кода, но и от ощущений, баланса, визуала, анимаций, таймингов и геймдизайнерских экспериментов. Поэтому классический TDD далеко не всегда ложится на разработку так красиво, как в книжках.
При этом я не считаю TDD бесполезным для игр. Наоборот, есть зоны, где он может работать очень хорошо: экономика, прогрессия, инвентарь, боёвка, расчёты урона, крафт, сохранения, симуляции и любая другая детерминированная логика.
В итоге продробнее расписал свои мысли в статье на Habr
❤8👍6
Bioneers вышел в закрытое тестирование!
Ровно год назад началась разработка игры, а сегодня первые игроки наконец получили доступ к закрытой Demo.
Впереди сбор фидбека, исправление багов и много работы до публичного релиза.
Но важный milestone пройден и в Bioneers уже играют реальные игроки
А если тоже хотите получить ключик и поиграть, то напишите мне в личку @romanchikov и я дам вам один
Ровно год назад началась разработка игры, а сегодня первые игроки наконец получили доступ к закрытой Demo.
Впереди сбор фидбека, исправление багов и много работы до публичного релиза.
Но важный milestone пройден и в Bioneers уже играют реальные игроки
А если тоже хотите получить ключик и поиграть, то напишите мне в личку @romanchikov и я дам вам один
🔥19❤5👌1
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 и высокий задел для будущего проекта.
Так что ждем продолжения! 🫡
Подвели итоги первых 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 и высокий задел для будущего проекта.
Так что ждем продолжения! 🫡
🔥19❤6👌1
Media is too big
VIEW IN TELEGRAM
🛠 Как Astra меняет мой подход к разработке
В последнее время много экспериментировал с Astra. И, на мой взгляд, она довольно сильно меняет подход к работе.
Некоторые задачи, на которые раньше уходили недели документации, прототипирования и обсуждений, теперь получается разобрать за несколько подходов.
Покажу на двух примерах из Bioneers.
1. Прототип логистики за сутки
По отзывам игроков у нас была проблема с логистикой: она непонятна и плохо контролируется.
При этом готового референса под нашу задачу я не нашёл. В той же Factorio многое построено на конвейерах. У нас ресурсы должны передаваться между клетками напрямую, иначе визуально получится завод, а мы всё-таки строим организм.
Примерно неделю я расписывал систему в Miro. И каждый раз находил новые нюансы: ага, здесь не продумал, тут ресурса не хватит, а здесь несколько клеток одновременно хотят его получить.
В какой-то момент понял, что нужно делать прототип и щупать руками. Уже морально приготовился потратить на это несколько недель вместе с разработчиком.
Но решил попробовать Astra. И за сутки сделал рабочий прототип.
Да, съел все лимиты, купил подписку за $200 и даже там упёрся в ограничения 😅
Но проверил основные кейсы, потыкал разные варианты и определился с тем, как система должна работать. По моей оценке, сэкономил около двух недель.
После этого написал GDD и приложил прототип как референс. Теперь разработчик и QA могут сами собрать нужную ситуацию и посмотреть ожидаемый результат.
2. Древо эволюции до готовности механик
Мне нужно было спроектировать близкое к финальному древо эволюции: технологии, ресурсы, зависимости, баланс.
Раньше я бы ждал реализации, потом шёл в Unity и всё настраивал.
Сейчас сделал веб-прототип со всем деревом. Могу менять стоимость технологий, выстраивать порядок открытия и смотреть, где у игрока может быть затык, а где стоит дать больше возможностей.
Причём делать это можно ещё до того, как сами механики готовы в игре.
Финальный баланс, конечно, проверяется в геймплее. Но структуру прогрессии уже можно проработать и передать разработчику.
И для меня это ТЗ нового уровня.
Я сейчас рассказываю со стороны game design, но как разработчику мне такой формат тоже очень нравится.
Приходит геймдизайнер, даёт короткое описание и прототип: «Смотри, механика должна работать вот так».
Можно пощупать, поменять параметры, проверить разные ситуации. Уже гораздо проще понять взаимодействие сущностей, декомпозировать задачу и потом проверить результат в реальной игре.
Текст всё ещё нужен. Но сколько обсуждений и уточнений можно сэкономить, когда рядом есть работающий пример.
Пока это одно из самых полезных применений Astra, которое я нашёл для себя.
В последнее время много экспериментировал с Astra. И, на мой взгляд, она довольно сильно меняет подход к работе.
Некоторые задачи, на которые раньше уходили недели документации, прототипирования и обсуждений, теперь получается разобрать за несколько подходов.
Покажу на двух примерах из Bioneers.
1. Прототип логистики за сутки
По отзывам игроков у нас была проблема с логистикой: она непонятна и плохо контролируется.
При этом готового референса под нашу задачу я не нашёл. В той же Factorio многое построено на конвейерах. У нас ресурсы должны передаваться между клетками напрямую, иначе визуально получится завод, а мы всё-таки строим организм.
Примерно неделю я расписывал систему в Miro. И каждый раз находил новые нюансы: ага, здесь не продумал, тут ресурса не хватит, а здесь несколько клеток одновременно хотят его получить.
В какой-то момент понял, что нужно делать прототип и щупать руками. Уже морально приготовился потратить на это несколько недель вместе с разработчиком.
Но решил попробовать Astra. И за сутки сделал рабочий прототип.
Да, съел все лимиты, купил подписку за $200 и даже там упёрся в ограничения 😅
Но проверил основные кейсы, потыкал разные варианты и определился с тем, как система должна работать. По моей оценке, сэкономил около двух недель.
После этого написал GDD и приложил прототип как референс. Теперь разработчик и QA могут сами собрать нужную ситуацию и посмотреть ожидаемый результат.
2. Древо эволюции до готовности механик
Мне нужно было спроектировать близкое к финальному древо эволюции: технологии, ресурсы, зависимости, баланс.
Раньше я бы ждал реализации, потом шёл в Unity и всё настраивал.
Сейчас сделал веб-прототип со всем деревом. Могу менять стоимость технологий, выстраивать порядок открытия и смотреть, где у игрока может быть затык, а где стоит дать больше возможностей.
Причём делать это можно ещё до того, как сами механики готовы в игре.
Финальный баланс, конечно, проверяется в геймплее. Но структуру прогрессии уже можно проработать и передать разработчику.
И для меня это ТЗ нового уровня.
Я сейчас рассказываю со стороны game design, но как разработчику мне такой формат тоже очень нравится.
Приходит геймдизайнер, даёт короткое описание и прототип: «Смотри, механика должна работать вот так».
Можно пощупать, поменять параметры, проверить разные ситуации. Уже гораздо проще понять взаимодействие сущностей, декомпозировать задачу и потом проверить результат в реальной игре.
Текст всё ещё нужен. Но сколько обсуждений и уточнений можно сэкономить, когда рядом есть работающий пример.
Пока это одно из самых полезных применений Astra, которое я нашёл для себя.
🔥12👌1