All that stuff about public vars vs. private with accessors
Do you know WHY you should? If you know WHY, you can infer WHEN, because nothing is universally best.
Yes, if you think that you may one day want to change it so that
int House::GetRooms() {return nRooms;}
is
int House::GetRooms() {return nRooms-nSecretRooms+nKnownSecretRooms();}
it would be better. However, sometimes it's better to directly use the variable.
It seems that most standards(such as avoid GOTO) are in place to ensure that the code can be altered or expanded without breaking anything.
So if I have an instance of lets say THIEF, it would never need to know the contents of HOUSE?
Shouldn't HOUSE's variables be public, so people moving around inside of it can interact with it?
How do I allow a member of class THIEF to get information about class HOUSE?
Making the contents public is fine as long as you don't mind limiting future expansion. Making it private with accessors is fine as long as you don't mind a potential slight speed loss(if the compiler doesn't just realize that both ways do the same thing, and optimize it for you), and scattering the logic of the code a bit more(though with decent naming, this shouldn't be a problem).
Go with what you feel is best, because some/many/all standards are there to make things easier in the long run, not simpler in the short run, and since you are learning a new subject, you want easier above all, at least until you understand why the standards exist.
-new post-State variables? Are they just used in a single function?
If so, you may optionally make them static variables within the function, though it probably isn't good OOP, since if you ever were to break it up, you would have to promote them the class vars or global-to-the-file vars.