Spielprogrammierung, Shape und Image

[Laurine]

Hallo

Ich habe vor, ein Spiel zu programmieren, aber mir fehlt ein entscheidender Teil. Ich habe auf einem Image ein Labyrinth erstellt (mit form1.Image1.Canvas.Rectangle usw) und nun auch eine Shape, die sich mit den Pfeiltasten bewegen lässt.

Nur kann ich mit meiner Shape noch durch die "Wände" hindurch gehen, und das sollte bei einem Labyrinth nicht so sein. Wie kann ich verhindern, dass die Shape durch Wände geht?
Kann man das über die Farbe des Untergrundes machen? und wenn ja, wie?
Geplant sind auch rote "Aktionsfelder" die auch beim Betreten ausgelöst werden müssen.

Wie kann ich das realisieren?

Vielen Dank schon im Vorraus

[Rollo62]

Wenn es nur um ein einfaches Labyrinth geht könnte man das ja auch über ein Array des Spielfeldes machen,
in dem die erlaubten Richtungen stehen.

[Sherlock]

Du mußt eigentlich immer nur wissen, wo was ist. Beim Einzeichnen hast du ja Koordinaten verwendet, die solltest du einfach weiter verwenden. Das Prinzip ist die Kollisionsabfrage, wie zB hier diskutiert: https://www.delphipraxis.net/149759-...nsabfrage.html

Sherlock

[Nju]

Hallo,
es gibt verschiedene Möglichkeiten ein Labyrinthspiel zu bewerkstelligen. Prinzipiell baue ich die bisherigen Vorschläge der Vorposter (mit eigener Erfahrung) aus:

1. Array
Wie ein Vorposter bereits geschrieben hat, sind hier die Zustandsinformationen (Begehbar, Wand, Schalter, etc.) drin, die man abfragen und anzeigen (mit Grafikblöcken)/verwerten kann.

a) Diese Methode eignet sich sehr gut für diskrete Bewegungen (und ist in diesem Fall verdammt schnell!).
b) Auch kontinuierliche Bewegungen sind möglich, allerdings must du im Hintergrund die Position auf das Array umrechnen. Z.B. jeder Block hat eine Größe von 20x20 Pixel. Wenn die Spielfigur eine Wand treffen würde (Spielfigurkoordinaten x=329, y=183 ---> Array[17, 10]), reagiere darauf. Ist immernoch sehr schnell.
c) Kollisionsabfrage der Grafiken: Jeder Block ist ein Objekt. Wenn die Spielfigur das Objekt "Wand" treffen würde, dann geht die Spielfigur nicht weiter. Bei Grundform-Kollisionsabfragen schnell, bei Polygonabfragen (z.B. Form eines unebenen Steins) "langsamer".

2. Layer
Hier greife ich deinen Vorschlag mit dem Untergrund auf: Der oberste Layer ist deine anzuzeigende Spielgrafik (das für den Spieler zu sehende Labyrinth).
Da drunter verstecken sich weitere Layer mit Zustandsinformationen. Der eine Layer kann für die Wände zuständig (keine Wand = transparent, Wand = Farbe) sein, ein weiterer für "Aktionsfelder". Ungewöhnliche Methode, geht aber bis zu einer gewissen Layerstufe ohne Probleme (Achtung->Wenn permanentes Scrolling im Einsatz ist, dürfte dies sehr langsam werden).

Wie du es machst, bleibt natürlich dir überlassen. Die gängigste Methode ist 1c, weil diese sehr schnell zu berechnen ist (Thema "Pixelgenaue Kollision" ist in Bezug auf Schnelligkeit mit Vorsicht zu genießen).

Mit Delphi würde ich allerdings keine Spiele (mehr) erstellen. Ja, ich widerspreche nicht, dass es möglich ist, das damit auf die Beine zu stellen und ja, ich spreche aus Erfahrung, man macht sich das Leben nur unnötig schwer. Du suchst dir Frameworks/Engines, die mit Delphi arbeiten. Ist gar nicht so leicht, da viele davon nicht mehr gepflegt werden. Grundfunktionen wie "Anzeigen, Animationen, etc." sind in der Regel mit dabei, Kollisionsabfrage und Physik darfst du dich mit rumschlagen.

