Ladebildschirm in Roblox: wichtige Ressourcen auswählen und Bereitschaft ehrlich erklären

Lege die erste Handlung des Spielers fest #

Beginne mit einer konkreten Handlung: Der Spieler liest den Namen einer Trainingsroute, sieht deren Startknopf und versteht, wohin dieser führt. Notiere die Bilder und Klänge, die genau dafür nötig sind. Eine umfangreiche Haustiersammlung im entfernten Laden gehört noch nicht zu diesem ersten Bildschirm. Mit einer gezielten Liste kannst du den Zweck jeder Ressource erklären, statt die ganze Experience zur Voraussetzung einer dekorativen Ladeanzeige zu machen.

Unser erfundenes Menü verwendet eine Illustration, ein Knopfsymbol und einen kurzen Klang. Die Namen illustration, start-icon und first-sound sind Lehrkennungen und keine veröffentlichten Roblox-Asset-IDs. Wir verbinden keine fremden Grafiken und präsentieren die Übung nicht als Prüfung unserer fünf Spiele. Ziel ist eine ehrliche Verwaltung ausgewählter Ergebnisse, bevor echte Downloads und eine Benutzeroberfläche damit verbunden werden. Die erfundene Situation liefert einen überschaubaren Prüfgegenstand.

Trenne Inhaltsladen und Spielbereitschaft #

ContentProvider bietet PreloadAsync zum Vorladen von Inhalten. Die Referenz kennzeichnet die Methode als unterbrechend für den aufrufenden Ausführungsstrang; ihre Callback-Beispiele melden eine Inhaltskennung und AssetFetchStatus. Diese Angaben betreffen Inhalte. Sie bestätigen nicht automatisch gelesene Speicherstände, erstellte Charaktere, erreichbare Server oder alle Weltobjekte. Für diese Aufgaben benötigt der Spielstart jeweils eigene Nachweise, statt eine universelle Bereitschaftsmarkierung aus einer einzigen Quelle abzuleiten.

Schreibe getrennt auf, was das Menü von den ausgewählten Bildern erwartet und was vor dem Start der Trainingsroute geschehen muss. Ein verfügbares Symbol bei noch fehlendem Charakter beweist kein vollständig geladenes Spiel. Ist nur die Ergebnisverwaltung einer Liste abgeschlossen, beschreibe diese Liste. Unsere Übung verwendet eine sprachliche Regel: Die sichtbare Meldung soll genau das Ergebnis nennen, das dein System tatsächlich prüfen kann, einschließlich noch offener anderer Aufgaben.

Mache aus der Anfragewarteschlange keinen Prozentsatz #

RequestQueueSize wirkt wie eine praktische Zahl für eine Fortschrittsanzeige. Das offizielle Leistungs-Handbuch warnt jedoch vor Schwankungen der Warteschlange. Sie ist kein fester Nenner deiner Aufgabe. Neue Anfragen können ihren Umfang während der Beobachtung verändern. Eine schrumpfende Warteschlange beschreibt deshalb nicht automatisch einen genauen Prozentwert der Menübereitschaft und beweist auch nicht zuverlässig, dass sämtliche benötigten Ressourcen vollständig geladen wurden.

Wähle für die Übung eine eigene unveränderliche Liste aus drei unterschiedlichen Kennungen. Ihre Größe bleibt vor und nach Ergebnismeldungen drei. Eine wichtige Voraussetzung ist die eindeutige Zuordnung zwischen Listeneintrag und gezähltem Ergebnis. Beliebige Objekte zu zählen und danach jeden Callback als ein Objekt zu behandeln, erzeugt ohne diese Prüfung keinen gültigen Prozentsatz für eine ganze Szene. Der Nenner muss zur tatsächlichen Prüfeinheit passen.

Erstelle eine kleine Liste notwendiger Ressourcen #

Das Leistungs-Handbuch empfiehlt gezieltes Vorladen, beispielsweise von Bildern des Ladebildschirms, wichtigen Menügrafiken und Ressourcen des Startbereichs. Das gesamte Workspace vorzuladen wird wegen längerer Wartezeiten als ungünstige Praxis beschrieben. Ordne jedem gewählten Eintrag einen Zweck zu: Warum brauchst du ihn jetzt, was sieht der Spieler ohne ihn, und welches Verhalten ist bei Nichtverfügbarkeit zulässig? Das hilft mehr als ein Verzeichnis aller später denkbaren Inhalte.

