Ich lerne Unreal...und mag BP nicht

  • Hallo zusammen,


    ich habe vor paar Tagen beschlossen mal was mit der Unreal Engine zu machen. Hatte jetzt am Montag wieder Zeit um mich mit meinem Hobby zu beschäftigten. Das Resultat könnt ihr Euch hier anschauen. VIDEO [EDIT: ist noch nicht fertig!]


    Ich habe das mit BP gemacht. Hatte vorher 0 Erfahrung mit der Art der Programmierung und es hat sehr viele Nachteile. Da sind einige Sachen die mir gar nicht gefallen haben. Naja egal.


    Das Spiel besteht aus zwei Objekten...dem Spielfeld + die Methoden dazu. Die sich bewegende Steine + die Methoden dazu und die "Hauptschleife". Die habe ich in das Level BP gepackt und das sieht aktuell so aus



    Ich würde gerne wissen....sieht es bei Euch auch so aus? Ich meine...das ist doch echt ein Durcheinander. Habe wirklich versucht Ordnung in das ganze zu bringen, aber Leute ihr müsst Eure Erfahrung mit mir teilen sonst verliere ich meinen Glauben an die Menschheit :D


    Ist das jetzt bei mir so wild weil ich ein Anfänger bin? Ist das so die "normale" Art wie das dann aussieht? Habt ihr ein paar Ratschläge wie man das besser machen kann?


    Ich danke Euch und freue mich wirklich auf ein paar gute Vorschläge....

    • Offizieller Beitrag

    Ich würde gerne wissen....sieht es bei Euch auch so aus? Ich meine...das ist doch echt ein Durcheinander. Habe wirklich versucht Ordnung in das ganze zu bringen, aber Leute ihr müsst Eure Erfahrung mit mir teilen sonst verliere ich meinen Glauben an die Menschheit :D

    Siehe: https://i.redd.it/ekimeqox3pk71.png   :laughing:


    Ich glaube du bist das Programmieren so extrem gewohnt, dass dir visuell Scripting ungewohnt und unpraktisch vorkommt.


    Ich komme ja beispielsweise eher aus der grafischen Ecke und stelle mir oft die selbe Frage bei "normalem" Quellcode.


    Für mich hört sich das jetzt so an, als wäre "normaler" Code viel Übersichtlicher.

    Da würde mich jetzt mal interessieren warum ?


    Ich hab früher meine ersten Gehversuche in Pascal, Turbobasic und GWBasic gemacht. Damals gabs dieses ganzen bunten Schnick schnack noch nicht wie es zb in visual Studio gang und gäbe ist. Ich meine natürlich die Syntaxhervorhebungen.

    Die Syntaxhervorhebung ist doch auch ein visuelles Feedback genau so wie die Comment Boxen. in Unreal.


    Ich finde die Comments Box schon sehr übersichtlich. Was du beispielsweise noch machen könntest, ist den Comment Box eine Farbe zu geben, damit kannst dein Blueprint zusätzlich zu den Comment Boxen nochmal Farblich abheben. Das kannst du machen, in dem du die Comment Box anklickst und dann rechts eine Farbe einstellst. Du kannst auch Farbliche Comment Boxen in einander verschachteln, so hast dort auch verschiedene farbliche Abhebungen.


    Das ist doch übersichtlicher als in einem riesigen Quellcode die richtige Stelle zu suchen.


    Ich hab eher Schwierigkeiten Blueprints aber auch in Pyhton wo ich teilweise Unterwegs bin so zu kommentieren das ich nach 3 Monaten wieder den Faden finde.

  • Da gewöhnt man sich schnell dran. Leider kann ich auf deinem Bild nicht viel sehen, da es recht klein alles ist.

    Aber, was du zum Beispiel auch machen kannst, ist, wenn du eine Verbindung zwischen den Nodes doppelklickst, dann entsteht ein extra Kontaktpunkt. Den kannst du dann so verschieben, dass die Linien nicht durch die anderen Nodes durchgehen, wenn du etwas mehr Übung hast, sie sich nicht kreuzen usw. Ist ein wenig tricky, weil die nicht so einfach mit dem Mauszeiger greifbar sind, geht aber in der Regel ganz gut. Kurz gesagt, nein, sieht nicht unbedingt so aus, nur wenn man sowas halt noch nicht kennt. ;)

    Wenn dir das nicht reichen sollte, dann gibt es noch Plugins, wie zum Beispiel Electronic Nodes, was allerdings rund 15 Euro kostet, aber vielleicht gibt es auch Alternativen. Damit kannst du dann ein paar Einstellungen machen, sodass die Linien nicht so geschwungen sind, sondern mehr eckig aussehen. Ist aber eher eine Geschmackssache.

  • Sleepy das Bild...es hat mich erschreckt :)


    Meine Erfahrung bis jetzt mit BP ist:

    • Bei der klassischen Programmierung versuche ich eine Funktion oder Methode so zu programmieren, dass es auf dem Monitor komplett zu sehen ist. Eines meiner Monitore steht senkrecht. So habe ich immer alles im Blick
    • In einer Funktion/Methode gebe ich Werte nur an einer Stelle zurück (könnte man auch in BP machen), aber durch diese Verknüpfungen der Nodes ist es mir passiert das ich an einer Stelle keinen Wert zurückgegeben habe und das Programm fehlerhaft lief. Ok das könnte man mit ein bisschen mehr Disziplin lösen
    • Bei For-Schleifen mit größerem Inhalt habe ich eine gute Übersicht durch die Möglichkeit, dass ich den Code einrücke kann. Wenn ich das mit BP mache, dann ist es einfach eine lange Schlange
    • Viele Sachen kann man mit normalen Programmieren eleganter lösen. Habe jetzt kein Beispiel zur Hand...kann ich nachreichen wenn ich wieder an meinem HomePC bin.
    • Programmieranfänger würde ich empfehlen auch einen Blick auf die normale Programmierung zu werfen.


    Comments Box farblich zu gestallten, das merke ich mir. Hört sich gut an.

    Comments Box schachteln ist gut. Habe ich auch gemacht.


    Das ist doch übersichtlicher als in einem riesigen Quellcode die richtige Stelle zu suchen.

    Ist wohl eine Gewohnheitssache. Ich finde mich immer gut zu recht und die Suche funktioniert ganz gut in VisualStudio...


    Tomarr das mit dem Doppelklick ist cool...Das Plugin ist auch ok...ich scheue auch nicht mal was zu investieren, aber mal sehen ob ich mir das holen will oder auch ohne leben kann.


    Mein Fazit...Programmieranfänger würde ich empfehlen auch einen Blick auf die normale Programmierung zu werfen. BP ist nicht schlecht und sollte verwendet werden. Auch ich werde BP weiterhin verwenden. Für kleinere Sachen ist es sicher gut geeignet, aber ich kann mir aktuell nicht vorstellen nur mit BP zu arbeiten. Früher oder später wird wohl C++ notwendig sein.


    Das ist meine jetzige Meinung, aber morgen kann sich die schon wieder ändern. ;)

  • Genauso wie du bei Clean Coding Dinge z.B. in Funktionen packst um selbst-dokumentierenden Code zu schreiben kannst du auch in Blueprint gewisse Dinge einfach in Funktionen verpacken und etwas aufräumen.


    Versuche einfach mal die Prinzipien von Clean Code auf Blueprint zu übertragen. Also

    • Erklärt sich der Blueprint von selbst
    • Wie ist die kognitive Komplexität?
    • Sind Variablen und Funktionen gut benannt?
    • Zu viele Zweige?
    • Zu viele exit points (zu viele returns in einer funktion)
    • etc.

    Das hier wäre z.B. das Blueprint Gegenstück zu Spagetti Code.

  • Bei der klassischen Programmierung versuche ich eine Funktion oder Methode so zu programmieren, dass es auf dem Monitor komplett zu sehen ist. Eines meiner Monitore steht senkrecht. So habe ich immer alles im Blick

    Das ist halt der Unterschied zwischen Code und BP. Bei Code ergibt ein senkrechter Monitor durchaus Sinn, weil Code wird halt geschrieben, wie in einem normalen Buch, Zeile für Zeile.

    Bei BPs ist es eher der horizontale Monitor, der besser geeignet ist, denn die In- und Outputs sind halt rechts und links angeordnet, weswegen sich da eher eine horizontale Richtung ergibt. Das ist auch der Grund, ich habe hier auch ein Buch über BP-Programmierung, aber durch die Natur die BPs darstellen ist es halt sehr eingeschränkt in seinen Möglichkeiten.

    Es gibt aber recht viele Möglichkeiten, wie du bei BPs das ganze ein wenig kompakter machen kannst. Du musst ja nicht alles horizontal anordnen. Ich habe mir zum Beispiel angewöhnt, wenn ich eine Variable auslese, dann geht das ja meistens in eine Node für die Auswertung, dann setze ich die Variable direkt unter die Auswertung. Ich brauche da ja nicht die Verbindungslinien zu sehen und durch die Nähe zur Auswertung weiß ich dann halt schon, dass da ein Zusammenhang besteht.

    Das Ganze hat bei mir auch ein wenig gedauert, bis ich da Ordnung reinbekommen habe. Wenn ich so richtig einen Lauf habe und die Ausnahmesituation eintritt, in der ich sogar mal weiß, was ich tue, lasse ich es immer noch gerne mal außer Acht. Aber das ist am Ende ja dann auch eine Frage der Disziplin. Würde Visual Studio nicht alles automatisch machen, mit einrücken usw. dann würde der Code bei vielen bestimmt genauso durchgeknubbelt aussehen.

  • Eure Antworten stimmen mich positiv, dass es mit der Zeit besser wird mit dem Verständnis für diese Art der Programmierung. Ich möchte noch was nachreichen...


    Version in "normalen" Code


    und die Blueprint-Variante



    Beide machen das selbe... :)

  • und die Blueprint-Variante

    Ich finde man sollte auch so viele Variablen nutzen wie nur möglich, oder vor allem wie in deinem Fall, wo ein Wert für mehrere Nodes nötig ist. Also den Index vom Loop hätte ich in eine lokale Variable gepackt, dann kannst du die Variable immer wieder verwenden, dann hast du nicht diese langen Linien die du zurück verfolgst, oder quer durchs Bild gehen. Das ganze hat sogar einen Begriff den wohl Programmierer nutzen, fällt mir aber gerade nicht ein :D

    Ich kenne z.B. auch einen Software und Front-End Entwickler, den habe ich dann mal Unreal gezeigt und er war total begeistert vom Visuellen Scripting. Geht also auch andersrum.

    Ich kann dir, bevor du weiter übst, unbedingt diesen Artikel zur BP Organisation empfehlen!
    https://www.techarthub.com/10-…ation-in-unreal-engine-4/

  • Vergiss auch nicht, BPs sind nur ein Angebot des anders Programmierens. Du kannst und darfst natürlich so viel C++ benutzen, wie du willst. Du musst BPs nicht verwenden, wenn du mit C++ besser klarkommst.

    Du kannst auch Mischformen verwenden, indem du zum Beispiel eigene Nodes in C++ programmierst und diese dann in deine Bps verbaust. Da ist die Engine sehr flexibel.

  • Ich hatte heute etwas Zeit um mich mehr in die Materie einzulesen und habe ein paar Eurer Vorschläge angewendet und man kann so das BP schon ordentlich aufräumen.


    Ich beherrsche viele Programmiersprachen, aber fühle mich bei C/C++ sehr wohl. Also werde ich das auch in UE verwenden, aber ich möchte doch nicht auf die Annehmlichkeiten von BP verzichten. Ich muss doch zugeben....trotz einiger Nachteile, erleichtert BP sehr wohl die Arbeit und am Ende ist wohl ein gesunder Mix die beste Lösung.

  • Ja Blueprints koennen haesslich sein, Blueprints koennen Spaghetti-Code sein und wenn du klassischer Programmierer mit viel Erfahrung und Anschlaegen bist nerven Blueprints manchmal auch tierisch - wie oft hab ich mich verklickt oder zu frueh Maus losgelassen beim verbinden von nodes.


    Blueprints wirst du erst lieben lernen wenn du extrem komplizierte Funktionen zur laufzeit debuggen musst. Denn wenn du 2 Monitore hast kannst du auf einem "spielen", pausieren und auf dem anderen nachsehen was genau passiert. Das ist die Staerke der Blueprints - du kannst den leuchtenden pulsierenden string sehen der von deinem branch ("IF THEN") ausgeht. Du wirst bei komplexen Funktionen die normal tausende Zeilen C++ Code haben auf einem Blick sehen wo der code "falsch abgebogen" ist, du hoverst mit der Maus ueber nodes um deren Werte zu sehen und erkennst Fehler sehr schnell.


    Manchmal hast du Bugs in 2 Minuten behoben wo du vorher Dutzende breakpoints ueber stunden gesetzt hast.


    Im kampf gegen Spaghetti code hilft es auch AUsgabewerte einer node in Variablen zu packen und diese dann an den 3 Stellen einzusetzen wo du sie brauchst anstatt Verbindungen ueber gefuehlt 10 Bildschirmlaengen zu ziehen. Es ist bei sehr komplexen Blueprints schon von Vorteil wenn diese Uebersichtlich bleiben. DU kannst auch eine Gruppe von Nodes markieren und mit Kommentar versehen, diese werden dann in eine schoene farbige box gesteckt so dass du dir eigene Codebloecke innerhalb eines BP logisch und optisch abgrenzen kannst um den Ueberblick zu behalten. Gibt auch ein paar Engine plugins um die Anordnung zu optimieren.


    Du kannst auch selber geschriebene C++ Funktionen in Blueprints exposen um die Flexibilitaet zu wahren und Funktionen selber zu schreiben - und diese dann aber beim Debuggen einfach in Blueprints zu visualisieren. Im Community Content Bereich findest du auch ein paar ganz simple Beispiele von mir - da habe ich eigentlich nur fertige C++ Funktionen der Engine zu Blueprints exposed. Vorgehensweise ist aber recht simpel wenn mans einmal gemacht hat. Vorteil ist dass du mit dem plugin die Funktionen praktisch "mit 2 klicks" in jedes neue projekt uebernehmen kannst.

  • Das ding drucke ich mir aus und hänge es an die Wand. Andere haben Weltkarten, ich sowas :laughing:





    Ich finde die Blueprint variante deutlich übersichtlicher ;)