Разработка / ROBLOX
Developer Product или Pass в Roblox: как выбрать тип игрового предложения
Разбери повторяемую покупку и однократную привилегию до создания магазина. Составь паспорт предложения, согласуй карточку с серверным эффектом и подготовь разные проверки для Developer Product и Pass.
Начни с обещания игроку #
Прежде чем выбирать тип продажи, напиши, что именно получает игрок. «VIP», «бонус» или «улучшение» слишком расплывчаты: одно слово может обозначать постоянный доступ, расходуемый предмет или временный эффект. Укажи результат, его область действия и что происходит после использования или нового входа.
Для упражнения возьмём два условных предложения: набор тренировочных жетонов и доступ к тренировочной комнате. Они не существуют как платные товары наших игр. В статье не создавались Pass или Developer Product, не менялись цены и не выполнялись покупки. Здесь мы принимаем проектное решение и составляем план проверки, а не запускаем настоящий магазин.
Различай повторяемую покупку и привилегию #
Developer Product предназначен для того, что игрок может купить несколько раз. Pass соответствует однократной покупке привилегии. Поэтому первый вопрос — может ли тот же игрок осмысленно приобрести это предложение ещё раз? Второй — что должно оставаться доступным после предыдущей покупки?
Ответ должен опираться на механику. Если жетоны расходуются и новое приобретение должно добавлять новый набор, рассмотрим Developer Product. Если покупка открывает одну привилегию без необходимости покупать её снова, рассмотрим Pass. Это кандидаты для нашего примера, не универсальная рекомендация монетизации и не обещание того, что предложение принесёт доход.
Открыть изображение крупнее ↗Заполни паспорт предложения #
В паспорте нужны понятное название, эффект, повторяемость, предполагаемый тип, соответствующий ID и правило применения эффекта. До создания реального объекта оставь ID незаполненным, не используй чужой или выдуманный рабочий номер. Отдельно укажи, какой серверный участок отвечает за право игрока и за изменение состояния.
Добавь вопрос о повторном входе. Для комнаты надо восстановить доступ владельца Pass; для жетонов важно понять собственную модель хранения количества и выдачи покупки. Эти задачи не решаются одним названием товара. Паспорт выявляет незавершённую работу раньше, чем привлекательная карточка окажется перед игроком.
Открыть изображение крупнее ↗Рассмотри расходуемый набор #
Предположим, тренировочные жетоны расходуются в учебной механике. Новая подтверждённая покупка должна дать предусмотренный новый набор. Не путай две разные покупки одного Developer Product с повторной обработкой одной покупки. Во втором случае задача — не повторить уже выполненную выдачу, а корректно завершить обработку той же операции.
Для проверки отдельно запиши эти два сценария, ожидаемое изменение количества и способ подтверждения. В этом материале нет готового receipt-обработчика, сохранения баланса или выполнения выдачи. Нельзя считать систему завершённой только потому, что количество увеличилось после одного нормального нажатия: неизвестны повтор обработки, ошибки и дальнейший вход.
Рассмотри доступ через Pass #
Для тренировочной комнаты Pass может обозначать право доступа после однократной покупки. Само создание Pass не реализует дверь, серверные правила или применение привилегии. Документация отдельно описывает проверку владения и назначение преимущества уже владеющему игроку при входе.
Поэтому в плане есть как новый покупатель, так и игрок, который владел Pass до текущего входа. Серверная логика должна учитывать нужного игрока и нужный Pass, а доступ — соответствовать описанию. Не используй неопределённое слово «навсегда» вместо точного обещания механики: запиши, какое право предоставляется в этом проекте и где оно действует.
Не смешивай подтверждение двух типов #
Developer Product обрабатывается через ProcessReceipt. Событие PromptProductPurchaseFinished не является подтверждением успешной покупки и не должно заменять обработку выдачи. Для Pass используются его собственные проверки владения и события; правила Developer Product нельзя переносить на него только из-за похожей кнопки.
На схеме пути разделены после выбора типа. У каждого пути свои идентификатор, подтверждение и применение. Это концептуальная карта, а не скрипт. Перед реализацией проверь актуальную справку нужного API и отдельные случаи своей системы. Не соединяй все предложения одним обработчиком завершения окна, который выдаёт эффект независимо от типа.
Согласуй карточку и игровой эффект #
Карточка должна понятно описывать результат и повторяемость. Для набора объясни, что получает одна покупка; для комнаты — какое преимущество доступно владельцу. Одинаковые изображение и заголовок у двух разных типов не заменяют объяснение. Кнопка должна вести к тому предложению, ID которого указан в паспорте.
Цену и сведения о продаже нужно получать и показывать в соответствии с актуальной реализацией Roblox, а не зашивать выдуманные значения из учебной статьи. Здесь цен нет. До реальных продаж проверь соответствие текста, типа и обработчика. Если часть эффекта не реализована, не выдавай её в описании за доступную возможность.
Раздели отсутствие права и ошибку проверки #
Для Pass есть разные исходы: подтверждённое владение, подтверждённое отсутствие владения и ошибка запроса. Ошибка не доказывает, что игрок не владеет Pass. Продумай сообщение о временной невозможности проверки и поведение двери, сохраняя различие между неизвестным результатом и установленным отсутствием права.
Для Developer Product отдельно планируются неизвестный ID, невозможность применения эффекта и ошибка записи. Не подтверждай выдачу, которую система не смогла выполнить и надёжно учесть по своей модели. Эти пункты показывают требования к следующему этапу разработки. Они не являются реализованным протоколом повторов или гарантией сохранности между серверами.
Подготовь матрицу проверок #
В колонке Pass запиши уже владеющего игрока при входе, нового покупателя, отмену и ошибку проверки. В колонке Developer Product — разные покупки одного товара, повтор одной обработки и временную невозможность выдачи. Для каждого случая укажи ожидаемое право или изменение, а фактические результаты заполни только после собственного теста.
Не проводи настоящую оплату только ради проверки этой инструкции. План можно сначала обсуждать и проверять на отдельном прототипе подходящими средствами, а возможность и условия конкретного теста уточнять перед его запуском. Таблица — оригинальная постановка задач; в статье нет реального платежа, выдачи или истории покупок наших игр.
| Вопрос | Что уточнить |
|---|---|
| Можно купить ещё раз? | Уточнить повторяемость механики |
| Что остаётся после покупки? | Определить количество или привилегию |
| Как выдаётся Product? | Отдельно проверенная обработка receipt |
| Как применяется Pass? | Проверка права и серверное применение |
Зафиксируй решение до запуска продаж #
Итог должен отвечать на четыре вопроса: что обещано, можно ли купить снова, какой тип выбран и как подтверждается и применяется эффект. Передай паспорт, матрицу и список незавершённого другому разработчику. Это помогает реализовать правильный путь, а не выбирать тип задним числом по уже нарисованному магазину.
Выбор типа не означает готовность платного магазина. Обработка Developer Product, право по Pass, интерфейс и сохранения требуют своих проверок. Аналитика нажатия не подтверждает выдачу, а посещение страницы сайта не подтверждает покупку в Roblox. В этом гайде оригинальные схемы и проектный план, без запуска продаж или обещания заработка.
| Проверка | Что записать |
|---|---|
| Обещание | Точный эффект и область действия |
| Идентификатор | Тип и соответствующий ID |
| Подтверждение | Право и фактическое применение |
| Повтор | Повторный вход и повтор обработки |
Первоисточники
Roblox Creator Hub — Developer ProductsRoblox Creator Hub — Passes
Roblox Creator Hub — MarketplaceService API
