Break it Komplikationen...

[speedy23]

hey leute, mein projekt nimmt gestalt an und hat potential;)

ich habe ja vor einiger zeit schonmal von meinem breakit(spiel) problem gesprochen
und nun das grundgerüst fertiggestellt.
es sind vorhanden
-steuerbarer reflektor,
-spieloberfläche,
-ball,
-nötige reflexionen um den ball im feld zu halten.
-game over funtion


aber mein problem ist:
der ball wird nur am obersten rand des brickszurückgeworfen und ich habe mit aufzeichnen und allem pipapo keinen gedanklichen ansatz für meinen fehler gefunden ... ihr könnts euch gerne anschauen, und für tipps und kritiken bin ich sowieso zu haben :)

was ich noch hinzufügen möchte:
- mehrere steine,
- zeitmesser,
- punktezähler sowie
- highscoreliste

dateien sind im anhang danke im voraus :)

[Blup]

Zitat:

Zitat von speedy23

hey leute, mein projekt nimmt gestalt an und hat potential;)

ich habe ja vor einiger zeit schonmal von meinem breakit(spiel) problem gesprochen
und nun das grundgerüst fertiggestellt.

Du hast ein bischen Oberfläche programmiert, ein Grundgerüst ist leider überhaupt nicht vorhanden.
Lies mal was ich hier Memory zum grundsätzlichen Aufbau eines Spiels oder Anwendung allgemein geschrieben hab und schau dir mein Beispiel an.

Die Anwendung wird in deiner jetzigen Struktur zu einem endlosen Spagettiprogramm mutieren.
Ein deutliches Zeichen ist, daß du schon jetzt bei den par Zeilen den Fehler nicht finden kannst.
Zum eigentlichen Fehler:
Überprüfe alle Positionsvergleiche auf "=" , in der Regel ist es sicherer auf "<=" oder ">=" zu testen.
Für die Änderung der Bewegungsrichtung ist es nicht ausreichend das Vorzeichen des Geschwindigkeitsvektors zu ändern.
Man muss auch prüfen ob der Vektor schon "umgedreht" wurde.
Bsp.: Das Objekt hat den oberen Rand überschritten, der Geschwindigkeitsvektor muss also für y-Richtung positive werden.

Delphi-Quellcode:

if ObererRandUeberschritten then
begin
  if dy < 0 then
    dy := -dy;
end
else if UntererRandUeberschritten then
begin
  if dy > 0 then
    dy := -dy;
end;
{Objekt bewegen}
y := y + dy;

[mkinzler]

Zitat:

Überprüfe alle Positionsvergleiche auf "=" , in der Regel ist es sicherer auf "<=" oder ">=" zu testen.

Das führt dann bei Deltas > 1 mit großer Wahrscheinlichkeit zur Fehlfunktion

[speedy23]

erstmal vorweg, danke für die kritik, sowas ist konstruktiv:)

ja ich muss dir natürlich recht geben nur mein problem war... so wie ich die kollisionen am panel (schläger) hatte wollte ich einfach alles auf den brick übertragen aber das geht nicht... gedanken habe ich mir ja schon gemacht, mir ist nur die tragweite nicht klar geworden, das hast du vollkommen recht!

ich dachte mir wenn ich erstmal den ball im feld halten kann, er reflektiert wird von wand und schläger, und sogar noch eine verlorenmeldung kommt, wenn er den unteren rand berührt, ist die sache zu 90% fertig. Das problem sind jetzt meine steine, dahingestellt ob image oder shape.

ich danke dir für deine antwort, aber ich verstehe nicht, warum es wichtig ist zu wissen, ob der vektor schon einmal umgekehrt wurde... denn das war ja bei den wänden auch der fall.
ich hab hier irgendeinen denkfehler, deswegen verstehe ich auch nicht wie du das meinst... .
wenn du vllt erklären könntest wie genau du das meinst, wäre ich sehr dankbar.

mfg
speedy23

[speedy23]

oder liege ich da so falsch??

[himitsu]

Zitat:

und hat potential;)

Ja klar, wenn fast noch nichts vorhanden ist, dann ist noch genügend Potential vorhanden.


Witzig finde ich Demomeldungen von verwendeten Komponenten.

Schön ist auch, daß mit dem Skinning schon begonnen wird, bevor überhaupt eine Funktion vorhanden ist.

Wenn du Quellcode zur Verfügung stellst, den sich ander auch noch freiwillig ansehn sollen,
dann wäre es nicht schlecht, wenn man zumindestens erwähnt, daß Zusatzkomponenten nötig sind, damit überhaupt was passiert.

Ansonsten macht es sich besser, wenn man die Oberfläche von der Logik trennt.
(dafür eignet sich OOP ja recht gut)


Am Einfachsten du erstellst dir erstmal je eine Klasse für alle Objekte (Spielfeld, Schläger, Ball/Bälle und Bricks), welche alle nötigen Informationen zu diesem Objekt enthalten,
anstatt deren Eigenschaften (wie Position, Größe und Geschwindigkeit) in irgendwelchen sonstwo verstecken Variablen oder der GUI abzulegen.

Das mit den getrennten Objekten hat auch den Vorteil, daß dein Code später etwas sortierter ist und man schneller was findet.

Und weißt du wie schwer es wird, wenn du alle Bricks einzeln verwaltest?
Stell dir mal vor du hast 100 Bricks ... dann hast du bei deinem aktuellem Code womöglich auch alle Kollisionsabfragen 100-mal im Code. :shock:


PS: Wenn du solche Probleme mit der Kollisionsabfrage hast, dann versuch es doch erstmal in der Realität?
Nimm dir ein Blatt Karopapier, mal ein Koordinatensystem drauf (entsprechend dem Monitor ... muß ja nicht Maßstabsgetreu sein)
schneide ein paar Figuren (Ball, Schläger, Brickets) aus und schau dir an, wie sich die Koordinaten verwalten und was du wie prüfen mußt.