I believe you’re referring to the Conditions and the use of a Nullable boolean value in the Evaluate.
The reason we are making it nullable is that we can have many IPredicateEvaluators. By design, most of them won’t have an answer to the question. QuestList, for example, should have no idea if HasItem is true. Inventory should have no idea if HasQuest is true.
Our Evaluators only return true (yes) or false (no) if they definitively know the answer.
Let’s take an example:
Suppose I have a Condition that is HasQuest(“MotherHubbards Bunions”) (I’m simplifying the condition, I know that’s one And with one Or with a Predicate HasQuest and Parameter[0] of MotherHubbards Bunions.
The Condition system gathers a list of IPredicateEvaluators, and asks each in turn "Is HasQuest(“MotherHubbards Bunions”) true?
First it goes to Inventory, and Inventory looks at the cases it can handle. None of these cases are HasQuest, so it returns null, or “I don’t know”.
Next it goes to BaseStats. (You probably haven’t done this yet, but BaseStats is where you would evaluate a Predicate such as IsAboveLevel). BaseStats looks at the Predicate, but has no answer to the question, so it answers null, or “I don’t know”.
Eventually, we get to QuestList. QuestList looks at the Predicate and it knows whether you have a quest or not, so it answers either true (yes, the player has this quest) or false (Nope, not in this list).
The bottom line, an IPredicateEvaluator should only return true or false if it knows the answer to the Predicate. If it doesn’t have an answer, then it should always return null.