Что-то у меня творческий кризис. Неделя тяжёлая выдалась, простыл еще к тому же (летом, ха-ха, но это уже классика), долечиться никак не могу. Поэтому вот вам арт Верховья, некогда обьяснять. Третью сцену из 8 уже закончили=)

Так, к новостям. Рынок труда продолжает штормить. Весной моя компания сократила больше сотни человек. И это была первая волна. Как показала практика - ни опыт, ни стаж работы в компании не давали никаких особых шансов сохранить место - убирали специалистов с прекрасным портфолио, которые работали и по 7 и по 10 лет.
Вторая волна на подходе и на этот раз я в неё тоже попадаю, с большой вероятностью. Увы и ах, такова се ля ви. Вернее не так - я выхожу на рынок труда и готов к новым вызовам (играет бравурная музыка).
Зато когда я перестану быть связанным NDA будет отличная тема для поста о том как проходят сокращения в разных компаниях ( и не смотря на отдельные кейсы в США и Европе русскоговорящий мобильный гемдев выглядит тут сооовсем не круто). В общем следите за новостями.
P.S.
проекты никуда не деваются, мы продолжаем над ними работу.

#gamedev #gamedevelopment #layoffs #сокращения #геймдев #нарративныйдизайн #narrativedesign #gamedesign #геймдизайн #opentowork #igaming

Вот появилась страничка в стиме одного из моих проектов - тут я выступаю как лид-нарративщик. Лор, квесты, персонажи, сценарии - это моя работа) А на страничке можно увидеть ролик, сценарий и раскадровку к которому писал я)
https://store.steampowered.com/app/3220640/Synvector/
#GameDev #NarrativeDesign #IndieGame #Steam #GameTrailer #WishlistNow

Я тут вот с чем столкнулся... Короче кажется, что в эпоху нейронок написание ГДД как навык должно отойти на второй план. Но тут происходит ровно то же самое, что происходит и и вайбкодинге. Если человек не знает каким должен быть ГДД, как он должен работать и какую структуру иметь - получается полная ерунда. Специалист который полагается только на нейронку просто не увидит и не поймет, что не так. Особенно это видно на маленьких документах — например, на вижен-доках конкретной механики.

Я пользуюсь определённой структурой. Вот она — с примерами и объяснениями, почему каждый блок нужен.

Вижен-документ механики — это 2–4 страницы, после прочтения которых два дизайнера принимают одинаковые решения по спорному кейсу. Если не принимают — вижен не работает.
Что в нём должно быть:
→ Проблема, а не решение. Не «сделаем систему морали 3×3», а «выборы игрока сейчас ощущаются разрозненными — нужна система, которая их связывает».
→ Ядро фичи — одна главная задача, которая не режется. Остальное может уйти при скоупе.
→ Дизайн-принципы — 3–6 коротких правил, по которым можно проверить любую конкретную сцену.
→ Границы — чем фича НЕ является. Пять строк ограничений экономят месяцы, потому что scope creep убивает больше фич, чем плохой дизайн.
→ MoSCoW — что обязательно, что желательно, что можно резать. Без этого разговор «надо резать скоуп» превращается в хаос.
Формула простая: хороший вижен фичи — фильтр принятия решений. После него команда одинаково понимает, что усиливает механику, а что её ломает.

Шаблон
Для тех, кому удобнее работать по чеклисту. Это не догма — порядок и состав секций подстраиваются под конкретную фичу. Но как отправная точка:

Название фичи и one-liner — что это за механика, одной фразой.
Зачем она нужна — проблема и опыт, который фича создаёт.
UX — делает / чувствует / понимает / запоминает.
Ядро фичи — одна главная задача.
Дизайн-принципы — 3–6 правил.
Core loop — цикл взаимодействия.
Каналы проявления — где и как игрок видит работу механики.
Контент-правила — что подходит, что не подходит.
Границы — чем фича не является.
Прозрачность — что показываем, что скрываем.
MoSCoW — приоритеты при резке скоупа.
Риски — что может сломаться и как снижаем.
Критерии успеха — как понять, что получилось.
#GameDesign #GDD #GameDev #GameProduction #DesignProcess

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

