FPS AI Übungsprojekt

Der Text ist noch WIP!!!

Ich bin mir nicht ganz sicher ob dies das richtige Forum hierfür ist, da es Teils Projektvorstellung ist, teils Workflow/DevDiary. Da man hier ja auf Deutsch schreibt geht das ja ohne Aufwand und es könnte für etwas Lese/Diskussions Stoff oder Fragen sorgen. Was Fragen angeht will ich das ganze relativ Transparent entwickeln, daher habe ich außer Zeit, kaum Hindernisse eine Frage zu dem ganzen auch zu beantworten:


Einführung
Ich habe schon seit längerem an einem "kleinem" Übrungsprojekt gearbeitet. Es gab im letztem halben Jahr auf Grund von Studien- und Diplomarbeit eine Pause und nun Arbeite ich wieder daran. Hauptsächliche Ziele sind für mich folgende:

• Lernen des Erstellens einer AI mit BehaviorTrees und EQS als Hauptkomponenten
• Programmieren eines recht allgemein gehaltenen Engine Moduls, was die Grundlagen für Menüs, Networking, etc für mich enthält und daneben auch Blueprint Libraries mit funktionen, die ich as nützlich erachte. Dieses sollte so sein dann ich es in so viel wie möglich Pojekten weiterverwenden kann.
• Programmieren der Grundlagen eines FPS, der vom Player Featureset eher Richtung Tactical FPS geht. Eine etwas realistischere Anwendungssituation schien mir sinnvoll für meine Übungen als nur kleinere Studien zur AI.

Anzumerken ist, dass es sich nur, um ein Hobbyprojekt handelt. Daher gibt es kaum richtige Zeitpläne oder substanzielle Pläne in welcher Form und wie ich es veröffentliche, wobei ich ab irgendeinen Punkt mindestens eine coocked Version irgendwo regulär hosten würde. Dieser thread soll in erster Linie als eine Art Devblog dienen in dem ich meine Gedanken und herangehensweise dokumentiere und die resultate zeige. Ich hoffe dass ich hiermit auch etwas meine Gedanken dazu Ordnen kann, oder vielleicht auch von euch etwas dazukommt.

Abkürzungen: FPS - first person shooter, FPP - first person perspective, TPP - third person perspective, BT - behavior tree, OSS - online subsystem, NYI - not yet implemeted

Der FPS Teil:
In diesem ersten Post gehe ich auf die schon bestehenden Features des FPS Teils ein. Je nach nachfrage schreibe ich vielleicht einen etwas detaillierteren Post zum Aufbau bestimmer systeme, aber wahrscheinlich keine richtigen Tutorials. Hier geht es hauptsächlich, um die Vorstellung dessen, was ich schon habe.

Allgemein
Statt wie normal in einem FPS habe ich mich an einer True FPP gewagt. Hierbei wird für FPP und TPP dasselbe Mesh verwendet. Zum einen hatte ich dafür schon ein setup für einen Prototypen für ein Parkour game erstellt, zum anderen wollte ich experimentieren wie doll ein Spiel davon profitiert, da in vielen FPS für mich Beine und Arme Perspektivisch falsch vorkamen, falls der Charakter überhaupt in der FPP Beine hatte. Ein recht neues Beispiel wo es Merkwürdig wirkt ist z.B. Rainbow Six Siege.
Hauptinspiration ist Rainbow Six Ravenshield. Das heißt meine ersten Ziele sind ein Coopfähiger "Terrorist"hunt Mode, Waffenanpassung, mindestens eine Waffe jeden Typs der existieren soll, mindestens ein Attachment jedes Typs das existieren soll, ein oder zwei kleinere Levels.
Ich habe mich für ein eher modernes Setting entschieden, damit ich für eventuelle Assets einfach Fotos als referenz nutzen kann. Das spart mir Konzeptzeichnungen, die ich eh nicht so gut kann.

