Blasterverhalten implementieren ist der Prozess, eine Blitzmechanik in Ego-Shooter-Erlebnissen zu programmieren. Während Spieler mit einem einzigen Klick oder Druck auf eine Taste blastern können, ist es wichtig, ein zufriedenstellendes und genaues Blitzverhalten zu erzeugen, da es das Vergnügen der Spieler am gesamten Gameplay verbessert.
Anhand des Beispiel-Lasertag-Erlebnisses lehrt dich dieser Abschnitt des Tutorials die Skripte zur Implementierung des Blasterverhaltens für zwei verschiedene Arten von Blastern, einschließlich Anleitungen zu:
- Erkennen, wann Spieler den Blitzknopf drücken.
- Überprüfen, ob der Spieler seinen Blaster verwenden kann, wenn er kürzlich den Blitzknopf gedrückt hat.
- Generieren von Blitzdaten, die dem Server mitteilen, wer den Blitz ausgelöst hat, wo er herkam und was das endgültige Ziel jedes Laserstrahls war.
- Den Server über die Blitzdaten informieren, damit er die entsprechenden Aktionen durchführen kann, wenn der Blitz mit einem anderen Spieler kollidiert.
- Den Blaster zwischen jedem Blitz zurücksetzen, um dem Blaster genügend Zeit zum Abkühlen zu geben, bevor er erneut blastern kann.
Nachdem du diesen Abschnitt abgeschlossen hast, wirst du mehr über die Skripte erfahren, die es dem Blaster ermöglichen, zu erkennen, wann seine Blitze mit anderen Spielern kollidieren, und dann die entsprechende Menge an Gesundheit gemäß jedem Blastertyp abzuziehen.
Spielerinput erkennen
Der erste Schritt zur Implementierung des Blasterverhaltens besteht darin, zuzuhören, wann ein Spieler den Blitzknopf drückt. Der Inputtyp, den Spieler verwenden, um den Blitzknopf zu drücken, hängt davon ab, welches Gerät sie verwenden, um auf das Erlebnis zuzugreifen. Zum Beispiel unterstützt das Beispiel-Lasertag-Erlebnis Maus- und Tastatursteuerungen, Gamepads und Touchsteuerungen. Du kannst jeden dieser Eingabetypen in ReplicatedStorage ⟩ UserInputHandler sehen.
Dieses Client-Skript verwendet ContextActionService, um MouseButton1 und ButtonR2 mit der Blitzaktion zu verknüpfen. Das bedeutet, dass jedes Mal, wenn ein Spieler entweder die linke Maustaste oder die R2-Taste eines Gamepads drückt, ein Laserstrahl aus dem Blaster ausgeht. Beachte, dass die HUDGui eine Schaltfläche zum Blastern auf mobilen Geräten enthält, die später im Skript verbunden wird.
UserInputHandler
Eine weitere wichtige Anmerkung ist die Verwendung von Enum.UserInputState.Begin in der Definition von onBlasterActivated(). Viele Interaktionen mit der Benutzeroberfläche, wie das Auswählen eines Blasters in diesem Beispiel, treten nicht auf, bis die Maustaste losgelassen wird (Enum.UserInputState.End), was den Benutzern die letzte Chance gibt, die Interaktion zu vermeiden. Ein Blitzmechanismus fühlt sich jedoch nicht reaktiv an, es sei denn, er tritt genau in dem Moment auf, in dem die Taste gedrückt wird.
Um dies zu veranschaulichen, kannst du Enum.UserInputState.Begin in Enum.UserInputState.End ändern und dann das Spiel testen, um zu sehen, wie die Reaktivität des Blitzes das Gameplay des Erlebnisses beeinflusst. Wenn Spieler beispielsweise die Taste gedrückt halten können, ohne den Blitz auszulösen, wie könnte das ihre Erfahrung beim Taggen anderer Spieler verändern?
UserInputHandler
local function onBlasterActivated(_actionName: string,
inputState: Enum.UserInputState, _inputObject: InputObject)
if inputState == Enum.UserInputState.End then -- aktualisierte Zeile, unbedingt zurückändern
attemptBlastClient()
end
end
Überprüfen, ob der Spieler blastern kann
Nachdem UserInputHandler einen Button-Druck oder einen Bildschirm-Tipp erkannt hat, ruft er ReplicatedStorage ⟩ Blaster ⟩ attemptBlastClient auf, um zu überprüfen, ob der Spieler blastern kann oder nicht. Wie die meisten Überprüfungen im Beispiel-Lasertag-Erlebnis erfolgt dies zweimal: zuerst auf dem Client und dann später auf dem Server. attemptBlastClient ruft dann ReplicatedStorage ⟩ Blaster ⟩ canLocalPlayerBlast auf, um eine einfache Überprüfung des blasterStateClient Spielerattributs durchzuführen:
canLocalPlayerBlast
local function canLocalPlayerBlast(): boolean
return localPlayer:GetAttribute(PlayerAttribute.blasterStateClient) == BlasterState.Ready
end
Wenn du ReplicatedStorage ⟩ Blaster ⟩ BlasterState untersuchst, kannst du sehen, dass das Erlebnis drei Blasterzustände hat: Ready, Blasting und Disabled. Um den Effekt jedes dieser Zustände zu sehen, kannst du das Erlebnis testen, deinen Spieler unter dem Players-Dienst auswählen und dann das Attribut blasterStateClient im Eigenschaften-Fenster beobachten. Beachte, wie es Disabled anzeigt, während du deinen Blaster auswählst, Ready die meiste Zeit und Blasting für weniger als eine Sekunde, nachdem du den Knopf gedrückt hast.
Diese kurze Pause verhindert, dass du so schnell blastern kannst, wie du klicken kannst. Wenn du beispielsweise die Funktion änderst, um immer true zurückzugeben, kannst du schnell deinen Blaster ohne Verzögerung abfeuern, was für das Lasertag-Gameplay unrealistisch ist.
canLocalPlayerBlast
local function canLocalPlayerBlast(): boolean
return true -- aktualisierte Zeile, unbedingt zurückändern
end
Blitzdaten generieren
Nachdem überprüft wurde, dass der Blaster des Spielers im Zustand Ready ist, ruft attemptBlastClient ReplicatedStorage ⟩ attemptBlastClient ⟩ blastClient auf. Der erste Schritt, den blastClient unternimmt, ist, das Attribut blasterStateClient des Spielers auf Blasting zu setzen, was den vorherigen schnellen Feuervorfall vermeidet.
Die Änderung des BlasterState auf Blasting spielt auch einen Ton in ReplicatedStorage ⟩ SoundHandler ab.
Der nächste Schritt besteht darin, die Blitzdaten zu generieren. Wenn du ReplicatedStorage ⟩ Blaster ⟩ BlastData überprüfst, kannst du sehen, dass jeder Blitz aus drei Informationen besteht:
- Der Spieler, der den Blitz initiiert.
- Ein DataType.CFrame, das den Ausgangspunkt des Blitzes darstellt.
- Eine RayResult-Tabelle, die das endgültige Ziel jedes Laserstrahls enthält und den getroffenen Spieler, falls ein anderer Spieler getroffen wurde.
Um diese Daten zu generieren, ruft blastClient ReplicatedStorage ⟩ attemptBlastClient ⟩ blastClient ⟩ generateBlastData auf, das du unten überprüfen kannst.
generateBlastData
local function generateBlastData(): BlastData.Type
local blasterConfig = getBlasterConfig()
local rayDirections = getDirectionsForBlast(
currentCamera.CFrame, blasterConfig)
local rayResults = castLaserRay(
localPlayer, currentCamera.CFrame.Position, rayDirections)
local blastData: BlastData.Type = {
player = localPlayer,
originCFrame = currentCamera.CFrame,
rayResults = rayResults,
}
return blastData
end
Diese Funktion beginnt damit, getBlasterConfig zu verwenden, um den Blastertyp des Spielers abzurufen. Das Beispiel bietet zwei Arten von Blastern: einen, der mehrere Strahlen mit einer breiten, horizontalen Streuung erzeugt, und einen anderen, der einen einzelnen Strahl erzeugt. Du kannst ihre Konfigurationen in ReplicatedStorage ⟩ Instances ⟩ LaserBlastersFolder finden.
Die Funktion verwendet dann currentCamera.CFrame als Ausgangspunkt für den Blitz und übergibt ihn an getDirectionsForBlast. An diesem Punkt geht es im Code nicht mehr um den Blaster, sondern um den Laserstrahl, über den du mehr im Abschnitt Treffer erkennen des Tutorials erfahren wirst. Schließlich hat generateBlastData, nachdem die rayResults-Tabelle erstellt wurde, alle Informationen, die es benötigt, um die Blitzdaten an blastClient zurückzugeben.
Den Server benachrichtigen
Sobald blastClient vollständige Daten für den Blitz hat, feuert es zwei Ereignisse ab:
blastClient
Der BindableEvent benachrichtigt andere Client-Skripte über den Blitz. Zum Beispiel verwendet ReplicatedStorage ⟩ FirstPersonBlasterVisuals dieses Ereignis, um zu wissen, wann visuelle Effekte angezeigt werden sollen, wie die Blitzanimation und die Abkühlungsanzeige. Ebenso benachrichtigt der RemoteEvent die Server-Skripte über den Blitz, die dann mit der Verarbeitung des Blitzes in ServerScriptService ⟩ LaserBlastHandler beginnen.
LaserBlastHandler
local function onLaserBlastedEvent(playerBlasted: Player, blastData: BlastData.Type)
local validatedBlastData = getValidatedBlastData(playerBlasted, blastData)
if not validatedBlastData then
return
end
if not canPlayerBlast(playerBlasted) then
return
end
blastServer(playerBlasted)
processTaggedPlayers(playerBlasted, blastData)
for _, replicateToPlayer in Players:GetPlayers() do
if playerBlasted == replicateToPlayer then
continue
end
replicateBlastEvent:FireClient(replicateToPlayer, playerBlasted, blastData)
end
end
Um Betrug zu verhindern, muss der Server alle Daten, die jeder Client sendet, überprüfen. Diese Überprüfungen umfassen:
- Ist BlastData eine Tabelle? Enthält sie ein Class.CFrame und eine andere Tabelle namens rayResults?
- Hat der Spieler einen Blaster ausgerüstet?
- Hat der Spieler einen Charakter und einen Standort innerhalb der Welt?
- Hat sich der Spieler nach dem Senden der Blitzdaten über eine übermäßige Distanz von dem Ort, an dem er den Laserstrahl abgefeuert hat, bewegt?
Diese letzte Überprüfung beinhaltet eine Beurteilung, und je nach Serverlatenz und Bewegungsgeschwindigkeit des Spielers könnte man entscheiden, dass unterschiedliche Werte für dein eigenes Erlebnis übermäßig sind. Um zu zeigen, wie man diese Beurteilung trifft, kannst du ein Print-Statement in getValidatedBlastData hinzufügen und das Erlebnis testen.
getValidatedBlastData
Während du dich bewegst und blasterst, beachte die Ausgabe. Sie könnte ungefähr so aussehen:
Wenn du die Bewegungsgeschwindigkeit für die Spieler in ReplicatedStorage ⟩ PlayerStateHandler ⟩ togglePlayerMovement erhöhst und dann erneut testest, wirst du wahrscheinlich auf viele fehlgeschlagene Überprüfungen aufgrund übermäßiger Bewegung zwischen Blitzen stoßen.
togglePlayerMovement
Aus diesem Grund solltest du, wenn du die Bewegungsgeschwindigkeit erhöhst, in Betracht ziehen, DISTANCE_SANITY_CHECK_TOLERANCE_STUDS in ServerStorage ⟩ ToleranceValues anzupassen. Weitere Informationen dazu, wie du dieses Problem angehen kannst, findest du im Abschnitt Bewegungsvalidierung.
Der Server führt dann Folgendes durch:
- Validiert rayResults.
- Überprüft, ob der Spieler blastern kann.
- Setzt den Blasterzustand zurück.
- Reduziert die Gesundheit für getaggte Spieler.
- Repliziert den Blitz für alle anderen Spieler, damit sie visuelle Effekte aus der Third-Person-Perspektive sehen können.
Für weitere Informationen zu diesen Serveroperationen siehe den Abschnitt Treffer erkennen des Tutorials.
Den Blaster zurücksetzen
Im Beispiel-Lasertag-Erlebnis verwenden Blaster einen Wärme-Mechanismus. Anstatt nach einer festgelegten Anzahl von Blitzen nachzuladen, benötigen sie Zeit zum "Abkühlen" zwischen jedem Blitz. Diese Abkühlungsverzögerung tritt sowohl auf dem Client (blastClient) als auch auf dem Server (blastServer) auf, wobei der Server als Quelle der Wahrheit fungiert.
blastServer
local blasterConfig = getBlasterConfig(player)
local secondsBetweenBlasts = blasterConfig:GetAttribute("secondsBetweenBlasts")
task.delay(secondsBetweenBlasts, function()
local currentState = player:GetAttribute(PlayerAttribute.blasterStateServer)
if currentState == BlasterState.Blasting then
player:SetAttribute(PlayerAttribute.blasterStateServer, BlasterState.Ready)
end
end)
Das Attribut secondsBetweenBlasts ist Teil der Blasterkonfiguration in ReplicatedStorage ⟩ Instances ⟩ LaserBlastersFolder. Nachdem die Verzögerung secondsBetweenBlasts vergangen ist, kann der Spieler erneut blastern, und der gesamte Prozess wiederholt sich. Um dem Spieler zu helfen, zu verstehen, wann er wieder blastern kann, enthält das Erlebnis eine Abkühlungsanzeige.
An diesem Punkt können Spieler erscheinen und wieder erscheinen, zielen und blastern, aber das Erlebnis muss immer noch die Ergebnisse jedes Blitzes bestimmen. Im nächsten Abschnitt des Tutorials wirst du lernen, wie du die Fähigkeit programmierst, dass der Blaster erkennt, wann der Blitz einen anderen Spieler trifft, und dann die entsprechende Menge an Gesundheit der Spieler gemäß den Blastereinstellungen reduziert.