In general, I think that's a good system, though things may be a little high at start... Maybe give them 50 to start and pass off the things they adjust as the results of their training?... After all, just 20 stats gives someone the ability to be at olympic level in two areas, near olympic in another, and slightly above average in the rest... Starting out the game as the smartest, most strongly willed man alive who can shoot with near-perfect acuracy doesn't sound terribly exciting to me... So I'd say at least cap how much you can put into one stat. (at say, 68?)

Since there's little chance your stats would get below say 45 (I'm assuming certain things would give you stat penalties to drop you that far.) Why not just rename 45 or so to 1 and possibly scale things up a bit.... Or, if you feel like keeping he rough starting point, and doing something somewhat unique, why not call them percentile scores?... Said percentiles of course would take into account the existance of psionics and other strange results of the perception crash. It'd even an in-game reason for stats, in the beginning of the game, the government would keep logs of your preformance, and rank you.

so

it is?
but one thing, I would prefer going without Charisma. Charisma skill tends to be one of those skills in games that isn't really useful for anything in the actual gameplay. And, besides, I'd like that to be based on player interaction rather than a number. I prefer going without it.

here's my suggestion for leveling-up:
Using skills improves them, but also after a certain point you level up, which gives you a few "stat points" that you can put into any skill, allowing you to improve skills that you otherwise wouldn't use because they're too weak for you (and therefore would be unable to improve because they're too weak).

_________________
aaaaaaaaaaaaaaaaaaa

I wouldn't use public fields for those (or just about anything). Make them private fields exposed via properties. I also wouldn't make them floats, use ints and you won't have precision issues.

I disagree with the usage of private variables for any reason. ints makes sense though.

_________________
aaaaaaaaaaaaaaaaaaa

I think floats of 0.1 always work better (somehow), especially with AI stuff. But that's just my opinion .

_________________
Serious game developer

http://www.persistentrealities.com
http://www.persistentrealities.com/vbfibre
http://www.ambiances.nl

Machaira, speak up.

_________________
aaaaaaaaaaaaaaaaaaa

So you disagree with fundamental OO principles (namely encapsulation)?

If you don't encapsulate with properties then if you change your code it will break other classes.

float increments of 0.1 stored as ints.



If you make them properties, you can make them based on integers but return floats for the stat calculation. (You won't be free to change this later if you don't use properties) The calculations based on stats are presumably going to be read all over the place in the project, so its probably a good idea to make them read-only. You have to assume everyone else is a terrible coder and they will find every way possible to break your class (thats how you write good classes). This includes them setting the value of one of the stats in their code when they shouldn't. Then you can add functions like LevelUpStrength() that include error checking code for level caps.

I don't believe in forcing restrictions. I still think we should have the 'properties' as you refer to them, but making the variables private is pointless.

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.

_________________
aaaaaaaaaaaaaaaaaaa

Why don't you want to use private fields? They increase the reliability and organization of your classes and improve encapsulation. OO turns to spaghetti code faster than non-OO if you don't use private variables.

Are all Pawns going to have stats? Is a crate a pawn? Should a crate have dexterity? There are lots of questions you need to ask before you write a lot of code.

unreal engine proves you wrong.


yes, no, no.
A Pawn is a character. A crate will be some subclass of Actor, I forgot to mention Actor. Actor is everything not an NPC.

_________________
aaaaaaaaaaaaaaaaaaa

UnrealScript isn't OO.

If UnrealScript isn't OO, then I don't know what OO is anymore.

_________________
aaaaaaaaaaaaaaaaaaa

No, there is a point, it's encapsulation. What if someone does:



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.


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.


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.

In Unreal, there are only very few objects which inherit from nothing afaik.

_________________
Serious game developer

http://www.persistentrealities.com
http://www.persistentrealities.com/vbfibre
http://www.ambiances.nl

Bad idea... that would be assuming that the players lowest is the lowest that could possibly be in a stat. As an example where this isn't the case, think of (for example) just about any animal in the world. Their intelligence would be well below that of a human character in game terms, so having the pc start their stats off at 1 leaves no room to have lower without having ugly negatives that could mess things up.

_________________
God must love stupid people, he made so many.
theraje: 'God doesn't love stupid people, they're just easier to make'
http://sharedillusions.blogspot.com

What is an entity by your definition? That's more unclear to me.
Actor == gameworld object. Actor tells me something that acts on the gameworld.
Pawn == object that can be controlled by intelligence (artificial or otherwise) in the form of a Controller class. It is very much like a chess piece. It's a playing piece, and not the chess board or the Chess player.
Controller == The 'brain' for a Pawn.


Only the class named Object inherits from nothing. 90+% of the objects in the engine inherit from Actor. GUIs, Textures, Subsystem (editor vs. game), and Locale are among the few things that inherit from Object. A couple of things are just classes to get UCC to load up data files like Skaarj_rc.

_________________
aaaaaaaaaaaaaaaaaaa

PC or NPC - basically anything living with any degree of intelligence. Actually you could just call the class Character and you'd be more correct, whether it's a player or non-player character.


I think it's the inanimate objects as actors that gets to me.

I would do the hierarchy something like this.

Entity (Base class for interactive elements, does collision detection, etc.)
-Character (Same for PC and NPC)
-Vehicle
-ItemPickup
-Projectile
-InanimateObject

Model View Controller anyone, or am I the only one who uses that?