Movement
Das Movement des Spiels ist relativ simpel und dicht an den schon bestehenden CharacterMovementComponent gehalten. Hinzu kamen das Kriechen und Sprinten. Als weitere Animationsbasierte Manöver gibt es auch Vaulting und Climbing, um kleinere Hindernisse zu überwinden. Des Weiteren kann man mit dem Scrollrad die Laufgeschwindigkeit des Charakters verringern/erhöhen. Es wurde auch dafür gesorgt, dass die AI auch auf diese Features zugriff hat. Zum einen funktioneren Climb und Vault nur über bestimme im Level platzierte Marker. Eine prozedurale Lösung wäre zwar möglich gewesen, jedoch kann ich so über ConstructionScripts automatisch NavLinks generieren, über die ich diese Movement Features ins NavMesh integrieren kann. Dadurch ist der AI schon beim Pathfinding klar, dass es diese Movements ausführen muss bzw. können die Movements von der AI getriggert werden, wenn die NavArea Class sich verändert. Die Grundidee dazu kam von diesem Tutorial von Mieszko Zielinski. Derzeitig läuft die Vault und Climb Bewegung über Root Motion ab, jedoch kann es sein, dass ich auf ein Pseudo-Root-Motion system umsteige, falls es probleme im Multiplayer damit gibt. (Näheres dazu ist in Videos zu Paragon von Epic erklärt)

Dazu gibt es das für Tactical FPS typische zur Seite lehnen. Dies ist jedoch eher ein Animation Feature.

[Demonstationsvideo folgt]

Die AI hat dazu noch zugriff auf ein simples Coversystem, wobei dieses eher als Verbindungselement zwischen AI-Movement und Animationen zu sehen ist.

Waffen
Das Waffensystem ist in C++ geschrieben. Der Zielworkflow soll am Ende so sein, dass man für eine standard-waffe nur Werte im Blueprint verändern muss und keine Zusätzlichen Nodes erstellen muss. Jedoch die möglichkeit hat über Funktionoverrides jegliche Funktionalität über Blueprint zu verändern. Will man also eine Waffe die beim Schießen nicht nur HitScan oder ein Projektil abfeuert, dann kann man z.B. die OnFire Funktion in Blueprint verändern. Soll es statt einen Muzzleflash vielleicht einen Effect am Waffenmaterial gehen (blinken, etc) dann erweitert man eben die SimulateFire Funktion.
Über Waffenattachments sollen, stats der Waffe verändert werden können. Dazu gehören eben Sights, Griffe, Laserpointer, etc, wie man es aus solchen Games kennt.
Ich nutze hauptsächlich die Waffe von Ironbelly studios aus dem Marketplace, da diese FPP Animationen besitzt, was für mich den Preis, recht gut kompensiert.

Animationsystem
Für die Animationen habe ich Kubolds Motion Capture Animationen genutzt. Diese decken das nötige Spektrum an Animationen für einen Shooter gut ab, jedoch sind diese hauptsächlich für TPP gemacht. Daher musste ich für die FPP über Skeletalcontrols die Waffe vor dem Kopf (und damit vor der Kamera) stabilisieren. Dies hatte zwar einen gewissen Aufwand an Arbeit, jedoch ermöglicht es mir noch folgende weitere Dinge:
Prozedurales Recoil/Weapon Swaying oder allgemein prozedurale Waffenanimationen und das Steuern der Arme über externe Objekte. Im jetzigen Status werden Recoilanimationen in den Waffen in Form von mehreren Float-Kurven festgelegt und Reload Animationen in der FPP werden von einem versteckten FPPMesh gesteuert, damit diese in der FPP gut bzw. wie in einem regulären FPS aussehen. Auch für Aim Down Sight kann ich die position der Waffe im Editor tweaken, statt es in einem Animationsprogramm tun zu müssen.
Als weiter Experimente habe ich vor, dass die Genauigkeitsverluste durch Bewegung in der Animation dargestellt werden, statt des derzeitigen Random Cone of Fire Systems.
Dazu gibt es auch Skeletalcontrols welche die Wirkelsäule steuern für das Lehnen nach rechts und links und SkeletalControls, mit denen ich Footplacement auf unebenem Untergrund vornehmen kann.
Man kann sich jetzt schon denken, dass diese Systeme zum Teil störend sein können in bestimmen Animationen. Will man z.B. die Vault Animation abspielen möchte man z.B. nicht unbedingt die Hände an der Waffe haben. Dazu habe ich zusätzliche Animation-Curves eingeführt, über die der Blend-Wert jeder dieser Controls gesteuert werden kann, falls eine Animation diese Funktionen nicht benötigen.

[Demonstationsvideo folgt]

