FPS AI Übungsprojekt

    • Offizieller Beitrag
    Zitat von LucyDemoon

    kommt mir das nur so vor oder wiederspricht sich das,


    denn wenn ich wissen will wie was geht weis ich auch warum es so geht

    Wenn man nur weiß welche Knöpfe man drücken muss um ans Ziel zu kommen statt die Technik dahinter zu verstehen.


    Man kann in Blender oder jedem anderen Programm auf einen Knopf drücken und die UV ist fertig. Das UV-Mapping aber zu beherrschen und zu verstehen dafür braucht man technisches Wissen und muss wissen wie das UV-Mapping überhaupt funktioniert.
    Bei einem Vorstellungsgespräch würde man daran einen guten und einen schlechten Artist erkennen.


    Das ist übrigens auch ein Grund warum ich dinge gerne ausgiebig erkläre und nicht einfach nur die Lösung poste.

    Zitat von Sleepy

    Wenn man nur weiß welche Knöpfe man drücken muss um ans Ziel zu kommen statt die Technik dahinter zu verstehen.
    Man kann in Blender oder jedem anderen Programm auf einen Knopf drücken und die UV ist fertig. Das UV-Mapping aber zu beherrschen und zu verstehen dafür braucht man technisches Wissen und muss wissen wie das UV-Mapping überhaupt funktioniert.
    Bei einem Vorstellungsgespräch würde man daran einen guten und einen schlechten Artist erkennen.


    Das ist übrigens auch ein Grund warum ich dinge gerne ausgiebig erkläre und nicht einfach nur die Lösung poste.

    Das ist richtig, leider mich selbst auch schon oft dabei ertappt das ich es genau nicht so mache.


    Aber viel wichtiger als nur Tutorials anzuschauen ist Dinge zu verstehen. Übrigens auch in anderen Situationen im Leben.


    Wie geht es eigentlich mit dem Projekt voran? :)

    Danke für die ganzen Antworten.



    Zitat von Sleepy

    Bin leider kein Video gucker ich kannst dir gern in einer Teamview Runde erklären aber Videos kenne ich keine.

    Bin auch kein Video gucker. TeamView kommt mir wie ein wenig zu viel Aufwand vor. Aber Danke für das Angebot.
    Ich werde da schon selber klar kommen oder das finden was mir da Vorschwebt.


    Zitat von sehrwitzig

    Sollte man auch besser nicht. :lol: Find ich wirklich gut. Die Fußbodengeräusche haben aber noch etwas von einem Stepptanz.
    Und die Gegner sind auch nicht nur Zielscheiben, wie man sieht. Klasse.

    Lol. Joa wenn man Sounds sieht sollte man sich Gedanken machen.
    So ganz zufrieden bin ich auch noch nicht. Ich weiß aber noch nicht so richtig wo ich dort ansetzen sollte. Wahrscheinlich sind es mehrere Dinge, beim langsam/leise gehen wird noch der selbe Sample abgespielt wie beim Laufen, jedoch würde sich da so einiges Ändern wie man mit dem Fuß auf dem Boden aufkommt. Zur Zeit finde ich auch an einigen Animationen den Sound den ich dazu abspiele zu laut, wie z.B. beim positionieren der Füße während der Stopping Animations und Turning Animations. Auch Details wie rauschen/rascheln von Kleidung, etc wären vielleicht hilfreich. So ein wenig warte ich jedoch darauf dass die neue Sound Engine von UE4 weiter ist, bevor ich so richtig mit Sound weiter mache.



    Was Status des Projektes angeht. Viel passiert nicht, außer Detail Änderungen. In den Letzten Wochen hatte ich aber auch kaum Lust noch nach der Arbeit am PC zu sitzen und noch mehr zu programmieren.
    Ist auch nicht schlimm, da mein Ziel mit dem Projekt ist es, meinen Spaß dran zu haben und hin und wieder etwas Neues zu lernen.


    Ein kleines update. Ich habe mich entschieden doch die Rückstellfedern einzubauen. Ich glaube das gibt dem ganzen einen besseren Gesamteindruck. Eigentlich sind diese wie viele Teile in der Realität schwarz lackiert.
    Ich mag es jedoch wenn man auf dem ersten Blick viel von dem Teil verstehen kann. Daher mache ich gerne Schrauben und so sichtbar und versuche Einzelteile etwas voneinander abzuheben.


    Find ich gut, solche Details lassen es nur (noch) besser wirken. Ist ein bewährtes Stilmittel würde ich sagen. :)


    Ist auch ein interessantes Gerät, basiert es auf einer echten Vorlage oder hast du es in komplett Eigenregie modelliert?

    Das Teil gibts in der Realität, wobei ich jedoch ein paar Freiheiten genommen habe. Einfach mal nach Cornershot googlen oder auf YouTube suchen, dann findet man was dazu.
    Ist eben ein Gerät mit dem man um die Ecke schießen kann, hauptsächlich dazu entwickelt dass Anti-Terror oder Polizei-Spezialkräfte sicherer einen Raum stürmen können. Gibts scheinbar auch mit Plüschkatzenaufsatz.

    Cool hab mir gerade auf YT ein "Review" angeschaut, immer wieder erstaunlich was die Amis so zuhause rumliegen haben. Das mit der Katze ist aber echt mal fies :D


    Dein 3D Model ist jedenfalls schön authentisch, das gefällt mir.

    Progress:


    Noch sieht es aber nicht interessant genug aus wenn man durch schaut, da muss ich noch etwas im inneren arbeiten.


    Update:

    Ein wenig kürzer, damit das innere vom Sight beim durch schauen nicht zu viel Screen Sapce einnimmt. Und die Halterung der Linse etwas modelliert.

    Noch mal ein 3D modell von nem Sight, weil ich gerade nichts anderes tun kann, da ich gerade meine Eltern besuchen bin und keinen PC mithabe mit dem ich UE4 laufen lassen kann.


    Kompaktes Sight von dem selben hersteller wie oben.



    Ein wenig Code habe ich auch noch gemacht, aber nichts was allzu spektakulär ist, sondern eher den Workflow für mich vereinfacht.

    Heute endlich mal wieder dazu gekommen was zu machen.



    Jetzt wo ich langsam den Marmoset baker immer mehr beherrsche werden die bakes auch recht schön.
    Bei der schraube die ich mit Quixel eingefügt habe sollte ich vielleicht noch etwas an der AO/Cavity arbeiten, damit es besser aussieht.


    Ich habe hier auch mal das GI in Marmoset ausprobiert. Eigentlich gefällt es mir, da es besser beleuchtet, aber einige Sachen "leuchten" mir zu viel. Da ist es ohne GI näher an UE4.

    Naja mal wieder etwas dran gearbeitet.
    Ein kleines Experiment. Beidhändiges Waffenhandling:

    Externer Inhalt www.youtube.com
    Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
    Durch die Aktivierung der externen Inhalte erklären Sie sich damit einverstanden, dass personenbezogene Daten an Drittplattformen übermittelt werden. Mehr Informationen dazu haben wir in unserer Datenschutzerklärung zur Verfügung gestellt.


    Ist nur ein recht kleiner Fortschritt, da es hauptsächlich Animation Mirroring war, was ich über ein plugin implementiert habe und etwas vorzeichenwechsel für meine IK-controller.


    und etwas wo ich noch kein Video habe, weil es schwer im detail zu visualisieren ist:
    Man sieht es ja in vielen Videos dass die AI bis jetzt immer sofort reagiert hat, wenn sie den Spieler sehen konnte.
    Ein kleines update in der AI sight perception soll das beseitigen. Jetzt funktioniert es so, dass jeder AI Charakter eine Awareness map besitzt, die mit einem Wert spezifiziert wie sehr diese Gegner wahrnimmt.
    Der Wert steigt für den jeweiligen Gegner, wenn sie einen Gegner sieht. Die steigung ist abhängig wie gut sie den Gegner sehen kann. Guckt z.B. nur der Kopf hervor, so dauert es länger, sieht sie den kompletten Körper so steigt der Wert sehr schnell. Wird ein Gegner nicht gesehen so sinkt der jeweilige Wert in der Map.


    Dann gibt es verschiedene Grenzen.
    0 - Ist sich keines Gegner bewusst: Kleiner Sichtkegel, Waffe unten.
    1 - Hat verdacht, dass ein Gegner da sein könnte. Großer Sichtkegel, Waffe im Anschlag
    2 - Ist sich sicher einen Gegner zu sehen. Großer sichtkegel, im Kampfmodus.


    Falls ein andere Sinn (Hören, Team, Schaden) einen Gegner wahrnimmt, so springt der Wert gleich auf 1 und geht solange nicht runter, bis alle Aufgaben (z.B. Gegner suchen) abgeschlossen sind.


    Die Grenzen könnte man theoretisch verschieden Setzen um verschiedene Schwierigkeiten zu ermöglichen.


    Die Idee einen ansteigenden Wert hatte ich schon eine Weile. Games wie Ghost Recon Wild Lands oder die neuen FarCry Titel visualisieren sowas ja recht gut und vorallem, um stealth zu ermöglichen ist das ein recht gutes System, weil man nicht sofort entdeckt wird, wenn man kurz mit dem Kopf aus der Deckung hervorschaut. Andererseits ist es nicht authentisch, wenn man die ganze Zeit sichtbar ist und der Gegner dich nicht sieht. Daher fand ich so ein Zeit-basiertes System gut.
    Eine gute Lektüre, dazu war dann noch Game Ai Pro 2 - Human Enemy AI in The Last of Us.


    Da sich der AI behavior tree auch weiterentwickelt hat sollte ich vielleicht auch wieder mal dazu einen längeren Post machen.

    Mini update. Ich wollte schon immer einen Unterlaufgranatwerfer implementieren.
    Das hat aber ein ganzes Stück rework meiner Weapon State Machine benötigt, um States aus externen Objekten sauber zuzulassen.


    Externer Inhalt www.youtube.com
    Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
    Durch die Aktivierung der externen Inhalte erklären Sie sich damit einverstanden, dass personenbezogene Daten an Drittplattformen übermittelt werden. Mehr Informationen dazu haben wir in unserer Datenschutzerklärung zur Verfügung gestellt.

    Hallo, ich dachte mal ich erkläre mal wieder eines meiner System.


    Ich will in diesem Post auf das WeaponStateSystem eingehen, da dies bestimmt viel Anwendung in anderen Bereichen finden könnte. Und obwohl es im UDK Standard war so zu arbeiten, sieht man wenig erklärung dazu wie man etwas ähnliches in der UE4 hinbekommt. Das ganze System lässt sich auch in Blueprint implementieren. Ich erkläre hier daher nur das grobe Konzept. Bei bedarf kann ich weiter ins Detail gehen, also bei Interesse bitte Fragen.


    Das ganze ist nichts neues und wird auch von Epic gerne genutzt, z.B. in UT4, in UDK konnte man sowas sogar nicht einfach innerhalb einer Klasse in U-Script implementieren.


    Die Problematik:
    Eine Waffe kann ich in mehreren Zuständen befinden wie z.B.

    • Inaktiv/Im Inventar
    • Im Waffenwechsel
    • Aktiv
    • Feuernd
    • Nachladend
    • Waffe unten
    • ...


    In jedem dieser Zustände sind gewisse Aktionen erlaubt oder nicht erlaubt. Z.B. Darf man während des Waffenwechsels nicht Nachladen oder Feuern können, auch der Waffenwechsel muss warten bis die Animation beendet ist, etc. Löst man sowas mit If-Then-Else oder Switch blöcken, kann das zu sehr viel Komplexität führen und einen neuen Zustand zu implementieren ist dann ein großer Aufwand, da man eine recht große Bedingung verändern muss, was auch viel Fehlerpotenzial birgt, da alle anderen Zustände in dieser gleichen Bedingung geprüft werden.


    z.B. Waffe Abfeuern:

    • Prüfe ob Waffe zur Zeit nachgeladen wird
    • Prüfe ob Waffe ausgerüstet ist
    • Prüfe ob Waffe gerade gewechselt wird
    • Prüfe ob Waffe gerade unten ist
    • ....
    • Feuern



    Um dieses Problem zu lösen wird eine Art StateMachine eingeführt.
    In meinem Fall habe ich eine WeaponState basisklasse basieren auf ActorComponent erstellt. Diese erzeugt die Schnittstelle zwischen allen WeaponStates und der Waffe selbst. Sie enthält folgende Funktionen:

    • BeginState
    • FinishState
    • TickState
    • Fire
    • Reload
    • Equip
    • Unequip
    • ... (und mehr)


    Im Fall der Basisklasse sind diese Funktionen zunächst leer. Da diese gar nicht instanziiert werden darf (es handelt sich um eine sogenannte "abstrakte" Klasse)
    BeginState und FinishState weden beim wechsel des States Aufgerufen. BeginState ist dazu da im einen Zustand zu starten also alle nötigen Initialisierungen/Vorbereitungen zu treffen, FinishState ist dazu da um einen Zustand sauber zu beenden.


    Nun werden die nötigen Zustände implementiert und die Funktionen überladen, als Beispiele mal folgendes:


    StateInactive:

    • Fire -> macht nichts
    • Reload -> macht nichts
    • Reload -> macht nichts
    • Equip -> Versucht die Waffe auszurüsten und wechselt bei Erfolg in den EquipWeaponState
    • Unequip -> macht nichts
    • ...


    StateActive

    • Fire -> Versucht zu feuern und geht in den FireWeaponState
    • Reload -> Versucht nachzuladen und geht in den ReloadWeaponState
    • Equip -> Macht nichts, da schon equipped
    • Unequip -> geht in den Unequip Weapon State


    StateFiring

    • BeginState -> Fängt an zu Feuern und startet entsprechende Timer für den Cooldown, etc.
    • Fire -> Macht nichts, denn wir feuern ja schon
    • Reload -> geht nicht, da wir gerade die Waffe abfeuern oder im Cooldown/Recoil sind
    • Equip -> s.o. geht nicht, also passiert nichts
    • Unequip -> s.o. geht nicht, also passiert nichts

    StateEquip

    • BeginState -> Fängt an die Waffe ausrüsten Animation abzuspielen und startet entsprechende Timer, um bei Auflauf dann in den ActiveState zu wechseln.


    Man erkennt hoffentlich das Prinzip. Alle möglichen Befehle existieren in jedem Zustand, jedoch sind nur die Befehle mit Logik befüllt die wirklich benutzt werden können.


    Wo ist hier jetzt der Vorteil?
    Die Waffe selbst besitzt nun all diese States als Components und einen Zeiger "CurrentState", welcher immer auf den Derzeitigen Zustand zeigt.
    Dadurch dass sich alle Zustände das gleiche Interface teilen, ist es der Waffe egal welchen Klasse der jetzige Zustand hat.


    Will man nun Feuern wird CurrentState->Fire aufgerufen. Da CurrentState immer auf den derzeitigen Zustand zeigt wird nun je nach Zustand die richtige Reaktion hervorgerufen.
    Zeigt CurrentState also auf StateInactive so passiert nichts. Zeigt CurrentState jedoch auf StateActive, so wird gefeuert, usw. Ohne irgendwelche komplexen If-Then-Else konstrukte kann also immer die richtige Reaktion ausgeführt werden je nachdem wohin der CurrentState gerade zeigt.


    Dadurch dass es sich um ActorComponents handlet kann die komplette Funktionalität eines Zustands inklusive Netcode auch in den WeaponState selbst implementiert werden. Dies verschafft eine Ganze menge Übersicht, was Code oder bestimmt auch Blueprints angeht.

    Hallo,
    Als kleine Information:
    Den C++ Source Code gibt es nun öffentlich auf GitHub: https://github.com/Tomura/TacticalPrototypeCPP


    Wer Interesse hat kann gerne reinschauen, einen Fork erstellen, etc.


    Dies enthält nur den C++ Source Code. Selbst wenn man es zu einer Executable compiliert muss man immer noch einiges an der Config anpassen und Content erstelltn (Blueprints, etc), um ein funktionierendes Spiel zu haben.
    Ich garantiere nicht dass der Code funktioniert oder dass ich Support biete (auch wenn ich bestimmt mal die ein oder andere Frage beantworte, je nachdem ob ich Lust drauf habe)

    Großartig, fürchte aber das ich damit nicht klar komme, aber ich schaue es mir an, aus Interesse! Also ich versuche es! :D


    Lohnt es sich nicht für dich ein FPS Kit in dem UE Assetstore zu veröffentlichen? Ich meine in dein Videos wirkt es wie ein AAA Shooter.

    Ich meine dass es sich nicht wirklich lohnt, da ich keine Lust habe regelmäßig dran zu arbeiten und es zu pflegen. (Und ich glaube es wird sich nicht rechnen was das Zeit/Nerven/Geld Verhältnis angeht.) Dann lieber einfach aus Spaß am Entwickeln, alle paar Wochen/Monate, ohne Verpflichtungen.


    Außerdem halte ich nichts von solchen Kits, da diese nur die Leute ansprechen die mMn keine Lust oder nicht die mentalen Kapazitäten haben, um sich ernsthaft damit auseinander zusetzen.