void GruenerDracheTaktik()
{
    blabla
}
void OgerTaktik()
{
    blabla
}
void OrkTaktik()
{
    blabla
}
...

Aber, wie rufe ich diese nun mit möglichst wenig Aufwand auf? Ich habe meine Gegner in einem Vector stecken und muss nun dementsprechend die jeweilige KI aufrufen. Ich möchte ungern:

vector<int>::iterator j;
for ( i = GegnerV.begin(); i != GegnerV.end(); i++){

if(i->name == "gruenerdrache"){
GruenerDracheTaktik()
}
if(i->name == "oger"){
OgerTaktik()
}
if(i->name == "ork"){
OrkTaktik()
}
... usw. usf. ...

Wie löse ich das Problem? Ich könnte natürlich auch mit einem switch/case arbeiten, aber selbst das ist ziemlich viel Schreibaufwand bei später mal mehr als XXX Gegnertypen.
Was gibts noch für Möglichkeiten? Kann ich vielleicht irgendwie einen dynamischen Funktionsaufruf bauen?

string Funktionsaufruf = i->name;
Funktionsaufruf();

Ich kann ja schon Objektorientierung. Ein bißchen. Ich denke nur nicht immer daran, was mir das alles bringt...

std::map<std::string, std::function<void(void)>> m_mTactics;

Stichwort wurde auch schon genannt: Polymorphie.

Und je nachdem, wie aufwendig diese Taktik ist, bietet es sich dann auch, die Taktiken in eigene Klassen auszulagern, um sie für unterschiedliche Gegner wiederzuverwenden usw. usf. Das bietet später einen hohen Grad von Wiederverwendbarkeit an und ist, wenn man den Durchblick hat, auch sehr gut wartbar. Dafür wurde OOP gemacht.

naja man bindet eine globale funktion an ein beliebiges string objekt. ok, map ist OOP und string auch aber der ansatz schreit ja schon nach polymorphie...

Genau das wird mit der map emuliert. nur weil kein "vitual" drin vor kommt, heisst es nicht, dass es etwas anderes ist.

Ohh ich sehe, jetzt gleich beginnt wieder die Diskussion was OOP ist :).

Nebenbei würde ich weder string noch map pauschal unter OOP einordnen. OOP ist nicht einfach nur "Funktionen und Daten zusammenklatschen".

Die map-variante outperformed virtual da unglaublich, weil du einfach nur für jede Wahlmöglichkeit einen String speichern kannst.

Aber auch der Entwurf mit virtuellen Methoden hat viele Nachteile. Natürlich kannst du Klassen "Oger" und "Magier" haben. Aber was ist mit Oger-Magiern? verhält sich im Nahkampf wie ein Oger, im Fernkampf wie ein Magier. In deinem Ansatz brauchst du ne dritte Klasse. Aber wenn du genug Kombinationsmöglichkeiten hast, dann verhält sich die Klassenanzahl exponentiell zu der Anzahl der Wahlmöglichkeiten. Und das ist tendentiell unschön. Niemand will so viele Klassen schreiben und dabei Code copy-pasten. Und wenn sich in einer implementation was ändert, musst du es direkt überall ändern.

Die map-variante outperformed virtual da unglaublich, weil du einfach nur für jede Wahlmöglichkeit einen String speichern kannst.

Falsch.

Falsch.

richtig.

Langsam wirst du unerträglich.

Wenn Du Die String-Sache weiter ausprogrammierst, wirst Du bemerken, daß Du doch nur auf Nahkampf und Fernkampf switchst

ich vermute mal, dass die Taktiken eines Magiers im Fernkampf anders sein sollten als die Taktiken eines Bogenschützen. Ich könnte ja auch einen Oger-Bogenschützen machen wollen .

In der Tat hatte ich schon einmal das Problem der kombinatorischen Explosion. Ich habe einen anderen mechanismus zur Lösung verwendet, virtual kam am Ende aber trotzdem nicht mehr vor (und mir wurde es erspart, ca 125 Versionen einer Klasse zu schreiben).

Worauf ich halt hinaus wollte: virtual ist nicht mehr die optimale Lösung, wenn deine Objektkategorien Strukturen haben, die die Menge der Kategorien groß werden lassen. In dem Fall: #Anzahl Rassen x #Anzahl Nahkampfstrategien x #AnzahlFernkampfstrategien. Da ist es besser nicht mehr zu sagen: "Ein Oger ist ein Gegner", sondern "Ein Gegner hat eine Rasse, eine Nahkampfstrategie und eine FernkampfStrategie". Die "hat"-Beziehung lässt sich recht unproblematisch auf unterschiedliche Arten Ausdrücken. Zugriff auf eine Map ist okay, Zeiger auch. Allerdings ist beim zeiger die map nur in einem anderen Teil des Programms versteckt.