spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Riecht nach schlechtem Design.

Nein zu Singleton.
Ja zu Refactoring.

Ich sehe nicht so ganz wieso eine der Modell-Klassen die Verwaltung (Image-Manager) kennen sollte.

Vergiss den Singleton Pattern. Du wirst sicher noch sehr viele Singletons sehen aber sei dir sicher dass jeder Einzelne davon ein Designfehler ist. Alle Welt verwendet Singleton. Und alle Welt verwendet ihn falsch. Singleton wird ständig eingesetzt als "Ersatz" für eine globale Variable. Denn das ist angenehm, dann braucht man sich nämlich keine richtigen Gedanken ums Design machen. Frag dich mal selbst: Wenn ich meine globale Variable in buntes Geschenkpapier einwickel, wird dadurch irgendwas besser? Ich denk die Antwort sollte ziemlich offensichtlich sein. Singleton ist kein Ersatz für eine globale Variable und war auch nie dafür gedacht. Das Problem ist dass all diese Leute die heute "Singleton" verwenden den Pattern nicht verstanden haben. Anfänger lassen sich leicht dazu verführen zu denken dass so ein "Singleton" eine gute Idee ist weil es für manch ungeschultes Auge auf den ersten Blick vielleicht einfach und elegant wirken mag. Ist es nicht. Es gibt extrem wenige wirkliche Anwendungsfälle für ein Singleton und selbst dann gibt es in jedem dieser Fälle meiner Erfahrung nach immer mindestens eine bessere Alternative.

Ich seh in deiner Beschreibung ein ganz anderes Problem:

Zitat von »Tschu«

Ansonsten müsste ich für neue Schüsse immer wieder den Image Manager übergeben [...]

Zitat von »Tschu«

[...] da nur mein Schifflein von der Klasse CShot weiß [...]

Sollte das Konzept von einem Projektil nicht eigentlich von fundamentaler Bedeutung für die ganze Spielmechanik sein? Wieso weiß nur eine einzelne Klasse davon? Beschreib mal ein wenig was genau du so vor hast. Ich bin mir sicher wir können dir helfen eine gute Lösung zu finden

Zitat von »Tschu«

Refactoring? ..

Darunter versteht man einfach nur das Umstrukturieren von Code.

Zitat von »Tschu«

Erstmal wollte ich nur drauf los programmieren und gucken wie die Bibliothek so funktioniert.
Mir ist dann halt schnell schlecht geworden, da ich bemerkt habe das es immer unsauberer wird..

Es gibt keinen besseren Weg um Erfahrung zu sammeln

Ich hab mir den Code mal ganz flüchtig angeschaut. Prinzipiell schaut das imo eigentlich ziemlich gut aus.

Du könntest eine eigene Klasse Weapon einführen die die Schüsse erzeugt und deinen ImageManager kennt, das Schiff bekommt dann einfach im Konstruktor seine Weapon übergeben und benutzt die um zu schießen. Die Weapon könnte sich auch darum kümmern die Schüsse zu verwalten.
Ich denk CShot braucht nicht wirklich ein set_Rotation(). Die Richtung in die der Schuss gefeuert wird kann, denk ich, eigentlich schon im Konstruktor festgelegt werden und muss sich dann nichtmehr ändern.
Überleg dir für die Bezeichner deiner Include-Guards andere Namen. Auch wenn es in der Praxis kein Problem ist, Namen die mit einem _ gefolgt von einem Großbuchstaben sowie Namen die mit __ beginnen sind für den Compiler reserviert. Ich verwend z.B. sowas wie CENGINE_INCLUDED. Für Visual C++ wäre es ideal #pragma once zu verwenden. Damit merkt sich der Compiler dass er den Header schonmal geparsed hat und wird ihn im Fall eines Mehrfach-Include garkein zweites Mal öffnen.
Nur für den Fall dass du es machst weil du denkst dass man das so macht: Es gibt keine besondere Regel dass Klassennamen mit einem C beginnen müssen. Die Konvention war afaik ursprünglich als Präfix für die Klassen der MFC gedacht und stammt aus Zeiten wo es namespace noch nicht gab. Dass es so viele verwenden ist damit also eigentlich genau das Gegenteil wofür es gedacht war. Aber wenns dir gefällt darfst dus natürlich weiterhin verwenden, ist am Ende natürlich reine Geschmackssache ;9

Also meiner Meinung nach sollte weder die Waffe, noch der Schuss den ImageManager kennen. Oder wenn, dann nur als Parameter im Konstruktor, aber nicht als Attribut der Klasse.

Prinzipiell geb ich dir recht, aber ich denk dann wird der Weg für unseren Anfänger ein wenig steil, denn dann bewegen wir uns wohl in Richtung Factory Method und Vererbung wird auch ins Spiel kommen. Ich denk für die ersten Schritte ist das schon ganz gut so wie ers macht, man muss es nicht gleich übertreiben

Natürlich könnte man auch einfach der Engine eine Methode geben die einen neuen CShot erzeugt da die den ImageManager sowieso kennt, das wär vermutlich noch eine bessere Lösung als den ImageManager in der Weapon Klasse zu halten.

Stimme dir bei beidem zu.

Zitat von »Tschu«

Ich wollt später sowieso noch ne Klasse machen für nen Objekt,
denn sowohl der Flieger als auch der Meteor später werden ähnliche Funktionen haben.
Vielleicht sogar Abstrakt?.. Vielleicht sollte ich sie sofort implementieren beim umstrukturieren.

[...]

Also wie ich es verstanden habe, sollte ich lieber die Engine die Erzeugung und die Verwaltung der Schüsse übernehmen und der Flieger hat eine Methode,
welche die Erzeugung eines solchen Schusses übernimmt?

Klingt gut, vor allem wenn du alle Spielobjekte gleich behandeln willst wird es sinnvoll sein dass die Engine sich um die Erzeugung derselben kümmert, dann kann sie die auch gleich verwalten.

Zitat von »Tschu«

Eine Frage die ich mich noch stelle, ich hab in meinem Code, die Tastaturabfrage für den Flieger in die Methoden der Flieger implementiert,
sollte ich diese Abfragen nicht lieber auch in die Engine integrieren, da so wie ich es sehe die Eigentlich nicht mit dem eigentlichen Flieger nichts
gemeinsam haben sondern nur nen Auslöser ist für die eigentliche Aktion, wie so ein Pilot in einem Helikopter!?

Ja, das klingt sehr vernünftig.