Spawnen und respawnen

Spawnen ist der Prozess, ein Objekt oder Charakter in einem Erlebnis zu erstellen, und Respawnen ist der Prozess, ein Objekt oder Charakter wieder in ein Erlebnis hinzuzufügen, nachdem eine Entfernungskondition erfüllt ist, wie zum Beispiel die Gesundheit eines Charakters, die null erreicht, oder das Herunterfallen von der Karte. Beide Prozesse sind wichtig, da sie sicherstellen, dass die Spieler deinem Erlebnis beitreten können und weiterhin spielen können, um ihre Fähigkeiten zu verbessern.

Diese Sektion des Tutorials verwendet das Beispiel-Laser-Tag-Erlebnis als Referenz und lehrt dich, wie du Robloxs integrierte Funktionen zur Handhabung von Spawnieren und Respawnen verwendest und anpasst, einschließlich Skripting-Anleitungen zu:

• Konfigurieren von Spawn-Standorten, sodass Spieler nur in die Spawn-Zone ihres Teams spawnieren können.
• Hinzufügen neuer Spieler und ihres Charakters zur Runde, während sie dem Erlebnis beitreten.
• Anpassen von Kraftfeldern, die Schaden verhindern, während Spieler spawnen und respawnen.
• Handhabung des Client-Zustands, damit das Gameplay zur richtigen Zeit korrekt funktioniert.
• Respawnen von Charakteren, nachdem sie aus der Runde getaggt wurden.
• Ausführen kleiner, allgemeiner Aktionen, die entscheidend sind, um Gameplay- und Charakterparameter festzulegen.

Dieser Abschnitt enthält viele Skripting-Inhalte, aber anstatt alles von Grund auf neu zu schreiben, wenn du ein Erlebnis erstellst, ermutigt er dich, bestehende Komponenten zu nutzen, schnell zu iterieren und herauszufinden, welche Systeme eine benutzerdefinierte Implementierung benötigen, um deiner Vision zu entsprechen. Nachdem du diesen Abschnitt abgeschlossen hast, wirst du lernen, wie man rundenbasiertes Gameplay implementiert, das Punkte verfolgt, den Spielerstatus überwacht und Rundenergebnisse anzeigt.

Konfigurieren von Spawn-Standorten

Wenn du das Erlebnis jetzt testen würdest, würden alle Spieler zufällig entweder am SpawnLocation-Objekt in der Spawn-Zone des grünen Teams oder am SpawnLocation-Objekt in der Spawn-Zone des rosa Teams spawnen. Dies stellt ein Gameplay-Problem dar, bei dem Spieler einander innerhalb jeder Spawn-Zone taggen könnten, sobald das Kraftfeld des Gegners verschwindet.

Um dieses Problem zu bekämpfen, konfiguriert das Beispiel-Laser-Tag-Erlebnis beide Spawn-Standorte mit einer Neutral-Eigenschaft, die auf false gesetzt ist, um zu verhindern, dass die Spieler des gegnerischen Teams in der falschen Spawn-Zone spawnen, und einer TeamColor-Eigenschaft, die auf den entsprechenden Team.Color-Wert aus Teamfarben zuweisen im vorherigen Abschnitt des Tutorials gesetzt ist:

• TeamASpawn – Der Spawn-Standort in der Spawn-Zone des grünen Teams mit einer TeamColor-Eigenschaft, die auf Mint gesetzt ist.
• TeamBSpawn – Der Spawn-Standort in der Spawn-Zone des rosa Teams mit einer TeamColor-Eigenschaft, die auf Carnation Pink gesetzt ist.

Wenn ein Spieler dem Erlebnis beitritt, überprüft ServerScriptService ⟩ Gameplay ⟩ Rounds ⟩ spawnPlayersInMap, wie viele Spieler bereits in jedem Team sind, und gibt dann das Team mit den wenigsten Spielern zurück.