UI/Menüs
Während ich das Ingame UI so minimal wie möglich halten will, möchte ich ein robustes UI system haben, welches auch Contoller Input gut unterstützt. Dabei will ich vorallem ein Gutes zusammenspiel zwischen C++ und UMG haben. Das Ideale Ziel für mich ist hierbei, wenn der Designspezifische Teil in UMG abläuft und nur sehr spezielle Logik dort in Blueprint Programmiert werden muss, während der Hauptteil der Logik in C++ stattfindet. Derzeitig läuft es so, dass ich für bestimmte Menüs C++ Basisklassen für die UMG Widgets erstellt habe und in den UMG Widgets bei Kopfdruck events die entsprechende Funktion aufrufe.
Geplante Menüs sind:

• Grafikoptionsmenü. Einstellen aller Scalability Settings und der nötigen DisplayFlags für Effekte wie Chromatic Abberation, Motion Blur, etc. (done)
• Sound options menü. Einstellen der Lautstärken (done), Verschiedene Sound Profile für Kopfhörer und Speaker betrieb. (NYI)
• Keybindings und Einstellen der Achsensensitivität für Maus. (done)
• Controllerbindungs und Einstellen der Achsensensitivitätskurven und Deadzones der Sticks. (NYI)
• HUD Customization (NYI)
• NewGame/HostGame Menü, Serverbrowser (WIP)
• Hauptmenü (done) mit Welcomescreen (NYI)
• Friendslist (integriert mit OSS) (WIP, anzeige der freunde und des online statuses funktioniert)

Jetziger Fokus:
Zurzeit strukturiere ich die AI gerade etwas neu, da ich nun das Prinzip der Behavior Trees besser verstanden habe, und erweitere die AI um Funktionen wie das in Deckung gehen, etc. Damit sollte vorallem das Problem gelöst werden können, dass man als Spieler wenige Chancen hat gegen die AI zu gewissen, wenn man überrascht wird.

Bevor ich ins Bett gehe lasse ich euch ein Video hier von dem, was ich habe in Aktion:

Mehr ist z.T. auf meinem Youtube Kanal zu finden. So einige neuere Videos sind noch nicht gelistet, da es recht kurze feature demonstrations für Kumpels im chat sind, da kommt später noch etwas.

Zitat von kraid

So muss eine Projektvorstellung aussehen. Klasse gemacht.

Viel Erfolg mit deinem Projekt.

Danke.
Ein kleines Update: Cover Animationen integriert. AI nimmt nun diese Animation, wenn sie in Deckung gehen will und eine NavArea auf dem NavMesh betritt, welche einen entsprechenden Flag gesetzt hat. Man sieht hier aber schon das Problem, dass der Gegnerische Pawn die Sight Perception verliert, da dort eine Wand im Weg ist. Da muss ich wohl gezwungenerweise dafür sorge, dass die AI leicht schummelt bis ich ein gutes Prediction/Estimation system eingebaut habe. Daher muss ich zur Zeit auf den armen Charakter schießen, damit er nen Perception Informationen über Damage bekommt.

Vielleicht schreibe ich heute Abend noch etwas zu meinem ersten AI Milestone und über ein paar Dinge, die ich versucht habe und wie gut/schlecht sie funktioniert haben.

Zitat von Sentino

WOW GEIL

Will mehr.

Ich find du hast das "zielen" usw richtig geil gemacht.

Wie sieht es aus mit dem Dmg System? sterben die "Feinde" nach ein paar Schüssen?

Planst du es eher realistisch oder so COD like?

Bin eher realistik fan

(lese mir gleich die Beschreibung durch)

Alles anzeigen

Auch danke. Zur Zeit sterben Feinde nach nur paar Schüssen, der Charakter im Grunde auch, wobei ich zum Debuggen natürlich Damage Reduction Cheats eingebaut habe. Das Slowmotion ist auch eher zum Debuggen da, damit ich wenn vieles parallel passiert einen guten Überblick habe und z.B. auch die prozeduralen Animationen bzw. Animationen allgemein gut Debuggen kann.
Ich will am Ende wohl eher beim Realistischen landen, aber das ist hauptsächlich dann Value-Tweaking und eine faire Gegner AI. Soll aber auch keine Militärsimulation ala ARMA werden.

Zum Technischen des Damage Systems. Es ist im Grunde ein einfaches HealthSystem mit HP. Headshots haben einen DamageMultiplikator, der nicht unbedingt tödlich ist zur Zeit, falls der Schuss z.B. vorher durch Glas oder eine Penetrierbare Oberfläche geht. Weitere Eigenschaften wie eine Headshotmultiplier, HitReaction für die AI, etc. sind in einem erweitertem DamageType abgelegt.
Da ich hauptsächlich CQC Situationen haben will, gibt es keine richtige Projektilsimulation. Eine realistische Simulation würde bei realistischen Projektilgeschwindigkeiten auf den Distanzen so oder so auf Hitscan hinauslaufen, jedoch will ich Querschläger irgendwann einbauen.