Одна из частых причин, почему фича ломается в разработке: команду ведут в спринт с вижен-доком вместо спецификации.
Вижен-док нужен. Но он не обязан отвечать на все вопросы реализации. Его задача: объяснить, зачем фича нужна, какое у неё ядро и по каким принципам команда принимает решения.
Спецификация нужна для другого: зафиксировать, как система ведёт себя в игре.

Выглядит обычно так: есть идея фичи, которая всем в общем-то нравится. Пишется хороший вижен: проблема, цель, ядро фичи, принципы, границы, MVP. Кажется, что всё понятно.
А потом: где точка входа? Что видит игрок в первом состоянии? Что происходит, если контент не разблокирован? Что делать, если игрок вернулся через месяц? Какие состояния у кнопки? Что логируем? Как фича ведёт себя в старом контенте?
И выясняется, что команда читала один и тот же документ, но представляла себе разные фичи. И вот тут уже необходима спека.

Что я хочу видеть в спецификации:
- Player flow — как игрок входит, что делает, как выходит, куда возвращается.
- Состояния системы — locked, unlocked, active, completed, empty, error, replay. Всё, что может увидеть игрок.
- Правила — триггеры, ограничения, зависимости, приоритеты.
- UX-поведение — что показываем, что скрываем, где tutorial hint, где достаточно affordance.
- Контентная модель — что нужно, ограничения, fallback, локализация.
- Edge cases — не «что должно произойти в идеале», а что произойдёт, когда игрок сделает всё не так.
- Аналитика — какие события логируем и какие метрики скажут, что фича работает.
- Scope layers — что в MVP, что можно добавить позже, что нельзя резать без потери смысла.
Это не бюрократия. Это способ не перекладывать дизайн-решения на разработчика, UX-дизайнера или продюсера в момент, когда фича уже в спринте.

Нейронка может помочь собрать структуру, ускорить черновик, накидать edge cases. Но она не отличит обязательное решение от красиво звучащего. Длинный гладкий документ со словами «engagement», «retention», «emotional reward» — это презентация намерений, а не production-ready документация.
Для меня это главный тест документации: после неё команда должна принимать меньше случайных решений, а не просто иметь ещё один файл в Confluence.

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

#GameDesign #GDD #GameDev #GameProduction #DesignProcess

Готовился к собеседованию, освежал кое-что в памяти. Понял: многие геймдизайнеры до сих пор не понимают, зачем FTUE вообще нужен. Его превращают в часовой туториал, в экспозицию для «истории» или просто бросают игрока один на один с офферами на 100 баксов и тремя видами валют.

FTUE — это кор-луп в миниатюре. Тот же цикл, что и вся игра, только сжатый и с рукой на плече. Первые минуты ведут жёстким коридором почти без развилок, а как только игрок усвоил базовый цикл, коридор расширяется в свободу. В Family Island это гринд, ресурсы, апгрейд дома: ровно то, чем игрок будет заниматься следующие полгода, просто медленнее и без риска облажаться с первого раза. Отдельный туториальный режим с урезанными механиками — уже проигрыш: учишь человека играть в игру, которой не существует. Если твой FTUE устроен иначе, чем основная игра, ты заставил его пройти обучение дважды.

Второй косяк я сам совершал лет десять назад. Хотелось рассказать историю с первых секунд: герой, завязка, драма. Экспозиция в первые пять минут почти всегда проваливается, даже если диалоги гениальные. Персонажей — минимум. Лора — минимум. Хочешь рассказать историю? Поставь ее на стоп и займись игроком. Текст на экране, который никто не читает, историей не станет. Первая сессия проходит через руки, а не через текст.

Третий — про деньги. Ресурсов с избытком, блокеры отложены, таймеры почти декоративные. Даже символический таймер учит: ожидание существует, но пока не мешает. Монетизация никуда не торопится: человек, который ещё не понял, во что играет, всё равно ничего не купит. Ему банально нечего защищать.