spawnPlayersInMap
local function getSmallestTeam(): Team
	local teams = Teams:GetTeams()

	-- Teams in aufsteigender Reihenfolge von klein nach groß sortieren
	table.sort(teams, function(teamA: Team, teamB: Team)
		return #teamA:GetPlayers() < #teamB:GetPlayers()
	end)

	-- Das kleinste Team zurückgeben
	return teams[1]
end

Sobald bekannt ist, welches Team die wenigsten Spieler hat, wird der Spieler in dieses Team sortiert, die Player.Neutral-Eigenschaft auf false gesetzt, damit der Spieler nur in die Spawn-Location seines Teams spawnen und respawnen kann, und dann wird sein PlayerState auf SelectingBlaster gesetzt, was du später im Tutorial näher kennenlernen wirst.

spawnPlayersInMap
local function spawnPlayersInMap(players: { Player })
	for _, player in players do
		player.Team = getSmallestTeam()
		player.Neutral = false
		player:SetAttribute(PlayerAttribute.playerState, PlayerState.SelectingBlaster)
		task.spawn(function()
			player:LoadCharacter()
		end)
	end
end

Wenn du Workspace ⟩ World ⟩ Map ⟩ Spawns untersuchst, kannst du sehen, dass es einen weiteren Spawn-Standort auf der Karte gibt: NeutralSpawn. Dieser Spawn-Standort ist einzigartig im Vergleich zu den anderen, weil er keine TeamColor-Eigenschaft hat, die auf eines der beiden Teams im Erlebnis gesetzt ist; stattdessen hat dieser Spawn-Standort eine Neutral-Eigenschaft, die sich ändert, je nachdem, ob eine Runde aktiv ist.

Wenn die Runde aktiv ist, wird die Neutral-Eigenschaft auf false gesetzt, damit spawnPlayersInMap die Spieler in Teams sortieren und in die Arena spawnen kann. Wenn die Runde jedoch nicht aktiv ist, wie in der Zeit zwischen einer Runde und der nächsten, wird die Neutral-Eigenschaft auf true gesetzt, sodass Spieler dort unabhängig von ihrem Teamstatus spawnen können. Dieser Prozess macht den Neutral Spawn-Standort zu einer funktionalen Lobby.

Um dies zu demonstrieren, überprüfe ServerScriptService ⟩ Gameplay ⟩ Rounds ⟩ SpawnPlayersInLobby, das am Ende einer Runde ausgeführt wird. Du kannst sehen, dass für jeden Spieler, der in die players: { Player } Tabelle übergeben wird, das Skript:

• Die Player.Neutral-Eigenschaft auf true setzt, um automatisch die Player.Team auf nil zurückzusetzen, sodass der Spieler in der Lobby respawnen kann, wenn eine Runde nicht aktiv ist, da die Neutral-Eigenschaft des Spawn-Standorts ebenfalls auf true gesetzt ist.
• Den PlayerState auf InLobby ändert, um den Blaster des Spielers und die Diagramme der Benutzeroberfläche im ersten Bereich zu entfernen.

Für weitere Informationen zur neutralen Spawn-Zone und ihrer Funktionalität für jede Runde siehe Runden hinzufügen im nächsten Abschnitt des Tutorials.

spawnPlayersInLobby
local function spawnPlayersInLobby(players: { Player })
	for _, player in players do
		player.Neutral = true
		player:SetAttribute(PlayerAttribute.playerState, PlayerState.InLobby)
		task.spawn(function()
			player:LoadCharacter()
		end)
	end
end

Neue Spieler verbinden

Luau-Code in Studio ist oft ereignisgesteuert, was bedeutet, dass Skripte auf Ereignisse von einem Roblox-Dienst hören und dann als Antwort eine Funktion aufrufen. Zum Beispiel, wenn neue Spieler zu einem Mehrspielererlebnis hinzugefügt werden, muss es ein Ereignis geben, das alles Notwendige verwaltet, damit Spieler erfolgreich verbinden können. Im Beispiel-Laser-Tag-Erlebnis ist dieses entsprechende Ereignis Players.PlayerAdded:Connect.

