Consider all your getters and setters. Maybe it makes sense to be able to get some of the values, but to set them to random arbitrary things does not make sense. For one, it makes the getters and setters useless (you could just reference the real variable names), and for another, it breaks Object oriented Design.

Consider you're walking through the woods and bump into a tree. Does the tree come in and magically set your health to a new value? Does the tree need to know about your armor, defense, etc? Does it need to kill you itself when your health runs out? This doesn't make sense.

Well thanks for replying.
I only tried today to program with classes, and it seems I didn't get the idea what could they be used for. My main idea was,that they are like tables (well that's what i thought it is for), like for example the table has id mana health.
And you could always read it and edit it.And it should have worked like this.
I have a loop, where while you in the Rat cave, the Rat monsters are created and then you have to fight. When you leave the Rat Cave, your location sets to another variable like 1. And the rat object disapears.It's like every location spawns monsters, or npc that are intended to be there, and when you leave the place, it will destroy them.

And about the second part, I didn't really understand what did you want to tell me. Considering you hit the Tree hard with your head, you could set your health lower. And considering I wear protection from hits, that gives me defense from trees, I would get no damage, no wounds or something like that.And considering whether or not it's a living/walking tree with some intellect and agressive, it could inted to attack me.
But in case, you mean otherwise why would I use Object as a databank for npc/monsters and whatsoever, I thought it really like that.
Well guess maybe I should just create so variables like

Your idea of classes as tables is ...odd. I'm not sure where you got that idea from. Classes are a way to represent self-contained entities. The "self-contained" part is important, this is called encapsulation.

Your code currently just acts exactly the same as a basic struct"

1234

struct Player
{
int health, defense;
};

The struct just holds data, it doesn't manage itself or do anything on its own - everywhere you have the struct you have to write code to manage it. This results in you having to rewrite the same code over and over, and then have to change it everywhere when you want to make a change. This is the opposite of encapsulation.

It also doesn't make sense conceptually, either; you don't go up to an enemy, punch them, and say "your new health is 2". You just punch them, and they lose health. You also don't ask the enemy how much health they have, or how much defense they have, etc. because it doesn't make sense to - you don't need to know any of that to punch them correctly.

With classes, OO, and encapsulation, objects and instances of classes manage themselves. As a general rule of thumb, getters and setters are bad.

You never need to get information, not even to display it - you can ask an object to display itself. Nobody asks you what you look like to be able to see you, you just make yourself visible.

You never need to set information either; as said before, you don't just punch something and say "your health is now 2" - you punch it and that changes its health itself. You normally change an object's condition, you don't set an object's condition. (Think: do you look at a box and every second tell it that it is one foot to the left? Or do you push the box?)

Try rewriting your code without any getters or setters at all. An object only needs to know about itself, so there's no need for getters, and an object will only change over time, so there is no need for setters.

As a hint, you will probably need a function that deals damage to a player or enemy, and you will need a function to ask the enemy to display itself so the person playing the game knows what they are battling. Then you will need a function to see if the enemy is dead, or if the player is dead.