I took "learn how to use git" as a critique. Hopefully that works.
Learning Git is a very useful skill to learn and in many places nearly mandatory or expected as a given.
Plus it can be quite a bit of fun, as it gives you the flexibility to experiment and revert any time you want.
Another useful tool to learn is CMake. If you know how to use it, you can easily compile a huge list of libraries and applications out there. If you learn to write your own CMake scripts, thousands of people can easily compile your application for any compiler they desire.
Now for the codeI personally prefer classes to start with a capital letter, as it makes it easier to differentiate between functions and variables (see SFML's source code).
While a bit tedious to write, I tend to write getters and setters for member variables instead of making them public. I do tend to not use set/get as SFML does, but instead just use function overload and let them same function name, but one takes a value and the other returns a value. For example
void speed(int speed) { m_speed = speed; }
int speed() { return m_speed; }
How you do it is really up to your preferences, having public member variables however isn't considered a good practice, unless it's a struct that just holds data and other functions manipulate it.
You don't need to define a protected section if you have nothing in there.
Constructors have initialization lists, you should use them and not initialize the member variables inside the constructor. Do this instead for example:
snake::snake(sf::Vector2i startPos, int startSpeed, int maxSpeed)
: failure(false)
, speed(startSpeed)
, mSpeed(maxSpeed)
, currentPiece(0)
, pieces(1)
{
pieces[0].pos = startPos;
}
Whether you use this formatting or a different one is up to you, important is that you understand what the initialization list does, so read up on it.
speed vs
mSpeed, make sure you use descriptive names. When I first read the header it was not clear at all what
mSpeed should be. Don't shy away from longer variable names. If it's tedious to type, then try some auto-complete extension for your IDE (which usually come with auto-complete by default anyways). For example
currentSpeed and
maxSpeed. I personally prefer the term "velocity" instead of "speed" as it feels a bit more precise/scientific.
Use white spaces around your operators! It will make your code a lot more readable to most devs out there.
while(loopvar < pieces.size())
// ...
tempVec *= mult;
Some even like to add a space after if/while/for:
while (loopvar < pieces.size())
Temporaries can sometimes make your code more readable, but sometimes they really aren't needed:
sf::Vector2f dim(30, 30);
rect.setSize(dim);
Would be better as:
rect.setSize(sf::Vector2f(30, 30));
And if you use C++11 and newer, you can make it even shorter with:
rect.setSize({30, 30});
Since C++11 (and earlier)
rand() is basically considered harmful. I suggest to watch the linked video and look into possibilities the
<random> header gives you.
Granted for your game it's not really an issue, it's however still good to learn the new one now, rather than later.
You shouldn't add "Obj" to a variable name, instead as suggested at the start use a capitalized first letter for the class to make it clear that
Food is the class and
food is probably an instance.
Mixing snake's speed and the framerate is not the best idea, instead you may want to make the movement independent of the framerate, by taking the delta time (time a frame takes) and multiply your speed by that. If you want to go crazy with the timing, check out the so often linked
Fix Your Timestep.
For the direction variable you could also use an enum, that way you don't have to rely on strings yet you can still see in the code what it means.
As by the C++ standard
return 0; is not needed for the main-function, but it also doesn't hurt to keep it, your choice!
I bet there's more to dissect, but for now this should be enough. Hope some points will make you dig even deeper into C++ and congrats on writing this and asking for advice. Many don't get something to finished-like state nor are they open to critique which is simply required if you want to learn and make progress. Keep it and you'll be able to whip out larger code pieces in no time.