Im erfundenen Menü kann Text die Illustration ersetzen, der Knopf soll eine lesbare Beschriftung behalten, und fehlender Klang darf seine Bedeutung nicht verschleiern. Das sind Entscheidungen dieses Prototyps, die noch mit Spielern geprüft werden müssen. Sie bedeuten nicht, dass jede Ressource jeder Experience entbehrlich ist. Ist ein Modell für den sicheren Levelstart notwendig, gehört dessen Bereitschaft zu einer gesonderten Startbedingung, die ein dekorativer Bildschirm nicht ersetzen kann.

Bild in voller Größe öffnen ↗

Führe unterschiedliche Ergebniszähler #

Das eigene Beispiel in reinem Luau speichert total, resolved, succeeded und failed. Der erste Wert bezeichnet die Listengröße, der zweite erhaltene Ergebnisse; die beiden anderen trennen Erfolge und Fehler. Die Funktion record nimmt eine Lehrkennung und einen booleschen Wert an. Sie ruft keine Roblox-API auf, lädt keine Datei und übernimmt Enum.AssetFetchStatus nicht unmittelbar. Ein echter Adapter muss ein geprüftes Ladeergebnis gesondert in den benötigten Zustand übersetzen.

Das Beispiel ist ein überprüfbares Verwaltungsmodell. Nach einem Fehler und zwei Erfolgen lauten die Werte resolved=3, succeeded=2 und failed=1. settled bedeutet, dass für alle Listeneinträge ein Ergebnis vorliegt; allSucceeded bleibt hier false. Fasse beide Prüfungen nicht mit einem Wort wie bereit zusammen. Ergebnisse für drei Versuche zu erhalten und drei Ressourcen erfolgreich zu beschaffen sind unterschiedliche Leistungen, selbst wenn die Anzahl bearbeiteter Einträge gleich ist.

-- Pure Luau bookkeeping, not a ContentProvider adapter.
-- Each manifest entry represents exactly one distinct content identifier.
local function newTracker(ids)
    assert(type(ids) == "table", "Manifest must be a table")
    local expected = {}
    local total = 0
    for _, id in ipairs(ids) do
        assert(type(id) == "string" and id ~= "", "Invalid content identifier")
        assert(not expected[id], "Duplicate content identifier")
        expected[id] = true
        total += 1
    end
    local entries = 0
    for index in pairs(ids) do
        assert(type(index) == "number" and index >= 1 and index % 1 == 0,
            "Manifest must use consecutive array indices")
        entries += 1
    end
    assert(entries == total, "Manifest cannot contain array gaps")
    local outcomes = {}
    local resolved = 0
    local succeeded = 0
    local failed = 0
    local tracker = {}

    function tracker.record(id, success)
        assert(type(success) == "boolean", "Outcome must be boolean")
        if not expected[id] or outcomes[id] ~= nil then
            return false
        end
        outcomes[id] = success
        resolved += 1
        if success then
            succeeded += 1
        else
            failed += 1
        end
        return true
    end

    function tracker.snapshot()
        return {
            total = total,
            resolved = resolved,
            succeeded = succeeded,
            failed = failed,
            settled = resolved == total,
            allSucceeded = resolved == total and failed == 0,
        }
    end

    return tracker
end

return newTracker

Verhindere Änderungen durch wiederholte Ergebnisse #

Erhält der Handler erneut ein Ergebnis für start-icon, dürfen die Zähler nicht ein zweites Mal steigen. Insbesondere soll ein versehentlich wiederholter Erfolg keinen bereits erfassten Fehler überschreiben. Unser Modell akzeptiert nur das erste Ergebnis einer bekannten Kennung und ignoriert fremde Meldungen. Das ist die Regel eines einzelnen Lehrversuchs. Ein absichtlicher neuer Download benötigt einen weiteren Versuch und eine ausdrücklich gewählte Richtlinie zur Aktualisierung des Zustands.

Prüfe die Liste vor Beginn: Kennungen müssen eindeutige, nicht leere Zeichenfolgen sein, und die Tabelle muss ein fortlaufendes Array ohne Lücken bilden. Sonst kann ipairs früher als erwartet stoppen und einen falschen Nenner liefern. Jeder zurückgegebene snapshot ist eine neue Tabelle; Änderungen ihrer Felder ändern das interne Modell nicht. Diese Grenzen werden unabhängig geprüft. Ihr Bestehen sagt nichts über die Netzverbindung oder das Verhalten der Roblox-Engine aus.

Bild in voller Größe öffnen ↗

Erkläre Fehler mit einer verständlichen Meldung #

