I still think we should have the 'properties' as you refer to them, but making the variables private is pointless.
No, there is a point, it's encapsulation. What if someone does:
if (stat = < some value >)
Yes, that's bad code, but the point is a public variable won't protect you from it. If you have accessor functions and the stat is read-only, you're fine.
Variables should only be public if you don't care if code outside the class changes them to any value at all. This isn't the case with stats and just about every other member of the Entity. It's just good practice to protect class members from random changes.
thanks for the code (I'll put it in minus the privateness). do we want to separate out class Stats from Pawn? I'll do it if you want, but I don't see many concrete advantages of doing so aside it being slightly cleaner.
Every entity will have stats. I still would have a stat class and a stat manager class, which allows you to apply modifications to stats without having to specifically know what those stats are. I'm slowly working on modifying the code that I have to fit PC.
You have to assume everyone else will make mistakes and they will find every way possible to break your class (thats how you write good classes).
QFT and fixed.
I don't assume everyone is a terrible coder, just that we're human and will make mistakes. I know I make my share of them.
Side topic - I seriously dislike some of the Unrealscript class names (Pawn, Actor, etc.), but that's just me. I see "Pawn" and think "chess piece" and I'm left wondering what the heck that has to do with game programming.
I see "Actor" and think "person" which isn't necessarily the case in UnrealScript.