Also.. zuerst einmal zur Loggen: Ich muss gestehen das mir der Begriff Singleton nicht geläufig ist; Werde mich mal einlesen, nach der allgemeinen Beschreibung würde ich sagen dass das auch für die Game-Class nützlich wäre..
Die Frage nun warum ich auf die BaseClass ist der Gedanke dass ich gerne den Herkunftsort der Nachricht mit geloggt hätte; also jede Klasse einen offiziellen "Namen" braucht. Und um nicht in jeder Klasse
|
C-/C++-Quelltext
|
1
2
3
4
5
6
7
|
class XY {
string m_Name;
}
void XY::DoStuff {
cout << "INFO: " << m_Name << ": Doing Stuff";
}
|
zu verpassen und gleichzeitig die 3 Funktionen Debug, Stat und Error jedes mal "inline" im Code zu verwenden schien es mir nach dem Klassenkonzept die einzige Möglichkeit..
@dot: Die Situation ist die Folgende: SFML stellt eine
Sprite-Klasse zur Verfügung. Ihr kann ich eine Image-Instanz zuweisen sowie Position und Skalierung (letzteres jetzt unwichtig). DrawItem definiert ein Sprite sowie die für alle gültigen Resourcemanager (nicht im Diagramm) und das
RenderTarget. Ebenso Abfrage-Funktionen über das Sprite (Höhe, Breite, Position). Das Movable ergänzt diese Klasse um die Variablen FrameRate und Velocity, wobei ersteres wie das RenderTarget für alle Movable Klassen gleich sind..
Und noch mal als Code:
|
C-/C++-Quelltext
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
|
class DrawItem : public BaseClass {
protected:
// Drawable object
sf::Sprite m_Sprite;
// Global resource manager
static const ResourceManager* m_ResManager;
// Global render target
static sf::RenderTarget* m_Target;
public:
DrawItem( void );
virtual ~DrawItem();
// Set global resource manager
static void SetResourceManager( const ResourceManager& resManager );
// Returns global resource manager
static const ResourceManager* GetResourceManager( void );
// Set global render target
static void SetRenderTarget( sf::RenderTarget& target );
// Returns global render target
static sf::RenderTarget* GetRenderTarget( void );
// Draws sprite on render target
virtual void Draw( void );
// Returns information about sprite
inline int GetWidth( void ) const;
inline int GetHeight( void ) const;
inline sf::Vector2f GetPosition( void ) const;
};
class Movable : public DrawItem {
protected:
// Global frame rate
static const int* m_FrameRate;
// Velocity of object
float m_Velocity;
public:
Movable(void );
virtual ~Movable( );
// Set global frame rate
static void SetFrameRate( const int& frameRate );
// Returns velocity
float GetVelocity( void ) const;
// Change velocity
void SetVelocity( float velocity );
void ChangeVelocity( float percentage );
};
|
Zu den Manager Klassen: LevelManager ist nicht die gleiche Ebene / das selbe wie die anderen.
Meine Überlegung war: Das Programm kann 3 "Zustände" haben: Es wird gespielt, im Menu herumgesucht oder mit dem Editor neue Level erstellt werden. Nun könnte ich in der GameKlasse beim Zeichnen oder InputVerarbeiten immer schön if clauses machen und dann den jeweiligen Code reinschreiben (oder in Funktionen packen), allerdings wird dann alles ganz schnell sehr groß (so meine Befürchtung).
Und damit das gar nicht erst passiert pack ich jeweils die "zusammengehörigen" funktionen in eine klasse. Denn was ich nicht möchte ist ein Lernprojekt wo ich nachher da steh und sag.. So.. fertig.. alles läuft "iwie", aber durch den Funktionenwust blick ich nicht mehr durch
Und spätestens wenn ich dann was erweitern/ändern möchte steh ich da