ich arbeite im Moment an einem Mariospiel und habe schon ein paar Grundfunktionalitäten eingebaut.
Bis jetzt hatte ich nur Bewegungen in der X-Achse implementiert (mit den Pfeiltaste) und bisher auch nur ohne Beschleunigung.
Ich will jetzt aber Beschleunigung einbauen und der header sieht jetzt so aus:

class Mario : public Actor
{
	public:
		Mario(ImageManager& manager, sf::RenderWindow& app, float posX = 0.f, float posY = 0.f);
		virtual ~Mario(void);
		virtual bool isDead();
		virtual void doLogics(float delta);
		virtual void draw(sf::RenderTarget& target);
		void setSpeed(float xSpeed, float ySpeed);
		sf::Vector2f getSpeed();
	private:
		sf::Sprite mySprite;
		sf::RenderWindow& myWindow;
		bool myIsDead;

		float mySpeedX;   //vorzeichenbehaftet
		float mySpeedY;
		float myAccelerationX;  //vorzeichenbehaftet
		float myAccelerationY;
		float myMaxSpeedX;    //(vorerst) absolut
		float myMaxSpeedY;

		XDirection::XDirection myXDir;
		YDirection::YDirection myYDir;

		//Verschiedene Animationen, die je nach Situation gewechselt werden
		AnimationLoop* myActiveLoop;
		AnimationLoop myLeftLoop;
		AnimationLoop myRightLoop;
		AnimationLoop myStandLeftLoop;
		AnimationLoop myStandRightLoop;
		AnimationLoop myLeft2RightLoop;
		AnimationLoop myRight2LeftLoop;

		void updateDirections(); //setzt richtung basierend auf pfeiltasten
		void updateAcceleration(); //berechnet aus richtung die beschleunigung
		void updateSpeed(float delta); //berechnet aus beschleunigung die geschwindigkeit
		void updatePosition(float delta); //berechnet aus geschwindigkeit die neue position
		void updateAnimation(float delta); //berechnet aus richtung, geschwindigkeit und beschleunigung den animationFrame

		//Pfade zu den Bildern
		static const std::string IMG_PATH_LEFT_1;
		static const std::string IMG_PATH_LEFT_2;
		static const std::string IMG_PATH_LEFT_3;
		static const std::string IMG_PATH_RIGHT_1;
		static const std::string IMG_PATH_RIGHT_2;
		static const std::string IMG_PATH_RIGHT_3;
		static const std::string IMG_PATH_STAND_LEFT;
		static const std::string IMG_PATH_STAND_RIGHT;
		static const std::string IMG_LEFT_2_RIGHT;
		static const std::string IMG_RIGHT_2_LEFT;
};

ein paar implementierungen noch:

void Mario::updatePosition( float delta )
{
	mySprite.Move(mySpeedX * delta, mySpeedY * delta);
}

void Mario::updateSpeed( float delta )
{
	mySpeedX += delta * myAccelerationX;
	mySpeedX = max(mySpeedX, -myMaxSpeedX);
	mySpeedX = min(mySpeedX, myMaxSpeedX);

	mySpeedY += delta * myAccelerationY;
	mySpeedY = max(mySpeedY, -myMaxSpeedY);
	mySpeedY = min(mySpeedY, myMaxSpeedY);
}

So, das problem ist jetzt

void updateAcceleration(float delta);

Also im Prinzip soll das so funktionieren:

-Wenn die Richtung rechts ist, wird die Beschleunigung erhöht (relativ problemlos)

-Wenn die Richtung links ist, wird die Beschleunigung niedriger (relativ problemlos) (niedriger heißt, dass es dadurch auch negativ werden kann)

-Wenn die Richtung STAND ist, muss je nach richtung entgegengesteuert werden.

Da sehe ich jetzt ein paar Probleme:
- Bei STAND können (über)schwingungen entstehen
- für die beschleunigungen bräuchte ich eigentlich auch maximalwerte

Ich vermute, dass das ganze irgendwie viel einfacher gehen muss, aber mir fällt nichts gutes ein.

Wenn ihr ansonsten noch Verbesserungsvorschläge zum bisherigen Aufbau usw. habt, immer her damit

Ich bin dankbar für jeden guten Vorschlag!

Als nächstes sind dann bewegungen an der y-Achse dran

Ich überlege noch, ob ich irgendwas mit Basisklassen da machen könnte, weil ja so ziemlich jede Spielfigur ein zumindest halbwegs ähnliches verhalten haben wird, aber trotzdem muss die Möglichkeit da sein, das Verhalten anzupassen, evtl. ne Basisklasse und man kann bei Bedarf überschreiben?
Nur dann müsste man in der Basisklasse auch festlegen, was es alles an Animationen gibt usw. glaube ich...

Wenn noch jemand Vorschläge hat, bitte her damit

