Spawnen und respawnen

Spawnen ist der Prozess, bei dem ein Objekt oder eine Figur in einem Erlebnis erstellt wird, und respawnen ist der Prozess, bei dem ein Objekt oder eine Figur wieder in ein Erlebnis hineingefügt wird, nachdem sie eine Entfernungsbedingung erfüllt haben, wie die Gesundheit eines Charakters auf Null sinken oder vom Land fallen.Beide Prozesse sind wichtig, weil sie sicherstellen, dass Spieler deiner Erfahrung beitreten können und weiterhin spielen, um ihre Fähigkeiten zu verbessern.

Mit der Beispiel-Laser-Tag-Erfahrung als Referenz lehrt dieser Abschnitt des Tutorials dich, wie du Roblox' integrierte Funktionen verwenden und anpassen kannst, um Spawnen und Respawnen zu verwalten, einschließlich Skriptanleitungen:

• Konfigurieren von Spawn-Orten, damit Spieler nur in die Spawn-Zone ihres Teams spawnen können.
• Hinzufügen neuer Spieler und deren Charakter zur Runde, wenn sie sich dem Erlebnis anschließen.
• Anpassung von Kraftfeldern, die Schäden verhindern, wenn Spieler spawnen und respawnen.
• Clientzustand verwalten, damit das Spiel zu der richtigen Zeit richtig funktioniert.
• Respawnen von Charakteren, nachdem sie aus der Runde entfernt wurden.
• Ausführung kleiner, unbestimmter Aktionen, die für die Festlegung von Gameplay- und Charakterparametern entscheidend sind.

Dieser Abschnitt enthält viel Skript-Inhalt, aber anstatt alles von Grund auf neu zu schreiben, wenn du ein Erlebnis erstellst, ermutigt er dich, vorhandene Komponenten zu nutzen, schnell zu iterieren und herauszufinden, welche Systeme eine benutzerdefinierte Implementierung benötigen, um deine Vision zu entsprechen.Nachdem du diesen Abschnitt abgeschlossen hast, wirst du lernen, wie du rundenbasiertes Spielen implementierst, das Punkte verfolgt, den Zustand des Spielers überwacht und die Rundenergebnisse anzeigt.

Spawn-Orte konfigurieren

Wenn du die Erfahrung gerade testen würdest, würden alle Spieler zufällig entweder im SpawnLocation Objekt in der Spawn-Zone des grünen Teams oder im SpawnLocation Objekt in der Spawn-Zone des rosa Teams erscheinen.Dies stellt ein Spielproblem dar, bei dem Spieler sich innerhalb jeder Spawnzone so schnell wie möglich markieren könnten, sobald das Kraftfeld ihres Gegners verschwindet.

Um dieses Problem zu bekämpfen, konfiguriert die Probepunktlasertag-Erfahrung beide Spawnorte mit einer Eigenschaft auf falsch um die Spieler des gegnerischen Teams von der Spawnzone in der falschen Zone zu beschränken, und eine Eigenschaft auf den entsprechenden Wert von Assign Team Colors aus der vorherigen Sektion des Tutorials:

• TeamASpawn – Der Spawn-Ort in der Spawn-Zone des grünen Teams mit einem Eigenschaftsset auf Mint .
• TeamBSpawn – Der Spawn-Ort in der Spawn-Zone des rosa Teams mit einem Eigenschaftsset auf Carnation Pink .

>

>

Wenn ein Spieler der Erlebnisbeitritt, ServerScriptService > Spiel > Runden > spawnPlayersInMap überprüft, wie viele Spieler bereits in jedem Team sind, und gibt dann das Team mit der geringsten Anzahl von Spielern zurück.

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

	-- Sortiere Teams in aufsteigender Reihenfolge von kleinst bis größt
	table.sort(teams, function(teamA: Team, teamB: Team)
		return #teamA:GetPlayers() < #teamB:GetPlayers()
	end)

	-- Gib das kleinste Team zurück
	return teams[1]
end