Heute Mal ein Post der etwas mehr erklärt, was ich gemacht habe. Ich würde im Grunde wissen, wie so etwas ankommt also ob es hilft, oder nicht. Mein Gedanke war, dass es im Gegensatz zu Tutorials kompliziertere Themen abdecken kann, da ich nicht großartig in die Ausführung des ganzen gehe, sondern eher in die Struktur. Z.T. muss ich wahrscheinlich auch noch üben, meine schlechte Schreibangewohnheiten, wie Schachtelsätze zu vermeiden. Ich entschuldige mich schon im Voraus für Typos. Bin echt schlecht darin Typos zu finden, wenn ich den Text nur am Bildschirm sehe.

Nun da im groben das Main-Game geklärt ist zu meinen Zielen mit der AI, der Hauptgrund warum ich das ganze überhaupt mache.
Mir ist recht oft aufgefallen, dass bei Indie Games vor allem Singleplayer Titel bessere Chancen haben ein Nischendasein und einen gewissen Kultstatus zu erreichen, während reine Multiplayer Titel das Problem haben eine Community aufzubauen und diese zu halten. Der Grund ist immer, dass viele Spieler die Sicherheit wollen, dass sie ein Spiel so spielen können, wie es vorgesehen ist. Das braucht oft eine entsprechende Playerbase. Es daher für viele schwer zu rechtfertigen ein Spiel zu kaufen, wenn diese Sicherheit nicht garantiert ist. Man steht also vor einen "Chicken and Egg"-Problem: Das Spiel hat keine große Spielerschaft und die Spieler die interessiert sind sind abgeschreckt, da es die Befürchtung gibt, dass Spiel nicht richtig spielen zu können. Dadurch ist sogar ein Nischendasein ausgeschlossen, da nur "Alles oder Nichts" möglich ist.

Für mich schien also der logische Schritt: wenn ich einen Multiplayer Titel mache sind Bots ein muss und 2. muss es ein Titel sein der auch mit einer kleinen Gruppe oder alleine viel Spaß macht. Dadurch sollte es möglich sein, dass trotz geringem Hype ein gewisses Nischendasein überhaupt möglich ist, damit wären die Unsicherheiten beim Kauf eliminiert. Ich habe mit Freunden aus meiner Pen&PaperRPG Gruppe immer wieder Ravenshield gezockt, wenn wir z.B. nicht genug Leute für eine RPG Sitzung waren oder wir einfach zu wenig Zeit dafür hatten.

Das erste Ziel war also eine Gegner AI.
1. Milestone

• AI ist sich nur über Gegner bewusst, die sie sehen/hören/spüren(damage) kann, oder über Team Mitteilungen kennt.
• vermeidet Team Killing.
• kann über eine einfache Implementation Türen öffnen
• kann auf das Vault- und Clim- System zugreifen]
• geht beim Nachladen in Sicherheit
• nimmt Verfolgung auf, wenn Gegner aus der Sicht ist. (Mit nur sehr einfacher Positionsabschätzung)
• Kommt anderen Teammitgliedern zur Hilfe, wenn diese es anfordern und der Weg nicht zu weit ist.

Dies ist vor allem dazu da, um mich mit den nötigen System vertraut zu machen. Diese wären Perception, EQS und Behavior Trees. Die Implementation die man in den Videos sehen kann sind verschiedene Stufen davon. Eine gute Quelle zu Behavior Trees war unter anderem diese Quelle: http://www.gamasutra.com/blogs…_for_AI_How_they_work.php
Neuerdings ist auch der erste Band von GameAIPro kostenlos auf deren Webseite http://www.gameaipro.com/ verfügbar und definitiv auch lesenswert.
Wenn man sich diese Anforderungen ansieht, zeigt es auch, dass man wahrscheinlich nicht mit einem reinen Behavior Tree alles abdecken kann. Diese sind zwar großartig für die Wahl von Aufgaben, aber für mich schienen sie nicht ganz so gut zu sein für Aufgaben, deren inneres sich immer wiederholt. Im Kampf z.B. muss ein Character sich immer wieder neu positionieren, z.B. als Reaktion auf die Bewegung des Spielers, oder ach um dem Schussfeld eines Freundes auszuweichen bzw. um zu verhindern, dass ein Freund ins Schussfeld kommt.
Der Parallel-Task-Node war dabei Hilfreich so etwas wie einen Pseudo-State hinzubekommen. Dieser Parallel Node läuft so lange, wie der Main Task läuft. Daher wird die Main Task so designt, dass er so lange anhält, wie ein "In-Combat" State anhalten soll.
Die erste Version des Behavior Trees sah grob wie folgt aus:

Zum Verständnis:
Ein Selector Node in BehaviorTree wählt Aktionen von Links nach Rechts. Dabei wird durch die Aktionen gegangen bis eine Aktion einen Erfolg meldet. Bei einem Erfolg wird also der Selector verlassen, bei Misserfolg wird der rechte Nachbar versucht ausgeführt zu werden. Ein Sequenz Node dagegen wandert bei Erfolg zum Nächsten Sub-Baum und bricht die komplette Sequenz ab, wenn es einen Misserfolg gibt.

Zuerst wird also immer versucht auf einen Gegner in Sicht zu feuern. Dieser Task hält solange an, wie der Gegner in Sichst ist (Decorator) oder bis die Munition ausgeht (Failure der Feuern Task). Dabei wird Parallel immer nach guten Positionen zum Feuern gesucht. Dieser sub-Baum endet immer mit einem Fehlschlag. Daher wird danach immer der Nachlade-Baum betreten. Hier wird zuerst geprüft ob das nachladen überhaupt notwendig ist (Decorator). Hier muss ich einen kleinen Fehler eingestehen. So wie es aussieht ist ein Decorator eher für den FlowControl während der Ausführung eines Baums gedacht, um ihn mitten in der Ausführung abzubrechen. Es wahrscheinlich sauberer gewesen eine Sequenz zu erstellen in der erst geprüft wird und dann nachgeladen und parallel die Bewegung stattfindet. Da es aber auch so funktioniert, kann es jeder handhaben wie er möchte.
Der Reload Baum endet bei erfolgreichem Reload in Erfolg. Daher wird der Baum zurückgesetzt und es wird zuerst geprüft ob wieder auf Gegner gefeuert werden kann. Ist dies nicht der Fall kommt man zum Reload-Baum, welcher mit voller Waffe fehlschlägt. Danach gelangt man in den Verfolgungs-Baum. Hier wird der Gegner verfolgt bis der Charakter ein besseres Ziel findet und wieder in den Combat Baum gelangt, oder aufgibt (time-out).
Verfolgung steht hier für mehrere Dinge.

• Verlorene Sicht-Ziele werden für eine Weile im Gedächtnis behalten. Diese werden mit höchster Priorität verfolgt.
• Ziele, die der Charakter hört, spürt (damage) oder über Team-Mitglieder kennt, werden auch in diesem Task gesucht, um diese in Sicht zu bekommen.

Eine bessere Bezeichnung wäre wohl Suchen statt Verfolgen.
Als letzter Sub-Baum gibt es die Aktion wieder zurück zum Ausgangspunkt zu gehen. Diese wird nur ausgeführt, wenn alle anderen Task nicht ausgeführt werden können, oder Fehlschlagen. Der Charakter geht also wieder Zurück zu seiner Ausgangsposition und steht dort Wache.

Das Video zeigt ganz gut, was das Ergebnis des ganzen war. Für mich war das schon ein zufriedenstellender Anfang. Probleme gab es noch beim sehr grob implementierten Türen öffnen, wenn die Tür in Richtung des Charakters aufgeht.

Für das Aiming der AI habe ich ein über Beschleunigung laufenden Modell genutzt, diese Beschleunigung wird über einen geschlossenen Lageregelkreis gesteuert. Dieser ist im Grunde ein kaskadierter PPI Regler. Das ganze war für mich ein Experiment, wie gut sich solche einfachen Servomotor-Regelkreise in der Spielentwicklung eignen können. Für mich war das Aiming zu schnell und zu präzise, trotz beabsichtigtem Überschwingen des Reglers. Jedoch muss ich noch schauen ob es nicht besser Funktioniert, wenn ich die Sollwerte verfälsche.

