spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Seit ein paar Monaten schon arbeite und lerne ich mit den UE4-Blueprints. Da ich vom Programmieren kaum Ahnung habe und die Blueprints darauf basieren, benötige ich mal ein paar Hinweise von den fähigen Leuten hier.

Ein Blueprint stellt ja eine Klasse dar. Wie groß und aus welchen Gründen sollte eine Klasse sein? Wo ziehe ich die Grenzen? Mal als Beispiel den PlayerCharacterBP. Ich kann dort theoretisch alles unterbringen, was mit dem Spielercharakter zu tun hat. Bewegung, Inventar, Charakterwerte, Zielsystem, Interaktionen, usw. Ich könnte aber auch nur die Events schreiben und für jede einzelne Funktion eine neue Klasse eröffnen, bis hin zu den Standardbewegungsabläufen. Ich denke sinnvoll ist irgendetwas dazwischen, aber nach welchen Kriterien ist es am sinnvollsten? Und gibt es eine maximale Größe, die ich z.B. aus Performance- oder Stabilitätsgründen nicht überschreiten sollte?

Hat es zudem irgendwelche Auswirkungen (außer Übersichtlichkeit), wenn ich den Inhalt einer Klasse in 2 oder mehr Blueprintgraphen (der selben Klasse) aufteile?

Danke schonmal für eure Hilfe.

Ein zweiter Graph ist eine 2. Seite innerhalb der Klasse. Ich kann die Variablen der ersten Seite nutzen, ich kann Events nur auf einer Seite benutzen (z.B. Event Tick oder Event BeginPlay), ich kann nur keine Funktionen untereinander verbinden ohne Custom Events dazwischen zu schalten. Ich denke es ist lediglich für die Übersichtlichkeit. Allerdings wäre das meines Laienverständnisses nach dann unnötig, wenn man nach dem SRP arbeitet. Wenn man die Funktion auf 2 Graphen aufteilen kann und es auch tun würde (macht man ja erst ab einer gewissen Größe), kann man sie eigentlich auch in 2 Klassen stecken.

Das der Code wächst und unübrsichtlichr wird, merke ich selbst, obwohl ich von Anfang an auf Übersichtlichkeit geachtet habe. Ich frage auch gerade jetzt, da es der beste Zeitpunkt ist nochmal etwas umzustrukturieren, bevor eine spätere Umstrukturierung wirklich zeitintensiv wird. Ich habe aber bereits vor dem Thread schon innerhalb einer Klasse Dinge mittels CustomEvents getrennt (macht es nochmal einfacher Funktionen auszulagern).
Das alles soll ja nun den Sinn haben, wie ich beim SRP gelesen habe, dass Programme einfacher gewartet werden können und innerhalb der Klasse übersichtlicher sind. Aber macht das beim Visual Scripting in der Form überhaupt sinn? Wie du schon schriebst Schorsch, entsteht dadurch wieder eine Komplexität, wenn man zu viele kleine Klassen hat. Zum Einen muss man sie sehr gut Verwalten, damit man die gesuchte Klasse wiederfindet, zum Anderen entstehen viele Kopplungen zwischen den Klassen. BPs haben ja nun den Vorteil, dass sie durch ihre grafische Oberfläche bereits wesentlich übersichtlicher sind und zudem über Werkzeuge wie das farbliche Einrahmen inklusive Kommentar besitzen. Zudem kann man über "Find References" Abhängigkeiten z.B. einer Variablen schnell suchen. Wenn man jetzt den Code auch noch innerhalb der Klasse modular aufbaut, sollte das trotz SRP-Verstoß keine Probleme geben oder täusche ich mich? Um mal konkret zu werden könnte ich mir vorstellen im CharakterBP zusätzlich neben den Spielerinput (was laut SRP alleine rein sollte) auch ein Objekttrigger und Targetsystem, sowie die Lauf- und Kamerafunktionen mit einzubauen.
Ich wette ihr widersprecht mir damit, mich interessieren aber noch die Gründe dagegen.

Naja so wie ich es letztlich verstanden habe, macht es ja am meisten Sinn z.B. eine Kameraklasse zu schreiben, die alle Kameramodi/-funktionen (der selben Kamera) mit beinhaltet anstatt die Modi und Funktionen noch sepparat zu trennen, aber größer sollte die Klasse auf keinen Fall werden (z.B. eine Funktion einer externen freifliegenden Kamera). Das Prinzip würde ich durch meinen neuen Wissensstand in etwa so jetzt überall anwenden. Ist es so in etwa sinnvoll?

Mag mir bitte nochmal jemand antworten?

Ich habe mich in letzter Zeit mit Clean Code beschäftigt und das Prinzip weitestgehend verinnerlicht. Momentan überarbeite ich sämtlichen Code. Bereits beim Überarbeiten merke ich deutlich, wie die Qualität des Codes steigt und welche Vorteile ich dadurch erhalte. Der ganze Aufbau ist viel dynamischer und zu meinem Erstaunen tatsächlich auch etwas übersichtlicher (obwohl ich es vorher schon nicht als unübersichtlich wahrnahm) trotz der höheren Klassenanzahl.

Danke nochmal für eure Hinweise, die restlichen Fragen haben sich mittlerweile erübrigt.