Kontrollpunkte in Roblox Studio: ein eigener Übungs-Obby

Die kleine Mechanik zuerst festlegen #

Baue einen kurzen Übungsweg mit Start, Checkpoint1 und Checkpoint2. Ein Spieler erreicht die Punkte der Reihe nach. Nach akzeptiertem Kontakt mit dem nächsten Punkt soll sein Charakter nach dem Tod dort wieder erscheinen. Der Rückweg zu einer früheren Plattform darf den Fortschritt nicht reduzieren. Ein zweiter Spieler besitzt einen eigenen Stand und einen eigenen Wiedereinstieg. Mit dieser Regel kannst du Erwartung und Beobachtung vergleichen.

Das ist ein neuer Übungsprototyp, keine Umsetzung aus Stone Trail oder einem anderen Spiel des Seitenautors. Der folgende Code wurde für diesen Unterricht geschrieben und logisch geprüft, hier jedoch nicht in der Roblox-Engine ausgeführt. Der Fortschritt existiert nur im Speicher des aktuellen Servers. Besuche übergreifendes Speichern, Belohnungen und vollständiger Schutz gegen Abkürzungen gehören nicht dazu. Prüfe zuerst diese begrenzte Mechanik und erweitere sie danach.

1. Eine eigene Szene mit genauen Namen vorbereiten #

Speichere ein neues kleines Projekt, damit die Übung kein bestehendes Spiel verändert. In Workspace brauchst du einen SpawnLocation namens Start und einen Folder namens Checkpoints. Erstelle darin zwei SpawnLocations: Checkpoint1 und Checkpoint2. Füge in ServerScriptService einen gewöhnlichen Script namens CheckpointServer hinzu. Die Pfade lauten Workspace.Start, Workspace.Checkpoints.Checkpoint1, Workspace.Checkpoints.Checkpoint2 und ServerScriptService.CheckpointServer. Checkpoint 1 mit Leerzeichen ist ein anderer Name.

Andere Wegflächen können normale verankerte Parts sein. Kontrollpunkte müssen tatsächlich SpawnLocations sein, nicht nur ähnlich gefärbte Parts. Entferne zusätzliche, unbenötigte Spawnpunkte aus dieser neuen Übungsszene. Ein Paket unbekannter Modellskripte ist unnötig: eigene Plattformen und eine Serverdatei reichen. Prüfe vor dem Code, dass alle drei Punkte sichtbar sind und nicht übereinanderliegen. Ein übersichtlicher Aufbau erleichtert später die Zuordnung von Kontakt und Ergebnis.

2. Kontakt und freien Platz zum Erscheinen einrichten #

Ordne Start, dann Checkpoint1 und dann Checkpoint2 auf einem kurzen sicheren Weg an. Zwischen ihnen muss genug Abstand für einzelne Kontakte liegen. Lass über jedem SpawnLocation Platz, damit der Charakter weder in einer Wand noch unter einer niedrigen Decke oder an einer Absturzkante erscheint. Farbe und Beschriftung unterscheiden die Plattformen, setzen aber keinen Fortschritt. Schwierige Fallen sind beim ersten Mechaniktest nicht nötig.

Die Tabelle beschreibt die Konfiguration dieser Übung. Der Script setzt die erforderlichen Werte beim Start erneut. Alle Punkte ermöglichen teamunabhängiges Erscheinen; Teamwechsel durch Kontakt ist ausgeschaltet. CanTouch erlaubt Kontaktereignisse, Anchored hält die Plattform fest. Neue Teams oder collision groups erfordern eine erneute Prüfung von Berechtigung und Kontakt. Lass vorerst das normale automatische Laden der Charaktere eingeschaltet. Eigenes Laden gehört nicht zu diesem Beispiel.

3. Den vollständigen Script auf dem Server einsetzen #