Sobald es das Team mit der geringsten Anzahl von Spielern kennt, ordnet es den Spieler in dieses Team ein, legt seine Player.Neutral Eigenschaft auf falsch fest, so dass der Spieler nur in den Spawnort seines Teams spawnen und respawnen kann, und legt seine PlayerState dann auf SelectingBlaster, was Sie später im Tutorial erfahren werden.

SpawnSpielerInnenInMap
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 Arbeitsbereich > Welt > Karte > Spawns > NeutralSpawn untersuchst, kannst du sehen, dass es einen weiteren Spawn-Ort auf der Karte gibt: NeutralSpawn .Dieser Spawn-Standort ist einzigartig von den anderen, weil er keine Eigenschaft TeamColor mit einem der beiden Teams im Erlebnis hat; stattdessen hat dieser Spawn-Standort eine Eigenschaft Neutral, die sich ändert, je nachdem, ob eine Runde aktiv ist.

Wenn zum Beispiel die Runde aktiv ist, wird die Eigenschaft Neutral auf falsch gesetzt, so dass spawnPlayersInMap Spieler in Teams sortieren und sie in die Arena bringen kann.Wenn die Runde jedoch nicht aktiv ist, wie die Zeit zwischen einer Runde und der nächsten, legt die Eigenschaft Neutral auf wahr fest, so dass Spieler dort unabhängig von ihrem Statusspawnen können.Dieser Prozess ist es, der die Neutrale Spawn-Ort zu einer funktionalen Lobby macht.

Um zu demonstrieren, wenn du ServerScriptService > Gameplay > Runden > SpawnPlayersInLobby untersuchst, die am Ende einer Runde ausgeführt wird, kannst du sehen, dass für jeden Spieler, der in die players: { Player } übergeben wird, das Skript, das. PL: die Skripts:

• Setzt ihre Eigenschaft auf wahr, um sie automatisch auf zurückzusetzen, so dass der Spieler in der Lobby respawnen kann, wenn eine Runde nicht aktiv ist, da auch die Eigenschaft des Spawnstandorts auf wahr gesetzt ist .
• Ändert ihre PlayerState zu InLobby, um die Blaster des Spieler:inund die visuellen Benutzeroberflächen der ersten Person zu entfernen.

Für weitere Informationen über die neutrale Spawn-Zone und ihre Funktionalität für jede Runde siehe Runden hinzufügen im nächsten Abschnitt des Tutorials.

SpawnSpielerInLobby
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

Verbinden Sie neue Spieler

Luau-Code in Studio ist oft ereignisgesteuert, was bedeutet, dass Skripte auf Ereignisse aus einem Roblox-Service hören und dann eine Funktion als Antwort aufrufen.Zum Beispiel muss es bei der Hinzufügung neuer Spieler zu einem Mehrspieler-Erlebnis ein Ereignis geben, das alles handhabt, was für die Verbindung von Spielern erforderlich ist.Im Beispiel-Laser-Tag-Erlebnis ist dieses entsprechende Ereignis Players.PlayerAdded:Connect .

Players.PlayerAdded:Connect ist ein Teil von mehreren Skripten im Erlebnis.Wenn du die Kurztaste Ctrl/Cmd+Shift+F verwendest und nach Players.PlayerAdded:Connect suchst, bieten die Ergebnisse einen guten Ausgangspunkt für das Verständnis der ursprünglichen Einrichtung der Erfahrung.

Zum Demonstrieren öffne ServerScriptService > SetupHumanoid .Die Unterscheidung zwischen Player und Character ist der Schlüssel zum Verständnis dieses Skript, das. PL: die Skripts:

• Ein Spieler ist ein verbundener Client, und ein Zeichen ist ein Humanoid.
• Spieler müssen einen Blaster auswählen und in die Bestenlisteaufgenommen werden. Charaktere müssen spawnen und einen Blaster empfangen.

