Entwicklung / ROBLOX

Developer Product oder Pass in Roblox: den Angebotstyp vor dem Shop wählen

Vergleiche wiederholbare Käufe mit einer einmalig gekauften Berechtigung. Beschreibe das Angebot, stimme Karte und Serverwirkung ab und plane unterschiedliche Prüfungen für Developer Products und Passes.

Aktualisiert: 2026-10-08

Mit dem Versprechen an Spieler beginnen #

Schreibe vor der Typwahl genau auf, was der Spieler erhält. VIP, Bonus oder Verbesserung sind zu ungenau: Sie können dauerhaften Zugang, einen Verbrauchsgegenstand oder einen zeitweiligen Effekt meinen. Beschreibe Ergebnis, Geltungsbereich und Verhalten nach Verbrauch oder späterem Beitritt.

Die Übung verwendet zwei erfundene Angebote: ein Paket Trainingsmarken und Zugang zu einem Trainingsraum. Beides sind keine echten bezahlten Angebote unserer Spiele. Für den Artikel wurden weder Passes noch Developer Products erstellt, Preise geändert oder Käufe ausgeführt. Wir planen eine Entscheidung und ihre Prüfung, keinen laufenden Shop.

Wiederholbaren Kauf und Berechtigung unterscheiden #

Ein Developer Product ist für etwas vorgesehen, das ein Spieler mehrmals kaufen kann. Ein Pass stellt den einmaligen Kauf einer Berechtigung dar. Frage zuerst, ob derselbe Spieler das Angebot sinnvoll erneut kaufen kann, und danach, was nach dem vorherigen Kauf verfügbar bleiben soll.

Die Mechanik bestimmt die Antwort. Werden Trainingsmarken verbraucht und soll eine neue bestätigte Bestellung ein weiteres Paket hinzufügen, kommt ein Developer Product infrage. Schaltet das Angebot eine Berechtigung ohne erneuten Kauf frei, kommt ein Pass infrage. Das sind Kandidaten für unser Beispiel, keine allgemeine Monetarisierungsempfehlung oder Ertragsprognose.

Zwei Typen — andere Regeln — Eigene Unterscheidungsskizze, kein laufender Shop oder Kaufhandler.

Eine Angebotsspezifikation ausfüllen #

Notiere verständlichen Namen, Wirkung, Wiederholbarkeit, vorgeschlagenen Typ, zugehörige ID und Anwendungsregel. Solange kein echtes Objekt existiert, bleibt die ID leer. Nutze keine fremde ID oder erfundene funktionsfähige Nummer. Benenne getrennt die Serverlogik für Berechtigung und Zustandsänderung.

Ergänze einen späteren Beitritt. Der Raum braucht die Anwendung des Zugangs für bestehende Passinhaber; die Marken brauchen ein festgelegtes Mengen-, Speicher- und Ausgabemodell. Der Angebotsname löst diese Aufgaben nicht. Die Spezifikation zeigt offene Arbeit, bevor eine attraktive Karte Spielern angeboten wird.

Spezifikation des Angebots — Eigene Angebotskarte. Die echte ID erst nach Erstellung eintragen.

Ein Verbrauchspaket betrachten #

Angenommen, die Trainingsmechanik verbraucht Marken. Ein neu bestätigter Kauf soll das vorgesehene weitere Paket liefern. Unterscheide zwei verschiedene Käufe desselben Developer Product von einer wiederholten Verarbeitung eines Kaufs. Bei Letzterer darf eine bereits erfolgte Ausgabe nicht einfach erneut stattfinden.

Plane beide Fälle getrennt mit erwarteter Mengenänderung und Bestätigungsmethode. Dieser Artikel implementiert weder Receipt-Handler noch gespeicherten Bestand oder Ausgabe. Eine normale Erhöhung nach einem Tastendruck beweist keine fertige Funktion: Wiederholungen, Fehler und spätere Beitritte sind noch ungeprüft.

Zugang über einen Pass betrachten #

Ein Trainingsraum-Pass kann Zugang nach einer einmaligen Anschaffung bedeuten. Das Erstellen implementiert weder Tür noch Serverregel oder Anwendung der Berechtigung. Die Dokumentation beschreibt Eigentumsprüfung und Zuweisung des Vorteils an bereits vorhandene Inhaber beim Beitritt separat.

Plane deshalb sowohl neue Käufer als auch Spieler, die den Pass vor dem aktuellen Beitritt besaßen. Die Serverlogik muss richtigen Spieler und richtigen Pass prüfen; der Zugang muss der Beschreibung entsprechen. Ersetze das konkrete Versprechen nicht durch ein undefiniertes „für immer“. Schreibe auf, welches Recht dieses Projekt gewährt und wo es gilt.

Bestätigungspfade getrennt halten #

