I'm working on an open source character controller class in C++

[Aerlamnias]

Hello guys! I'm a computer programming student who has long been interested in getting into some relatively low-level game programming. I thought about trying out SDL but the object oriented nature of SFML was really appealing to me. So as my first project, instead of working on a game, I've decided to code some "portable" classes that can help in getting a game up and running but are also easily expanded by whoever happens to be using them.

Now, because this is my first project and foray into game programming of this nature, I am very much doing this in a "learn as you go" kind of way, so we shall see where this all goes.

Here is the github link for anyone who is interested: https://github.com/FrankBotos/SFML-Topdown-Player-Character

My plans for this are relatively modest. I want to build perhaps 2-3 other classes that are derived from this, that can be used with different perspectives (for example, 2d side scroller). I will attempt to also add collision detection at some point, though that may be beyond my abilities at the moment.

For now, here is a simple class that will take your sprite sheet and animate it and provide movement!

Hopefully some people actually find some kind of use for this.

[Hapax]

Often the best way to learn is to do so your project seems worthwhile.
Good luck! 

EDIT: I just had a quick look at your repository. I would recommend - for clarity, if nothing else - repositioning the charMove() code outside of (probably before) the drawing (including the clear).

Also, consider inheriting from sf::Drawable. It allows you to just do

window.draw(character);

instead of window.draw(character.getSpriteObj());
This also stops you returning a sf::Sprite object, just to draw it. If you do wish to stick to your method, you should return a reference to the sprite instead of an object itself.
If you don't want to do either of these things, you could still have an internal draw method that takes (a reference to) the sf::RenderWindow as a parameter e.g. character.draw(window);

[Aerlamnias]

Hello, thanks for the constructive reply! I will go ahead and implement these suggestions for the next version. Last night I did quite a bit more work on this, implementing a second movement method, which, instead of moving the character at a static speed, simply ramps up the speed and then ramps it back down using whatever values are specified in the constructor.

After fixing those issues you pointed out, I believe I will try my hand at adding some collision detection!

The newest "version" should be pushed to github in a day or two.

[Hapax]

There's information about inheriting from sf::Drawable here, in this tutorial.

I think you should also look into controlling your timestep. The article, Fix Your Timestep, has detailed information on how to do that. You may also be interested to know that I have written classes to simplify timestep control in my small timing library, Kairos.
I think that the timestep stuff should be done before you start work with collision as it can simplify the calculations. If not, it can still reduce the chance of the collisions failing by making it more predictable.

[Aerlamnias]

One of my big concerns about this so far has been making sure that everything stays consistent when framerates change. I noticed early on that imposing a framerate limit will actually change movement speeds and stuff. So that's definitely something I think is worth checking out.

[smguyk]

http://gafferongames.com/game-physics/fix-your-timestep/

[Hapax]

Good luck, Aerlamnias. The simplest, but quite dangerous (because it looks like it's fixed perfectly), solution is to multiply all changes by the amount of time that has passed during that frame (delta time, or dt). The afore-mentioned article goes into a lot more detail about it 

http://gafferongames.com/game-physics/fix-your-timestep/

I think I just said that 

Fix Your Timestep

[Aerlamnias]

Haha, well, looks like I've got a bit of reading to do here.

Speaking of which, is std::chrono more accurate than sf::Time?

I've been using sf::Time because of the ease of use, but something tells me std::chrono is more accurate?

[dabbertorres]

I doubt there is an accuracy difference (unless an implementation of std::chrono does something different). But std::chrono does do more. That would be because std::chrono is actually a namespace, not a class. The std:: comparable type would be std::chrono::duration, which, depending how you use it, may or may not be more accurate than sf::Time.

But at this point, I'm just arguing semantics. Since you're using SFML, and presumably sf::Clock, sf::Time would be preferred (though not required).

[Hapax]

As far as I'm aware, SFML uses OS-specific timing functions that 'should' be the most accurate timing possible.
That said, std::chrono is cross-platform and 'should' not be less reliable, which is why I used it in Kairos (see above).
SFML avoids being dependant on C++11 at the moment so using std::chrono internally would be impossble but maybe it is planned for internal use in SFML 3?