Künstliche Intelligenz



  • Guten Abend,

    ich hab eine Frage bezüglich einer AI. In meinem Spiel gibt es auch eine AI, bzw. NPC's. Ich möchte eine Basisklasse AI, die den Zusammenhang von verschiedenen NPC's als grundlegende Basis setzt. D.h., es gibt z.B. ein gegnerisches Monster, aber auch einen friedlichen Verkäufer.
    Daher frage ich, ob jemand eine gute Struktur hätte, die vielleicht so aussieht

    AI
                 |
          ----------------
          |              |
       Monster       Verkäufer
    

    Das ist jetzt wohl eher schlecht, aber ich denke ihr wisst was ich meine. Einfach nur mehrere Klassen, die aber als Oberklasse die AI Klasse haben. Aber vielleicht denkt ihr auch, dass es am besten wäre einfach nur eine Klasse AI zu haben und man dort einfach setzt was es ist, quasi eine Klasse die sich um den ganzen AI Stuff kümmert.
    Ich wäre über Hilfe erfreut 😉

    FreakY



  • Die beiden sollten vielleicht eher von einer gemeinsamen Klasse "Object" oder falls es bei dir sonst nichts gibt, von "Creature"/"Lifeform" oder sowas erben.
    Dort kannst du ja dann durchaus allgemeine Funktionen unterbringen, die den Nachfahren nützlich sein könnten (z.B. findNearest(N)PC, getAll(N)PCsInRange...).



  • Ich programmiere in C#, womit ich Interfaces nutze : "IPlayerableCharacter", die einen Charakter spielbar macht, "IAttackable" um festzulegen, ob ein Charakter oder NPC angegriffen werden kann und "ICharacterable" um sowas wie ein Character, also Spieler oder NPC zu setzen, falls es als Info hilft. Von daher hab ich gedacht dass die AI Klasse diese Interfaces nutzt, nur sollten sich NPC's unterscheiden.



  • Hmja... also eine einzige AI-Klasse "für alle" fände ich fürchterlich...
    wenn schon, dann für jede unterschiedliche AI eine eigene Klasse. Sofern viele davon ähnliche Funktionalität benötigen, kann man diese dann in die Vorfahrklasse AI auslagern.
    Wenn sich z.B. sowohl deine Monster wie auch deine Verkäufer bewegen sollen, könntest du dort eine Standardfunktion implementieren, die z.B. einfach einen Schritt in eine zufällige Richtung geht.
    Die einzelnen AI können darauf zurückgreifen oder ein eigenes Bewegungsmuster implementieren.


  • Mod

    naja, heutzutage setzt man eher auf data driven denn auf class hierarchy. wenn die objekte nicht wirklich unterschiedliche implementierungen von einzelnen funktionen brauchen, dann besteht auch kein grund sich zu beschraenken indem man klassen spezialisiert.

    deine frage also "Daher frage ich, ob jemand eine gute Struktur hätte, die vielleicht so aussieht" ist eine loesung fuer ein problem was du nicht definiert hast.

    was ist also das grundlegene problem weshalb du auf diese vererbungsstruktur als loesung kommst?



  • Ich habe dafuer ein Sensor + Controller + Actuator. Die Interfaces werden dann fuer die einzelnen "Dinge" spezialisiert. Das hat den Vorteil, dass auch eine Kamera (Laserkanone, oder was auch immer) an der Wand Bewegungen verfolgen (schiessen, Alarm ausloesen, oder was auch immer) kann.



  • Mein Problem ist, dass ich eine Basis AI Klasse haben will und andere Klasse davon erben. Da ich verschiedene NPC's habe, sprich z.B. gegnerische Monster oder freundlichen Verkäufer, weiß ich nicht wie die Unterklassen heißen sollen, was sie brauchen und was in der Oberklasse sein muss. Ich kann ja nicht einfach eine Unterklasse "class Verkaeufer : public AI" etc. nennen.



  • Mein Problem ist, dass ich eine Basis AI Klasse haben will

    Tja, aber vielleicht ist Vererbung nicht das geeignete Mittel.



  • Also dann doch die Lösung die ich meinte, dass die AI Klasse alles fasst und je nachdem, was der NPC für Eigenschaften hat, setze ich diese?

    int NPCFlag { get; private set; } //0 einfacher NPC, 1 Verkäufer, ...
    bool IsFriendly { get; private set; }
    ...
    

    Und jeder NPC hat ein eigenes AI Objekt?



  • Warum ist isFriendly nicht Teil der AI?



  • Ist es doch ... Gut, damit es zum besseren Verständnis dient:

    class AI : ICharacterable
    {
        public string Name { get; private set; }
        public Location Location { get; private set; }
    
        public int Flag { get; private set; }
        public bool IsFriendly { get; private; set; }
        public int Fraction { get; private set; } // 0 Orc, 1 Zwerge
        public AI(int flag, bool friendstatus, int fraction, string name, Location location)
        {
            this.Flag = flag;
            this.IsFriendly = friendstatus;
            this.Fraction = fraction
            this.Name = name;
            this.Location = location
        }
    }
    ...
    static void main()
    {
        AI Friendly_Orc_Seller1 = new AI(1, true, 0, "Thor", new Location(5, 7, "Arthania"));
    }
    

    Das ich praktisch alles in die AI Klasse klatsche, was einen NPC ausmacht und je nachdem passend zu dem NPC die Eigenschaften setze.


  • Mod

    FreakY<3Cpp schrieb:

    Mein Problem ist, dass ich eine Basis AI Klasse haben will

    stimmt, das ist ein problem. du willst etwas haben ohne einen grund fuer diese designentscheidung zu nennen und es sieht nicht aus als ob es noetig waere, bisher.

    Da ich verschiedene NPC's habe, sprich z.B. gegnerische Monster oder freundlichen Verkäufer, weiß ich nicht wie die Unterklassen heißen sollen, was sie brauchen und was in der Oberklasse sein muss. Ich kann ja nicht einfach eine Unterklasse "class Verkaeufer : public AI" etc. nennen.

    was wenn ein verkaeufer ploetzlich ein gegner wird weil du ihn geschlagen hast? oder ein monster ein verkaeufer wird weil du ihn dazu verzaubert hast? oder ein gegner dir ploetzlich hilft weil du dich als "freund" von ihm getarnt hast .... fuer alles eine klasse? es ist doch viel simpler das ueber composing zu machen oder einfach nur ein paar flags zu setzen.


  • Mod

    FreakY<3Cpp schrieb:

    Ist es doch ... Gut, damit es zum besseren Verständnis dient:
    [cs]...

    tja, so sollte es sein, ich sehe nichts was irgendwie codemaessig fuer eine subklasse anders waere.

    ich wuerde dir empfehlen statt den kommentaren, aussagekraeftigereren code zu nehmen, z.b. enums fuer die fraction, statt int.



  • Ja hab ich mir eben auch schon gedacht und werde ich auch mit enums umsetzen.


Log in to reply