Developer Products werden über ProcessReceipt verarbeitet. PromptProductPurchaseFinished bestätigt keinen erfolgreichen Kauf und darf die Ausgabeverarbeitung nicht ersetzen. Passes besitzen eigene Eigentumsprüfungen und Ereignisse; ähnlich aussehende Tasten machen die Regeln nicht austauschbar.

Die Zeichnung trennt beide Pfade nach der Typwahl. Jeder hat eigene Kennung, Bestätigung und Anwendung. Das ist eine konzeptionelle Karte, kein Skript. Prüfe vor der Umsetzung die aktuelle API-Dokumentation und deine Fälle. Verwende keinen allgemeinen Fenster-beendet-Handler, der unabhängig vom Typ eine Wirkung vergibt.

Karte und Spielwirkung abstimmen #

Die Karte erklärt Ergebnis und Wiederholbarkeit. Bei einem Paket ist der Inhalt eines Kaufs wichtig, beim Raum die Berechtigung des Inhabers. Gleiche Bilder und Überschriften für zwei Typen ersetzen diese Erklärung nicht. Die Taste muss auf die Angebots-ID aus der Spezifikation verweisen.

Preis- und Verkaufsinformationen werden nach der aktuellen Roblox-Umsetzung geladen und dargestellt, nicht durch erfundene Tutorialwerte ersetzt. Hier stehen keine Preise. Prüfe vor echten Verkäufen Beschreibung, Typ und Handler zusammen. Noch nicht umgesetzte Wirkungen dürfen nicht als verfügbare Funktion beworben werden.

Fehlendes Eigentum und Prüffehler trennen #

Beim Pass sind bestätigtes Eigentum, bestätigtes Nichteigentum und eine fehlgeschlagene Anfrage verschiedene Ergebnisse. Ein Prüffehler beweist nicht, dass der Spieler keinen Pass besitzt. Plane eine Meldung für vorübergehend nicht mögliche Prüfung und das Türverhalten, ohne unbekanntes Ergebnis mit fehlender Berechtigung gleichzusetzen.

Für Developer Products sind unbekannte ID, nicht ausführbare Wirkung und fehlgeschlagene Aufzeichnung getrennte Fälle. Bestätige keine Ausgabe, die das System nicht ausführen und nach seinem Modell zuverlässig erfassen konnte. Das sind Anforderungen an die Umsetzung, kein fertiges Wiederholungsprotokoll und keine Garantie gegen Fehler zwischen Servern.

Eine Prüfmatrix vorbereiten #

Für Passes gehören bestehender Inhaber beim Beitritt, neuer Käufer, Abbruch und Eigentumsprüffehler in die Liste. Für Developer Products gehören verschiedene Käufe desselben Angebots, wiederholte Verarbeitung eines Kaufs und vorübergehend unmögliche Ausgabe hinein. Notiere erwartetes Recht oder Änderung; echte Beobachtungen erst nach einem eigenen Versuch.

Führe nicht allein zum Befolgen dieses Artikels eine echte Zahlung aus. Besprich und prüfe den Plan zunächst in einem getrennten Prototyp und kläre verfügbare Mittel und Bedingungen eines konkreten Tests. Die Tabelle ist eine eigene Aufgabenstellung. Sie enthält keine echte Zahlung, Ausgabe oder Kaufhistorie unserer Spiele.

Frage	Klären
Erneuter Kauf möglich?	Wiederholbarkeit der Mechanik bestimmen
Was bleibt nach dem Kauf?	Menge oder Berechtigung festlegen
Wie wird Product ausgegeben?	Getrennt geprüfte Receipt-Verarbeitung
Wie wird Pass angewendet?	Eigentumsprüfung und Serveranwendung

Die Entscheidung vor dem Verkauf festhalten #

Das Ergebnis beantwortet vier Fragen: Was ist versprochen? Kann es erneut gekauft werden? Welcher Typ wurde gewählt? Wie wird die Wirkung bestätigt und angewendet? Übergebe Spezifikation, Matrix und offene Aufgaben an einen anderen Entwickler. So folgt die Umsetzung dem Angebot und nicht umgekehrt einer fertigen Shopzeichnung.

Die Typwahl macht keinen bezahlten Shop betriebsbereit. Product-Verarbeitung, Passrecht, Oberfläche und Speicherung benötigen eigene Prüfungen. Ein Klick bestätigt keine Ausgabe und ein Websitebesuch keinen Roblox-Kauf. Diese Anleitung enthält eigene Zeichnungen und einen Entwurf, ohne Verkaufsstart oder Einkommensversprechen.

Prüfung	Festhalten
Versprechen	Genaue Wirkung und Geltungsbereich
Kennung	Typ und passende ID
Bestätigung	Recht und tatsächliche Anwendung
Wiederholung	Späterer Beitritt und erneute Verarbeitung

Originalquellen

Roblox Creator Hub — Developer Products
Roblox Creator Hub — Passes
Roblox Creator Hub — MarketplaceService API