Настроение у меня сегодня средней токсичности поэтому начну публикацию с цитаты:



— Пойдёшь ко мне в штат?

— Кем?

— Криэйтором.

— Это творцом? Если перевести?

— Творцы нам тут на х... не нужны. Криэйтором, Вава, криэйтором.



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

Так учат на курсах, так оценивают портфолио, так друг другу объясняют на собесах. И это не работает.

Остин из Gardenscapes — нервный британский дворецкий. Три слова, и персонаж готов. Ни карточки, ни детских травм, ни арки. Работает, потому что считывается за секунду — милый нелепый дворецкий, который говорит смешные вещи между раундами. Яркий архетип и тональная точность. Трёхстраничный бэкграунд здесь лежал бы в Confluence мёртвым грузом.

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

Почему так устроено? Потому что проработка — не метод. Это психологическая защита. Трёхстраничная карточка персонажа в казуальном квесте даёт нарративщику ощущение, что он занимается настоящей работой, а не строчит реплики для скип-баттона. Пятиактовая структура в hidden object даёт ощущение, что ты пишешь историю, а не обслуживаешь пазл. Хочется быть творцом. Индустрия подыгрывает: курсы продают «глубину», студии просят «проработку» в вакансиях. Вопрос «а нужна ли тут эта глубина?» не задаёт никто.

Если ты делаешь Ведьмака или Disco Elysium — да, тебе не обойтись без проработки. Соулслайк без продуманного лора разваливается. Но таких проектов единицы. И как бы тебе ни хотелось чувствовать себя писателем в очередной вариации Gardenscapes, карточка персонажа с детской травмой не сделает матч-3 лучше. Она сделает Confluence тяжелее.

Хороший нарративщик — не тот, кто прорабатывает глубже. А тот, кто точно определяет, какая глубина нужна конкретной игре. Написать персонажу карточку на три страницы может выпускник курсов. Понять, что конкретно этому проекту от персонажа нужна одна точная строчка — задача сложнее. В матч-3 это архетип и тон голоса. В соулслайке — лор, вшитый в описания предметов. В narrative RPG — да, полная проработка с арками и мотивациями. Переключаться между этими режимами, а не тащить везде один и тот же — и есть профессионализм.

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

#narrativedesign #gamedesign #gamewriting #gamedev #gamedevelopment

Демка Изнанки (постсоветского хоррора) в мае у нас не вышла...но я не расстроился. Мы нашли классного звукача который сделает к постсоветскому хоррору хороший саунд дизайн (заглавную тему и интегрирует атмосферные звуки). Плюс артистки попросили время на полишинг и переделку некоторых иллюстраций.
А я тем временем решил не терять время и начать в параллель второй проект - Верховье.

Что это будет? Проект на форкфрейме, написанном нашей командой для Изнанки. Я не хочу писать длинную конструкцию вроде "визуальная новелла с элементами РПГ и интерактивного графического романа", потому что это не так. Наши проекты похожи на визуальную новеллу уже довольно отдаленно и содержат в себе много механик близких скорее играм в стиле ДнД и Диско Элииум. Назовём это графической нарративной РПГ.

Про что это будет?
Офицер получает приказ подняться вверх по реке через всю зону конфликта, найти другого офицера, который перестал выходить на связь и построил в глуши собственное маленькое государство. Найти и устранить. Да, это Apocalypse Now. Да, это «Сердце тьмы» Конрада. Нет, это не пересказ.
У Копполы Уиллард наблюдатель, он плывёт и смотрит. У нас игрок принимает решения с открытыми глазами и платит за каждое. Штаб остаётся позади, а впереди путь который изменит героя. при этом протагонист постепенно сползает в безумие и игроку придется во всей красе столкнуться с эффектом ненадёжного рассказчика.

Визуально — кинематографическое аниме-пейнтерли. Здесь кислотная зелень джунглей, мертвенная тиловая вода и небо, которое давит сверху как крышка. Гиперконтраст, хроматическая аберрация, плёночное зерно, красиво и тошнотворно одновременно.
Механики — моральный компас, навыки с d20-чеками, отряд, который реагирует на решения поведением. Кто-то спорит, кто-то молчит, кто-то перестаёт смотреть в глаза. Потери необратимы. Состав группы к финалу — прямое зеркало того, как ты командовал.

же готов сеттинг, написан синопсис, начаты работы по арту.
Мы планируем собрать играбельный пролог истории на полчаса-40 минут к концу лета и выложить в открытый доступ чтобы собрать фидбэк. В общем ссылки будут тут, следите за новостями. Спасибо за внимание.
P.S.
а еще там будут дроу. Но это не точно=)
#gamedev #indiedev #indiegame #narrativedesign #gamedevelopment

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