Entwicklung / ROBLOX
Ein Roblox-Abzeichen für einen Erfolg: Bedingung und Serverprüfung
Planen Sie ein Abzeichen für eine Übungsstrecke: genaue Bedingung, zugehöriges Spiel, Serververgabe und Eigentumsprüfung. Trennen Sie Oberflächenmeldung, API-Ausführung und bestätigtes Ergebnis.
Zuerst den Erfolg beschreiben #
Wählen Sie ein kleines Ziel, das ein Satz erklärt: die Übungsstrecke absolvieren und ihr Ziel erreichen. Notieren Sie Pflichtabschnitte und den Serverzustand, der den Abschluss bestätigt. Das Abzeichen soll diesen Erfolg darstellen, nicht die Berührung irgendeines ähnlich aussehenden Teils.
Unser Beispiel plant ein getrenntes Übungsprojekt. Es wurde kein Abzeichen erstellt, keine ID ermittelt und keine Auszeichnung vergeben; der Code Ihrer Spiele blieb unverändert. Der Artikel bereitet eine Implementierung vor und ist kein bereits getestetes BadgeService-Skript.
Name, Beschreibung und Bedingung abstimmen #
Der Name beschreibt das Ergebnis, die Beschreibung erklärt den Erwerb. Vergleichen Sie beide mit der Streckenregel. Ist die gesamte Strecke nötig, schreiben Sie nicht, dass ein Beitritt genügt. Klären Sie eine undefinierte Mechanik vor der Erstellung ihrer Erfolgskarte.
Halten Sie weitere Wirkungen separat fest. Münzen, Gegenstände oder neue Bereiche entstehen nicht durch den Namen eines Abzeichens; sie benötigen eigene Implementierungen. Unser Plan betrifft nur das Abschlussabzeichen, keine Robux, Avatar-Gegenstände oder zusätzlichen Privilegien.
Das Objekt ohne unbeabsichtigte Kosten vorbereiten #
Die Abzeichenwerkzeuge im Creator Dashboard gehören zum ausgewählten Spiel. Die Dokumentation beschreibt Erstellung über dessen Menü und Verwaltung unter Engagement → Badges. Prüfen Sie vor jeder Erstellung Spiel und aktuelle Quote: Zusätzliche Abzeichen können Robux kosten.
Für den Artikel braucht es kein echtes Objekt. Füllen Sie eine Spezifikation mit leerem badgeId-Feld und Ziel aus. Nutzen Sie keine fremde ID oder erfundene funktionierende Nummer. Wird später in einer eigenen Aufgabe ein Objekt erstellt, vergleichen Sie Seite, ID und Spiel mit der Spezifikation.
Symbol und Verfügbarkeit prüfen #
Die Dokumentation empfiehlt ein Ausgangsbild mit 512×512 Pixeln und berücksichtigt kreisförmigen Zuschnitt. In unserem Plan bleibt das wichtige Symbol im Kreis, der lange Name außerhalb der Grafik. Prüfen Sie die Erkennbarkeit bei kleiner Darstellung, nicht nur im Vollbild.
Ein Abzeichen besitzt einen Aktivierungszustand. Deaktivierte Abzeichen erscheinen nicht im Abzeichenbereich der Spielseite und sind nicht erwerbbar. Eine Grafik erstellen und ein Abzeichen anlegen sind verschiedene Aufgaben. Ein schönes Symbol bestätigt weder Verfügbarkeit noch Serverbedingung.
Das Ziel mit Serverlogik verbinden #
Die Dokumentation beschreibt die Vergabe durch AwardBadgeAsync aus einem Server-Script. Vor dem Aufruf muss unsere zukünftige Logik bestimmen, ob dieser Spieler diese Strecke abgeschlossen hat. Eine Clientmeldung „fertig“ oder Animation ersetzt keine Prüfung des Spielzustands.
Notieren Sie Speicherort des Fortschritts und Erkennung des gültigen Ziels. Listen Sie Ablehnungsfälle auf: Pflichtstart fehlt, Ziel gehört zu einer anderen Strecke oder Erfolg ist bereits bestätigt. Das sind vorgeschlagene Anforderungen, keine Ergebnisse ausgeführter Tests.
Bild in voller Größe öffnen ↗Informationen, Vergabe und Eigentum trennen #
GetBadgeInfoAsync liefert Abzeicheninformationen einschließlich IsEnabled. AwardBadgeAsync vergibt ein Abzeichen, UserHasBadgeAsync prüft dessen Eigentum. Die Aufrufe beantworten verschiedene Fragen und dürfen nicht zu einer einzigen Beobachtung „funktioniert“ zusammenfallen.
Erfassen Sie getrennt: richtiges Abzeichen gewählt, Verfügbarkeit geprüft, Bedingung erfüllt, Vergabeaufruf beendet und Eigentum geprüft. Testkonto und badgeId gehören in einen privaten Prüfbericht. Der öffentliche Artikel braucht keine echten Spielerdaten.
Mehr als geschützten Aufruferfolg prüfen #
Die API nennt boolean als Ergebnis für AwardBadgeAsync und UserHasBadgeAsync. Ein geschützter Aufruf liefert getrennt den Ausnahmestatus und den Rückgabewert der inneren Funktion. Fehlerfreiheit darf deshalb nicht automatisch als erfolgreiche Vergabe bezeichnet werden.
Ein Fehler bei der Eigentumsprüfung lässt das Ergebnis unbekannt, statt Abwesenheit zu beweisen. Unser vorgeschlagenes Protokoll bewahrt beide Ergebnisebenen und die folgende Entscheidung. Zeigen Sie nicht sicher „erhalten“, wenn nur Funktionsaufruf oder Tastendruck beobachtet wurden.
Wiederholung und fehlende Voraussetzungen prüfen #
Der Plan enthält erneute Zielberührung, bereits besessenes Abzeichen, deaktiviertes Objekt, falsche ID und fehlgeschlagene Informationsabfrage. Definieren Sie bekanntes Wissen und ehrliche Oberflächenmeldung je Fall. Verwandeln Sie nicht jeden Fehler in eine neue Vergabe.
Betrachten Sie einen späteren Beitritt separat. Abzeicheneigentum und Streckenfortschritt sind verschiedene Zustände; eines bestätigt nicht das ganze Profil. Benötigt die Mechanik einen zusätzlichen Vorteil, prüfen Sie Anwendung und Speicherung in einem eigenen Szenario.
Begrenzten Test und Beobachtungen planen #
Nutzen Sie ein getrenntes Übungsprojekt und ein festgelegtes Ziel. Prüfen Sie Verhalten vor dem Ziel, korrekten Abschluss und Wiederholung. Die folgende Tabelle stellt erwartete Fragen, keinen Bericht einer echten Vergabe. Testen Sie keine fremden Spiele oder Konten.
Notieren Sie Schritt, Ausgangszustand, API-Ergebnis und Eigentumsergebnis. Wiederholen Sie nach einer Änderung den problematischen Fall. Simulierter Aufruf, gedankliches Diagramm und tatsächliche Studio-Prüfung liefern unterschiedliche Nachweise; kennzeichnen Sie die Ebene ausdrücklich.
| Szenario | Prüfen |
|---|---|
| Vor dem Ziel | Bedingung noch unbestätigt? |
| Gültiges Ziel | Was bestätigt den Abschluss? |
| Wiederholung | Eigentum und erneutes Signal getrennt? |
| API-Fehler | Unbekannt nicht als Erfolg bezeichnet? |
Spezifikation weitergeben #
Die Spezifikation enthält Ziel, Beschreibung, ausgewähltes Spiel, zukünftige badgeId, Verfügbarkeit, Serverbedingung und Prüfmatrix. Listen Sie fehlende Implementierung und notwendige Beobachtungen vor dem Start separat auf. So versteht der nächste Chat die Aufgabe.
Ein fertiger Übungserfolg beweist nicht die Richtigkeit aller Spielbelohnungen. Hier wurden weder Erstellung noch Zahlung oder Vergabe ausgeführt. Das Ergebnis ist eine prüfbare Regel mit Nachweisplan für spätere Implementierung in einer vereinbarten Umgebung.
Bild in voller Größe öffnen ↗| Feld | Festhalten |
|---|---|
| Ziel | Genaue Handlung der Beschreibung |
| Objekt | Richtiges Spiel, ID und Verfügbarkeit |
| Logik | Serverbedingung und Wiederholung |
| Nachweis | Testart und beobachtetes Ergebnis |
Originalquellen
Roblox Creator Hub — BadgesRoblox Creator Hub — BadgeService API