Vererbung für Spielobjekte klingt gut, auch wenn Du die dann zusammen in einen Container packen kannst. Da die Spielfiguren sich gegenseitig nicht kennen sollen, macht auch ein Bereich Sinn, in dem so was wie Bewegungen mit Kollisionsabfragen gehandelt werden. So was wie "Environment" oder "PhysicalWorld" oder so was. Da kannst Du dann bewegen, Kollisionsabfragen machen und auch noch irgendwelche physikalischen Spielchen global für alle Figuren einbauen.

Ich würd die Animationen von der Bewegung trennen. Mache ein Sprite und ein AnimationSprite davon durch Komposition und die jeweiligen Spielfiguren verweisen dann wiederum auf die animierten Sprites (kann ja auch ein Mapping über nen Namen sein, ist ja egal). Du wirst ja auch mehrere Mauerstücke etc. haben. Dann hast Du mehrere Spielelemente mit gleichem Sprite.

Ich bin mir nicht ganz sicher, wie du das meinst.
Also erstmal möchte ich darauf hinweisen, dass SFML zwischen images und sprites unterscheidet, images speichern einfach nur ganz dumm bilddaten und ein Sprite hat einen Pointer auf ein image, ein subrect, positionen usw..
Also auch wenn ich mehrere Mauern mit dem gleichen Bild habe, habe ich insgesamt nur 1 Bild im speicher liegen, weil die Sprites nur pointer speichern.

Erübrigt das dann deinen Vorschlag, oder hab ich nen wichtigen Punkt außer acht gelassen?
Falls letzteres der Fall ist, dann wäres ganz gut, wenn du deinen Vorschlag nochmal ein wenig ausführen kannst bitte.

Ich beschreib nochmal wie ich das im Moment handhabe:
Jede Figur hat einige AnimationLoops (bei ner wand kann es auch einfacher sein, aber bei mario ist das zumindest so), zwischen denen gewechselt werden kann.
Jede Animationloop hat einen vector von einem Triples, die jeweils
-nen Pointer aufn image
-nen subrect
-ne dauer des frames
speichern.

Ich habe mir jetzt folgendes überlegt:
Ich benutze auch für die y-achse eine konstante beschleunigung.
Je nachdem, ob gerade ein sprung gemacht wird oder nicht, ist die YRichtung
YDirection::UP oder YDirection::DOWN
(sowas wie stehend gibt es bei y nicht nach meinem bisherigen entwurf).
Dann wird dadurch die position umgesetzt.
Jetzt kann man denken - man fällt doch immer weiter nach unten, dafür hab ich dann folgendes erdacht:
Ich mache ja sowieso immer kollisionsprüfungen und wenn ich dann merke, dass mario in einem block hängt, wird er nen stück nach oben gesetzt, so, dass er aufm block drauf ist.

Findet ihr das so ok, oder habt ihr bessere Vorschläge?
Sollte man vielleicht nicht nach, sondern vor der Bewegung überprüfen, ob man auf einem Untergrund steht?

Bei meinem Ansatz fällt mir spontan ein Problem auf:
Wenn man das mit allen Figuren so macht, und bei Kollisionen die Koordinaten umsetzt, dann kann die Reihenfolge der Kollisionsüberprüfung das verhalten bestimmen, weil dann ja während der Kollisionsüberprüfung Koordinaten umgesetzt werden...
Aber vll ist das nicht so schlimm, weil ich das im moment so eingerichtet hab, dass man immer 100 Logikframes pro sekunde hat und deswegen die Bewegungen von frame zu frame sehr gering sind.

Zum Untergrund: vorher prüfen geht nicht, wenn man sich im Sprung bewegen können soll, ist aber auch nicht nötig. Zur Zeit prüfst du, ob er in einen Block gefallen ist und setzt ihn gegebenenfalls wieder hoch. Warum prüft du nicht stattdessen, ob er in einen Block fallen würde und lässt ihn gegebenenfalls nicht fallen (bzw. nur maximal bis auf den Block)?

for(unsigned int i = 0; i < actors.size(); ++i)
{
   actors[i].doLogics(delta);  //führt unter anderem bewegungen durch
}
for(unsigned int i = 0; i < actors.size(); ++i)
{
   for(unsigned int j = i; j < actors.size(); ++j)
   {
      if(detectCollision(actors[i], actors[j]))
      {
          actors[i].collideWith(actors[j]);
          actors[j].collideWith(actors[i]);
      }
   }
}

Das mit collideWith soll dann irgendwie mit double dispatch funktionieren.

Wenn ich bei jeder bewegung überprüfe, dann müsste ich das zu sowas ändern:

for(unsigned int i = 0; i < actors.size(); ++i)
{
    actors[i].doLogics(delta);
    for(unsigned in j = i /*oder 0?*/; j < actors.size(); ++j)
    {
        if(detectCollision(actors[i], actors[j]))
        {
            actors[i].collideWith(actors[j]);
            actors[j].collideWith(actors[i]);
        }
    }
}

Nur dann würde die reihenfolge wieder ne rolle spielen, aber evtl kann man das aufgrund der kurzen zeitdifferenzen vernachlässigen...
Oder hat wer ne bessere Idee vielleicht?