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.
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.