gegenseitiger Zugriff von zwei abgeleiteten Klassen

[martin28]

Hi alle zusammen.

Folgendes Problem: Ich versuche gerade ein kleines Rollenspiel zu programmieren, wo ich zum ersten Mal versuche, mittels Objekten meine Dinge im Spiel zu beschreiben (bietet sich ja besonders an ).

Grober Aufbau soweit:
Bewegliches Objekt = Class () mit x-Position, y-Position ,Leben, Angriffskraft etc
1x Spieler Objekt = Class (Bewegliches Objekt)
viele Monster Objekte = Class (Bewegliches Objekt)

Dinge die schon funktionieren sind z.B. das Bewegen, da wird eine Funktion aus Bewegliches Objekt aufgerufen, mit der ich den Spieler oder die Monster bewegen kann. Soweit so gut.

Was ich jetzt versuche herauszubekommen:
Ich möchte eine gemeinsame Angriffsroutine schreiben, die in Bewegliches Objekt verankert ist. Einerseits soll es möglich sein, dass das Spieler Objekt ein beliebiges Monster Objekt angreifen kann. Andererseits soll es möglich sein das ein Monster Objekt das Spieler Objekt angreift. Zur Krönung soll es dann noch möglich sein, das ein beliebiges Monster Objekt ein anderes beliebiges Monster Objekt angreifen kann. (hoffe das versteht einer )

Wie kann ich ein Zugriff von einem Beweglichem Objekt auf ein anderes Bewegliches Objekt ermöglichen? Ist es sinnvoll eine Art Counter-ID für jeden neue Bewegliche Objekt zu vergeben? Kann ich eine Funktion in Beweglichen Objekt aufrufen, die einen Zeiger auf ein anderes Bewegliches Objekt hat?
Welche Texte sollte ich zu dem Thema noch lesen?

Danke euch soweit erst einmal.

Martin

[mkinzler]

Einfach als "Bewegliches Objekt". GGf. dann wirklichen Typ überprüfen

if <Objekt> is Spieler then ...

[stahli]

Delphi unterstützt leider keine überkreuzenden Units.
M.E. Ist das der einzige wirkliche Makel an Delphi.

Die Kompilierung geht so schneller, man muss allerdings häufig auf Typecasts zurückgreifen.

Ich würde mir wünschen, dass sich Vorwärtsdeklarationen (die ja innerhalb einer Unit möglich sind):
ClassB = class;
auch auf andere Units anwenden lassen:
ClassB = class in unit ClassB;
Zumindest wenn bestimmte Rahmenbedingungen (die eine solche Auflösung absolut ausschließen würden) eingehalten werden.

Im Moment meckert mir der Compiler einfach zu schnell.

Habe ich ClassA und ClassB in einer Unit stehen, gibt es keine Probleme. Gliedere ich diese aber aus Gründen der Übersichtlichkeit in zwei getrennte Units aus, ändert sich ja eigentlich an den Beziehungen untereinander nichts. Delphi lehnt dies aber ab - und DAS PRANGERE ICH AN!

[martin28]

Hi.

Ja das es keine überkreuzenden Units gibt, finde ich auch 'ungünstig'. Daher muss ich ja auch alle wichtigen Objekte in eine Unit schreiben.

@mkinzler

Der is Operator funktioniert doch nur wenn die Objekte auch erzeugt habe, oder? (bei mir ist Bewegliches Objekt nur die Basis, von den ich dann Spieler und Monster ableite diese dann deklariere und initialisiere...)

Martin

[mkinzler]

Ja ab, da ja die IS-A Beziehung zwischen Klasse und Superklasse besthet, ist jedes Objekt vom Typ Spieler/Monster gleichzeitig auch vom Typ "Bewegliches Objekt"

Delphi-Quellcode:

function <Klasse>.TesteWas( Obj1, Obj2: TBewObjekt);
begin
    if ((Obj1 is TPlayer) and (Obj2 is TMonster)) or
       ((Obj2 is TPlayer) and (Obj1 is TMonster)) then //Kollision Spieler mit Monster
    begin
         ...
    end;
    ...
end;

[Sir Rufo]

Du willst doch 2 Objekte gegeneinander kämpfen lassen. Dann mach das doch

Delphi-Quellcode:

procedure Fight( const AObj, BObj : TBewObj );
begin
  AObj.Leben := AObj.Leben - BObj.Staerke;
  BObj.Leben := BObj.Leben - AObj.Staerke;
end;

[r2c2]

Zitat von Sir Rufo:

Du willst doch 2 Objekte gegeneinander kämpfen lassen. Dann mach das doch

Delphi-Quellcode:

procedure Fight( const AObj, BObj : TBewObj );
begin
  AObj.Leben := AObj.Leben - BObj.Staerke;
  BObj.Leben := BObj.Leben - AObj.Staerke;
end;

Genau. Bzw. besser noch als Methode:

Delphi-Quellcode:

procedure TMovableObject.Fight(AOther : TMovableObject);
begin
  Self.Leben := Self.Leben - AOther.Staerke;
  AOther.Leben := AOther.Leben - Self.Staerke;
end;

Das ist ziemlich straightforward.

Interessant wirds erst, wenn es einen Unterschied macht, wer gegen wen kämpft. Siehe hierzu:
http://www.christian-rehn.de/2009/08/31/multimethoden/
http://www.christian-rehn.de/2010/01...iple-dispatch/


mfg

Christian

[Sir Rufo]

Zitat von r2c2:

Interessant wirds erst, wenn es einen Unterschied macht, wer gegen wen kämpft. Siehe hierzu:
http://www.christian-rehn.de/2009/08/31/multimethoden/
http://www.christian-rehn.de/2010/01...iple-dispatch/


mfg

Christian

Die Anforderung aus dem Link würde ich so umsetzen.
Da kann auch jeder mit jedem und die lästige Forward-Deklaration fällt auch weg.

Delphi-Quellcode:

type
  TThing = class
    procedure CollideWith( Thing : TThing );
  end;

  TShip = class( TThing )
  end;

  TAsteroid = class( TThing )
  end;

  TBase = class( TThing )
  end;

  TThingCollisionHelper = class helper for TThing
    procedure CollideWith( Thing : TShip ); reintroduce; overload;
  end;

  TShipCollisionHelper = class helper for TShip
    procedure CollideWith( Thing : TShip ); reintroduce; overload;
    procedure CollideWith( Thing : TAsteroid ); reintroduce; overload;
    procedure CollideWith( Thing : TBase ); reintroduce; overload;
  end;

  TAsteroidCollisionHelper = class helper for TAsteroid
    procedure CollideWith( Thing : TShip ); reintroduce; overload;
    procedure CollideWith( Thing : TAsteroid ); reintroduce; overload;
  end;

[r2c2]

Class helpers hier zu nutzen ist ne interessante Idee. Gefällt mir. Aber es löst das Problem nicht. Zusätzlich ist immer noch eine is-Verzweigung oder das Visitor-Pattern nötig. Beispiel:

Delphi-Quellcode:

var
  a, b: TThing;
begin
  a := TAsteroid.Create;
  b := TShip.Create;
  a.CollideWith(b);

Hier wird TThing.CollideWith( Thing : TThing ); aufgerufen. Und nicht TAsteroidCollisionHelper.CollideWith( Thing : TShip ); Und das ist der springende Punkt...

mfg

Christian

[sx2008]

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.

Daher müssen zwei Klassen (TSpieler und TMonster) sich gegenseitig nicht kennen, sondern sie können jede notwendige Information über die gemeinsame Basisklasse erfahren.