Game Development Reference
In-Depth Information
// Return which of the two approaches will leave us with
// the most remaining health.
if ( HealthFirst > ArmorFirst ) {
return GOAL_HEALTH_ARMOR;
} else {
return GOAL_ARMOR_HEALTH;
}
}
The differences from our earlier version is that we replaced the variable
mHealthKitValue
with the function call
HealthKitValue
(
mTimeToHealth,
mHealthKitDecayRate
).
If we wanted to, we could continue to add factors to this decision. What if we
want to consider the likelihood that the Health Kit or Armor will still
be there
by
the time we arrive? All we need to do is add additional variables or functions to cal-
culate the various utilities and apply them to the decision equation itself.
Additionally, we could extend this function to accommodate many possible
end decisions. For example, perhaps it is best to go out and get
only
the Armor? Or
only
the Health Kit? What if we included a third potential stop along the way—such
as a nifty weapon. We would only need to process our different utility values and
compare them at the end. Theoretically, we could have many different possibilities
stored in an array or a list and, after processing them all, sort them by the result
value and see which one is the best. But now we are really getting ahead of our-
selves. We will revisit this later on. (Aren't you excited?)
What we have covered in this chapter is what amounts to a core building block of
decision making. It is the measuring stick with which we determine how important
the different sides of a problem are to us. In the Prisoner's Dilemma, this was the
length of time in jail. In Cutting the Cake, our utility for cake was what made us
want
to make sure we got the biggest piece possible.
In the Ultimatum, Dictator, and Trust Games, utility was measured in terms of
money—and yet there a few other things sneaking into the equation… Guilt? Fear?
Altruism? These factors prevented us from electing to purely maximize our utility