Я редизайнил FTUE на одном из проектов. Воронка +15%, D1 +15%, D7 +10%. Никакой магии — просто убрал всё, что мешало человеку понять игру за первые двадцать минут.
Где именно должна проходить граница FTUE и почему это не совпадает с концом туториала — расскажу вторым постом.

#FTUE #GameDesign #MobileGaming #PlayerRetention #NarrativeDesign

Вторая часть про FTUE

Спроси любого дизайнера, где у него заканчивается FTUE. Велик шанс услышать: «когда заканчивается тутор». Неправильный ответ.

После первых минут кор-лупа начинается разгон: одна новая механика за раз, сначала power-up, потом мини-игра, потом что-то социальное. Не пачкой, иначе перегрузка и отвал уже на этом этапе. Каждое действие даёт результат в течение секунд: погриндил, тут же потратил ресурс на стройку, увидел, как меняется экран. Три-четыре шага между действием и наградой — и связь рвётся. Человек перестаёт понимать, зачем вообще жмёт на экран.

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

А потом — порог. Включается всё «настоящее» разом: блокер, коллекции, ежедневные награды, полноценный гринд. Вот тут и заканчивается FTUE. Пропавшие стрелки говорят об интерфейсе. Граница — событие в экономике игры.

Я не назову это самым интуитивным определением, но это единственное, которое реально работает для аналитики. Без этой точки дизайнер не понимает, что именно тюнить дальше: обучение или уже игру. Аналитик путает, что мерить как воронку первого касания, а что как ретеншн основного цикла. Одну и ту же метрику дёргают то как онбординг, то как core retention, и оба вывода получаются неточными.

Если твой аналитик не может назвать точное событие, после которого начинается «настоящая» игра — у тебя не FTUE. У тебя произвольно нарезанные первые N уровней, которым задним числом придумали название.

#FTUE #GameDesign #MobileGaming #PlayerRetention #NarrativeDesign

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

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

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

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

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

#GameDesign #FeatureOwnership #GameDev #Leadership #GameIndustry

Я утверждал, утверждаю и буду продолжать утверждать: D&D и подобные системы — лучший тренажёр для геймдизайнера. Особенно для высоких грейдов.

DM не пишет историю целиком заранее. Он создаёт условия, в которых история случается. NPC с мотивациями, конфликты с несколькими исходами, точки давления. Лид-дизайнер работает так же: задаёт пространство решений, в котором команда принимает свои.

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

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

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

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

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

#gamedesign #dnd #tabletop #gamedevelopment #leadership

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

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

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

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

Отсюда и путаница. Опытный миддл+ выглядит сеньором, пока не попадёт в ситуацию без готовой постановки. Сеньор часто становится лидом по стажу и продолжает решать задачи руками сам, вместо того чтобы строить процесс. Так получаются лиды, которые сами становятся узким местом команды, и сеньоры, которые молча ждут ТЗ.

Хотите проверить грейд честнее, чем через тестовое? Спросите, что человек делает, когда задача поставлена неправильно. Миддл сделает, как сказали. Сеньор придёт с возражением и альтернативой. Лид спросит, почему у нас задачи вообще ставятся так.
#gamedesign #leadership #gamedevelopment #careergrowth

Ошибку сделали раньше — когда формулировали задачу.

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

Задача почти всегда приходит уже в виде решения. «Нужно добавить ежедневные награды», «нужно ускорить туториал». Внутри формулировки уже сидит чей-то ответ на проблему, которую вслух не проговорили.

Проблему замечает не дизайнер. Аналитик видит просадку на третий день, потом её пересказывают продюсеру, который к этому моменту прочитал отзывы, потом комьюнити-менеджеру, у которого лежит тред с сорока одинаковыми жалобами. Каждый пересказ добавляет немного объяснения. До дизайнера задача доезжает с уже вшитой причинно-следственной связью. Дизайнер решает чужую гипотезу и искренне считает её фактом.

В Diablo II торговля ушла на сторонние сайты. Там кидали, продавали дюпнутые вещи, договаривались с незнакомцем в аське. Blizzard сформулировала это как «игрокам негде безопасно торговать» и построила в Diablo III аукцион за реальные деньги. Аукцион эту проблему решил. И заодно убил смысл убивать монстров. Лучший способ одеться оказался не в подземелье, а на витрине аукциона. 18 марта 2014-го обе версии закрыли.

