gegenseitiger Zugriff von zwei abgeleiteten Klassen

[r2c2]

Zitat:

Zitat von sx2008 (Beitrag 1061102)

Es fehlt mindestens eine weitere Klasse.
Beim Spieler und Monster würde man eine zusätzliche Waffen-Klasse einsetzen.
Wenn der Spieler das Monster angreift, dann stirbt das Monster nicht durch den Spieler, sondern durch dessen Waffe(n).
Wenn also eine Figur angegriffen wird, dann entscheidet die Waffe(n) und die Defensivkraft des Gegners über den Ausgang des Angriffs.

Das kommt drauf an, ob Waffen relevant sind, d.h. ob der Spieler/das Monaster die Waffe wechseln kann, etc. Wenn ja, hast du Recht. Ansonsten ist eine Waffenklasse unnötig.

mfg

Christian

[Memnarch]

Ich denke man kann hier folgendermaßen vorgehen(so mach ich das normalerweise)

Wir definieren eine Klasse TEntity.

TEntity hat verschiedene Parameter die genutzt werden können(leben, waffen und vielleicht nochn paar neutrale skills bei bedarf).

TEntity besitzt ein Event EntityAction.

Ich entferne mich an dieser stelle davon für jeden Typus eines Gegners eigene Klassen abzulaieten, und benutze eine einzige. Der clou an der sache ist, dass das was das Object machen soll an dass EntityAction event Attached wird.

Erstellen wir eine TEntity dass als Gegner fungieren soll kann so zb die selbstgeschriebene Methode Gegner genutzt werden, ODER wir schreiben eine Methode die den Playercode enthält.

Beispiel(aus meiner kleinen mini 2dengine)

Code:

TEntity = class(TComponent)
  public
    Mesh: TMesh;
    Skill1: Single;
    Skill2: Single;
    Skill3: Single;
    Skill4: Single;
    Skill5: Single;
    Skill6: Single;
    Skill7: Single;
    Skill8: Single;
    Skill9: Single;
    Skill10: Single;
    EntityAction: procedure(My: TEntity);
    constructor Create(AOwner: TComponent); override;
  end;

Ein einfaches beispiel für eine Entity Klasse
Eine Aktion für das Object kann dann so geschrieben werden:

Code:

procedure MeineAktion(My: TEntity)
begin
  My.Skill1 := My.Skill1+2;
end;

Zugewiesen kann es dann so werden:

Code:

  MeineEntity.EntityAction := MeineAktion;

Dann brauchst du noch eine schleife, die alle aktionen der in einer liste gespeicherten Objekte ausführt:

Code:

procedure TEngine.DoEntityActions;
var i: Integer;
begin
  for i := 0 to FEntityCount - 1 do
  begin
    if Assigned(FEntityLIst[i].EntityAction) then
    begin
      FEntityLIst[i].EntityAction(FEntityLIst[i]);
    end;
  end;
end;

FEntityList ist ein Array indem alle erstellten Entyties hinterlegt sind.
Deren EntityAction wird(falls verfügbar) aufgerufen und der Action die Entity instanz übergeben.


Dass mal als anregungen ;)

Wenn was unverständlich ist, einfach nachfragen^^. Bin schlecht im erklären :D