SetupHumanoid prüft sofort, ob der Spieler einen Charakter hat (gerade beigetreten) oder nicht (wird respawned).Nachdem es eine gefunden hat, ruft es onCharacterAdded() auf, holt das Humanoid Modell vom Charakter und gibt es an ServerScriptService > SetupHumanoid > setupHumanoidAsync für die Anpassung weiter.Nachdem diese Werte festgelegt wurden, wartet das Skript dann, bis die Gesundheit des Charakters auf Null sinkt.Sie erfahren mehr über das Wiederbeleben später in diesem Abschnitt des Tutorials.

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 Notiz mit diesem Skript ist, dass die Eigenschaften vollständig optional sind, was bedeutet, dass, wenn Sie die ersten sechs Zeilen der Funktion entfernen, die Erfahrung immer noch ordnungsgemäß funktioniert.Anstatt funktionale Anforderungen zu sein, ermöglicht jedes Eigenschaft, Designentscheidungen zu treffen, die deinen Spielzielvorgaben entsprechen.Zum Beispiel:

• Wenn du möchtest, dass Charakternamen auf größere Entfernung angezeigt werden, reduziere den Wert von Humanoid.NameDisplayDistance.
• Wenn du nur die Gesundheit eines Charakters anzeigen möchtest, wenn sie unter 100% liegt, stelle Humanoid.HealthDisplayType auf Anzeigen bei Schaden ein.
• Wenn du möchtest, dass sich Charaktere auseinanderfallen, wenn ihre Gesundheit auf 0 sinkt, lege Humanoid.BreakJointsOnDeath auf Wahr fest.

Wenn du die Werte dieser Eigenschaften änderst, ist es wichtig, zu testen, damit du den Einfluss deiner neuen Einstellungen sehen kannst.Du kannst das Erlebnis, das Spieler in einer Mehrspielerumgebung erleben, nachahmen, indem du mindestens zwei Charaktere im Abschnitt Clients und Server des Test -Tab auswählst.

Ein weiteres Beispiel für das Ereignis Players.PlayerAdded:Connect ist in ServerScriptService > PlayerStateHandler .Genau wie im vorherigen Beispiel prüft PlayerStateHandler sofort auf einen Zeichen.Wenn der Spieler nicht in der Lobby ist, legt das Skript ein Spielerattribut auf den Zustand SelectingBlaster fest, den ersten Zustand für eine Runde, in der Spieler aus zwei verschiedenen Blastertypen nach dem Spawnen in der Arena auswählen können.Dieser Zustand beinhaltet auch ein Kraftfeld, das verhindert, dass Spieler Schaden nehmen, während sie ihre Auswahl treffen.

Spielerstatus-Handler
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 erfordert eine Diskussion: attributeChangedConnectionByPlayer .Diese Tabelle speichert alle Spieler und ihre Connections an den GetAttributeChangedSignal .Der Grund, diese Verbindung in einer Tabelle zu speichern, ist, dass sie sich abmelden kann, wenn der Spieler die Erlebnisverlässt.Dieser Prozess dient als Art von Speicherverwaltung, um zu verhindern, dass die Anzahl der Verbindungen im Laufe der Zeit immer größer wird.

Spielerstatus-Handler
local attributeChangedConnectionByPlayer = {}
local function onPlayerAdded(player: Player)

	-- Behandeln Sie alle zukünftigen Updates des Spielersstatus
	attributeChangedConnectionByPlayer[player] = player
		:GetAttributeChangedSignal(PlayerAttribute.playerState)
		:Connect(function()
			local newPlayerState = player:GetAttribute(PlayerAttribute.playerState)
			onPlayerStateChanged(player, newPlayerState)
		end)
end

-- Trennen von der veränderten Verbindung des Attributes, wenn der Spieler geht
local function onPlayerRemoving(player: Player)
	if attributeChangedConnectionByPlayer[player] then
		attributeChangedConnectionByPlayer[player]:Disconnect()
		attributeChangedConnectionByPlayer[player] = nil
	end
end

Du kannst sehen, dass beide verbundene Funktionen in onPlayerAdded() Anruf onPlayerStateChanged() anrufen.Während der ersten Einrichtung nachdem ein Spieler in ein Team sortiert, onPlayerAdded() setzt PlayerState auf SelectingBlaster, so wird die erste if Aussage zu falsch und deaktiviert die BlasterState .Im späteren Implementiere Blaster Abschnitt des Tutorials erfährst du mehr Details zu diesem Prozess.