Trenne Fortschritts- und Ergebnismeldung. Bearbeitet: 2 von 3 ausgewählten Ressourcen beschreibt die Verwaltung; eine Ressource wurde nicht beschafft beschreibt einen Ausgang. Schreibe nicht alles geladen, wenn failed größer als null ist. Erfinde ohne Messung keine genaue Restdauer. Ein verständlicher nächster Schritt hilft mehr als ein gleichmäßig laufender Balken, der den unbekannten Teil des Zustands verbirgt und damit eine falsche Sicherheit vermittelt.

Für das erfundene Menü schlagen wir eine lesbare Ersatzbeschriftung für ein fehlendes Bild und einen eigenen Hinweis auf fehlenden Klang vor. Die Prototypprüfung muss feststellen, ob Richtung und Startaktion verständlich bleiben. Wichtige Spielobjekte brauchen eine andere Reaktion: Beschreibe die Einschränkung und biete einen zulässigen Ausgang oder neuen Versuch an. Versprich keinen sicheren Erfolg. Ein Ressourcenfehler kann eine Prüfung von Kennung und Zugriff verlangen, statt endlos gleicher Anfragen.

Fortsetzen darf keinen Abbruch des Downloads vortäuschen #

Das offizielle Handbuch empfiehlt bei vielen zu ladenden Ressourcen eine Möglichkeit zum Überspringen des Wartens. Lege fest, was der Knopf in deinem Prototyp bedeutet: einen dekorativen Bildschirm schließen und mit einem Ersatz fortfahren oder ein eingeschränktes Menü öffnen. Seine Beschriftung muss zur Handlung passen. Aus der Empfehlung folgt nicht, dass ein Klick automatisch einen laufenden PreloadAsync-Aufruf abbricht oder die betroffenen Ressourcen erfolgreich geladen macht.

Kommt ein Ergebnis nach dem Schließen der Anzeige an, soll der Handler seinen Zustand korrekt aktualisieren, ohne den Spieler zur Ladeanzeige zurückzuziehen. Die Verbindung einer konkreten GUI mit dem Ladelebenszyklus braucht eine eigene Prüfung. Unser reines Modell erstellt keine GUI und implementiert keinen Überspringknopf. Es zeigt Entscheidungsdaten, aber ist kein fertiges System für Abbruch, erneute Versuche oder Bildschirmwechsel in beliebigen Spielen und Geräten.

Prüfe Verwaltung und Integration getrennt #

Prüfe zuerst das Modell mit künstlichen Ereignissen: unbekannte Kennung, Wiederholung, Fehler, zwei anders geordnete Erfolge und eine noch offene Liste. Genaue Zähler und das Ausbleiben eines falschen allSucceeded sind entscheidend. Die eigenständigen Prüfungen laufen ohne Netzverbindung. Sie belegen nur die Logik des gewählten Beispiels. Prüfnamen und Ergebnisberichte müssen diese Grenze erhalten, damit ein Tabellentest nicht als Prüfung eines tatsächlichen Roblox-Laders erscheint.

Danach sind in einem eigenen Lehrprojekt erlaubte Ressourcen, beobachtete echte Statusmeldungen und Menüprüfungen auf vorgesehenen Geräten nötig. Notiere Kennungen, Umgebung, jeden Ausgang und die Verfügbarkeit einer normalen Handlung. Prüfe Nichtverfügbarkeit und eine geschlossene Anzeige gesondert. Diese Integration wurde für den Artikel noch nicht durchgeführt. Ladezeit, Speicheränderungen und Einfluss auf Spielerbindung wurden nicht gemessen und lassen sich aus den Verwaltungsprüfungen allein nicht ableiten.

Bewahre ein nachvollziehbares Ergebnis auf #

Ein nützliches Ergebnis enthält die kleine Ressourcenliste, die Gründe ihrer Auswahl, den Unterschied zwischen resolved und succeeded, das Verhalten bei failed und die Grenze der Bildschirmbereitschaft. Die Aufzeichnung von zwei Erfolgen und einem Fehler muss den Fehler ausdrücklich erhalten. Bei einer leeren Liste teilt das Modell nicht durch null: Es meldet einen abgeschlossenen Zustand ohne Ressourcen. Beschreibe diesen Fall in Worten, statt einen undefinierten Prozentsatz anzuzeigen.

Bevor du die Idee in ein echtes Spiel überträgst, gib einem anderen Entwickler den Code, die eigenständigen Prüfungen und die Liste ungeprüfter Bedingungen. Lade nicht die ganze Welt vor, nur um schöne 100% zu zeigen. Der erste Bildschirm soll die gewünschte Handlung verständlich machen und seinen Zustand ehrlich erklären. Artikel und Lehrmodell sind eigene Inhalte; prüfe aktuelle API-Angaben in den offiziellen Quellen und miss die Ergebnisse des konkreten Spiels gesondert.