Here it is, it's a lot but don't take it personally and you did great for your first C++ game.
Overall:
- stdafx.h I mentioned before
- you really like shorts and uint8 for some reason, just use ints and unsigned (ints) and char and unsigned char as appropriate but don't optimize for size/efficiency like that, there is no point
- names in all caps and starting with _ shouldn't be used (but many projects do it to not clutter auto complete with them, yes), see:
https://stackoverflow.com/a/228797- some magic numbers are present, ie. 735 and 375 in Food.cpp
- it's not an error but it became a convention to put public members first and private ones second (or third if there are protected ones) in classes in C++
- it's also not an error but many people use hpp for C++ headers to signify they aren't C headers, if you ever mix C and C++ or happen to use a library that has binding/APIs in both (i.e. like SFML does) then you will appreciate the difference
- you could use sf::RenderTaraget, not sf::RenderWindow in draw functions, or even make your classes inherit from sf::Drawable
Snake.cpp:
- it's not an error but it's customary and nice towards the reader to name the file with main function main.cpp (or main.c in C)
- you don't need to restart clock right after it's created
- you might want to look into c++ <random> header instead of using C randomness, both are as easy for int but c++ is easier for floats and more featureful and correct for ints
- you don't need to comment //creating player before calling player.create(), it's self evident from the function what's going on
- you don't need braces around case values, case sf::Event::Closed: will do
- your key handling is wrong, you should use evnt.key.code to see which key got pressed in sf::Event::KeyPressed, not call sf::Keyboard::isKeyPressed which are for realtime keyboard polling, since your loop is quick the result is the same but that's wrong way to do it according to how SFML is made
- the above would also allow you to use switch to pick level
- you might actually reconsider using numeric keypad and use normal numeric keys (Num1, etc.) since many older laptops don't have it (mine does, but still), such a key->level number function is also a good candidate to put in its own function since its independent from other code, etc.
- in general you might want to put that stuff into its own class and call methods to draw, update, etc. since such a long main function is just hard to follow and there is no downside to using a class or a few functions
- you can compare sf::Vectors of same kind with just ==, no need to compare x and y separately and comparping floats for equality might be a bad idea, snake's logic is very tight and fully doable/designed with just ints so it might be better that way and just using floats to interface with SFML shapes and such
Food.h and Food.cpp:
- you might make spawn take snake by reference if it's never null
- the float constant could be a global const in the cpp file, it's not needed in the class itself, especially since it's private
-
Block.h and Block.cpp:
- just that magic constant 14.f
Player.h and Player.cpp:
- block and snake don't have m_ in front of them but you use that convention for all other normal class members across the game
- you use windows line endings usually (which is so-so, but default in VS still...) but here you mix windows and linux style line endings in the file, not an error but it shows up in some editors when there is an inconsistency
- block is esentially a useless member, you could create or emplace a block in the function intself, no need for having a member you never use or modify and only push back into the vector
- setFillColor is weird, why the & and then -> ? why not just
snake[i].setFillColor
or even better a ranged for from C++11?
- vector has a 'back' member that you can use to access the last element, no need for smt[smt.size() - 1] and they are both exactly the same in terms of safety (that is - they don't check if vector isn't empty)
- in drawTo you use a for loop but without a & so you copy each block, then render it, then throw it away
- a few magic numbers again, 195, 735, 375
- deletePlayer and createPlayer are a bad interface, just clear the snake on each player creation, there is no downside to that and it's cleaner, if you need to create player twice without deletion in between then you can add a bool argument dontdelete that is false by default or use a separate function, the only purpose deletePlayer serves right now is to be forgotten and cause an unusual bug