Öffne CheckpointServer in ServerScriptService und ersetze den Inhalt durch das vollständige Beispiel unten. Übernimm Einrichtung und Initialisierung ebenso wie den Touched-Handler. Die Tabelle checkpoints definiert eine feste Reihenfolge; sie verlässt sich nicht auf die Reihenfolge von GetChildren. configure prüft Objektklassen und setzt Eigenschaften. WaitForChild wartet auf fehlende Namen, assert meldet die falsche Klasse. Korrigiere zuerst die Hierarchie, dann prüfe den Weg.

Der Server weist Player.RespawnLocation zu und verwaltet progress mit Player als Schlüssel. Ein LocalScript in StarterPlayerScripts ersetzt diesen Aufbau nicht. Vermeide einen zweiten Script, der gleichzeitig RespawnLocation verändert. Beginne nach dem Aufbau eine neue Testsitzung. Code in einen bereits laufenden Test einzufügen bewegt einen lebenden Charakter nicht sofort zu Start: Die Zuweisung legt einen künftigen Wiedereinstieg fest und ist kein Teleportbefehl.

local Players = game:GetService("Players")
local start = workspace:WaitForChild("Start")
local folder = workspace:WaitForChild("Checkpoints")
local checkpoints = {
    folder:WaitForChild("Checkpoint1"),
    folder:WaitForChild("Checkpoint2"),
}
local progress = {}

local function configure(spawn)
    assert(spawn:IsA("SpawnLocation"), "Expected SpawnLocation")
    spawn.Anchored = true
    spawn.CanCollide = true
    spawn.CanTouch = true
    spawn.Enabled = true
    spawn.Neutral = true
    spawn.AllowTeamChangeOnTouch = false
end

configure(start)
for _, checkpoint in ipairs(checkpoints) do
    configure(checkpoint)
end

local function initialize(player)
    if progress[player] ~= nil then return end
    progress[player] = 0
    player.RespawnLocation = start
end

Players.PlayerAdded:Connect(initialize)
Players.PlayerRemoving:Connect(function(player)
    progress[player] = nil
end)
for _, player in ipairs(Players:GetPlayers()) do
    initialize(player)
end

for index, checkpoint in ipairs(checkpoints) do
    checkpoint.Touched:Connect(function(hit)
        local character = hit:FindFirstAncestorOfClass("Model")
        if not character then return end
        local player = Players:GetPlayerFromCharacter(character)
        if not player or player.Character ~= character then return end
        local humanoid = character:FindFirstChildOfClass("Humanoid")
        if not humanoid or humanoid.Health <= 0 then return end
        local current = progress[player]
        if current == nil or index ~= current + 1 then return end
        player.RespawnLocation = checkpoint
        progress[player] = index
    end)
end

4. Den Spieler hinter der berührenden Detailfläche finden #

Touched liefert die andere Detailfläche. Sie kann zu einem Charakter, einem fallenden Würfel oder einem Gegenstand gehören. Der Handler findet das nächste Model, prüft GetPlayerFromCharacter, vergleicht player.Character und sucht einen Humanoid mit positivem Health. Ohne diese Bedingungen könnten Gegenstände oder tote Charaktere Fortschritt verändern. Ein ungeeigneter Kontakt endet mit return, bevor ein neuer Wiedereinstieg gesetzt wird.

Das Beispiel setzt einen normalen Charakter mit Humanoid in seinem Model voraus. Ein ungewöhnlich verschachtelter rig benötigt eine bewusst angepasste Modellsuche; entferne die Spielerprüfung nicht nur, um einen Fehler zu verdecken. Ein serverseitig beobachteter Kontakt beweist keine ehrliche vollständige Route. Bewegung und Physik brauchen eine eigene Sicherheitsbetrachtung. Wir prüfen hier persönliche Kontrollpunkte auf einem gewöhnlichen kurzen Übungsweg, kein fertiges Anti-Cheat-System.

5. Reihenfolge ohne gemeinsamen Blockierer sichern #