Разворачивает симптом в причину скучная работа. Что именно изменилось и когда, с точностью до патча, а не «в последнее время». Какой сегмент задет, а какой нет. Иногда это все игроки, иногда только новые на мобилках, и это разные истории. Куда игрок уходит вместо ожидаемого действия. И было ли так всегда, или это просто давняя норма, которую раньше не мерили.

Если хотя бы на один вопрос нет ответа, на руках пока наблюдение.

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

Гарнизон в Warlords of Draenor отвечал на понятный запрос. Игроку нужна своя прогрессия вне рейдов, свой угол, где всё зависит только от него. Он это дал — и засосал игроков внутрь, профессии выродились в клик по зданию, выходить в мир стало незачем. Подписка сначала подскочила к десяти миллионам, но к августу 2015-го упала до 5,6 миллиона, и через квартал Blizzard объявила, что вообще перестанет называть эту цифру.

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

Если проверить нельзя вообще никак, гипотезу, скорее всего, сформулировали так, чтобы её нельзя было опровергнуть.

Спросите у трёх человек из команды, какую проблему решает фича. Если ответы разные, вы ещё не начали работать над задачей — вы работаете над чьим-то предположением.

#gamedesign #productdesign #gamedevelopment #featureownership

В понедельник у меня был собес после одной истории.
На прошлой неделе я опубликовал пост в линкеде о том как "классно" со мной пообщался рекрутер (пришёл не прочитав CV и все интервью заняло 20 минут в течение которых я пересказывал первую страницу своего резюме, после чего получил отказ). Пост залетел и поднялся небольшой шум. Ко мне пришёл их хед HR и предложил мне, раз такого дело, пообщаться с командой на позицию продюсера сюжетной компании. Итак, в понедельник случился собес

Я не буду характеризовать поведение интервьеров на собесе. Больше часа времени мы разговаривали о каких-то пространных вещах (мои любимые игры, дизайн миссий в них, режиссура в RDR2 и все в таком духе). Не было разобрано:
ни одного продуктового кейса;
ни одного кейса по метрикам;
ни одного кейса по аналитике;
ни одного кейса по progression;
ни одного кейса по UX;
(кроме того что я сам попытался описать)

Сегодня мне пришёл отказ с формулировкой:
"У нас сейчас запрос чуть в другую сторону. И для продюсера сюжетной линии, и для FTUE нам нужен человек, который будет оунить весь игровой опыт: не только нарративную составляющую, но и геймплей, темп, progression, UX, продуктовые итерации и работу механик в целом."
И у меня один вопрос: вы там что, охуе..., кхм, в смысле - так хер ли вы не спрашивали?

Это все может свидетельствовать о нескольких вещах:

1. У них внутри нет единого понимания роли
Главный ГД, судя по интервью, искал кого-то ближе к:
open-world mission designer;
narrative director с глубоким знанием Rockstar;
автору сюжетной кампании;
возможно, человеку с прямым опытом GTA/RDR.
А после встречи отказ упаковали в более солидную формулировку про ownership всего игрового опыта

2. Решение приняли довольно рано
Нередко интервьюер за первые 15–20 минут решает, что кандидат «не его», а оставшееся время просто продолжает разговор без реальной попытки проверить компетенции.
Тогда финальный фидбек не является причиной отказа. Это рационализация уже принятого решения.

Что это говорит о компании?
Не обязательно, что весь проект плохой, но конкретно найм показывает несколько красных флагов.
нет competency matrix для роли;
нет структуры интервью;
должность названа одним образом, а в голове руководителя существует другая;
решения могут приниматься по субъективному впечатлению, а потом обосновываться задним числом;
главный ГД, вероятно, плохо разделяет нарративный, миссионный, продуктовый и продюсерский уровни работы.

Короче русский геймдев такой геймдев.

#gamedesign #leadership #gamedevelopment #careergrowth