 |
JLI Spieleprogrammierung
|
| Vorheriges Thema anzeigen :: Nächstes Thema anzeigen |
| Autor |
Nachricht |
freedom
Mini JLI'ler
Anmeldedatum: 03.05.2006
Beiträge: 2
Wohnort: Wien
Medaillen: Keine
|
 Verfasst am: 03.05.2006, 13:44 Titel: Begrenzung der Bewegungsmöglichkeiten |
 |
|
Hallo alle zusammen !
Ich bin hier neu, und würde gerne wissen wie ich in einem Level die Bewegungsmöglichkeiten von einem Sprite begrenzen kann.
Was ich damit meine:
Ich habe vor ein Spiel zu programmieren, dass Pacman ähnelt.
Bei Pacman gibt es ja viele Gänge in denen man Punkte sammelt.
Die Mauern die die Gänge ausmachen, bewirken, dass das Sprite nicht frei herumlaufen kann. Wie kann ich jetzt die Mauern programmieren, dass das Sprite nicht mit ihnen in Berührung kommen kann ?
Ich hoffe auf Hilfe |
|
| Nach oben |
|
 |
HotAcid
Super JLI'ler
Alter: 42
Anmeldedatum: 04.08.2002
Beiträge: 372
Wohnort: Berlin
Medaillen: Keine
|
| Verfasst am: 03.05.2006, 14:00 Titel: |
|
|
du musst die Position der Mauer mit der des Sprites vergleichen.
_________________
StGB §§ 328 Abs. 2 Pkt 3:
Mit Freiheitsstrafe bis zu fünf Jahren oder mit Geldstrafe wird bestraft, wer eine nukleare Explosion verursacht. |
|
| Nach oben |
|
|
The Lord of Programming
Living Legend
Alter: 36
Anmeldedatum: 14.03.2003
Beiträge: 3122
Medaillen: Keine
|
| Verfasst am: 03.05.2006, 14:00 Titel: |
|
|
Da gibt es viele verschiedene Methoden, aber die einfachste und ausbaufähigste wird wohl sein, wenn du deine Level in eine externe Datei auslagerst. Für den Anfang wird es das einfachste sein, wenn du deine Level tilebasiert aufbaust.
D.h. du teilst deinen gesamten Level in gleich große Quadrate. Jedes dieser Quadrate kann dann ein bestimmtes Tile "tragen". Du hast z.B. drei verschiedene Möglichkeiten: Steinboden, Wand, Holz. Jedes dieser Tiles erhält jetzt eine eindeutige ID (Steinboden=0, Wand=1, Holz=2). In deiner Leveldatei speicherst du jetzt nichts anderes als die richtige Reihenfolge dieser IDs.
Beim Laden deines Levels musst du nur noch diese Werte richtig interpretieren. Wenn du nun die Koordinaten des Sprites in die Koordinaten deiner "Tilemap" umrechnest, kannst du immer sofort sagen, was sich unter dem Sprite befindet.
Das ganze ist natürlich noch ausbaufähig, weil ein Sprite auch auf mehreren Tiles gleichzeitig sein kann, aber das lässt sich auch hinterher noch implementieren, wenn du schon mal so weit bist 
_________________
www.visualgamesentertainment.net
Current projects: RDTDC(1), JLI-Vor-Projekt, Tetris(-Tutorial), JLI-Format
(1) Realtime Developer Testing and Debugging Console
Anschlag, Anleitung zum Atombombenbau, Sprengkörper...
Hilf Schäuble! Damit er auch was findet... |
|
| Nach oben |
|
|
GreveN
JLI Master
Alter: 37
Anmeldedatum: 08.01.2004
Beiträge: 901
Wohnort: Sachsen - Dresden
Medaillen: Keine
|
| Verfasst am: 03.05.2006, 15:26 Titel: |
|
|
Ich würde die Kollisionsabfrage generell losgelöst von dem jeweiligen Tile-Objekt, über eine zusätzliche Kollisionsmap, realisieren. Der RPG-Maker verwendet da ein System, welches ich abgewandelt ziemlich klasse finde.
Du speicherst zu der Tilemap mit den Grafiken noch eine zusätzliche, mit einer Struktur, die in etwa so ausschauen könnte:
| CPP: | struct tile_collision
{
bool top : 1;
bool bottom : 1;
bool left : 1;
bool right : 1;
}; |
Das verschafft dir die Möglichkeit, Tiles nicht generell 'unbegehbar' machen zumüssen, was u.U. z.B. etwas komisch aussehen könnte, wenn sich die Figur an einer Klippe befindet - die Klippe ist am unteren Rand des Tiles und die Figur kann sich der Klippe überhaupt nicht nähern, da das Tile nicht betretbar ist.
Wenn sich die Figur jetzt nach unten bewegen soll, testest du einfach, ob 'top' der 'tile_collision'-Instanz des unteren Tiles gesetzt ist oder nicht, ist dies der Fall lässt sich das Tile nicht betreten - in o.g. Fall könnte jetzt 'bottom' gesetzt sein und die Figur kann das Tile nach unten nicht verlassen.
Insgesamt lässt sich sagen, dass dieses Verfahren in der Praxis etwas besser, bzw. realistischer aussieht, da Tiles, die einseitig den Weg versperren nicht zwangsweise von allen 4 Seiten unbegehbar sind.
Die Implementierung würde ich auch nicht unbedingt als anspruchsvoller betrachten. Und letztendlich besitzt diese Variante noch den Vorteil, dass du Optik und Physik klar voneinander trennen kannst und du bist nicht so strikt auf eine bestimmte Zahl von Objekten (Mauer, Weg, Wasser, ...) fixiert.
p.s.: Die hier vorgestellten Systeme beziehen sich natürlich auf Tile-orientierte Spiele (Pac-Man würde ich so implementieren), es gibt natürlich noch andere anwendbare Verfahren, bspw. Bitmasken, die sind allerdings schwieriger zu implementieren, wesentlich langsamer und brauchen noch dazu ordentlich Speicher. |
|
| Nach oben |
|
|
freedom
Mini JLI'ler
Anmeldedatum: 03.05.2006
Beiträge: 2
Wohnort: Wien
Medaillen: Keine
|
| Verfasst am: 03.05.2006, 18:04 Titel: |
|
|
danke für die schnellen posts !
wäre nett wenn einer mal ein Tutorial daüber schreiben würde
ich würde mich sehr darüber freuen
woher wisst ihr, dass überhaupt?
seit ihr da selber draufgekommen, oder aus einem Buch ? |
|
| Nach oben |
|
|
DirectXer
Dark JLI'ler
Anmeldedatum: 05.02.2005
Beiträge: 1201
Wohnort: Köln
Medaillen: Keine
|
| Verfasst am: 03.05.2006, 18:21 Titel: |
|
|
| freedom hat Folgendes geschrieben: | danke für die schnellen posts !
wäre nett wenn einer mal ein Tutorial daüber schreiben würde
ich würde mich sehr darüber freuen
woher wisst ihr, dass überhaupt?
seit ihr da selber draufgekommen, oder aus einem Buch ? |
sowas kommt mit der erfahrung. Manchmal kommt man selbst drauf, manchmal liest man sowas zufällig, manchmal sagt es einem einer... Man muss nur lange genug dabei sein  |
|
| Nach oben |
|
|
The Lord of Programming
Living Legend
Alter: 36
Anmeldedatum: 14.03.2003
Beiträge: 3122
Medaillen: Keine
|
| Verfasst am: 03.05.2006, 18:36 Titel: |
|
|
Ja, du musst dir einfach über die Möglichkeiten bewusst sein, die du hast, um irgendwas bestimmtes zu erreichen.
Mit der Zeit wird es immer einfacher, sich daraus den besten Weg zusammen zu konstruieren.
Ich habe (in anderen Fragen) schon von vielen Methoden gehört, an die ich nie gedacht hätte, wenn mich nicht jemand darauf aufmerksam gemacht hätte, aber das ist normal
Hängt eben davon ab, wie man denkt...
_________________
www.visualgamesentertainment.net
Current projects: RDTDC(1), JLI-Vor-Projekt, Tetris(-Tutorial), JLI-Format
(1) Realtime Developer Testing and Debugging Console
Anschlag, Anleitung zum Atombombenbau, Sprengkörper...
Hilf Schäuble! Damit er auch was findet... |
|
| Nach oben |
|
|
GreveN
JLI Master
Alter: 37
Anmeldedatum: 08.01.2004
Beiträge: 901
Wohnort: Sachsen - Dresden
Medaillen: Keine
|
| Verfasst am: 03.05.2006, 19:28 Titel: |
|
|
| freedom hat Folgendes geschrieben: | wäre nett wenn einer mal ein Tutorial daüber schreiben würde
ich würde mich sehr darüber freuen |
Pass auf, mit einem Tutorial kann ich zwar nicht dienen, aber eigentlich ist das Ganze recht easy. Ich gehe mal davon aus, dass du weißt, was eine Tilemap ist, bzw. wie tilebasierte Spiele funktionieren.
Nun wirst du doch so, oder so ähnlich eine Tilemap für die eigentlichen 'grafischen' Tiles erzeugen:
| CPP: | class sprite
{
...
};
sprite* tilemap[100][100]; |
Das Ganze natürlich jetzt stark vereinfacht, dem Verständnis wegen.
Das überträgst du jetzt auf dein 'Kollisionssystem', also speicherst du statt den Tiles, Instanzen dieser Kollisions-Test-Struktur die ich oben vorgestellt habe. Kurz:
| CPP: | struct tile_collision
{
bool top : 1;
bool bottom : 1;
bool left : 1;
bool right : 1;
};
tile_collision* collisionmap[100][100]; |
Letztendlich muss dieses Array noch irgendwie sauber initialisiert, sprich mit Werten vollgepackt werden. Da das per Hand auf Dauer etwas ätzend wird (*hust*), könntest du dir dafür bspw. eine Funktion schreiben, die eine Datei ausliest und das Kollisions-Array vernünftig initialisiert.
Rendern bzw. zeichnen würdes du den ganzen Kram ja jetzt so:
| CPP: | for(unsigned int y=0; y<100; ++y)
for(unsigned int x=0; x<100; ++x)
tilemap[x][y]->render(...); |
Mit dem Testen auf Kollision verhält es sich im Prinzip genauso:
| CPP: | switch(direction)
{
case up:
if(!(collisionmap[playerpos.x][playerpos.y-1]->bottom) &&
!(collisionmap[playerpos.x][playerpos.y]->top) &&
( Teste hier evt. noch irgendwelchen anderen Blabla! ))
--playerpos.y;
break;
case down:
if(!(collisionmap[playerpos.x][playerpos.y+1]->top) &&
!(collisionmap[playerpos.x][playerpos.y]->down) &&
(...))
++playerpos.y;
break;
case right:
if(!(collisionmap[playerpos.x+1][playerpos.y]->left) &&
!(collisionmap[playerpos.x][playerpos.y]->right &&
(...))
++playerpos.x;
break;
case left:
if(!(collisionmap[playerpos.x-1][playerpos.y]->right) &&
!(collisionmap[playerpos.x][playerpos.y]->left &&
(...))
--playerpos.x;
break;
} |
So, dass ist jetzt alles natürlich sehr spartanisch, außerdem keine Sicherungsmechanismen, die z.B. überprüfen ob die Werte noch gültig sind, bzw. die Map schon zu Ende ist, das ist auch alles nicht schön OO, ich weiß, aber es sollte ja schließlich verständlich sein, also schiebt euch eure Kritik sonst wohin. 
Naja, so müsste das jedenfalls funktionieren, auch wenn ich das jetzt fix aus dem Kopf gemacht habe und deshalb diverse Tippfehler und dergleichen enthalten sein könnten. |
|
| Nach oben |
|
|
|
|
Du kannst keine Beiträge in dieses Forum schreiben.
Du kannst auf Beiträge in diesem Forum nicht antworten.
Du kannst deine Beiträge in diesem Forum nicht bearbeiten.
Du kannst deine Beiträge in diesem Forum nicht löschen.
Du kannst an Umfragen in diesem Forum nicht mitmachen.
|
Powered by phpBB © 2001, 2005 phpBB Group
Deutsche Übersetzung von phpBB.de |
FAQ
Suchen
Mitgliederliste
Benutzergruppen
Medaillen
Registrieren
Profil
Einloggen, um private Nachrichten zu lesen
Login
