As Warner says. Here are my suggestions:
Separate the various parameters into two layers; an influences layer and a behaviors layer. The behaviors are things like speed, etc. Influences are things like agression, hunger, other characters behaviors, etc.
Each influence can affect multiple behaviors and Each behavior can be affected by multiple influences.
All the scalar behaviors and scalar influences should be expressed the same way, either as percents or coefficients (0.0 - 1.0) which I prefer.
(WAIT: See last paragraph first...)
Since 1.0 is the maximum, select an average or normal value for each influencing parameter (make it always .5 for simplicity's sake).
Now it gets a bit weird, but it addresses your .25 * .25 problem.
If the influencing parameter is below normal (which is .5) then we are decreasing the behavior paramenter. Simply double the influencing parameter and multiply.
Thus, a .40 energy level influencing a .64 speed would result in a speed of .512, a slight reduction.
On the other hand, if the influencing parameter is more than .5, it is increasing the behavior parameter. You can't just double and multiply because that could put the new value over the top (1.0) and cause a bug.
Instead, first flip both the influencing and behavior parameters (i.e. 1.0 - parameter) and do the same as above. Then flip the result.
So, if a .70 energy level is influencing a .64 speed:
- Flip .70 to .30 (1.0 - .70)
- Double it to .60
- Flip .64 to .36 (1.0 - .64)
- Multiply .60 * .36 = .216
- Flip .216 to .784 (1.0 - .216)
Thus, a somewhat higher than average energy level (.70) turned a .64 speed to a .784 speed.
The advantages are the great flexibility of being to take any number of factors into consideration, and the fact that the result will never go outside the range 0.0 - 1.0. And the fact that you only need to do all this when a change happens so it shouldn't be much of a performance hit.
I used this system for determining the influence of things like altitude and temperature on the color of a terrain pixel, but I could see that it would work for behaviors as well.
I just realized another way would be to have an average of 1.0 with no maximum. This way you would just multiply as needed. At the moment it sounds to me like a far simpler system than the one I described above as long as you aren't bound by a fixed maximum as I was in my terrain program.
Anyway, good luck.
Separate the various parameters into two layers; an influences layer and a behaviors layer. The behaviors are things like speed, etc. Influences are things like agression, hunger, other characters behaviors, etc.
Each influence can affect multiple behaviors and Each behavior can be affected by multiple influences.
All the scalar behaviors and scalar influences should be expressed the same way, either as percents or coefficients (0.0 - 1.0) which I prefer.
(WAIT: See last paragraph first...)
Since 1.0 is the maximum, select an average or normal value for each influencing parameter (make it always .5 for simplicity's sake).
Now it gets a bit weird, but it addresses your .25 * .25 problem.
If the influencing parameter is below normal (which is .5) then we are decreasing the behavior paramenter. Simply double the influencing parameter and multiply.
Thus, a .40 energy level influencing a .64 speed would result in a speed of .512, a slight reduction.
On the other hand, if the influencing parameter is more than .5, it is increasing the behavior parameter. You can't just double and multiply because that could put the new value over the top (1.0) and cause a bug.
Instead, first flip both the influencing and behavior parameters (i.e. 1.0 - parameter) and do the same as above. Then flip the result.
So, if a .70 energy level is influencing a .64 speed:
- Flip .70 to .30 (1.0 - .70)
- Double it to .60
- Flip .64 to .36 (1.0 - .64)
- Multiply .60 * .36 = .216
- Flip .216 to .784 (1.0 - .216)
Thus, a somewhat higher than average energy level (.70) turned a .64 speed to a .784 speed.
The advantages are the great flexibility of being to take any number of factors into consideration, and the fact that the result will never go outside the range 0.0 - 1.0. And the fact that you only need to do all this when a change happens so it shouldn't be much of a performance hit.
I used this system for determining the influence of things like altitude and temperature on the color of a terrain pixel, but I could see that it would work for behaviors as well.
I just realized another way would be to have an average of 1.0 with no maximum. This way you would just multiply as needed. At the moment it sounds to me like a far simpler system than the one I described above as long as you aren't bound by a fixed maximum as I was in my terrain program.
Anyway, good luck.