Портрет целевого покупателя и игровой сценарий использования пака

Здравствуйте. В прошлом уроке вы сравнивали тематические ниши по насыщенности, цене и косвенным признакам спроса. Теперь нужно сделать важный переход: перестать думать о паке как о наборе красивых объектов и описать его как решение задачи конкретного разработчика.

К концу урока у вас будет одностраничный черновик из двух связанных частей:

1. портрет целевого покупателя — не абстрактный «геймдев», а разработчик с конкретной задачей, ограничениями и причиной купить набор;
2. игровой сценарий — одна сцена или небольшой фрагмент игры, который покупатель сможет собрать с помощью вашего пака.

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

---

Покупатель пака — не игрок и не «все инди-разработчики»

У вашего будущего продукта есть как минимум три аудитории:

Роль	Что ей важно	Почему не стоит смешивать роли
Конечный игрок	Атмосфера, история, игровой опыт	Игрок почти никогда не выбирает ваш ассет-пак напрямую
Покупатель пака	Экономия времени, понятность файлов, единый стиль, возможность собрать нужную сцену	Именно этот человек принимает решение о покупке
Разработчик, который будет использовать ассеты	Сетка, тайлы, варианты, анимации, совместимость элементов	Иногда это тот же человек, что и покупатель; в маленьких командах чаще всего так и есть

Фраза «мой пак для инди-разработчиков» слишком широка, чтобы помочь вам решить, что рисовать. У начинающего автора hobby-проекта, программиста, который делает прототип, и художника небольшой студии действительно могут быть общие интересы, но их задачи, бюджет и требования различаются.

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

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

Это не демография. Возраст, страна и любимые игры могут быть полезны для будущего маркетинга, но для состава ассет-пака важнее другое:

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

---

Портрет строится на наблюдениях, а не на фантазии

На прошлом уроке вы собрали карточки конкурентов. Теперь ищите в них не только цены и превью, но и следы пользовательских задач: вопросы в комментариях, состав паков, обновления, расширения и повторяющиеся категории ассетов.

Полезно вести три колонки: наблюдение, осторожный вывод, решение для своего продукта.

Наблюдение	Осторожный вывод	Решение для будущего пака
В комментариях покупатели спрашивают про атаки, инструменты и предметы для крафта	Часть пользователей планирует не статичную карту, а игру с действиями и прогрессом	Если вы обещаете приключенческий сценарий, обозначьте, есть ли в первом наборе интерактивные объекты и состояния
Пользователь спрашивает про дома и интерьеры	Открытая природная локация сама по себе может не закрывать весь нужный сценарий	Либо включить входы и интерьеры, либо честно ограничить пакет внешними локациями
Пользователь уточняет сетку и импорт спрайт-листа	Техническая ясность влияет на пригодность покупки	Позднее понадобятся понятные размеры, сетка и организация файлов

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

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

---

Сценарий использования задаёт состав, а не тема

Тема отвечает на вопрос: «какой это мир?»

• фэнтези;
• sci-fi;
• современный город;
• шахта в горах.

Сценарий отвечает на другой вопрос: «что игрок делает в конкретной части игры и какую сцену должен собрать разработчик?»

Сравните формулировки:

Слабая формулировка	Почему она не помогает
«Пак для фэнтези-RPG»	Неясно, это лес, таверна, подземелье, город, бой или ферма
«Горные тайлы и пропсы»	Перечисляет тему, но не задаёт сцену и функциональность
«Красивый набор для игр»	Не говорит покупателю, какую проблему набор решает

Рабочая формулировка	Что она уже определяет
«Набор для top-down приключения, где игрок проходит горный перевал, входит в заброшенную шахту и исследует пещерные камеры»	Нужны поверхности, перепады высоты, входы, проходы, ориентиры и шахтные пропсы
«Набор для sci-fi roguelite, где игрок зачищает отсеки станции и открывает двери между комнатами»	Нужны модульные комнаты, двери с состояниями, укрытия, контейнеры и читаемые проходы
«Набор для фермерской игры, где игрок расчищает участок, выращивает ресурсы и обустраивает двор»	Нужны почва, вода, растения в состояниях, инструменты либо их визуальные результаты, декор и варианты сезона

Сценарий полезен, потому что он создаёт проверяемую причинно-следственную связь:

1. Разработчик хочет собрать определённую игровую ситуацию.
2. Для неё требуются конкретные типы пространства, препятствий, объектов и визуальных сигналов.
3. Эти требования определяют минимальный состав пака.
4. Всё, что не поддерживает сценарий, либо становится расширением, либо не входит в продукт.

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

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

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

---

Проверка сценария: может ли покупатель собрать обещанную сцену?