Ein neuer Spieler startet mit progress 0. Akzeptiert wird nur current + 1: zuerst Index 1, dann 2. Weitere Kontakte mit dem ersten Punkt durch Füße oder andere Körperteile passen nach der Bestätigung nicht mehr zum nächsten Index. Nach Punkt 2 wird Punkt 1 ebenfalls abgelehnt. Die Regel verhindert Rückschritt und Überspringen. Ein frei wählbarer Weg bräuchte einen anderen Vertrag.

Es gibt keinen gemeinsamen debounce, der nach einem Kontakt alle Spieler blockiert. Jeder Player ist ein eigener Tabellenschlüssel. Prüfung und beide Zuweisungen enthalten kein task.wait oder anderes Warten. Spieler können unabhängig vorankommen. Das ist eine logische Betrachtung des kurzen Handlers, keine Zusage für spätere asynchrone Erweiterungen. Wenn Belohnungen, Datenabfragen oder Verzögerungen hinzukommen, prüfe Wiederholungen und den Zeitpunkt der Zustandsänderung neu.

6. Tod, neuer Test und erneuter Beitritt unterscheiden #

Ein akzeptierter Kontakt verändert RespawnLocation dieses Players. Der lebende Charakter bleibt stehen; die Zuweisung wird beim nächsten normalen Erscheinen überprüft. Nach dem Tod entsteht ein neues Charakter-Model, der Player bleibt aber in der Sitzung und behält seinen progress-Eintrag. Setze progress nicht in CharacterAdded zurück, sonst würde jeder Tod den Kontrollpunkt löschen.

Beim Verlassen entfernt PlayerRemoving den Speichereintrag. Ein erneuter Beitritt beginnt mit 0 und Start. Stop mit einem neuen Studio-Test erzeugt ebenfalls eine neue Sitzung. Das Beispiel enthält keine vollständige Zurücksetzen-Taste innerhalb des Spiels. Falls du sie später baust, muss sie Index und RespawnLocation zurücksetzen; eine geänderte Beschriftung reicht nicht. Das Speichern des Projekts speichert Szene und Code, nicht die laufende Spielertabelle.

Bild in voller Größe öffnen ↗

7. Den Einzeltest Schritt für Schritt ausführen #

Wähle Test im Studio-Testmenü und starte. Dieser Modus fügt einen Charakter ein; Run simuliert ohne Avatar und passt nicht zur ersten Prüfung durch Gehen. Beginne eine neue Sitzung und überprüfe Start. Gehe normal auf Checkpoint1, halte dort an und lasse den Charakter an einem getrennt geplanten Absturzbereich des Prototyps sterben. Warte auf das normale erneute Erscheinen und notiere den Ort.

Wiederhole den Versuch an Checkpoint2. Kehre danach körperlich zu Punkt 1 zurück und prüfe einen weiteren Tod: Punkt 2 soll ausgewählt bleiben. Verwechsle dies nicht mit Stop und neuem Test, denn dabei wird der Speicher absichtlich geleert. Notiere tatsächliches Ergebnis und Vorhersage getrennt. Falls der Absturzbereich keinen Tod auslöst, ist noch kein RespawnLocation-Test fehlgeschlagen. Bestätige zuerst Tod und neuen Charakter.

8. Gegenstand, Überspringen und Wiederholung prüfen #

Berühre in einem eigenen Versuch Checkpoint2 vor Checkpoint1. Die Reihenfolge soll Start beibehalten. Erreiche anschließend beide Punkte regulär. Für den Gegenstandstest erstellst du einen normalen unverankerten Würfel und lässt ihn physisch auf eine Kontrollfläche fallen. Er entspricht keinem Player und darf niemandes Fortschritt verändern. Vergleiche Serverzustand oder das spätere Erscheinen des betreffenden Spielers, nicht nur die Farbe.