Players.PlayerAdded:Connect ist Teil mehrerer Skripte im Erlebnis. Wenn du die Strg/Cmd+Shift+F-Tastenkombination verwendet und nach Players.PlayerAdded:Connect suchst, liefern die Ergebnisse einen guten Ausgangspunkt, um die Anfangseinrichtung des Erlebnisses zu verstehen.

Um dies zu demonstrieren, öffne ServerScriptService ⟩ SetupHumanoid. Der Unterschied zwischen Player und Character ist wichtig, um dieses Skript zu verstehen:

• Ein Spieler ist ein verbundener Client, und ein Charakter ist ein Humanoid-Modell.
• Spieler müssen einen Blaster auswählen und in die Rangliste aufgenommen werden. Charaktere müssen spawnen und einen Blaster erhalten.

SetupHumanoid überprüft sofort, ob der Spieler einen Charakter hat (gerade beigetreten) oder nicht (respawnt). Nachdem er einen gefunden hat, ruft er onCharacterAdded() auf, erhält das Humanoid-Modell des Charakters und übergibt es an ServerScriptService ⟩ SetupHumanoid ⟩ setupHumanoidAsync zur Anpassung. Nachdem diese Werte festgelegt sind, wartet das Skript, bis die Gesundheit des Charakters null erreicht. Du wirst später in diesem Abschnitt des Tutorials mehr über Respawnen erfahren.

setupHumanoidAsync
local function setupHumanoidAsync(player: Player, humanoid: Humanoid)

	humanoid.DisplayDistanceType = Enum.HumanoidDisplayDistanceType.Subject
	humanoid.NameDisplayDistance = 1000
	humanoid.HealthDisplayDistance = 1000
	humanoid.NameOcclusion = Enum.NameOcclusion.OccludeAll
	humanoid.HealthDisplayType = Enum.HumanoidHealthDisplayType.AlwaysOn
	humanoid.BreakJointsOnDeath = false

	humanoid.Died:Wait()
	onHumanoidDied(player, humanoid)
end

Die wichtige Anmerkung zu diesem Skript ist, dass die Eigenschaften vollständig optional sind, was bedeutet, dass das Erlebnis weiterhin ordnungsgemäß funktioniert, wenn du die ersten sechs Zeilen der Funktion entfernst. Anstatt funktionale Anforderungen zu sein, ermöglicht jede Eigenschaft dir, Designentscheidungen zu treffen, die deine Gameplay-Ziele erfüllen. Zum Beispiel:

• Wenn du möchtest, dass die Charakternamen in näherer Distanz angezeigt werden, reduziere den Wert von Humanoid.NameDisplayDistance.
• Wenn du möchtest, dass die Gesundheit eines Charakters nur angezeigt wird, wenn sie unter 100 % liegt, setze Humanoid.HealthDisplayType auf DisplayWhenDamaged.
• Wenn du möchtest, dass Charaktere zerfallen, wenn ihre Gesundheit null erreicht, setze Humanoid.BreakJointsOnDeath auf True.

Wenn du diese Werte änderst, ist es wichtig, das Erlebnis zu testen, damit du die Auswirkungen deiner neuen Einstellungen sehen kannst. Du kannst nachstellen, was die Spieler in einer Multi-Client-Simulation erleben, indem du mindestens zwei Charaktere in einem Server & Clients-Playtest aus der Galerie auswählst.

Ein weiteres Beispiel für das Ereignis Players.PlayerAdded:Connect findet sich in ServerScriptService ⟩ PlayerStateHandler. Genau wie im vorherigen Beispiel überprüft PlayerStateHandler sofort, ob ein Charakter vorhanden ist. Wenn der Spieler sich nicht in der Lobby befindet, setzt das Skript ein Spielerattribut auf den Zustand SelectingBlaster, den Anfangszustand für eine Runde, in der die Spieler nach dem Spawn in die Arena aus zwei verschiedenen Blaster-Typen auswählen können. Dieser Zustand beinhaltet auch ein Kraftfeld, das verhindert, dass Spieler Schaden nehmen, während sie ihre Auswahl treffen.