Spielerstatus-Handler
local function onPlayerStateChanged(player: Player, newPlayerState: string)
	-- Blasterzustand ist nur 'Bereit', wenn Spielerzustand 'Spielen' ist
	local newBlasterState = if newPlayerState == PlayerState.Playing then BlasterState.Ready else BlasterState.Disabled

	-- Stelle die Zerstörungsfeldlogik ein, wenn der Spieler beginnt zu spielen
	if newPlayerState == PlayerState.Playing then
		scheduleDestroyForceField(player)
	end

	player:SetAttribute(PlayerAttribute.blasterStateServer, newBlasterState)
end

Wenn du Breakpoints oder sogar nur eine print()-Aussage hinzufügst, kannst du sehen, dass onPlayerStateChanged() während der Erlebnishäufig aufgerufen wird: wie zum Beispiel während der ersten Einrichtung einer Runde, um sich auf den Hauptcode-Pfad zu setzen, nachdem der Spieler einen Blaster ausgewählt hat, und wenn der Spieler in die Lobby zurückkehrt oder sich zum Neutralen -Spawn-Ort bewegt.Darüber hinaus, nachdem der Spieler einen Blaster gewählt hat, ServerScriptService > BlasterSelectedHandler > setzt die PlayerState auf Playing, und PlayerStateHandler kann schließlich das Kraftfeld entfernen, indem es scheduleDestroyForceField() aufruft.

Kraftfelder anpassen

Anstatt eine benutzerdefinierte Implementierung zu verwenden, verwendet die Probelaser-Tag-Erfahrung die integrierte Klasse ForceField von Studio, um zu verhindern, dass Spieler Schaden nehmen, während sie ihren Blaster auswählen.Dies gewährleistet, dass die einzige Anforderung für Spieler, mit einem Kraftfeld zu spawnen, darin besteht, Spawnorte mit einer SpawnLocation.Duration Eigenschaft einzuschließen, die größer als 0 ist.Die Probe verwendet einen beliebigen Wert von 9,999, um Kraftfelder zu aktivieren, und behandelt dann die tatsächliche Dauer programmatisch in ReplicatedStorage > ForceFieldClientVisuals .

Ähnlich wie setupHumanoidAsync , sind die meisten Zeilen in ForceFieldClientVisuals optional.Wenn du beispielsweise die Inhalte der Funktion wie das folgende Skript deaktivierst, verwendet die Erfahrung das Standard-Funkelfeld statt des hexagonalen Skripts in StarterGui > ForceFieldGui .

Kommentieren von Eigenschaften in ForceFieldClientVisuals
local function onCharacterAddedAsync(character: Model)
    -- lokales Kraftfeld = character:WaitForChild("Kraftfeld", 3)
    -- wenn nicht forceField dann
    -- zurückgeben
    -- beenden
    -- forceField.Visible = falsch
    -- localPlayer.PlayerGui:WaitForChild("ForceFieldGui") aktiviert = wahr
    -- forceField.Destroying:Wait()
    -- localPlayer.PlayerGui.ForceFieldGui.Enabled = falsch
end

Da das benutzerdefinierte Kraftfeld ein GUI ist und nicht ein neues ParticleEmitter, betrifft das ForceFieldClientVisuals -Skript nur die visuellen Effekte der ersten Person für jeden Spieler:in, nicht die visuellen Effekte der dritten Person, wenn Spieler auf andere Spieler schauen.Visuals in der dritten Person behalten das Standard-Roblox-Aussehen.Für weitere Informationen zur Änderung von Kraftfeldern siehe ForceField.Visible.

>

>

Kraftfelder sind nützlich, weil sie den Spielern genügend Zeit geben, zwischen dem Spawnen und Respawnen ohne die Sorge um gegnerische Spieler zu verschwinden, aber schließlich müssen sie für das Gameplayverschwinden.Das Skript, das die Kraftfeldentfernung behandelt, befindet sich in ReplicatedStorage > scheduleDestroyForceField und prüft auf drei einzigartige Bedingungen:

