Pac-Man Hilfe

[DeddyH]

Zitat von DelphiforNUBS:

das kann man mit einer for-Schleife realisieren...

1) alle Eckpunkte von pacman durchgehen
--- mit jedem punkt:
prüfe ob X1 > X2 und X1 < X3

IntersectRect, das ermittelt auch völlige Überlappung (wenn ein Rechteck das andere komplett umschließt).

[BadenPower]

Zitat von DeddyH:

IntersectRect, das ermittelt auch völlige Überlappung (wenn ein Rechteck das andere komplett umschließt).

Ich glaube kaum, dass das hier zur Anwendung kommen muss, da ich eher vermute, dass dieser Pacman sowieso nur von einer Zelle zur anderen springen wird.

[DeddyH]

Zitat von BadenPower:

Zitat von DeddyH:

IntersectRect, das ermittelt auch völlige Überlappung (wenn ein Rechteck das andere komplett umschließt).

Ich glaube kaum, dass das hier zur Anwendung kommen muss, da ich eher vermute, dass dieser Pacman sowieso nur von einer Zelle zur anderen springen wird.

Mir ging es auch eher darum, etwas Fertiges zu verwenden, statt eine fehlerträchtige eigene Lösung anzustreben.

[Sir Rufo]

Pacman benötigt keinerlei Kollision-Detection wo sich Rechtecke überlagern.

Das gesamte Spiel läuft auf einem Gitter ab. Jede Zelle ist dabei entweder eine Wand oder ein Fresspunkt oder ein Powerpunkt. Pacman selber befindet sich entweder genau in einer Zelle oder ist auf dem Weg von einer Zelle zur anderen. Sobald sich Pacman direkt auf der Zelle befindet ist der Punkt gefressen.

Zusammenstösse mit den Geistern fragt man einfach über den Status ab, denn auch die sind entweder auf einer Zelle oder auf dem Weg zu einer anderen Zelle.

[Bjoerk]

Als "mitlesendender 10%-Profi" frage ich mich, weshalb diese Zwischenzustände?

[Mavarik]

Zitat von Bjoerk:

Als "mitlesendender 10%-Profi" frage ich mich, weshalb diese Zwischenzustände?

Flüssigere Bewegungen...

[Popov]

Ich denke die Tipps bis jetzt sind klein wenig zu gut gemeint. Das sind Anfänger, ich denke nicht, dass sie Kollisionen prüfen wollen oder auf flüssige Bewegungen aus sind. Ich kann mich aber auch irren.

@TE

Jeder der so ein Schulprojekt anfängt stürmt zuerst auf das DrawGrid. Mit Bitmap kann man das übrigens genauso leicht lösen.

Zu dem eigentlichen Thema. Ich hab mal damals mit C64 ein Spiel gespielt, das ein sehr simples wie einfaches Konzept hatte. Es sah ganz normal aus, man bewegte sich in einem sehr großem Labyrinth, der Bildschirm hat immer nur ein Teil davon angezeigt. Es gab frei Flächen, Wände, Wände die man weg ballern konnte, usw.

Das interessante war aber die Mappe. Das war nicht eine große gezeichnete Grafik, das war eine Textdatei, wie z. B. diese hier.

Code:

ammmmmmmmmmmmb
mggggggggggggm
mgmmmmmgmmmmmm
mgggmmmggggggm
mmmgmmmgmmmmgm
mggggggggggggm
cmmmmmmmmmmmmd

Sie bestand aus lauter Buchstaben und Zahlen. Das Geniale dabei war nun, dass jeder Buchstabe für eine kleine Grafik stand (nennen wir sie mal Symbole). Alle Symbole waren gleich groß und jeder Buchstabe stand für einen Symbol.

Wenn also gezeichnet wurde, wurde im Speicher geguckt für was (um mal bei dem oberen Beispiel zu bleiben) g steht. Und dann wurde statt g eben das Symbole gezeichnet. Das war also eine simple Methode um aus einer kleinen Textdatei eine gewaltige Grafik-Mappe zu erstellen.

Was dieses Konzept nun möglich macht ist, die Mappe zu verändern. Bleiben wir bei PackMan. Hier könnte g für einen Punkt stehen. Hat PackMan den Punkt gefressen, wird g durch ein h ersetzt. Und h ist ein Symbol ohne den Punkt. Man ersetzt einfach g durch h und das Programm erledigt den Rest. Denn nun zeichnet das Programm die Grafik neu und zeichnet anstelle des Symbols für g, das Symbol für h.

Hier ein zwei Beispiele. Das erste nur mit Bitmap, dann habe ich noch ein Beispiel für DrawGrid gemacht:

[Zwinge112]

Danke für die viele Hilfe, ich versuche es weiter und hänge den Quellcode mal noch an.

[Popov]

@Zwinge112

Ich hab da kurz reingeschaut und gebe zu meine Schwierigkeiten gehabt zu haben euer Konzept zu verstehen. Ihr habt anscheinend einen StringGrid für die Mauern und ein für Packman wo der war. Beide StringGrids nutzt ihr eigentlich nur als Speicher. Dann übertragt ihr den Packman aus der Position des zweiten StringGrids auf die Image. Die Wände in der Image haben aber anscheinend nichts mit dem ersten StringGrid für Wände zu tun, bzw. die Werte sind von Hand eingetragen und entsprechen in etwa denen auf der Image. Und nun versucht ihr alles zu koordinieren. Erste StringGrid, zweite StringGrid und die Image.

Und wie ich es nun verstehe möchtest du wissen wie du auch noch die Punkte da in das Spiel bringst. Dazu brauchst du eigentlich eine dritte StringGrid.

Ich will eure bisherigen Programmierleistungen nicht schmälern, ihr habt vielleicht ein sonderbares Konzept, aber zumindest viel geschafft. Das Problem ist, dass ihr es etwas kompliziert macht. Aus eurer Sicht habt ihr vermutlich den einfachsten Lösungsansatz genommen, wobei StringGrid als Datenspeicher zu nutzen logisch erscheint, aber das rächt sich im weiteren Verlauf. Denn nun braucht ihr einen weitere StringGrid für andere Daten und nun eigentlich noch mal welche für wieder neue Daten.

Wenn ich nun sehe, dass ihr sogar eine Klasse entwickelt habt, frage ich mich wieso ihr einen so komplizierten Weg über die StringGrids geht? Warum löst ihr das alles nicht über einen Array Record?

Delphi-Quellcode:

type
  TPacLaby = record
    Wand: Integer;     //Hier die Wand programmieren
    Besucht: Integer;  //Hier vermerken wo PacMan schon war
    Punkte: Integer;   //Hier Punkte setzen, die PackMan schluckt. Wobei...
                       //wo Packman schon war, da sind auch die Punkte weg.
                       //Somit sind Punkte überall da wo Packman noch nicht war.
  end;

var
  PacLaby: array[0..23, 0..23] of TPacLaby;

procedure TForm1.FormCreate(Sender: TObject);
begin
  PacLaby[0, 0].Wand := 1;
  //...
end;

[DeddyH]

Oder vielleicht so in der Art:

Delphi-Quellcode:

const
  FELDER_X = 24;
  FELDER_Y = 24;
  
type
  TFeldZustand = (dtNix, dtWand, dtPunkt, dtGeist, dtPacman);
  
  TSpielfeld = array[0..FELDER_X - 1, 0..FELDER_Y - 1] of TFeldzustand;