Neither. You should have methods that do things. If one of those things happens to correspond with a specific internal variable that’s great but there should be nothing that telegraphs this to the users of your class.
Private data is private so you can replace the implementation whenever you wish (and can do full rebuilds but that’s a different issue). Once you let the Genie out of the bottle you will find it impossible to push it back in.
EDIT: Following a comment I made to another answer.
My point here is that you are asking the wrong question. There is no best practice with regard to using getters/setters or having public members. There is only what is best for your specific object and how it models some specific real world thing (or imaginary thing perhaps in the case of game).
Personally getters/setters are the lesser of two evils. Because once you start making getters/setters, people stop designing objects with a critical eye toward what data should be visible and what data should not. With public members it is even worse because the tendency becomes to make everything public.
Instead, examine what the object does and what it means for something to be that object. Then create methods that provide a natural interface into that object. It that natural interface involves exposing some internal properties using getters and setters so be it. But the important part is that you thought about it ahead of time and created the getters/setters for a design justified reason.