• Nachdem Spieler einen Blaster ausgewählt haben, müssen Kraftfelder lange genug bestehen, um den Spielern Zeit zu geben, sich an ihre Umgebung anzupassen.
• Während dieser Akklimatisierungszeit können Kraftfelder keinen Vorteil darstellen, daher müssen sie verschwinden, sobald ein Spieler seinen Blaster abfeuert.
• Kraftfelder müssen verschwinden, wenn Spieler ihre Charaktere entweder vor der Explosion oder vor Ablauf der Kraftfeldzeit zurücksetzen.

Jede dieser Überprüfungen im scheduleDestroyForceField Skriptaufruf endForceField() für diese Bedingungen.

ZeitplanZerstörungskraftfeld
-- Endkraftfeld, wenn Spieler explodiert
local blasterStateAttribute = getBlasterStateAttribute()
attributeChangedConnection = player:GetAttributeChangedSignal(blasterStateAttribute):Connect(function()
	local currentBlasterState = player:GetAttribute(blasterStateAttribute)
	if currentBlasterState == BlasterState.Blasting then
		endForceField()
	end
end)

-- Endkraftfeld, wenn Spieler zurückgesetzt wird
characterRespawnedConnection = player.CharacterRemoving:Connect(endForceField)

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

endForceField() beinhaltet eine scheinbar seltsame if Aussage rund um den forceFieldEnded booleschen.Da die Prüfungen sequentiell ausgeführt werden, kann das Skript die endForceField() -Funktion zweimal oder sogar dreimal aufrufen.Die forceFieldEnded boolesche Funktion gewährleistet, dass die Funktion nur einmal versucht, ein Kraftfeld zu zerstören.

ZeitplanZerstörungskraftfeld
local function endForceField()
	if forceFieldEnded then
		return
	end
	forceFieldEnded = true

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

Clientzustand verwalten

Während der Großteil dieses Abschnitts sich auf ServerScriptService > PlayerStateHandler konzentriert, gibt es ein anderes Skript mit demselben Namen in ReplicatedStorage .Der Grund für die Aufteilung ist die Client-Server-Architektur:

• Der Client muss die Zustandsinformationen des Spielers verstehen, damit er in Echtzeit angemessen reagieren kann, z. B. die richtigen Benutzeroberflächenelemente anzeigen oder Spieler ermöglichen, sich zu bewegen und zu explodieren.

• Der Server braucht all diese gleichen Informationen, damit er Exploits verhindern kann.Zum Beispiel benötigt der Server auch den Zustand des Spielers, um Aktionen wie das Spawnen und Ausrüsten von Charakteren, das Deaktivieren von Kraftfeldern und das Anzeigen einer Bestenlisteauszuführen.Deshalb befindet sich dieses Skript in ReplicatedStorage und nicht an einer rein clientseitigen Position.

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

Spielerstatus-Handler
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(`Invalid player state ({newPlayerState})`)
	end
end

Alle Antworten auf Ereignisse werden in diesem Skript logisch zusammengefasst, weil sie ein ähnliches Verhalten erfordern, um Steuerungzu aktivieren oder zu deaktivieren, die Kamerabewegung und die sichtbare UI-Schicht.Zum Beispiel müssen Spieler während der Blasterauswahl sowohl unverwundbar als auch nicht Verschiebungswerkzeugsein.Der Server behandelt bereits das Kraftfeld, aber der Client handelt die Bewegung.Um zu demonstrieren, wenn du die Logik für die onSelectingBlaster()-Funktion überprüfst, kannst du sehen, dass der Client die Bewegung des Spielers deaktiviert, während sie einen Blaster auswählen.

Spielerstatus-Handler
local function onSelectingBlaster()
	togglePlayerCamera(true)
	togglePlayerMovement(false)
	setGuiExclusivelyEnabled(playerGui.PickABlasterGui)

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