PlayerStateHandler
local function onPlayerAdded(player: Player)
	player.CharacterAdded:Connect(function()
		if not player.Neutral then
			player:SetAttribute(PlayerAttribute.playerState, PlayerState.SelectingBlaster)
			onPlayerStateChanged(player, PlayerState.SelectingBlaster)
		end
	end)

Eine bestimmte Variable in PlayerStateHandler verdient eine Diskussion: attributeChangedConnectionByPlayer. Diese Tabelle speichert alle Spieler und ihre Connections zum GetAttributeChangedSignal. Der Grund, diese Verbindung in einer Tabelle zu speichern, besteht darin, dass PlayerStateHandler sie trennen kann, wenn der Spieler das Erlebnis verlässt. Dieser Prozess dient als eine Art Speichermanagement, um zu verhindern, dass die Anzahl der Verbindungen im Laufe der Zeit immer größer wird.

PlayerStateHandler
local attributeChangedConnectionByPlayer = {}
local function onPlayerAdded(player: Player)

	-- Alle zukünftigen Updates zum Spielerstatus behandeln
	attributeChangedConnectionByPlayer[player] = player
		:GetAttributeChangedSignal(PlayerAttribute.playerState)
		:Connect(function()
			local newPlayerState = player:GetAttribute(PlayerAttribute.playerState)
			onPlayerStateChanged(player, newPlayerState)
		end)
end

-- Von der Attributänderungsverbindung trennen, wenn der Spieler das Spiel verlässt
local function onPlayerRemoving(player: Player)
	if attributeChangedConnectionByPlayer[player] then
		attributeChangedConnectionByPlayer[player]:Disconnect()
		attributeChangedConnectionByPlayer[player] = nil
	end
end

Du kannst sehen, dass die beiden verbundenen Funktionen in onPlayerAdded() onPlayerStateChanged() aufrufen. Während der Anfangseinrichtung, nachdem ein Spieler in ein Team sortiert wurde, wird onPlayerAdded() auf SelectingBlaster gesetzt, sodass die erste if-Anweisung als falsch ausgewertet wird und den BlasterState deaktiviert. Im späteren Abschnitt Blaster implementieren des Tutorials wirst du mehr über diesen Prozess erfahren.

PlayerStateHandler
local function onPlayerStateChanged(player: Player, newPlayerState: string)
	-- Blaster-Zustand ist 'Bereit' nur, wenn der Spielerstatus 'Spielend' ist
	local newBlasterState = if newPlayerState == PlayerState.Playing then BlasterState.Ready else BlasterState.Disabled

	-- Logik für das Zerstören des Kraftfelds planen, wenn der Spieler mit dem Spielen beginnt
	if newPlayerState == PlayerState.Playing then
		scheduleDestroyForceField(player)
	end

	player:SetAttribute(PlayerAttribute.blasterStateServer, newBlasterState)
end

Wenn du Haltepunkte hinzufügst oder sogar nur eine print()-Anweisung verwendest, kannst du sehen, dass onPlayerStateChanged() häufig im gesamten Erlebnis aufgerufen wird: zum Beispiel während der Anfangseinrichtung einer Runde, um sich auf den Hauptcodepfad zu setzen, nachdem der Spieler einen Blaster ausgewählt hat und wenn der Spieler in die Lobby oder den Neutral Spawn-Standort zurückkehrt. Darüber hinaus setzt ServerScriptService ⟩ BlasterSelectedHandler, nachdem der Spieler einen Blaster auswählt, den PlayerState auf Playing, und PlayerStateHandler kann schließlich das Kraftfeld entfernen, indem es scheduleDestroyForceField() aufruft.

Kraftfelder anpassen

