4. Sprites verwalten

Sprites verwalten

  • R

    Hallo, ich spiele momentan ein bischen mit allegro rum
    und wollte mal Fragen wie ihr eure Sprites bei größeren Projekten
    verwaltet.

    Das Buch über allegro das ich habe schlägt eine Sprite Klasse vor,
    bei der alle Eigenschaften auf public gesetzt sind...und einen
    Spritehandler, der die Sprite Klassen verwaltet.

    Das finde ich allerdings nicht sehr komfortabel...
    nicht nur das das nicht im sinne der Objektorientierung ist,
    wenn man verschiedene Animationen hat, wie z.B. verschiedene
    Attacken eines Charakters wird es schnell ein einziges Durcheinander.
    Wie verwaltet ihr eure Sprites? Bevor ich nochmal ein Spiel starte,
    wollte ich diese Fragen beantworten und bin interessiert wie ihr das regelt,
    sonst endet es wieder in einem unübersichtlichen Code.

    0
  • D

    Ich kenne mich mit Allegro nicht aus und kann daher nur allegmein sprechen.

    Zunächst ist eine Sprite-Klasse insofern sinnvoll, falls Resourcen freigegeben werden müssen, etc. Das lässt sich entsprechend bequem über den Destruktor erledigen. Des Weiteren wird oft ein SpriteManager verwendet, der Sprites lädt und auch im Speicher behält. Das sehe dann z.B. so aus:

    spriteManager.LoadSprite("Test.png"); // Sprite wird erstmalig geladen

    Beim nächsten Aufruf von spriteManager.LoadSprite("Test.png") würde dann eine Kopie zurückgegeben werden - ein neues Laden entfällt.

    Für Animationen würde ich eine weitere Klasse schreiben, die ein Sprite entgegennimmt:

    SpriteAnimation myAnimation(mySprite); // Eventuell zusätzlich angeben, wie groß ein Einzelbild ist, falls abweichend

myAnimation.play("1,2,3,10,4"); // Bilde aus den angegeben Einzelbildern eine Animation

    Sollte die Animation sehr komplex sein, da sie vielleicht aus vielen einzelnen Animationen besteht, so kannst du dafür noch eine weitere Klasse schreiben, usw.

    Für die eigentlichen Spielobjekte (Gegner, Spieler, Objekte, ...) kannst du dann weitere Klassen basteln, die dann z.B. Lebenspunkte, usw. verwalten.

    Das ist doch schon durchaus komfortabel, oder?

    0
  • R

    Das ist schon sehr komfortabel^^
    Ich war mir unsicher ob und wie ich das aufteilen soll,
    weil ich bis jetzt nur immer eine riesige Sprite Klasse gesehen habe und nicht
    erfahren bin mit den Beziehungen zw. Klassen.

    Ich versuche mal einen Ansatz wie ich es aufteilen würde:

    Spritehandler

    -Sprite image;
-Sprite* load ( char* filename );

    Animation

    -curframe
-framecount
-totalframe
-animstartx
-animstarty
-animwidth
-animheight
-xdelay, ydelay;

Animation ( Sprite* img );

    Control

    int up; // z.b. up = KEY_UP // allegro spezifisch
int down;
int left;
int right;

int x, y;
int xspeed, yspeed;

void move_right();
…
void move_down();

    Player

    Control control;
int score;
void drawframe ( Animation& anim , BITMAP* dest );

    Allerdings weiß ich nicht ob das in der Praxis dann klappt ...
    Wäre nett wenn ihr mir die Fehler von diesem Entwurf aufzeigen könntet, oder
    wie man es besser macht.

    0
  • D

    Wozu soll die Klasse Control sein? Ich sehe da keinen Vorteil. Stattdessen solltest du eine Klasse erstellen, die z.B. so aussieht:

    class GameObject
{
 protected:
  Sprite mySprite;
  size_t myX;
  size_t myY;
  size_t myXSpeed;
  size_t myYSpeed;

 public:
  virtual void logic() = 0;
  void move(size_t x, size_t y);

  void render();

  // ...
};

class Player : public GameObject
{
 private:
  int Score;

 // ...
};

    Dann brauchst du nur von dieser Klasse erben und hast alles zusammen. Die Tastaturabfrage musst du jedenfalls irgendwie anders realisieren. Aber eigentlich ist das ja oft eh nur in der Hauptschleife der Fall...

    Aber so ganz gezielt helfen kann man dir nicht, es hängt alles immer von vielen Faktoren ab. Oft muss man auch einfach ins kalte Wasser springen und stellt irgendwann fest, dass man das nicht gut gelöst hat. Als ich C++ angefangen habe zu lernen, da habe ich sehr oft Projekte komplett neu angefangen, da ich das Limit meines Klassendesigns erreicht hatte - es war einfach nicht gut gelöst, da ich etwas nicht beachtet habe. Das kommt eben erst mit der Erfahrung. Vielleicht wäre SFML für dich ja sogar angebrachter, da es in C++ geschrieben ist und du vielleicht auch ein Gefühl bekommst, wie OOP läuft, da du damit zwangsläufig arbeiten musst.

    http://www.sfml-dev.org/

    0
  • R

    Danke für den Typ,
    ich werd mit SFML mal ansehen.
    Nur lerne ich sehr gerne systematisch mit Büchern und da gibts leider noch kein buch
    Ich denke ich werde die spieleprogrammierung noch ein paar wochen auf Eis legen und erstmal noch weiter C++ lernen, bis ich erfahrener bin.
    Das Problem war nur, das ich keine Idee hatte was ich als Übung programmieren könnte.
    Irgendetwas was über einen Taschenrechner, oder Flächenberechnung in der Konsole hinausgeht,
    hat da jmd sptontan einen Tipp?

    0
Anmelden zum Antworten