AppGameKit ist gerade für Anfänger sehr gut geeignet schnelle Ergebnisse zu erzielen (mit Tier 2 ist man in Bezug auf Geschwindigkeit "konkurrenzfähig") -> allerdings kostenpflichtig, gibt aber eine Testversion und regelmäßige Rabattaktionen. Und dann gibt es ja noch zahlreiche kostenlose Engines (Unity, etc.), die von der Einarbeitung dann doch schon wesentlich komplexer sind (dafür aber umso mächtiger).

Zusammenfassend:
Zum Testen mit Methode 1a (und mit Einschränkung 1b) nimm Delphi - erwarte aber keine Wunder, denn du fährst einen Kleinwagen mit schlecht einrastender Gangschaltung (in Bezug auf Spiele!). Ab Methode 1b würde ich auf Spieleengines oder Frameworks greifen, die für Spiele ausgelegt sind.
Methode 2 empfehle ich nicht. Ich wollte nur mal Kreativität spielen lassen.

[Rollo62]

Hallo Nju,

danke für die tolle Wortschöpfung, ich bin also ein "Vorposter"
Gefällt mir.

Natürlich gibt es richtige Game-Systeme, aber auf kleinem Level macht Delphi durchaus Sinn.
Auch einfache Physik ist ab Werk integriert mit Box2D.
Mit Firemonkey kann man Bewegungen, etc. leicht reinbringen.
https://www.youtube.com/watch?v=JiHFspGIpBk
https://www.youtube.com/watch?v=O4-SFLjF8OU
Ganz so pessimistisch wäre ich deshalb nicht unbedingt.

[matashen]

Hallo,

klassisch macht man das mit Collissiondetection und Maskierung (XOR) wenn man die Figur auf den Untergrund zeichnet.

Da wir aber in der Objectwelt sind bietet sich hier ein Detection auf Objectebene an.

Allerding wie Vorposter schon schrieben nimmt man da eine fertige Engine die das automatisiert hier gabs auch mal eine recht gute 2D Engine vor 10 Jahren oder so hat das ein User gebaut nannte sich Andora (oder ähnlich, einfach mal suchen).

Ausser du willst als Projekt eine eigene Engine bauen

EDIT:
gibts sogar nocht und tatsächlich schon 10 Jahre her, hat der User Igel457 gemacht
https://sourceforge.net/p/andorra/wiki/Home/

Gruß Matthias

[Nju]

Zitat von matashen:

Hallo,

klassisch macht man das mit Collissiondetection und Maskierung (XOR) wenn man die Figur auf den Untergrund zeichnet.

Da wir aber in der Objectwelt sind bietet sich hier ein Detection auf Objectebene an.

Allerding wie Vorposter schon schrieben nimmt man da eine fertige Engine die das automatisiert hier gabs auch mal eine recht gute 2D Engine vor 10 Jahren oder so hat das ein User gebaut nannte sich Andora (oder ähnlich, einfach mal suchen).

Ausser du willst als Projekt eine eigene Engine bauen

EDIT:
gibts sogar nocht und tatsächlich schon 10 Jahre her, hat der User Igel457 gemacht
https://sourceforge.net/p/andorra/wiki/Home/

Gruß Matthias

Also wenn es um eine Übersicht an Spieleengines für Delphi geht, ist diese Liste ziemlich gut:

http://wiki.freepascal.org/Game_Engine

Aber wie gesagt: Diese werden zum Teil seit Jahren nicht mehr gepflegt. Selbst Andorra 2D ist aus dem Jahre 2008. Bin mir nicht ganz sicher, ob ich das vor 3-4 Jahren noch ordentlich zum Laufen bekommen habe...
Glaube mit DelphiX habe ich 2005 mal etwas rumgespielt und für brauchbar empfunden (Debugging war aber die Hölle!).

Nicht falsch verstehen: Ich finde es toll, dass sich Leute dafür begeistern können und der Delphi-Community dadurch viel Arbeit abnehmen. Ich persönlich würde solche Projekte eher zum Einstieg in die Spieleprogrammierung ansehen. Denn früher oder später wird man feststellen, dass es viel einfacher und komfortabler geht.

[alberthut]

Hallo @Nju, ich bin froh, dass du den Link oben geteilt hast, aber ich verstehe "the game loop" nicht wirklich. Kannst du mir noch ein paar Ideen geben?