Anstatt eine benutzerdefinierte Implementierung zu verwenden, verwendet das Beispiel-Laser-Tag-Erlebnis die integrierte ForceField-Klasse von Studio, um zu verhindern, dass Spieler Schaden nehmen, während sie ihren Blaster auswählen. Dies stellt sicher, dass die einzige Voraussetzung, damit Spieler mit einem Kraftfeld spawnen, darin besteht, Spawn-Standorte mit einer SpawnLocation.Duration-Eigenschaft zu haben, die größer als 0 ist. Das Beispiel verwendet einen arbiträren Wert von 9.999, um Kraftfelder zu aktivieren, und verwaltet die tatsächliche Dauer programmgesteuert in ReplicatedStorage ⟩ ForceFieldClientVisuals.

Ähnlich wie setupHumanoidAsync sind die meisten Zeilen in ForceFieldClientVisuals optional. Zum Beispiel, wenn du den Inhalt der Funktion wie im folgenden Skript kommentierst, verwendet das Erlebnis das Standardfunkeln-Kraftfeld anstelle des hexagonalen Skripts in StarterGui ⟩ ForceFieldGui.

Commenting Out Properties in ForceFieldClientVisuals
local function onCharacterAddedAsync(character: Model)
    -- local forceField = character:WaitForChild("ForceField", 3)
    -- if not forceField then
    -- return
    -- end
    -- forceField.Visible = false
    -- localPlayer.PlayerGui:WaitForChild("ForceFieldGui").Enabled = true
    -- forceField.Destroying:Wait()
    -- localPlayer.PlayerGui.ForceFieldGui.Enabled = false
end

Da das benutzerdefinierte Kraftfeld eine GUI ist und kein neuer ParticleEmitter, beeinflusst das Skript ForceFieldClientVisuals nur die visuellen Darstellungen für jeden Spieler im ersten Personenansicht, nicht die Third-Person-Visuals, wenn Spieler andere Spieler ansehen. Die Third-Person-Visuals behalten das Standardschein von Roblox bei. Für weitere Informationen zum Modifizieren von Kraftfeldern siehe ForceField.Visible.

Kraftfelder sind nützlich, weil sie Spielern genug Zeit bieten, während des Spawnens und Respawnens zu agieren, ohne sich um feindliche Spieler kümmern zu müssen, aber schließlich müssen sie für das Hauptlaser-Tag-Gameplay verschwinden. Das Skript, das die Entfernung des Kraftfelds behandelt, befindet sich in ReplicatedStorage ⟩ scheduleDestroyForceField, und es überprüft drei einzigartige Bedingungen:

• Nachdem Spieler einen Blaster ausgewählt haben, müssen die Kraftfelder lange genug halten, um den Spielern zu erlauben, sich an ihre Umgebung zu gewöhnen.
• Während dieser Akklimatisierungszeit dürfen Kraftfelder keinen Vorteil bieten, sodass sie verschwinden müssen, sobald ein Spieler seinen Blaster abfeuert.
• Kraftfelder müssen verschwinden, wenn Spieler ihre Charaktere zurücksetzen, entweder bevor sie abfeuern oder bevor die Zeit des Kraftfelds abläuft.

Jede dieser Überprüfungen im scheduleDestroyForceField-Skript ruft endForceField() für diese Bedingungen auf.

scheduleDestroyForceField
-- Kraftfeld beenden, wenn der Spieler abfeuert
local blasterStateAttribute = getBlasterStateAttribute()
attributeChangedConnection = player:GetAttributeChangedSignal(blasterStateAttribute):Connect(function()
	local currentBlasterState = player:GetAttribute(blasterStateAttribute)
	if currentBlasterState == BlasterState.Blasting then
		endForceField()
	end
end)

-- Kraftfeld beenden, wenn der Spieler zurücksetzt
characterRespawnedConnection = player.CharacterRemoving:Connect(endForceField)

-- Kraftfeld nach 8 Sekunden beenden
task.delay(MAX_FORCE_FIELD_TIME, endForceField)

endForceField() enthält eine scheinbar seltsame if-Anweisung um die forceFieldEnded-Boolean. Da die Überprüfungen nacheinander ausgeführt werden, kann das Skript die Funktion endForceField() zwei- oder sogar dreimal aufrufen. Die forceFieldEnded-Boolean stellt sicher, dass die Funktion nur einmal versucht, ein Kraftfeld zu zerstören.