EDIT: die erstellung meines Spielers sieht bei mir dann z.B. so aus(ginge noch schöner, aber war maln "Iam Boored" projekt^^:

Code:

Player := GameEngine.AddEmptyEntity(Point(0,0),Self);
Player.Mesh.LoadFromMesh(CarMesh);
Player.Mesh.Pos_X := -25;
Player.Mesh.Pos_Y := 650;
Player.Mesh.RefreshBBox();
Player.EntityAction := PlayerAction;

EDIT2: Und Außerdem gehören Pos_X/Y eigentlich nicht in die Meshklasse*hust*
Kommt zur Entity, da das Mesh per Entity Position für die WeltPosition versetzt wird.


MFG
Memnarch

[r2c2]

Ja das geht auch, ich würde das so aber nicht machen. Aus mehreren Gründen. Der Hauptgrund ist, dass es letztendlich unübersichtlich wird. Wenn das Programm wächst hast du viele Objekte, die sich nur in den zugewiesenen Events unterscheiden. Wenn du jetzt mehr als nur eine Stelle hast, die sich für verschiedene Gegner ändert (Bewegung, Aussehen, Kampftaktik, was weiß ich), wird es schwer noch durch zu blicken, weil nicht klar ist, welche Events zusammengehören also dem selben Gegnertyp zuzurechnen sind. Außerdem kannst du so nicht so einfach mehrere gleichartige Gegner erstellen (der Aufwand hält sich in Grenzen, aber du müsstest extra ne Funktion dafür schreiben).

Zudem sind so die Variationen an Gegnern beschränkt.

Events haben den Vorteil, dass du sie zur Laufzeit wechseln und zuweisen kannst. Das nutzt du hier aber nicht. Und selbst wenn du das bräuchtest, könntest du das besser per Delegation lösen...

Events verwendet man normalerweise nur da, wo es wirklich um Ereignisse geht (ja es gibt diverse Ausnahmen). Also um Schnittstellen zu anderen Klassen. Als Ersatz für Vererbung sind sie IMHO eher nicht sinnvoll.

Sry, aber IMHO hat deine Lösung mehr Nach- als Vorteile.

mfg

Christian

P.S.: Nimm properties. Public fields sind bööse...

[Memnarch]

Zitat:

Außerdem kannst du so nicht so einfach mehrere gleichartige Gegner erstellen (der Aufwand hält sich in Grenzen, aber du müsstest extra ne Funktion dafür schreiben).

Also ich kann eine Funktion für XBelibig viele gegner nutzen.
Ich glaube du hast DoEntityAction nicht verstanden. Der MY parameter wird auf das aktuell zu nutzende objekt gesetzt.

Zitat:

Zudem sind so die Variationen an Gegnern beschränkt.

Wieso den dass?

Bitte nicht vergessen, Es wird auch nicht spezielle eine Angriffsfunktion geschrieben, sondern generell eine Angreif funktion die verschiedene werte von EntityA und EntityB auswertet.

[r2c2]

Zitat:

Zitat von Memnarch (Beitrag 1061639)

Also ich kann eine Funktion für XBelibig viele gegner nutzen.

Klar geht das. Hab ich auch geschrieben. Du musst nur einen Konstruktor emulieren. Aber warum denn emulieren, wenn man einen richtigen haben kann?

Zitat:

Ich glaube du hast DoEntityAction nicht verstanden. Der MY parameter wird auf das aktuell zu nutzende objekt gesetzt.

Hier emulierst du den Self-Parameter. Durch Nutzung der OO-Features hast du sowas ohne das alles selbst machen zu müssen. Du kommst ja teilweise auf die richtigen Ideen (Konstruktor, Self), baust das aber selbst nach anstatt das Vorhandene zu nutzen.

Zitat:

Zitat:

Zudem sind so die Variationen an Gegnern beschränkt.

Wieso den dass?

Ich geb zu, das hätte ich genauer darlegen können. Der Punkt ist folgender: Du hast unterschiedliche Arten von "Gegnern", die du definieren willst. Dabei sind die Arten unterschiedlich genug, dass du unterschiedlichen Code brauchst (das spräche eigentlich für Vererbung, die du aber wieder nur emulierst). Durch die Events definierst du einzelne Möglichkeiten, wie du Gegner variieren kannst. Das beschränkt dich aber in den Möglichkeiten, die du hast um Gegner zu variieren:
- du kannst auf keine privaten Felder zugreifen
- damit kannst du auch keine Methoden (bzw. bei dir Events) über einen internen Zustand koppeln. Alles, was deine Events tun, muss nach außen sichtbar sein.
- du kannst auch keine neuen Methoden und Eigenschaften hinzufügen

Das alles (und vielleicht noch mehr) schränkt dich ein.

Auf der anderen Seite hast du diverse Nachteile auf Seiten der Lesbarkeit:
- du verstößt gegen das Prinzip der geringsten Überraschung: Man erwartet eine solche Verwendung von Events nicht. Man kann so etwas tun, sollte dann aber einen sehr guten Grund dafür haben.
- zusammengehöriger Code (Code für Gegner A) ist nicht in einer Klasse gruppiert. Damit fehlt Übersicht
- du bietest diverse Möglichkeiten deinen Code falsch zu benutzen. Beispielsweise durch falsche oder fehlende Eventzuweisungen. Guten Code kann man intuitiv richtig benutzen, aber nur schwer falsch.

Das alles sind Nachteile. Gravierende Nachteile. Echte Vorteile bringt dein Ansatz aber keine. Zumindest hab ich keine entdecken können.

Auf weitere Probleme in deinem Code (Skill1..Skill10 uaahhh...) gehe ich aus Zeitgründen jetzt nicht weiter ein.

Sei mir nicht böse, aber dein Ansatz ist wirklich nicht so gut. Überdenke ihn nochmal.


mfg

Christian

[Memnarch]

Zitat:

- du kannst auch keine neuen Methoden und Eigenschaften hinzufügen

Das ist so halb und halb. Viele Funktionen/Methoden sind in der engine klasse enthalten, weil sie sich auch auf Engine interne abläufe beziehen.
So z.B. Move, was eine Entity zum gegebenen Punkt bewegt und dabei kollision ausführt.

Aber stimmt für reines OOP ist das nicht unbedingt was :P
Rührt noch aus alten Tagen diese Angewohnheit:twisted:

Is jetzt Ca 3/4 MOnate alt der Code, seitdem einiges mehr gemacht in Delphi.

Trotzdem gäbe es bei mir immer einige Funktionen die absolut nicht in der Entity landen würden(siehe move).

Ich bin als Zentrum TEngine orientiert die alles andere Steuern kann(Bzw, deren funktionen werden von dene ntities genutzt. Enginen verwaltet halt alles)

Und was SKill1-X angeht..naja, wirklich nichts feines :D

[r2c2]

Zitat:

Zitat von Memnarch (Beitrag 1061720)

Zitat:

- du kannst auch keine neuen Methoden und Eigenschaften hinzufügen

Das ist so halb und halb. Viele Funktionen/Methoden sind in der engine klasse enthalten, weil sie sich auch auf Engine interne abläufe beziehen.
So z.B. Move, was eine Entity zum gegebenen Punkt bewegt und dabei kollision ausführt.

[...]

Ich bin als Zentrum TEngine orientiert die alles andere Steuern kann(Bzw, deren funktionen werden von dene ntities genutzt. Enginen verwaltet halt alles)

Das ist auch nicht so toll. Nennt sich Gottklasse...

mfg

Christian