1) First check against intelligence and (in the future (For now just leave a TODO comment), level that we do not have today
). If intelligence and experience (level) failed...
2) Second check is against all three of these stats on equal bases: ["agility", "defence", "magic"]. Your normalization of fatigue to get freshness is also an awesome idea, which should be taken into consideration on equal bases as well!
I like the idea to check against intelligence and experience first to avoid a trap and check defensive stats only if the "spot the trap" check fails. It makes sense. However, the system currently is to simply to support that in one encounter.
Possible solutionsA) We create a SpotDangerEncounter. The capability for characters in this encounter would depend on intelligence, experience and possibly a stat that represents the senses (I think I saw a stat called something like awareness?). If the characters succeed, they avoid the trap/fight/other danger and continue with their quest directly. This can be realized with a branched quest. The caveat here is that only diverging branches are possibly, not converging branches (diamond structures). Bigger quests with multiple traps are hard to code without converging branches.
Example
# diverging branches are possible
quest start
|
SpotDanger
/ \
Trap end
|
end
# converging branches are (currently) not possible
quest start
|
SpotDanger
/ \
Trap |
\ /
end
B) We recreate the branching functionality of quests for encounters and define encounter checks also in an ElementTree. I would advise against that as it adds complexity we don't really need.
C) We create a new encounter base class that allows characters to perform one or several "spot the danger checks" and win the encounter if they succeed. That's probably the solution that is easiest to code for me. It makes creating new encounters more difficult as then there are two base classes new encounters can be subclassed from and they will work slightly different.
My opinionI think the best approach is to go with solution A). We can stick with the current system as it's IMHO good enough and before we start loading quests from XML I will figure out how to do converging branches in quests. That way we can keep the encounter classes relatively simple and you don't have to jump from quest to encounter classes constantly if you want to figure out the sequence of checks necessary to complete a quest.
EDIT: added a solution C). That one would be doable too, but is not as flexibel as solution A) and we proably want converging branches for quests anyway.