The time has come when I have to implement stats for players and non-playing entities. This is a subject I've been avoiding for some time but I've had some thoughts about how to model/implement the concept.

Here are my notes so far - input is appreciated: Do you see weaknesses in the approach, have you tried something similar, or have you perhaps solved the problem in a totally different ways?

Stats layers:
Contains: max Walk/run speed,damage for weapontypes, attack speed, maxhealth, maxmana, health/mana regen. str/dex/wis/con etc.

Layer 0 - base stats for entity types / character classes. From Config files (Using prototype pattern - no need to read config files more than once)
http://gameprogrammingpatterns.com/prototype.html
- players draw base stats from class-based config. What happens to existing players if config changes? See Layer 1
Layer 1 - personal base stats. Only for players?. Saved in DB (Recalculate functionality useful for bug-fixing or respeccing)
could be the value the player sees in the stat window
= Layer 0 + level gains and chosen Stat allocations
= Layer 0 + individual modifications for monsters? Perhaps some monsters are "elite" but share Layer 0 with non-elite.
Layer 2 - stats with equipment and buffs/debuffs. (Can be shown in paranthesis in stat window - perhaps separate eq and buff/debuff?)

recalculate a Layer 2 member for each use? or recalculate entire layer 2 when equipment and buffs/debuffs change?

Considerations:
Ease of implementation
Added complexity - this is especially bad if the rest of the system is affected. Black-box preferred
Performance

Note:
Some stats may influence others (more str = more damage etc.) - some stats may not exist in lower layers but instead be a result of more basic stats?
Stats may also have a volatile character - health is constrained by max health and affected by health regen. But at the same time it should perhaps still be saved in DB so you can't log out just to regen

First, read this thread: http://www.gamedev.net/topic/680775-rpg-stats-temporary-changes-harder-than-i-realised/

That's about code, but it includes many considerations relating to the design (and obviously it goes both ways).

Second, read (or re-read, since you already know the site): http://gameprogrammingpatterns.com/type-object.html

Using a type object can simplify the question of "What happens to existing players if config changes" by making it explicit which parts of the information are shared (and probably live in your game database) and which parts are per-instance. You may choose not to use the type object and will stick entirely with a prototype, but I think it's worth giving this some serious thought.

Thanks for that thread link - there is a very good discussion there. And yeah I was actually unsure if my subject belonged in this forum. It's definitely design - but I'm not quite sure if it's "game design".

Yes the Type Object article is a re-read:) It's not actually a choice beween the prototype pattern and a type object because the 2 can easily be combined. I'm not sure if I'll need a type object though, because I'm already separating behaviour from status and aiming for a pretty data-centric approach, with entity-definition files containing values for stats, behaviour class to use along with behaviour modifying values etc. I guess you could say the Behaviour object is already similar to a Type object?

keep it as simple as possible.

i personally use functions that simply return adjusted_str(), adjusted_dex(), armor_rating() etc.

the functions calculate the current value of the adjusted stat based on the core stat and any modifiers.