Studio / ROBLOX
Zwei Spieler in Roblox Studio: einen Test sinnvoll organisieren
Plane eine Lernsimulation mit zwei Clients und getrennten Beobachtungen für A, B und den Server. Ausgangszustand, persönliche und gemeinsame Ergebnisse, kurze Aktionsfolgen, Wiederholungen und Respawn.
Bild in voller Größe öffnen ↗Ein Durchlauf, drei Blickwinkel #
Zwei Figuren nebeneinander beweisen noch keine funktionierende Mehrspielermechanik. Client A kann ein überzeugendes Ergebnis anzeigen, Client B das alte Objekt und der Server einen anderen Zustand. Dieser Leitfaden ordnet Beobachtungen. Er entwickelt weder ein Belohnungssystem noch eine allgemeine Absicherung für RemoteEvent.
Verwende eine separate Lernkopie deines Projekts. Eine einfache Szene mit einem Spawnpunkt genügt, um den Start zu prüfen; eine Interaktion wird nur untersucht, wenn sie bereits vorhanden ist. Wähle ein gemeinsames Objekt und ein persönliches Oberflächenelement, soweit dein Prototyp sie enthält. Erfinde während der Beobachtung keine neue Regel. Für diesen Artikel wurden weder Studio noch die fünf Spiele des Websiteautors gestartet. Die folgenden Schritte und leeren Protokollfelder sind Anleitungen, keine Ergebnisse eines durchgeführten Tests.
1. Zuerst einen Fall beschreiben #
Notiere Projektversion, Modus, zwei Clients, ausgewähltes Objekt und Bereitschaftsbedingung. Beispielsweise sind beide Figuren erschienen und beweglich, das gemeinsame Objekt ist vorhanden und das benötigte Panel erreichbar. Bestimme den Ausgangswert anhand deiner Implementierung sowie die Positionen von A und B. Ein unbekannter Ausgangswert wird geklärt; eine zufällig sichtbare Farbe ist kein Ersatz.
Trenne Erwartung und Beobachtung. „A verändert das gemeinsame Objekt; B sieht die Änderung“ ist eine Anforderung, kein Beleg. Die persönliche Hilfe von A kann ausschließlich zu A gehören; auch das wird vorher entschieden. Lege erlaubte Wiederholungen und die Rückkehr zum Ausgangszustand fest. Für den ersten Durchlauf reicht eine Aktion. Mehrere gleichzeitig wechselnde Menüs und Aufgaben erschweren die Zuordnung einer Abweichung.
2. Den Modus nach der Fragestellung wählen #
Ein einzelner Test/F5 fügt eine Spielfigur ein; Run/F8 startet ohne sie. Zwei Clients erfordern Server & Clients. Die aktuelle Dokumentation verortet die Teststeuerung links in Studios mezzanine. Orientiere dich daran, statt aufgrund einer älteren Anleitung eine nicht passende Registerkarte zu suchen.
Ein Einzeltest eignet sich für eine kurze Bereitschaftskontrolle. Sein Wechsel zwischen Client und Server ändert den Blickwinkel innerhalb dieses Tests, erzeugt aber keinen zweiten Spieler. Server & Clients stellt die getrennten Clients für unsere Untersuchung bereit. Team Test ist ein anderer Ablauf mit Mitwirkenden und hierfür nicht nötig. Formuliere zuerst die Frage, dann wähle den Modus. Die Modustabelle zeigt Möglichkeiten und Grenzen, ohne jede laufende Szene als Mehrspielertest zu bezeichnen.
| Modus | Zweck dieses Durchlaufs | Grenze |
|---|---|---|
| Test / F5 | Einzelbereitschaft mit Figur | Erzeugt keinen zweiten Spieler |
| Client / Server im Einzeltest | Zwei Seiten desselben Einzelstarts | Keine zwei unabhängigen Clients |
| Run / F8 | Szene ohne Figur ausführen | Kein Ersatz für zwei handelnde Spieler |
| Server & Clients · 2 · Play/F7 | Zwei Clients und Server für A/B/S | Lokale Simulation, kein öffentliches Spiel |
3. Genau zwei Clients starten #
Wähle im Testmenü Server & Clients, stelle die Clientzahl auf 2 und drücke Play oder F7. Studio öffnet separate Sitzungen: einen simulierten Server und je eine Sitzung pro Client. Warte auf den vollständigen Start, bevor du handelst. Das ursprüngliche Bearbeitungsfenster ist kein weiterer Spieler; die Fensterzahl allein genügt nicht als Kontrolle.
Bezeichne die Clients im Protokoll als A und B, den Server als S. Stelle fest, welcher Client welche Figur steuert. Prüfe im serverseitigen Dienst Players die beiden Player-Instanzen. Ein ausgeblendeter Dienst lässt sich über Show Services… im Kontextmenü von Explorer anzeigen. Schreibe die tatsächlich verwendeten Testnamen auf. Versprich weder Player1/Player2 noch echte Konten. Bei einem unvollständigen Start wird zuerst die Testbesetzung korrigiert.
4. Beobachtung statt neuen Code einrichten #
Öffne Explorer und Output über Window; die Dokumentation nennt außerdem entsprechende Werkzeugleistenknöpfe. Explorer dient dem konkreten Objekt und seinen Werten, Output den Fehlern und bereits vorhandenen Meldungen des Projekts. Show Context, Show Timestamp und gegebenenfalls Show Source helfen, Herkunft und Reihenfolge festzuhalten. Ein zusätzliches Skript wird hier nicht benötigt.
Jede Notiz erhält eine Seite: A, B oder S. LocalPlayer bezeichnet den jeweiligen Clientspieler; der Server arbeitet mit den Spielern der Sitzung. „Der Spieler“ ohne Rolle ist ungenau. Filtere einen Fehler nicht weg, bevor er dokumentiert ist. Keine Ausgabe beweist nicht, dass keine Operation stattfand: Der Prototyp könnte schlicht nichts ausgeben. Fehlende Belege werden gekennzeichnet; zusätzliche Diagnoseänderungen bespricht man nach dem ursprünglichen Durchlauf.
5. Drei Ausgangszustände erfassen #
Vor der ersten Eingabe werden drei unabhängige Einträge erstellt. A: Figurenposition, sichtbares Objekt und persönliches Panel. B: dieselben Angaben aus seiner Sicht. S: relevantes Objekt und Serverwert, Players-Besetzung und verfügbares Protokoll. Kopiere niemals den Serverwert in die Beobachtungsspalte von B, als hätte B ihn gesehen.
Ein gemeinsames Ergebnis bedeutet nicht zwingend identische Bilder. Kameras, lokale Panels und verfügbare Bereiche können sich unterscheiden. Bei Streaming ist ein entferntes, clientseitig fehlendes Objekt nicht automatisch ein Fehler. Bereite vergleichbare Bedingungen vor: Beide Figuren stehen nahe dem gewählten Objekt; notiere dessen tatsächliche Verfügbarkeit. Eine Verschiebung durch den serverseitigen Explorer mitten im Test wäre ein eigener Eingriff mit anderem Ausgangszustand, keine neutrale Beobachtung.
Bild in voller Größe öffnen ↗6. Aktionen zuerst nacheinander prüfen #
A führt eine vorher festgelegte Aktion aus, B beobachtet zunächst nur. Erfasse die Oberflächenreaktion von A, den Serverzustand und das sichtbare Ergebnis bei B. Vergleiche alle drei mit der Anforderung. Dokumentiere eine Abweichung vor einer Codekorrektur, sonst stammen Beobachtung und Schlussfolgerung aus verschiedenen Versionen.
Stelle den vereinbarten Ausgangszustand wieder her und tausche die Rollen. Jetzt handelt B, während A beobachtet. Eine gemeinsame Regel darf bewusst beide Clients verändern. Umgekehrt sollte das Öffnen einer persönlichen Hilfe bei A nicht auch B öffnen, wenn dies als lokale Funktion definiert ist. Beide Erwartungen gehören zu deiner Spezifikation. Der zweite Blickwinkel prüft genau diese Unterscheidung; er verlangt keine pauschal gleichen Bildschirme.
7. Eng benachbarte Aktionen genau benennen #
Bereite einen Fall vor, in dem A handelt und B kurz danach folgt. Wiederhole mit umgekehrter Reihenfolge ab dem Ausgangszustand. Notiere die tatsächlich ausgeführte Eingabefolge. Eine Person, die zwischen Fenstern wechselt, kann nicht garantieren, dass beide Anfragen im selben Servertakt eintreffen. Nenne dies kurz aufeinanderfolgende Aktionen, keine belegte Gleichzeitigkeit.
Die Konfliktregel gehört zur vorhandenen Mechanik: Vielleicht ist nur eine Änderung zulässig, vielleicht werden Aktionen eingereiht oder die zweite abgelehnt. Schreibe die gewählte Regel auf, ohne sie für diesen Artikel zu erfinden. Dass B nach A ein verändertes Objekt sieht, ist allein kein Fehler. Vergleiche die Folge mit der Vorgabe. Präzise Gleichzeitigkeit verlangt einen gesondert kontrollierten Fall; zwei schnelle Eingaben decken nicht alle möglichen Konkurrenzsituationen ab.
8. Späte Antwort und Wiederholung trennen #
Wenn die vorhandene Implementierung Anfrage und Ergebnis zuordnet, notiere diese Verbindung. Prüfe, ob eine späte Antwort die Anzeige einer neueren, anderen Aktion überschreibt. Ein fehlendes Ergebnis ist unbekannt und nicht automatisch abgelehnt. Ob eine Wiederholung sicher ist, entscheidet der tatsächliche Ablaufvertrag der Mechanik, nicht ein bequem erreichbarer Knopf.
Nutze Network Simulator nur in einem separaten kontrollierten Durchlauf und notiere die Einstellungen beider Richtungen. Das Studio-Werkzeug ist beta; prüfe die aktuelle Verfügbarkeit. Eine Presetauswahl bereitet Werte vor, erst Apply aktiviert sie. Langsames Fensterwechseln ist keine simulierte Netzverzögerung. Danach die notierten Basiswerte wiederherstellen und anwenden: Reset bereitet Ideal Fiber vor, nicht null Verzögerung. Liveverbindungen werden nicht geändert. Fehlt die Zuordnung zum Ergebnis, dokumentiere die Beobachtungsgrenze statt einen sicheren Wiederholungsversuch zu versprechen.
9. Respawn bleibt in derselben Sitzung #
Lass nach einem klaren Ausgangsdurchlauf die Figur von A mit dem vorhandenen Verfahren des Lernprojekts neu erscheinen. Notiere Änderungen bei A, die Sicht von B und den verbleibenden Zustand auf S. Ein neuer Character ist kein neu beigetretener Player. CharacterAdded bezieht sich auf das Erscheinen oder Wiedererscheinen einer Figur und garantiert keine erhaltenen Panels, Aufgaben oder Spielzustände.
Warte vor der nächsten Aktion erneut auf die Bereitschaftsbedingung. Je nach Implementierung müssen alte Figurenreferenzen oder lokale Elemente erneuert werden. Hier wird weder repariert noch Code ergänzt: Der Entwickler erhält einen reproduzierbaren Fall. Nenne Respawn nicht einen neuen Besuch und ersetze ihn nicht durch ein vollständiges Sitzungsende. Deaktiviert das Projekt gewöhnliches Figurenladen, nutze seinen vorhandenen Mechanismus statt automatischen Respawn allgemein vorauszusetzen.
10. Sitzungsende und Dateispeichern unterscheiden #
Nach dem Protokollieren beendet End Session aus einer beliebigen Simulationssitzung alle simulierten Clients und den Server von Server & Clients. Im Einzeltest beendet Stop den Test und setzt Objekte auf ihren vorherigen Zustand zurück. Ein einzelnes geschlossenes Fenster oder eine Pause ist kein universeller Ersatz für das vollständige Ende.
Kehre zum ursprünglichen Bearbeitungsprojekt zurück. Für eine lokale Kopie verwende File → Save to File, wenn du Autorenmaterial geändert hast. Das speichert keinen Spielerfortschritt. Laufzeitänderungen der Welt werden nicht automatisch zu Dateibearbeitungen. Ein neuer Start braucht einen neuen Ausgangseintrag. Externe Persistenz kann trotz Neustart Daten behalten; untersuche sie getrennt. Bewahre das Beobachtungsprotokoll außerhalb des Projekts auf, damit Reihenfolge und Kontext nach dem Ende erhalten bleiben.
11. Ein reproduzierbares Ergebnis weitergeben #
Ein hilfreicher Bericht enthält Version, Clientbesetzung, Ausgangslage, genaue Eingaben, A/B/S-Rollen, Erwartung und tatsächliche Beobachtungen. Füge bei einer Abweichung verfügbare Fehler mit Kontext hinzu und vermerke, ob derselbe Start sie reproduzierte. „Funktioniert“ ohne solche Bedingungen erlaubt anderen Entwicklern keinen verlässlichen Vergleich.
Offizielle Quellen und Artikelstruktur wurden geprüft; unsere Diagramme sind Pläne, keine Studioaufnahmen. Ein echter Test nach dieser Anleitung fand nicht statt. Die lokale Simulation belegt weder physische Telefone noch öffentliche Server oder sämtliche Netzbedingungen. Nach einer Korrektur wiederholt man den problematischen Fall und den zugehörigen Ausgangsdurchlauf. Reale Geräte und die benötigte Zielumgebung folgen getrennt. Ein kleines genaues Protokoll macht zwei Clients zu nützlichen Beobachtungspunkten statt lediglich zusätzlichen Fenstern.
| Fall / Eingabe | Vorab festgelegtes Kriterium | A: beobachtet | B: beobachtet | S: beobachtet |
|---|---|---|---|---|
| Ausgangsstart: beide bereit | Verfügbarkeit und Wert erfassen, mit Fallbeschreibung vergleichen | — | — | — |
| A handelt, B beobachtet | Änderungen nach gemeinsamer Regel; getrennte Beobachtungen | — | — | — |
| B handelt, A beobachtet nach Rücksetzung | Prüfung mit getauschtem Auslöser | — | — | — |
| A öffnet persönliches Panel, falls vorhanden | Bei lokaler Regel bleibt Bs Panel geschlossen | — | — | — |
| Rasch A → B, danach separat B → A | Reihenfolge notieren; definierte Konfliktregel vergleichen | — | — | — |
| Wiederholung und späte Antwort: eigener Durchlauf | Anfrage/Ergebnis zuordnen; andere neuere Operation nicht überschreiben | — | — | — |
| Respawn von A in derselben Sitzung | Bereitschaft, Character und erforderlichen Zustand prüfen | — | — | — |
| End Session und neuer Start | Neue Besetzung/Ausgangswerte notieren; keine sauberen externen Daten voraussetzen | — | — | — |
Originalquellen
Roblox Creator Hub — Studio testing modesRoblox Creator Hub — Client-server runtime
Roblox Creator Hub — Players
Roblox Creator Hub — Player
Roblox Creator Hub — Explorer
Roblox Creator Hub — Output
Roblox Creator Hub — Network Simulator
Roblox Creator Hub — Place files
