spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Überlege mal, was passieren muss, damit du triffst, und was du überprüfst.

EDIT: Eigentlich bin ich kein Fan von Rechtschreib-Hinweisen aber:

Wight = Wicht
Width = Breite

Lenght = ---
Length = Länge

Zitat von »Patty1991«

Kannst du mir die kollisition mal schnell als codeschnippsel (am besten funkionierend) posten ?
der feind were 32x32 und der schuss 6x12 groß

Nein, ich poste dir keinen Codeschnipsel. Selber lernen hilft am meisten

Zitat von »Patty1991«

- Nur die if schleife mit den defines

Es gibt keine If-Schleifen, nur If-Abfragen.

Zitat von »Patty1991«

Abgesehn von den rechtschreibfehlern muss doch folgendes passieren:

Damit eine kollision statt finden kann, muss doch schuss.x und y mit der position des feindes übereinstimmen,
da sie sich aber beide bewegen können sie sich nicht treffen - hier kommen jetz die defines ins spiel

Die kollision soll nich pixelgenau sein, sondern nur "treffend"

Wieso auch immer die Defines bei diesem Problem helfen sollen verstehe ich nicht ganz (Abgesehen davon mag ich Defines sowieso nicht und benutze lieber const, aber das ist in einem solchen Fall Geschmackssache )
Abgesehen davon hast du einen Denkfehler. Überlege mal, was schuss.x/y sind, und was die Position deines Feindes ist (qualitativ, nicht quantitativ).

Ein weiterer Tipp: Schüsse und Feinde sind Flächen, keine Punkte.

Edit: Schön, dass du es jetzt per Copy-Paste gelöst hast. Aber verstehst du die Lösung auch? Das ist das wichtigste. Niemals fremden Code verwenden, wenn man ihn nicht versteht.

Ich finde, dass man sollte für Spielinterne Koordinaten keine Pixel verwenden sollte. Muss man dies dennoch machen sollte man dennoch keine Ganzzahlen für die Positionsangaben verwenden. Macht man das, kann man seinen Charakter ohne Probleme je Frame um weniger als 1 Pixel bewegen. Hat man Ganzzahlen, kann man seinen Charakter nur um eine feste Anzahl an Pixel/Frame bewegen, läuft das Spiel also mit 60 FPS ist die Geschwindigkeit des Charakters immer ein Vielfaches von 60 Pixel/Sekunde.

Die Bedingung ist einfach übermäßig mit Klammern ausgestattet. Werden alle unnötigen Klammern entfernt, landet man bei folgender Bedingung (für das if muss natürlich noch ein Klammernpaar drum herum):
Hier lässt sich aber wieder eine Unschönheit erkennen: Man sollte seine Elemente grundsätzlich anhand ihres Mittelpunkts positionieren, nicht aber anhand einer ihrer Ecken. Drehungen sind bspw. nur dann problemlos möglich, wenn die Drehung um den Mittelpunkt durchgeführt wird (und die Berechnung auch anhand des Mittelpunkts arbeitet).
Der obige Code ist immernoch so umfangreich, da geprüft wird, ob die beiden Rechtecke sich berühren. Würde man prüfen, ob sie sich _nicht_ berühren und das Ergebnis negieren, würde man bei folgendem Code landen (bei dem bereits von einer Positionierung anhand des Mittelpunkts ausgegangen wird):
Und grundsätzlich lässt sich sagen, dass diese Prüfung ausgelagert werden sollte, da diese an vielen Stellen wahrscheinlich noch benötigt wird. Auch wird bisher davon ausgegangen, dass es sich bei den Elementen um Rechtecke handelt, obwohl Kreise evtl. besser geeignet sein könnten. Die Berechnung bei Kreisen (nicht bei Ellipsen) wäre (wenn konsequent Vektoren verwendet werden würden, die Operatoren überladen sind und sqrMagnitude das Quadrat der Länge des Vektors darstellt):

Es gibt durchaus noch diverse Stellen, an denen noch das Eine oder Andere verbessert werden könnte.
Ein wichtiges Beispiel wäre da noch die Benennung, die nicht ganz einheitlich ist. Mal sind Variablen kleingeschrieben_mit_unterstrichen, mal camelCase und dann wieder camel_Case_Mit_Unterstrichen.