I know someone already answers, but to give you my opinion:
1. How should I build my game loop? Or more specificly where? Should I create it to main directly, or should I have class that has function for game loop, and then I just create object and call the function in main? Is there any performance differences between these 2 options?
It shouldn't matter. Any performance difference will be so low you wouldn't be able to measure it. In terms of performance in general, as long as you don't do anything overly stupid, 2D games (what I assume you're doing) aren't really effected by performance all that much.
2. What is best way to create different cursor? Is it just fine to make cursor invisible and draw own cursor to position of mouse? Or is this too heavy thing to handle?
Use whatever method you like best. Again, any performance "issues" with such little things would be impossible to notice.
3. How should I implement drawing inventory? Or anything that contains buttons, should I make class that checks for clicks inside specific coordinates or is there better way to do it?
There's lot of information on GUI programming out there. If you're starting out, I suggest looking for a simple GUI library (I've heard about SFGUI, not sure if that's what you're looking for, though) and learning out it works before trying to roll your own. There isn't a single way to program GUIs in C++, so there's no "wrong" or "right" way to do it (that isn't to say you can't make a bad GUI library, but that they're many ways to make one).
4. How do I know is my code good/efficient? What can I do to improve it?
I suggest reading up on good programming practices (Scott Meyer's Effective C++ is a good book, also check out
http://gameprogrammingpatterns.com/contents.html). But performance, again, shouldn't really be an issue. This isn't like the Atari days. You don't need to micro-manage every little piece of your code (maybe if you're writing an OS kernel, but that's entirely different).
5. How I should make character dialogues? If there is lot to talk about, it is pain to write that.. Maybe I should use Lua to write the dialogues and then just implement them to characters with c++?
Do not use Lua. Lua should be reserved for when you need to program
behavior in files, not
data, like dialog. You can just save dialog inside text files.
6. Imagine I have created game. I have all textures in folders. Anyone can go and change them? He could take for example wall texture and make it transparent, and with this he sees through walls? Is there a way to precent this? Same with .exe file that runs the game, is it possible to crack the code and edit it?
Any files left out in the open, the user can edit. If you really want to keep users from accessing the files, you could try custom binary formats.
To save a float in binary:
void save(const char *filename, float value)
{
std::ofstream stream(filename, std::ios::binary | std::ios::trunc);
stream.write(reinterpret_cast<const char*>(&value), sizeof(float);
}
To load it back:
float load(const char *filename)
{
std::ifstream stream(filename, std::ios::binary);
float value;
stream.read(reinterpret_cast<char*>(&value), sizeof(float));
return value;
}
Just store whatever data you need in that and you'll be good. It does come with the downside that you need to convert any asset that uses the format into it before you use it, though. So it might be useful to create a small library for any custom formats, and then create a small program that will allow you to convert files to and from the format and just access the (now converted) files through the library in your game.
If you need it really secure, you'd have to do some tricks in order to try to make it so the format cannot be easily decoded. But as long as the game's single-player, you shouldn't worry. If the player wants to see through a wall, let them do it.
You also cannot keep them out entirely. No matter what format you use, your game has to decode it one way or another. You can put as many barriers in their way as you'd like, but your game will still have the code to decode the files, so any "hacker" determined enough can and will get to the files. If you were selling the game, you'd typically make it hard enough that you'd hope the hacker would simply pay the money for the game instead.
