Die meiste Arbeit davon könntest du in einer Methode des Spielfeldes machen, dass ein Feld zu einem bestimmten Typ macht:
Delphi-Quellcode:
type TFeld = class
...
TFeldClass = class of TFeld;
TBomb = class(TFeld)
...
end;
TBombClass = class(TBomb);
// usw.
type TSpielfeld = class
private
const FELDGROESSE = 10;
FFelder = array[0..FELDGROESSE-1, 0..FELDGROESSE-1] of TFeld;
public
SetFieldTo(i,j: byte; NewClass: TFeldClass);
end;
procedure TSpielfeld.SetFieldTo(i,j: byte; NewClass: TFeldClass);
begin
if not (FFelder[i,j] is NewClass) then begin // Veränderung?
FFelder[i,j].Free;
FFelder[i,j] := NewClass.Create;
end;
end;
Alle vorzunehmenden Einstellungen, wie z.B. ExplodeTime etc., gehören sowieso in den Konstruktor der entsprechenden Unterklasse (in diesem Fall TBomb.Create)
Jetzt ließe sich mit Spielfeld.SetFieldTo(0,0, TBomb) das linke obere Feld zu einer Bombe machen, ein anschließender Aufruf Spielfeld.SetFieldTo(0,0, TWall) verwandelt die Bombe in eine Wand.
Nachteil: Alle alten Objektreferenzen verlieren dabei ihre Gültigkeit, wenn du dir also im Spielerfigur-Objekt ein die TFeld-Instanz abspeicherst, auf der sich die Figur gerade befindet, kann es dir passieren, dass diese ihre Gültigkeit verliert. Um das zu vermeiden müsstest du halt grundsätzlich immer über Zeilen- und Spaltenindex auf die Felder zugreifen.
//edit:
@McLane: Konstruktoren sind automatisch virtuell (wär ja sonst auch wenig sinnvoll)...das override braucht (darf?) da also nicht hin. Reintroduce ist falsch, verdecken willst du hier ja nicht.