Threads ist nicht der richtige Weg für sowas und es machts vermutlich noch komplizierter.
Ich kann nicht unbedingt auf PB bezogen sprechen, weil ich da selbst noch Anfänger bin, aber was bei einem Ballergame so alles parallel ablaufen muß, daß weiß ich.
Wichtig zu klären ist erstmal:
Ist Dir denn rein theoretisch klar, was der Rechner bzw. das Programm alles tun müsste, um eben so eine Salve von Schüssen auf den Schirm zu bringen? Also wenn Du die Problemlösung z.B. auf einem Zettel in normaler Umganssprache ausformulieren würdest.
Wenn Du die Problemstellung also schonmal theoretisch lösen kannst, dann ist das die halbe Miete. Wenn man noch nicht alle PB-Befehle kennt, die dazu nötig sind, ist das zwar ziemlich ärgerlich, aber das ist eine Sache die sich im laufe der Zeit von selbst erledigt.
Das/die ersten Programme dauern leider dadurch unverhältnismäßig lange (also bei der Erstellung). Das mußt Du einfach so hinnehmen und wenn möglich nicht ungeduldig werden oder gar alles hinknallen.
Falls dir die theoretische Lösung der Problemstellung nicht klar ist, dann solltest Du mit etwas einfacheren Strukturen beginnen. Etwa nur ein Schuß für den es dann auch nur 3 oder 4 feste Variablen gibt.
Der Code da oben ist eigentlich gutes Anschauungsmaterial, aber eben schon einen Schritt weiter als es vermutlich für Dich gut wäre.
Versuche es erstmal mit etwas weniger Anspruch an Dich selbst.
Also: Vorher mal ganz in Ruhe nachdenken, welche Schritte zur Problemlösung alle nötig sind - also so rein theoretisch - und nicht einfach auf Teufel-komm-raus loscoden.
(Ich habe einen Kumpel, der konnte sich (früher mal) noch keinen Heimcomputer leisten, aber er hat ungelogen nächtelang an der Schreibmaschine Programmcode entwickelt... der dann nacher, als er seinen VIC 20 hatte, auch anstandslos funktionierte... naja, er musste das zwar alles nochmal abtippen und der Typ ist eh nen ziemlich heftiges Beispiel, aber das ist genau der richtige Weg (wenn auch etwas übertrieben in diesem Fall
. Der Kerl hat später VIC20/C64/Amigas göttlich in Assembler programmiert und konnte mit den Maschinen "jonglieren", wie ein Artist! Eben weil er immer das Problem und seine Lösung so exekt wie möglich versucht hat zu verstehen.)
Auch wichtig:
Versuche möglichst ein großes Problem in mehrere kleine Teilprobleme zu splitten, durch die das große Problem abgebildet wird.
Der Mensch ist nicht dazu gemacht ein komplexes Problem als ganzes zu erfassen und zu lösen... Immer schön kleine Häppchen... Babyschritte sozusagen. Klingt blöd, aber bringt viel.
Und am besten bringt man seine Lösungen zu den kleinen Problem-Häppchen alle fein säuberlich getrennt in einzelnen Prozeduren unter. Man verliert so nicht so schnell den Überblick.
Also soweit erstmal ein paar persönliche Tips von mir.
Viel Erfolg wünsche ich.
Gruß Markus