scheduleDestroyForceField
local function endForceField()
	if forceFieldEnded then
		return
	end
	forceFieldEnded = true

	attributeChangedConnection:Disconnect()
	characterRespawnedConnection:Disconnect()
	destroyForceField(player)
end

Client-Zustand handhaben

Während der Großteil dieses Abschnitts auf ServerScriptService ⟩ PlayerStateHandler fokussiert ist, gibt es ein weiteres Skript desselben Namens in ReplicatedStorage. Der Grund für die Aufspaltung ist die Client-Server-Architektur:

• Der Client muss Informationen über den Spielerstatus verstehen, um entsprechend in Echtzeit reagieren zu können, wie die richtigen Benutzeroberflächenelemente anzuzeigen oder den Spielern zu ermöglichen, sich zu bewegen und zu schießen.

• Der Server benötigt all diese Informationen, um Ausnutzungen zu verhindern. Zum Beispiel benötigt der Server auch den Spielerstatus, um Aktionen wie das Spawnieren und Ausstatten von Charakteren, das Deaktivieren von Kraftfeldern und das Anzeigen einer Rangliste auszuführen. Daher befindet sich dieses Skript in ReplicatedStorage und nicht in einem rein client-seitigen Standort.

Um diese Kernlogik zu sehen, überprüfe das folgende Skript in ReplicatedStorage ⟩ PlayerStateHandler, das den aktuellen Zustand des Nutzers überprüft und dann die entsprechende Funktion aufruft, die die entsprechenden Aktionen für diesen Zustand behandelt.

PlayerStateHandler
local function onPlayerStateChanged(newPlayerState: string)
	if newPlayerState == PlayerState.SelectingBlaster then
		onSelectingBlaster()
	elseif newPlayerState == PlayerState.Playing then
		onPlaying()
	elseif newPlayerState == PlayerState.TaggedOut then
		onTaggedOut()
	elseif newPlayerState == PlayerState.InLobby then
		onInLobby()
	else
		warn(`Ungültiger Spielerstatus ({newPlayerState})`)
	end
end

Alle Ereignisreaktionen sind in diesem Skript logisch gruppiert, da sie ein ähnliches Verhalten erfordern, um die Steuerung des Spielers, die Kamerabewegung und die sichtbare UI-Schicht zu aktivieren oder zu deaktivieren. Zum Beispiel müssen Spieler während der Blasterauswahl sowohl unverwundbar als auch bewegungslos sein. Der Server behandelt bereits das Kraftfeld, aber der Client kümmert sich um die Bewegung. Um dies zu demonstrieren, wenn du die Logik der onSelectingBlaster()-Funktion überprüfst, kannst du sehen, dass der Client die Bewegungen des Spielers deaktiviert, während er einen Blaster auswählt.

PlayerStateHandler
local function onSelectingBlaster()
	togglePlayerCamera(true)
	togglePlayerMovement(false)
	setGuiExclusivelyEnabled(playerGui.PickABlasterGui)

	localPlayer:SetAttribute(PlayerAttribute.blasterStateClient, BlasterState.Disabled)
end

Die onPlaying()-Funktion ist ebenfalls einfach. Sie aktiviert die Bewegung, wechselt zur Hauptanzeige (HUD), aktiviert den Blaster und ruft die gleiche Kraftfeldfunktion wie der Server auf.

PlayerStateHandler
local function onPlaying()
	togglePlayerMovement(true)
	setGuiExclusivelyEnabled(playerGui.HUDGui)

	localPlayer:SetAttribute(PlayerAttribute.blasterStateClient, BlasterState.Ready)

	scheduleDestroyForceField()
end

Charaktere respawnen

Das Beispiel-Laser-Tag-Erlebnis behandelt das Respawnen von Charakteren zurück in eine Runde durch den Zustand onTaggedOut() in ReplicatedStorage ⟩ PlayerStateHandler. Wie die Zustände onSelectingBlaster() und onPlaying() löst onTaggedOut() einzigartiges Verhalten aus, das den Änderungen des playerState-Attributs entspricht. Genauer gesagt deaktiviert er die Bewegung des Spielers, zeigt die Respawn-Benutzeroberfläche an und deaktiviert den Blaster.