Touched hängt von physischer Bewegung ab. Zwei verankerte Objekte durch CFrame übereinanderzusetzen ist kein gleichwertiger Ereignistest. Fehlt Kontakt, prüfe CanTouch beider Objekte und collision groups. Schreibe nicht erfunden „Würfel abgelehnt“, bevor du es ausprobiert hast. Die spätere Tabelle zeigt erwartete Ergebnisse, keinen Bericht eines bereits ausgeführten Engine-Tests. Trenne diese Begriffe auch in deinen eigenen Prüfnotizen.

9. Zwei Spieler mit unterschiedlichen Ständen testen #

Wähle Server & Clients mit zwei Clients und starte mit Play oder F7. A erreicht Punkt 1, B bleibt bei Start. Nach dem Tod soll A bei Checkpoint1 und B bei Start erscheinen. Danach erreicht B den ersten, A den zweiten Punkt. Vergleiche beide Ergebnisse. Prüfe auch nahezu gleichzeitigen Kontakt beider Charaktere mit Punkt 1: Ein gemeinsamer Blockierer darf keinen Spieler auslassen.

Dieselbe gefärbte Fläche in zwei Kameras reicht als Beleg nicht. Die Farbe eines Workspace-Objekts ist gemeinsam, RespawnLocation gehört einem Player. Notiere, welcher Client gehandelt hat und welcher Charakter wieder erschien. Beende danach mit End Session die gesamte Mehrclientsitzung. Zwei lokale Clients überprüfen konkrete Fälle, beweisen aber weder die Leistung eines großen Servers noch die Unterstützung verschachtelter Avatare oder aller ungewöhnlichen Kontaktfolgen.

10. Ein verletztes Kriterium nach dem anderen suchen #

Prüfe bei Problemen zuerst den Pfad, dann SpawnLocation-Klasse, Server-Script, CanTouch, lebenden Player, erwarteten Index und Spawnberechtigung. Ein falscher Name und bewusst abgelehnter Index 2 haben unterschiedliche Ursachen. Für Laufzeitfehler dient der verknüpfte Output-Leitfaden; der vollständige Konsolenunterricht wird hier nicht wiederholt. Die Falltabelle enthält keine bestanden-Markierungen. Ergänze eigene Beobachtungen neben den Erwartungen.

Kontrolliere insbesondere, ob Enabled ausgeschaltet oder Neutral nach dem Start verändert wurde. Der Punkt muss in Workspace bleiben und zum Spieler passen. Andere Skripte können Eigenschaften oder RespawnLocation später ändern. Berichte bei einem falschen Ziel die Reihenfolge und die tatsächliche Plattform statt nur „kaputt“. Prüfe eine Korrektur in einem klar definierten Versuch. Endlose Wartezeiten reparieren keine falsche Reihenfolgeregel.

11. Ergebnis speichern und eine Erweiterung wählen #

Beende den Test und speichere den funktionierenden Prototyp unter einem klaren Namen. Notiere Hierarchie, Skriptversion, automatische Charakterladung, tatsächlich ausgeführte Einzel- und Zweiclientfälle sowie erwartete und echte Ziele. Die Logikprüfung dieses Artikels bedeutet nicht, dass dein Projekt einen Studio-Test bestanden hat. Vergleiche die wichtigen Fälle in deiner Szene, bevor die Mechanik in ein bestehendes Spiel kommt.

Als nächster kleiner Schritt eignet sich eine persönliche Bestätigung oder eine ausdrückliche Zurücksetzen-Taste. Dauerhaftes Speichern ist eine eigene Aufgabe mit Laden, Schreibfehlern, Datenversionen und Rücksetzregeln; hier wird kein DataStore verwendet. Versprich keinen ewigen Fortschritt. Bewahre zunächst die klare Regel: Tod führt während dieses Besuchs zum erreichten Punkt, Verlassen beendet diesen Übungsstand im Arbeitsspeicher. Ein überprüfter kleiner Vertrag lässt sich besser erweitern.