Kollisions Abfrage und Klassen design

[Templon]

Hi,
Also ich habe 2 Fragen zu einem 2D Jump'n run Game. Bis jetzt habe ich den Editor zum erstellen der Maps gemacht.

1. In diesem befindet sich die Klasse "Player", in der werden zum beispiel die X und Y-Koordinaten wo ich sie gesetzt hab, Image etc. gespeichert. Nun in dem Game brauch ich diese Klasse nun auch wieder, aber mit noch mehr Funktionen wie z.B. move etc. Soll ich nun schon in der Player Klasse vom Editor die Funktion impelemtieren? Oder wie soll ich das am besten machen?

2. Wie soll ich die Kollisions Abfrage am besten implementieren? Ich habe mir überlegt, das wenn ich z.B. nach rechts drücke der Player immer einen bestimmen Zahl nach vorne lauft (z.B. 10 Pixel) und dann bevor er läuft schaut ob etwas im weg ist? Aber wie? Die Tiles haben ein Rectangle als Kollisionsmodel und der Player auch. Wie kann ich schauen ob die sich überschneiden werden? Ach ja und was sollte da alles in einem Thread ablaufen?

Grüsse Templon

 

[Marco13]

Es ist schwierig, zu solchen Designfragen was zu sagen, wenn man das Gesamtsystem nicht kennt. Wichtig wäre z.B. zu wissen, wie stark der Editor und das Spiel gekoppelt sind. Aber eine Möglichkeit (auf Basis der wenigen Informationen) wäre, die Klasse "Player" für den Editor zu verwenden, und eine Klasse "GamePlayer extends Player" zu erstellen, die die Funktionen bereitstellt, die NUR für das Spiel benötigt werden. Das kann man dann notfalls später relativ leicht trennen oder zusammenfügen.
Die zweite Frage ist noch schwieriger. Wenn alles immer Rechtecke sind, und die Bewegung NIE so groß sein kann, dass ein Spieler z.B. mit EINEM Schritt komplett durch eine Wand laufen kann, dann könntest du einfach die "Umrisse" der Objekte als Rectangle speichern, und dann (bevor der Schritt wirklich ausgeführt wird) mit rectangle.intersects(otherRectangle) überprüfen, ob eine Kollision stattfinden wird, und dann ggf. nur einen kleineren Schritt erlauben (das könnte man dann aber evtl. auch effizienter implementieren - also sauber in einer Methode kapseln!). Die Kollisionserkennung in einem eigenen Thread zu machen wäre vermutlich sehr schwierig, und bei einem "kleinen" Spiel wohl auch nicht angemessen - das sollte der Game-Thread nebenbei erledigen.

 

[Templon]

Hallo, und erstmal danke für deine Hilfe :toll:

Das mit dem extenden hab ich mir auch schon gedacht, dann werde ich das mal so probieren.. Sind eigentlich schon recht stark gekoppelt also die Enemy, Tile und Player Klassen brauche ich alle, und noch ein paar andere.

In meinem Tile Objekt habe ich die Kollision gespeichrt aber noch nicht als Rectangle, aber mit den Rectangle ist das sicher eine gute Idee. Was würdest du alles in einen Thread packen? Sicher den Player und die Gegner? Und was noch?

 

[Marco13]

Da sieht man, wie schwierig es ist, dazu etwas zu sagen: Player und Gegner können "vermutlich" in einen Thread. Aber was GIBT es denn noch, was dort rein könnte? :wink: Ich würde dich jetzt aber ungern in irgendeine falsche Richtung lenken, was das angeht. Ich habe selbst noch kein Jump&Run geschrieben.

 

[Guest]

Was würdest du alles in einen Thread packen? Sicher den Player und die Gegner? Und was noch?

Wozu? Ich kann mich nur immer wiederholen: Threads in Spielen sind meistens keine gute Idee und sollten vermieden werden, wenn es möglich ist.

 

[EgonOlsen]

Opps...Login vergessen. Das da oben war ich.

 

[Marco13]

Jetzt, wo du das sagst, fällt mir auf, dass die Frage
Was würdest du alles in einen Thread packen? Sicher den Player und die Gegner? Und was noch?
sehr mißverständlich war: Ich habe das so interpretiert, dass Player und Gegner in EINEM (gemeinsamen) Thread liegt, und NICHT in jeweils einem (eigenen) Thread. Das Problem ist bei mehren Threads eben immer die Synchronisation. Und wenn man sich die ersparen kann, sollte man das tun.

 

[Templon]

Was muss denn da synchronisiert werden? Bei meinem letzten Spiel (Äpfel fliegen vom Himmel runter, und man muss diese mit einem Korb einfangen ) ... Da war jeder Apfel ein eigener Thread, und ich hatte keine Probleme damit...

 

[Marco13]

Es kommt immer darauf an. (Ziemlich schwammig, das ganze). Aber ohne synchronisation könnte es z.B. passieren, dass der Spieler und ein Gegner ein "fast gleichzeitig" irgendein "Power-Up-Item" schnappen - normalerweise sollte es nur EINER von beiden bekommen, und ohne synchronisation bekommen es dann evtl. BEIDE. (Wobei das noch das am-wenigsten-schlimme wäre, was passieren könnte - Exceptions bei ungünstiger Wahl der verwendeten Collections usw. könnten auch auftreten). Aber das ist nur ein abstraktes Beispiel um die möglichen Probleme zu verdeutlichen.

 

[Wildcard]

Was muss denn da synchronisiert werden? Bei meinem letzten Spiel (Äpfel fliegen vom Himmel runter, und man muss diese mit einem Korb einfangen ) ... Da war jeder Apfel ein eigener Thread, und ich hatte keine Probleme damit...

Genauso kann es passieren das einer der Threads nicht mehr dran kommt und der Apfel in der Luft verhungert, oder das er viel zu schnell fällt usw.
Zusätzlich zu den Gefahren erzeugen so viele Threads auch einen Verwaltungsoverhead.
So viele Threads wie nötig, so wenige wie möglich.

 

[EgonOlsen]

Was muss denn da synchronisiert werden? Bei meinem letzten Spiel (Äpfel fliegen vom Himmel runter, und man muss diese mit einem Korb einfangen ) ... Da war jeder Apfel ein eigener Thread, und ich hatte keine Probleme damit...

Wenn die Argumente dagegen nicht einleuchten, dann probieren wir es doch mal anders herum: Was spricht denn deiner Ansicht nach dafür, das so zu machen?

 

[Templon]

Ja gibt eigentlich keine, ich hab gedacht es geht nur mit Threads... Falsch gedacht Mein Bruder hat mir auch gesagt, das ich gar keine brauche, ich könne einfach alles in einer grossen schleife machen.

 

[Wildcard]

Du hast in aller Regel 2 Threads für diese Art Anwendungsfall:
Den Event Dispatcher Thread in dem deine GUI läuft und einen Hintergrundthread der für Bewegung zuständig ist.

 

[Templon]

Den Event Dispatcher Thread hab ich sowieso den muss ich nicht starten oder?

 

[Wildcard]

Der startet automatisch sobald ein Fenster aufgeht.
Falls du dich mal gefragt hast warum ein Programm wenn man ein Fenster aufmacht nicht wie üblich terminiert sobald das Ende der main erreicht ist, jetzt hast du die Antwort :wink:

 

[Templon]

Hehe, danke gut zu wissen Bin halt noch ein noob in Java .. Naja dann werd ich mal anfangen das ohne Threads zu lösen.. Und einfach wieder fragen wenn etwas unklar ist