Welcome to CodeRanch!
As Tim has pointed out, if your code uses the static keyword a lot, then your design is off. Static means that a field or method is a member of a class of objects, not an instance of an object. And since Java is Object Oriented, we want to try and make everything as much about instances of objects as possible.
Let's consider the 'Name' field, which hereafter I will call 'name' instead, as should you. When you make it static, you're saying "Every NPC that will ever exist, share the exact same name". Changing the name of one NPC will change the name of all NPCs. When you don't make it static, you're saying "Every NPC has their own name, which may or may not be equal to the name of another NPC".
Static fields should be used for one purpose and one purpose only: Declaring constants. A constant is a value that will never change normally. For the constant to change, the code itself must change. A good example is Math.PI. It's value will not change, it represents a fixed known value. The developers might change the code and recompile it to make it more accurate, but its meaning doesn't change. Usually constants are strings for fixed identifiers and keys, or numeric.
Static methods are used when you want to write behavior that doesn't depend on instance fields. While static variables are bad, static methods aren't bad in their own right, but if you have a lot of them it just means you are probably not using the language it was intended to be used. After all, we usually want our behavior to be based on fields of object instances.
Now let's get to your questions. When to use getters and setters? The answer is as little as possible. You want to keep information contained inside an object as much as possible, and let the object modify itself or interact with other objects in reaction to events. So try to reformulate methods that affect your object in a way that closer resembles events that might happen. For instance, instead of saying setDamage(int), you might want to say something like injure(Weapon) instead, and the NPC itself determines how much it is injured, based on what weapon it was hurt with and other private information it contains, which might include armor that the NPC is wearing or how nimble they are. Often, you will want to get rid of setters entirely. For instance, why would you want to change the name of an NPC after it has received one when it was created? Use constructors to give fields an initial value that can't be changed later.
For getters, only expose them when the rest of your application really needs them. If you want to display health bars in your application, then you obviously need to be able to get the health of an NPC. If you want to keep health a secret, then why expose the getter in the first place? Even then, expose accessors in steps: If they're only required in the current package, then don't make them public. Make them public if you want to be able to access them from everywhere.
I changed your class a little bit to demonstrate some concepts. Don't take it as a precise example of the code you must write. Programming is as much personal taste as it is science.
I renamed the class to Creature, because it's usually better to write out acronyms, NonPlayerCharacter might be a bit verbose, and Character is already a class of the Java standard API. The class is final to prevent it from being extended. You should always make classes final unless you intend to extend them, and if so, you must really design them well for it. There are a lot of complex things you must take into account when allowing your class to be extended.
The class is package private, and so are its constructor and methods. Only make them public when you need to be able to access them outside of the package that the class is in.
The fields are all instance fields (non-static) and most of them are final to prevent them from being changed. Why would you allow the name or the maximum health of an NPC to be changed after they've been created? If you want to be able to change the max health, in response to events like leveling up or drinking some magic potion, you can always make the field non-final in a later version of the code. The initial values for these fields are set in the constructor, and can not be changed through setters.
With the healthIndication() method I gave an example of how you can query an object for information, without exposing all the internal details of the object through getters. HealthIndication is an enum (a finite collection of constants) that gives rough estimates of how much a creature was injured. This is what it could look like:
As you can see in both types, the non-private methods and constructors check their parameters to see if no invalid values were entered.