Actor BP's instance oder mehrere Childs?

  • Hallo, erneute Anfängerfrage.

    Wie ist im Folgenden die übliche Vorgehensweise?
    Als Beispiel; ich habe div. Objekte mit denen ich interagieren kann. Dafür habe ich einen Parent BP wo die allg. Funktionen drin sind die jedes Objekt hat. Nun mach ich einen Child für zB, Bücher, einen für Verbrauchsgegenstände und einen für einfach Objekte die man sich nur stumpf anschauen kann. Bei Interaktion haben diese halt verschiedene Aktionen.

    So - sollte ich dann für zB. Bücher dann für jedes Buch was so rumliegen würde ein eigenes BP Child machen? Also einfach das BP duplizieren, umbenennen und das Mesh für das Buch ändern und den Text?
    Oder kann ich auch einen allg. BP Bücher haben, den ich immer wieder ins Level ziehe und dann im Level einfach die Werte ändern kann durch Puplic Variablen?<

    Das ist jetzt kein Problem oder so, sondern eine allgemeine Frage der Ästhetik ^^
    Wie man es üblicherweise machen sollte, Vor- und Nachteile???

    Oder mache ich mir da zu viele oder unnötige Gedanken??

  • Oder kann ich auch einen allg. BP Bücher haben, den ich immer wieder ins Level ziehe und dann im Level einfach die Werte ändern kann durch Puplic Variablen?<

    Ich habe nur einen einzigen "Master_Item_Actor", da setze ich alle Variablen.

    Da bei mir aber alles random sein wird, gibt es ein DataTable, welches alle Daten beinhaltet und dann im Spiel alles random erstellt wird.



    Ein Freund erstellt für jedes Item, einen eigenen Actor, hat er so im Studium gelernt, nennt sich wohl Objekt-orientiert...


    Das einzige, wo ich viele verschiedene Actor erstelle, sind die Gegner, da ich da mal Probleme hatte, dass die Animationen nicht abgespielt werden.

    Die Werte werden aber ebenfalls von nem DataTable gesetzt, da das meiner Meinung nach, übersichtlicher ist, als zig Actor, immer einzeln öffnen zu müssen, um die Werte anzupassen ^^

  • Bei nem Buch brauchst ja nur eine Variable, ne ID. Wie Butter Fly Games richtig sagt, ziehst über die ID den Inhalt des Buches und den Mesh rein. Läuft dann halt über nen DataTable oder ne sonstige Datenbank. Lässt sich auch wesentlich geschmeidiger verwalten. Für den Leveldesigner ist das dann auch einfacher. Der setzt nur den BP und gibt die ID ein und schon hast du dein Buch fertig eingefügt.

  • Ich kann bei dem Thema aus eigener Erfahrung sprechen, und dir nur empfehlen es so zu machen wie Annubis und Butter Fly Games es beschrieben haben. Es gibt meiner Meinung nach auch keinen Grund es anders zu machen, mal abgesehen von Fällen wie bei Butter Fly Games was aber wohl eher ein Problem der Engine ist, als ein Problem der Art der Durchführung. Das macht dir dann nicht nur das designen einfacher, sondern auch das (zufällige) spawnen der Actors einfacher. Also wenn du z.B. eine neue Eigenschaft der Bücher haben willst, fügst du einfach einen neuen Eintrag ins Struct ein, passet das schnell im Data Table an und fertig. Sonst müsstest du in jedem einzelnen Actor die Eigenschaft hinzufügen, und mühselig in den Code einbinden.

  • Fürs Hintergrund Wissen.
    In meinem Falle möchte ich nichts zufällig spawnen lassen, die Objekte haben auch keine Random Werte.
    Es würde wirklich nur Objekte gehen die einen festen Platz und eine feste Funktion haben und man mit denen halt Interagiert.

    DataTables müsst ich mir noch anschauen. Damit habe ich mich bisher noch nicht befasst.

  • Es vereinfacht auch in gewissen Fällen die Möglichkeit der Übersetzung. Falls ein Game in mehreren Sprachen kommen soll. Unsere Lösung war für verschlüsselte Bücker bzw. Papyrosrollen. So musste man nicht rumklickern und konnte simpel abfragen, ob jmd die Fähigkeit hatte, die Rollen zu lesen, dann wurde er einfach auf einen anderen DataTable geleitet. Dem "Buch" ist das ja wumpe.