PlayerStateHandler
local function onTaggedOut()
	-- Steuerelemente deaktivieren, während man getaggt wird
	togglePlayerMovement(false)
	togglePlayerCamera(false)
	setGuiExclusivelyEnabled(playerGui.OutStateGui)

	-- Blaster deaktivieren, während man getaggt wird
	localPlayer:SetAttribute(PlayerAttribute.blasterStateClient, BlasterState.Disabled)
end

Wenn du dieses Verhalten testen möchtest, kannst du Esc drücken, zur Einstellungen-Registerkarte navigieren und dann auf die Charakter zurücksetzen-Schaltfläche klicken. Beachte, dass du, wenn du den Respawn-Bildschirm auslöst, dich nicht bewegen, die Kamera nicht drehen oder deinen Blaster abfeuern kannst.

Es ist wichtig zu beachten, dass dieses Skript tatsächlich keine Charaktere respawnt, sondern einfach verhindert, dass sie agieren, und den Spielern visuelles Feedback gibt, dass der Server ihre Charaktere respawnt. Um dies zu demonstrieren, wenn du ServerScriptService ⟩ SetupHumanoid ⟩ setupHumanoidAsync ⟩ onHumanoidDied überprüfst, stellt das Skript PlayerState auf TaggedOut (was im Wesentlichen ReplicatedStorage ⟩ PlayerStateHandler benachrichtigt) und fügt einige visuelle Indikatoren hinzu. Die tatsächliche Logik des Respawnen ist ein integriertes Verhalten von Roblox.

Wenn Spieler zurück in die Runde respawnen, respawnen sie an ihrem Team-Spawn-Standort gemäß der SpawnLocation.TeamColor-Eigenschaft. Um die Respawn-Zeit anzupassen, kannst du die folgende Zeile oben in SetupHumanoid hinzufügen. Um mehr über diese Technik zu erfahren, siehe Players.RespawnTime.

SetupHumanoid
local Players = game:GetService("Players")
Players.RespawnTime = 10 -- neue Zeile, in Sekunden

Sonstige Einstellungen

Im Rahmen der Anfangseinrichtung führt das Beispiel-Laser-Tag-Erlebnis auch einige kleine, aber entscheidende Schritte durch:

• Das Erlebnis enthält ein leeres Skript namens StarterPlayer ⟩ StarterCharacterScripts ⟩ Health, das die standardmäßige Roblox-Gesundheitsregeneration deaktiviert. Siehe für eine Erklärung des Verhaltens dieser Eigenschaft Humanoid.Health.

• Das Erlebnis verwendet eine Kamera in der ersten Person, indem die StarterPlayer.CameraMode.LockFirstPerson-Eigenschaft festgelegt wird. Beachte, dass du, wenn du Benutzern ermöglichen möchtest, zwischen der ersten und der dritten Person zu wechseln, die Eigenschaft programmatisch ändern musst und nicht nur einmal in Studio festlegen darfst, und die Steuerungen sowie die Benutzeroberfläche an die Perspektivänderung anpassen musst.

• Das Erlebnis verwendet die integrierte Roblox-Rangliste mit der Einheit "Punkte", die Spieler jedes Mal verdienen, wenn sie einen anderen Spieler taggen. Du kannst die Konfiguration in ServerScriptService ⟩ SetupLeaderboard sehen, aber Ranglisten im Erlebnis bietet eine vollständige Übersicht. Beachte, dass onPlayerTagged Punkte zur Rangliste hinzufügt, was du in Runden hinzufügen und Treffer erkennen lernen wirst.

Jetzt, da die Spieler spawnieren, einen Blaster auswählen und ihn aus einer ersten Person Perspektive anvisieren können, lehrt dich der nächste Abschnitt die Skripte hinter der Erstellung von rundenbasiertem Gameplay.