Die onPlaying()-Funktion ist ähnlich einfach.Es ermöglicht Bewegungen, Übergänge zum Haupt-Head-up-Display (HUD), aktiviert den Blaster und ruft die gleiche Kraftfeldfunktion wie der Server auf.

Spielerstatus-Handler
local function onPlaying()
	togglePlayerMovement(true)
	setGuiExclusivelyEnabled(playerGui.HUDGui)

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

	scheduleDestroyForceField()
end

Charaktere wiederbeleben

Die Probepunktlasertag-Erfahrung behandelt die Wiederbelebung des Charakters durch die onTaggedOut() Zustandsphase in ReplicatedStorage > PlayerStateHandler zurück.Wie der Zustand und aktiviert einzigartiges Verhalten entsprechend den Änderungen am Attribut .Konkret deaktiviert es die Bewegung des Spielers, präsentiert die Respawn-Benutzeroberfläche und deaktiviert den Blaster.

Spielerstatus-Handler
local function onTaggedOut()
	-- Steuerelemente deaktivieren, während markiert wird
	togglePlayerMovement(false)
	togglePlayerCamera(false)
	setGuiExclusivelyEnabled(playerGui.OutStateGui)

	-- Deaktiviere Blaster, während er markiert wird
	localPlayer:SetAttribute(PlayerAttribute.blasterStateClient, BlasterState.Disabled)
end

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

>

>

Es ist wichtig zu beachten, dass dieses Skript tatsächlich keine Charaktere wiederbelebt, es hindert sie nur daran, zu agieren, und gibt visuelles Feedback an Spieler, die der Server ihre Charaktere wiederbelebt.Um zu demonstrieren, wenn du ServerScriptService > SetupHumanoid > setupHumanoidAsync > aufHumanoidDied untersuchst, setzt das Skript PlayerState auf TaggedOut (im Wesentlichen benachrichtigt ReplicatedStorage > PlayerStateHandler ), und fügt einige visuelle Indikatoren hinzu.Die tatsächliche Logik des Respawnens ist ein integriertes Roblox-Verhalten.

Wenn Spieler wieder in die Runde zurückkehren, respawnen sie an der Spawn-Position ihres Teams gemäß der EigenschaftenSpawnLocation.TeamColor.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 .

Humanoid einrichten
local Players = game:GetService("Players")
Players.RespawnTime = 10 -- new line, in seconds

Sonstige Einrichtung

Als Teil der initialen Einrichtung führt das Sample-Laser-Tag-Erlebnis auch einige kleine, aber kritische Schritte aus:

• Das Erlebnis enthält ein leeres Skript namens StarterPlayer > StarterCharacterScripts > Gesundheit , das die Standard-Roblox-Gesundheitsregeneration deaktiviert.Für eine Erklärung des Verhaltens dieser Eigenschaftensiehe Humanoid.Health .

• Die Erfahrung verwendet eine First-Person-Kamera, indem sie die EigenschaftenStarterPlayer.CameraMode.LockFirstPerson festlegt.Beachten Sie, dass, wenn Sie Benutzer ändern lassen möchten zwischen Erster- und Drittpersonenkameras, Sie die Eigenschaft programmatisch ändern müssen, anstatt sie nur einmal im Studio einzustellen, und die Steuerelemente und die Benutzeroberfläche ändern, um die Änderung der Perspektive auszugleichen.

• Die Erfahrung verwendet die integrierte Roblox-Bestenliste mit der Einheit "Punkte", die Spieler jedes Mal verdienen, wenn sie einen anderen Spieler markieren.Du kannst die Konfiguration in ServerScriptService > SetupLeaderboard sehen, aber In-Experience-Leaderboards bietet eine vollständige Übersicht.Beachte, dass onPlayerTagged Punkte zur Bestenliste hinzufügt, die du in Runden hinzufügen und Treffer erkennen lernen wirst.

Jetzt, wo Spieler Spawnkönnen, wähle einen Blaster aus und ziele ihn aus einem Ansichtaus, der nächste Abschnitt lehrt dich über die Skripte, die hinter der Erstellung von rundenbasierten Gameplaystehen.