Практик Sebbyspoons формулирует это через метафору конструктора: на упаковке не должны быть показаны объекты, для которых внутри не хватает деталей. В видео есть слишком сильное утверждение о том, что полнота набора сама по себе гарантирует продажи. Его принимать не нужно: продажи зависят также от спроса, цены, видимости карточки, качества и конкуренции. Но критерий «можно ли собрать обещанную сцену?» действительно полезен.

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

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

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

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

Граница первого продукта: это набор окружения; он не обещает готового героя, врагов, интерфейс или полностью готовую боевую систему.

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

---

Соберите портрет покупателя по пяти параметрам

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

Параметр	Что зафиксировать	Пример для горно-пещерного сценария
Контекст проекта	Размер команды, этап и тип игры	Одиночный разработчик или малая команда; прототип уже работает, но пока использует временные визуальные элементы
Конкретная задача	Что нужно сделать в ближайшем игровом фрагменте	Собрать исследуемую горную локацию с переходом в шахту и пещеру
Боль и потери времени	Что приходится делать вручную без пака	Подбирать несовместимые скалы, выдумывать переходы поверхности, дорисовывать входы и шахтные детали
Критерий покупки	Как покупатель поймёт, что набор подходит	Сможет увидеть в превью целую сцену, список модулей и понятную сетку; заметит, что элементы рассчитаны на совместную сборку
Причина отказаться	Что создаст риск или недоверие	Неясные размеры, отсутствие углов и переходов, слишком мало вариантов, декоративные элементы без базовых тайлов, непрозрачная лицензия

На основе таблицы соберите короткий портрет. Его можно написать в таком виде:

Целевой покупатель: одиночный разработчик или небольшая команда, создающие пиксельную top-down игру и переходящие от серого прототипа к первой атмосферной локации. Им нужен согласованный набор окружения, чтобы быстро собрать горный маршрут, вход в заброшенную шахту и несколько пещерных камер без поиска и ручной стилизации десятков сторонних объектов. Покупатель выбирает пак, если видит в нём полный набор базовых модулей, понятные ограничения и готовый пример собранной сцены.

Это уже сильнее, чем «для RPG-разработчиков», потому что из него следуют решения:

• нужны не только красивые большие скалы, но и элементы, которыми можно строить границы прохода;
• нужны не только тележки и кирки, но и поверхность, пещерные стены и вход;
• превью должно показывать маршрут и читаемую сцену, а не россыпь объектов на нейтральном фоне;
• отсутствие персонажей допустимо, если набор прямо позиционируется как окружение и не выдаёт себя за полный game kit.

---

Ваш рабочий документ: «покупатель + сцена»

Создайте документ из восьми пунктов. Одной страницы достаточно; его задача — сделать будущие решения последовательными, а не написать красивый маркетинговый текст.

1. Ниша-кандидат

Зафиксируйте формат, камеру, тему и игровой сценарий.

Pixel art, top-down, модульное окружение для горно-пещерной приключенческой локации.

2. Одно предложение о покупателе

Используйте конструкцию:

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

Не пишите «для всех, кто делает игры». Если формулировка подходит одновременно создателю гонок, карточной игры, визуальной новеллы и RPG, она ещё слишком общая.

3. Игровая ситуация

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

Например: «Игрок проходит по опасной тропе, находит вход, исследует пещеру и собирает ресурсы в заброшенной шахте».

4. Визуальная задача разработчика

Опишите сцену со стороны того, кто её строит:

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

Это связывает игровые действия с ассетами.

5. Минимальные категории ассетов

Запишите категории, а не количество объектов:

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

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

6. Ясная граница

Отдельно запишите, чего в первой версии не будет. Это защищает от расползания объёма:

Не входят: игровые персонажи, враги, UI, эффекты и интерьер поселения. Они могут стать совместимыми расширениями, если соответствуют спросу и не противоречат основному стилю.

7. Доказательства и допущения

Разделите факты и интерпретацию.

Тип записи	Пример
Наблюдение	В карточках похожих паков покупатели спрашивают о входах, зданиях, атаках, крафтовых ресурсах или технической разметке
Вывод	Покупателям важны не отдельные декоративные объекты, а возможность продолжить игровую задачу
Допущение	Для выбранного горно-пещерного сценария разработчики особенно оценят модульные переходы и шахтные пропсы
Что проверить позже	Есть ли у прямых конкурентов такая связка и считают ли они её базовой или отличающей особенностью

8. Проверка обещания

Закончите документ одной фразой:

Покупатель сможет собрать [конкретную сцену] без необходимости самостоятельно создавать [критические недостающие категории].

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

---

Главное

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

• Формулируйте покупателя через его контекст, задачу, ограничения и критерий покупки.
• Извлекайте гипотезы из карточек конкурентов и комментариев, но не выдавайте отдельные наблюдения за статистику рынка.
• Определяйте пак через игровую сцену, а не только через тему и список красивых объектов.
• Полнота означает не «включить всё», а «дать достаточно элементов для честно заявленного сценария».
• Ясно указывайте, что входит в первый набор и что станет возможным расширением.

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