Ausblick/Jetzt (2. Milestone)
Mir sind im Grunde die Grundlagen nun bekannt. Jetzt geht es darum den bestehenden Tree aufzuräumen, zu verfeinern und dafür zu sorgen, dass die AI deutlich komplexere Manöver ausführen kann. Im Kampf soll sie in Deckung gehen und hin und wieder aus dieser raus kommen zum feuern. Sie muss Gefahren wie Granaten entgehen. Hier wird es höchstwahrscheinlich Probleme geben ein Team aus AI Charakteren zu koordinieren, da nun die optimalen Positionen begrenzt sind. Die Charaktere werden sich also höchstwahrscheinlich über diese Positionen streiten. Die AI Charaktere müssen sich also nun bewusst über ihre Freunde in der Umgebung sein. Koordinierte Team Bewegungen sind jedoch noch nicht in diesem Milestone geplant.
Der komplexere Tree wird auch mehr Herausforderungen im FlowControl bringen.

Ein weiterer Gedanke den ich hatte: Da ich in der Diplomarbeit mit bayesischen Schätzern (um genau zu sein einem Maximum-A-posteriori Schätzer) zu tun hatte, hat sich mir die Frage gestellt, in wie fern ich solche nutzen kann für die Estimation von Gegnerpositionen mit Priori knowledge (z.B. einer vorher aufgenommenen HeatMap) und den unsicheren Perception Daten. Zuerst will ich jedoch sehen ob so ein kompliziertes System überhaupt nötig ist. Da muss ich wohl eine Literatur Recherche machen

Mal ein kleines Update zum Loadout Menü:

Habe mich Mal um das ACOG Sight gekümmert, damit meine Sight Klassen die Möglichkeit besitzen RenderTargets zu nutzen. Während des Uploads habe ich das Material noch etwas verbessert, damit es ein paar schwache Reflektionen auf der Linse gibt.

Danke für die netten Worte.

Zitat von Sentino

Sieht wirklich wiedermal gut aus!

Ist das langsame Zielen absicht?

Nicht aus Gameplay Sicht. Das Slowmo is mehr zum Spaß drin bzw. habe ich es eingeführt um in Ruhe gewisse animationen/übergänge oder AI verhalten anschauen zu können.
Falls es ums Zielen an sich geht, das zur Hälfte meinem schlechten Aim zu schulden und zur anderen Hälfte, dass ich Rückartige bewegungen im Video möglichst vermeiden will. Allzu bewusst filme ich das ganze aber nicht.

Zitat von Dj EKI

Als nächstes möchte ich Schusslöcher sehen !! :pinguin:

Da hätte ich ein paar Ideen zu. 4.13 soll ja endlich UV koordinaten bei HitResults mit angeben. Da könnte man vielleicht über UCanvas oder anderen Mittel für Türen und dünne Wände sogar richtige Löcher machen in dem man in der Laufzeit eine Maske erstellt.
Ansonsten kann man natürlich einfach decals spawnen, da habe ich schon mit POM experimentiert, aber ich glaube einfache Decals mit Normal map arbeiten besser, da die POM decals bei mir irgendwie für nen Graphics Driver Crash sorgen, wenn ich diese in größeren Massen spawne. Falls irgendwer mutig ist kann ich ihm nen beispiel projekt mit den POM decals zukommen lassen, damit er mir sagen kann ob es bei ihm auch solche Probleme gibt.
Hier mal mein video zu den POM Decals:

Ein kleines Experiment:
Da in 4.13 nun UV Koordinaten zu FHitResults abgefragt werden können, habe ich mir mal gedacht, dass man über Canvas während der Runtime dynamische OpacityMasks generieren könnte. Das hier ist nur ein schenller Prototype dafür. Eigentlich ein netter Effekt, aber keine Ahnung ob ich den wirklich nutzen werde.

Der Aufbau ist recht einfach. Zuerst muss man in 4.13 das Settings "Support

Bei den Traces muss man dann in den Einstellungen dafür sorgen dass die FaceId mit zurückgegeben wird.

Nun kann man folgendes BP erstellen.

Das Event Simulate Hit gehört zu meinem Waffen System. Es wird dann Ausgeführt, wenn lokal die Treffer Effekte gespawnt werden. Das Impact FX Component ist ein ActorComponent, was die standardmäßigen Partikel Effekte, Decals, Sounds beim Treffer, mit anderen ausgetauscht werden können, z.B. wenn ein Objekt spezielle Sounds beim Treffer haben sollen. Das Event ist eine Möglichkeit das Verhalten beim Treffer etwas komplexer zu gestalten, wie hier.

Dazu wird ein dazugehöriges Material erstellt:

Wichtig ist der TextureParameter in welchem in der Laufzeit der CanvasRenderTarget eingesetzt wird und das Material auf Masked gestellt ist.