Здравствуйте. В прошлом уроке вы ранжировали три конкретные идеи и выбрали наиболее обоснованную для первого релиза. Теперь важно не превратить победившую идею в бесконечный список желаемых ассетов.
В этом уроке вы определите минимальный продаваемый комплект: не самый маленький набор файлов, а законченный продукт, с которым покупатель действительно может собрать обещанную сцену. Затем вы отделите от него расширения, которые увеличивают ценность серии, но не исправляют недоделки первой версии. В конце у вас будет карта продукта: ядро, явные границы и несколько совместимых направлений роста.
Ориентир по времени: около 40 минут.
Минимальный комплект — это выполненное обещание, а не минимум картинок
Покупатель не приобретает абстрактные «красивые пиксели». Он покупает возможность быстрее собрать часть своей игры: комнату станции, маршрут через шахту, рыбацкий остров, рынок, подземелье или другую конкретную локацию.
Поэтому вопрос для первого релиза звучит не так:
«Какое наименьшее число спрайтов я могу нарисовать?»
А так:
«Что должно быть в наборе, чтобы покупатель собрал заявленную сцену, не дорисовывая базовые элементы и не подбирая несовместимые ассеты у другого автора?»
Selling Pixel Art Assets Online
Посмотрите фрагмент Selling Pixel Art Assets Online от Sebbyspoons - Game Dev and Pixel Art. Автор формулирует покупательскую логику: набор ценен не как украшение, а как комплект строительных элементов для игровой сцены.
Посмотрите полноту набора. Обратите внимание на критерий: покупателю должно хватать компонентов, чтобы собрать показанный и обещанный результат, а не только один декоративный угол сцены.
У автора в видео речь идёт о наборе, достаточном для игры или уровня целиком. Для вашего первого top-down окружения это нужно интерпретировать аккуратно. Если вы продаёте именно environment pack, он не обязан включать полноценного персонажа, врагов, интерфейс и все игровые анимации. Но он обязан честно и самостоятельно решать свою задачу.
Например:
| Обещание на карточке товара | Что покупатель вправе ожидать |
|---|---|
| «Top-down набор для заброшенной научной станции» | Полы, стены, углы, границы помещения, проходы, узнаваемые технические пропсы и достаточно вариантов, чтобы собрать хотя бы несколько помещений. |
| «Набор для горного маршрута и входа в шахту» | Поверхности, края и переходы ландшафта, скалы, вход, шахтные конструкции, ориентиры и пропсы, связывающие маршрут в цельную локацию. |
| «Набор для космического рыбацкого острова» | Воду, береговые переходы, островные поверхности, пирсы или платформы, точки ловли, базовые постройки и тематические ориентиры. |
Если в превью показана дверь, ведущая в помещение, а в паке нет ни дверного проёма, ни способа собрать примыкающие стены, это не «материал для будущего обновления». Это пробел в обещании.
Три уровня содержимого
Чтобы не называть любое отложенное решение «расширением», разделяйте ассеты на три уровня.
| Уровень | Смысл | Решение |
|---|---|---|
| Критический пробел | Без элемента нельзя собрать заявленную сцену или элементы не состыкуются. | Добавить в первый релиз. |
| Ядро первого комплекта | Элемент нужен, чтобы покупатель получил обещанную возможность и собрал правдоподобную вариацию сцены. | Включить в минимальный продаваемый комплект. |
| Расширение | Добавляет новую локацию, новый тип использования, новые вариации или заметно более широкий диапазон сцен, но базовый набор уже работает без него. | Запланировать после первого релиза. |
Ключевое правило:
Расширение усиливает работающий продукт. Оно не должно закрывать дыру, из-за которой базовый продукт нельзя использовать по назначению.
Например, для набора «научная станция» дополнительные медицинские модули, оранжерея или грузовой отсек могут быть расширениями. Но внутренние и внешние углы стен, закрывающие разрывы в базовой комнате, — это часть ядра.
Думайте не предметами, а системой сборки
Случайный набор из десяти красивых ящиков, терминалов и ламп выглядит как коллекция иллюстраций. Набор, который позволяет собрать разные помещения из тех же элементов, становится системой. Именно эта разница делает модульные ассеты полезнее для разработчика.

