Usually I employ private variables, but when it comes to games I feel like maybe there is no need for those, and I should go with public. Am I wrong, or is there no need for private variables if the program is a game? (or at least not a strong need)

I realise the need for private variables in case we're working as a team. But even if it is a large project, but which I'm doing on my own, would it still be as important as the first?

What functionality? Would coordinates, health and armor for example be part of that functionality? Or would they be considered an internal aspect of the class?[/quote]Many physics systems prefer you modify coordinates by applying forces to an object, rather than directly modifying the actual position. In that case, the adjustment of the position is private functionality.

Does health have any invariants? One could be that health must be between 0 and 100 (inclusive). If you've got a rule like that, then one approach would be to make the variable private and make a public 'setter'bool Character::SetHealth( int newHealth )
{
if( newHealth >= 0 && newHealth <= 100 )
m_Health = newHealth;//only set the value if it's valid
return m_Health == newHealth;//return true/false indicating if the newHealth value was actually set.
}But usually getters/setters aren't very useful. Usually a better design incorporates some logic about how the members should change, instead of just guarding against bad changes, e.g.int Character::TakeDamage( int damage, bool ignoreArmour )
{
assert( damage >= 0 );
if( !ignoreArmour )
{
m_Armour -= damage;
if( m_Armour < 0 )
{//there is some damage left over after depleting all the armour
damage = -m_Armour;
m_Armour = 0;
}
else
damage = 0;//armour absorbed all the damage
}
m_Health -= damage;
if( m_Health < 0 )
m_Health = 0;
return damage;//return the actual amount of health that was removed (after armour calculations)
}Now, with the above, instead of just making sure that people don't set invalid health values, we've made it so people don't have to set health values at all. Instead we've invented a new concept -- damage -- and created an interface for dealing damage. Not only does this ensure that health values are always valid, it centralises the logic for dealing with armour at the same time -- no other part of the code base should have to know exactly how health/armour calculations work any more, and instead of our objects just being blobs of data, they're interesting interfaces that you can interact with instead. In any class, everything public is the interface, and everything private is stuff that the user of the class doesn't have to know about. In general, the less that each part of the code-base knows about, the better.

Part of the reason for doing this is, if you find there's a bug in the way armour is being reduced, you know that it must be in the above function somewhere (or actually, somewhere in the class that owns the above function). If armour was a public variable, then the bug could literally be in any file of your code base.

[edit]mrwonko's example below is a good one too -- often you want to call a function when a variable changes. If anyone can change things, then you'll have a hard time actually enforcing that rule (i.e. it's easy to forget to call the function if you change the variable).