Skyrim's Modular Approach to Level Design
Прочитайте два коротких фрагмента статьи Skyrim's Modular Approach to Level Design от Game Developer. Это материал о 3D-уровнях, но принцип «kit как система» напрямую применим к пиксельным тайлам и модульным пропсам.
В начале статьи, до раздела “Going Modular: Pros and Con”, прочитайте определение kit. Зафиксируйте мысль: несколько элементов могут давать намного больше комбинаций, чем предполагает их количество. Затем перейдите к разделу “Where Kits Come From - Our Process”, подразделу “2) The Proof Phase”. Прочитайте этап проверки. Сосредоточьтесь на порядке работы: сначала доказать, что система собирается и покрывает нужные случаи, и только затем вкладываться в финальную детализацию.
Для вашего пака это означает: прежде чем рисовать «героический» объект, который красиво смотрится в обложке, нужно убедиться, что существуют обычные элементы, которые покупатель будет использовать десятки раз.
Полезно разложить выбранную тему на функциональные роли, а не сразу на конкретные спрайты.
| Функциональная роль | Что она даёт покупателю | Пример для top-down окружения |
|---|---|---|
| Основа пространства | Место, по которому строится сцена. | Пол, земля, вода, каменный грунт. |
| Границы | Отделяют доступную зону и формируют объём. | Стены, скалы, обрывы, береговые кромки. |
| Соединения | Позволяют переходить между частями пространства. | Углы, дверные проёмы, лестницы, мостки, переходы поверхностей. |
| Функциональные пропсы | Подсказывают назначение места или игровое действие. | Терминал, ящик, рыболовная точка, рельсы, вагонетка. |
| Ориентиры | Делают сцену запоминающейся и помогают визуально различать зоны. | Большая антенна, шахтный вход, водонапорная башня, алтарь. |
| Вариативность | Снижает заметную повторяемость. | Второй вариант пола, повреждённая стена, альтернативный ящик, декаль. |
Первые четыре роли чаще всего образуют ядро. Ориентиров обычно нужно немного, но хотя бы один может быть обязательным, если именно он формирует коммерческое отличие пака. Вариативность нужна, однако её нельзя путать с бесконечным количеством декора: сначала создайте базовую связность системы, потом добавляйте заменяемые варианты.
Проверка «можно ли собрать сцену»
Поскольку вы работаете только в Aseprite, тестирование не требует игрового движка. Создайте отдельный файл, например:
00_scope_proof.aseprite
В нём соберите на нативном разрешении не финальную иллюстрацию, а грубую карту проверки состава. Используйте временные цветные блоки или простые силуэты для ещё не нарисованных ассетов.
Ваша карта должна содержать:
- главную зону сцены;
- минимум один переход между типами пространства;
- несколько границ и углов;
- один функциональный участок;
- один визуальный ориентир;
- две различающиеся компоновки, которые используют общую систему элементов.
Например, для станции это могут быть короткий коридор с дверным проёмом и маленькая комната с терминалом. Для горной шахты — участок тропы с поворотом, входом, рельсами и небольшой пещерной камерой.
Если для сборки карты приходится каждый раз добавлять уникальную заплатку — «ещё один специальный угол», «одну стену только для этого случая», «отдельный кусок пола, чтобы закрыть щель» — это сигнал проверить не список исключений, а логику базового модуля.
Как провести границу первого релиза
Сначала напишите одно узкое продуктовое обещание. Не «полный набор для любой RPG», а конкретная возможность, которой покупатель сможет воспользоваться.
Рабочая формула:
[Тип разработчика] сможет собрать [конкретную игровую сцену] с помощью [тип системы ассетов], не смешивая несовместимые наборы для базовых элементов этой сцены.
Например:
Разработчик top-down adventure сможет собрать заброшенный технический отсек с несколькими соединёнными комнатами, используя совместимые полы, стены, двери, терминалы и складские пропсы в едином пиксельном стиле.
После этого классифицируйте каждую категорию будущих ассетов. Ниже приведён условный пример для «заброшенной технической станции»; замените его своей темой, а не копируйте состав буквально.
| Категория | Решение | Основание |
|---|---|---|
| Полы и их бесшовные варианты | Ядро | Без них невозможно создать площадь помещения. |
| Прямые стены, внутренние и внешние углы | Ядро | Без них комнаты распадаются на несвязные фрагменты. |
| Дверной проём или проход | Ядро, если в обещании есть соединённые комнаты | Покупатель должен собрать заявленную связь пространств. |
| Терминал, контейнер, технический ящик | Ядро | Они объясняют назначение места и дают сцене функциональный характер. |
| Один крупный ориентир: генератор или антенна | Ядро, если это часть визуального отличия | Он помогает показать тему пака в превью и в сцене. |
| Пять дополнительных типов помещений | Расширение | Базовый набор может работать с одним основным типом помещения. |
| Медицинская мебель, оранжерея, грузовой отсек | Расширение | Это новые тематические поднаборы, а не исправление комнаты. |
| Полноценные персонажи, враги, интерфейс | Отдельный будущий набор либо исключение | Они выходят за рамки обещания environment pack. |
| Десятки цветовых замен каждого предмета | Позднее решение | Сначала важнее структурная совместимость и читаемость. |
Обратите внимание на условие у двери. Если вы заявляете «интерактивные двери с открытым и закрытым состояниями», оба состояния относятся к ядру. Если вы продаёте только набор статичного окружения, честнее включить проём или закрытую дверь как часть архитектуры и не обещать функциональную анимацию.
Не путайте масштаб с завершённостью
Первый релиз не обязан содержать все возможные биомы, типы комнат и игровые системы. Но он должен быть законченным на собственном уровне. Условный маленький пакет может быть коммерчески убедительнее большого, если его граница ясна:
- Слабая формулировка: «Sci-fi tileset с разными объектами».
- Рабочая формулировка: «Модульный top-down набор для сборки коридоров и небольших технических помещений заброшенной станции».
Во втором случае покупатель видит и возможности, и ограничения. Это снижает риск разочарования и помогает вам не добавлять всё подряд.
Расширения: новые возможности, а не новые несостыковки
Модульность ценна покупателю, потому что позволяет повторно использовать элементы в разных комбинациях. Но для автора она требует подготовки: одинаковой сетки, логики соединений и ясных правил.
Why My Game Assets Didn't Sell (5 Mistakes)
Посмотрите фрагмент Why My Game Assets Didn't Sell (5 Mistakes) от Sture. Он кратко объясняет, почему модульность повышает полезность набора, но одновременно требует более строгого планирования.
Посмотрите ценность модульности. Отделите два вывода: повторное использование экономит время покупателю, а для автора оно означает необходимость заранее согласовать размеры, соединения и визуальные правила.
Для будущих релизов возможны два честных формата.
| Формат | Что это значит для покупателя | Когда выбирать |
|---|---|---|
| Дополнение к базовому набору | Расширение использует систему первого пака и требует его для полноценной сборки сцены. | Когда новый контент естественно опирается на уже существующие полы, стены, границы и пропсы. |
| Самостоятельный, но совместимый набор | Новый пак можно использовать отдельно; он имеет достаточное ядро, но совпадает со стандартами первого. | Когда новая тема должна решать свою законченную задачу и быть понятной новому покупателю без предыдущей покупки. |
| Будущий bundle | Несколько совместимых паков продаются как более полный набор со скидкой относительно отдельных продуктов. | Когда серия уже содержит несколько самостоятельных или взаимодополняющих релизов. |
Необязательно решать сейчас, как именно вы будете продавать каждое расширение. Важно уже сейчас понимать его зависимость. Не называйте «дополнением» комплект, который без базового пака превращается в несколько несвязных украшений, если это не указано ясно.
Контракт совместимости
Расширение не должно быть просто «похоже по настроению». Совместимость лучше рассматривать как короткий контракт, который будет уточняться и окончательно фиксироваться в следующем модуле курса.
Запишите для всей серии следующие правила:
| Область | Что нужно зафиксировать |
|---|---|
| Сетка | Единый размер тайла и размеры объектов, кратные основной сетке. |
| Перспектива | Одинаковая top-down логика: какие плоскости видны, насколько высоко видны боковые стороны объектов. |
| Масштаб | Соотношение дверей, ящиков, мебели, препятствий и будущего персонажа. |
| Свет | Одно основное направление света и похожая система теней. |
| Палитра | Общие принципы яркостных групп и контраста; расширение может иметь свою акцентную палитру, но не должно разрушать читаемость базы. |
| Контуры и кластеры | Одинаковая плотность детализации, характер контура и размер пиксельных кластеров. |
| Точки соединения | Ширина дверных проёмов, типы углов, края поверхностей, места крепления настенного декора. |
| Именование | Понятные категории и названия, чтобы покупатель мог найти совместимые элементы. |
Числовые значения сетки, масштаба и размеров вы закрепите в модуле о производственных ограничениях. Сейчас достаточно заранее отметить, что расширения будут использовать один и тот же будущий стандарт, а не создавать новый для каждого релиза.
Хорошая карта развития продукта
Продолжим условный пример со станцией. Карта может выглядеть так:
| Релиз | Новая возможность для покупателя | Что использует из базы | Что не должно измениться |
|---|---|---|---|
| База: технический отсек | Коридоры и небольшие служебные комнаты. | Основная система пола, стен, проходов и технических пропсов. | Все базовые правила серии. |
| Расширение: медицинский сектор | Медпункт, изолятор, лабораторный угол. | Те же размеры стен, дверных проёмов, пола и настенных креплений. | Сетка, освещение, пропорции, язык контуров. |
| Расширение: грузовой сектор | Склад, погрузочная зона, сервисный шлюз. | Базовую архитектуру и систему соединений. | Точки стыковки и масштаб объектов. |
| Самостоятельный совместимый пак: внешняя платформа | Участок станции в открытом космосе. | Палитру, масштаб и часть технических пропсов. | Размер тайла и стилистические правила; при этом в наборе должен быть свой достаточный комплект платформ и границ. |
Здесь каждый будущий релиз добавляет новый сценарий. Ни один не обязан компенсировать то, что в базовом паке отсутствует нормальный угол стены или переход между основными поверхностями.
Рабочая сессия: составьте карту вашего первого продукта
Выделите на эту работу около 18–20 минут. Откройте заметки с выбранной идеей и создайте документ product_scope_v1.
1. Зафиксируйте обещание и исключения
Заполните четыре строки:
| Поле | Ваше решение |
|---|---|
| Название рабочего пака | Короткое тематическое название без маркетинговых обещаний. |
| Сцена покупателя | Что он сможет собрать из набора. |
| Ядро продукта | Какие функциональные роли обязательно покрывает первый релиз. |
| Явные исключения | Что сознательно не входит в версию 1.0. |
Исключения особенно важны. Например: «Не включает персонажей, врагов, интерфейс, эффекты, второй биом и подземный сектор». Это не слабость продукта, если базовая сцена уже закончена.
2. Создайте таблицу решений по составу
Для каждой категории ассетов используйте такой шаблон:
| Категория | Роль в сцене | Статус: ядро / расширение / исключено | Почему | Какая тестовая сцена это подтверждает |
|---|---|---|---|---|
Не начинайте с количеств вроде «30 пропсов». Сначала докажите, что каждая категория нужна. Количество появится позже, когда вы определите сетку, размеры, варианты и реальную трудоёмкость.
Хорошее основание выглядит так:
«Внутренний угол стены относится к ядру, потому что без него нельзя замкнуть небольшую комнату на тестовой карте».
Слабое основание выглядит так:
«Поставлю в ядро, потому что мне нравится рисовать такие объекты».
3. Опишите до трёх расширений
Для каждого расширения заполните карточку:
| Поле | Что записать |
|---|---|
| Название расширения | Например, «Грузовой сектор», «Пещерные глубины» или «Рыбацкий рынок». |
| Новая сцена | Какую дополнительную ситуацию сможет собрать покупатель. |
| Зависимость | Нужен ли базовый пак или расширение будет самостоятельным. |
| Общие элементы | Какие правила и модули оно использует совместно с базой. |
| Граница | Чего расширение не добавляет, чтобы не расползаться дальше. |
Если вы не можете назвать новую сцену, это, вероятно, не расширение, а просто декоративный вариант. Такие варианты полезны, но их лучше хранить в списке «после выпуска», а не выдавать за отдельный продукт.
4. Проверьте карту одним жёстким правилом
Посмотрите на каждый элемент из списка расширений и примените правило:
Если убрать этот элемент, можно ли всё ещё собрать сцену, обещанную в описании базового пака?
- Если нет, перенесите элемент в ядро или сократите исходное обещание.
- Если да, это кандидат на расширение.
- Если элемент никак не связан с обещанной сценой и будущей серией, исключите его из текущего плана.
Итоги
Минимальный продаваемый комплект — это не «наименьший набор спрайтов», а самостоятельная система, которая выполняет одно ясное обещание покупателю.
Главные ориентиры:
- Базовый пак должен позволять собрать заявленную сцену без критических пробелов и смешивания несовместимых ассетов.
- Сначала определяйте функциональные роли: поверхности, границы, соединения, пропсы, ориентиры и ограниченную вариативность.
- Проверяйте состав через тестовую карту в Aseprite, а не через ощущение, что «ассетов уже достаточно».
- Расширения должны добавлять новую сцену или новую возможность, а не латать недочёты ядра.
- Совместимость серии опирается на единые правила сетки, масштаба, перспективы, света, палитры и точек соединения.
В следующем уроке вы соберёте эти решения в одностраничный коммерческий бриф: тему, отличие, площадку, состав первого релиза и технические ограничения.
Can't find a good explanation? Sign up and we'll make it for you
Sign up