new 1.txt

Utility of time has to be considered in many cases - look at the distance to an object e.g. utility for the
time commitment for grabbing a set of keys increases when you're right next to them. By keeping the keys
in consideration at all times, then you can grab the keys as you pass them rather than having to replan.

Instead of building a big long formula, do it in little pieces - better reuse, easy to understand, more
scalable. Also lets you compartmentalize updates.

Managing scalability:
 * Every n frames
 * Use triggered updates

Split data calculation into separate processes
 * Used by multiple calculations for same agent
 * Used by decision calculations for multiple agents
 * Blackboard architecture

Lends itself to multithreading.

Utility-based architectures always analyze all options, rather than one.
Rate all options based on respective factors
Select the most appropriate options at a time

 * Not based on arbitrary thresholds
 * Handles situational edge cases a lot better
 * Easier to manage potentially conflicting logic

Consider pros and cons of a couple of apartments - lots of different factors to consider!
How do we weight them up? Even if we have loads of pros and cons, we might only have a few *types* of consideration

For example:
 * Cost (of rent)
 * Distance to _something_ (work, woodland, shops)
 * Aesthetics (how nice looking is something?)
 * Noise restrictions

Many of these are reusable in other contexts!

Of course we can't do much without knowing about preferences. Consider preferences of the agent:
 * Doesn't care about cost
 * Wants to be close to work
 * Wants nice aesthetics
 * Wants to make lots of noise

So these preferences provide values for these factors.

High principles: 
 * We want modular pieces of decision logic, called "considerations"
 * We want to be able to add/remove considerations easily, at runtime
 * Extensible so we can easily create new types of considerations
 * Reusable, so we can use between decisions and also from project to project!

 Architecture:
 * Reasoner is a high level thing that makes decisions. Has a list of possible choices e.g:
 Play with a ball, select a weapon, play an animation etc.
 * Each choice has a list of "considerations" - each consideration evaluates one aspect of the situation
 * Considerations generate appraisals.
 * Appraisals are combined to arrive at a final decision

Consideration
 * Encapsulates one aspect of a larger decision: distance,cost, selection history, benefit etc
 * Parameterized for easy customization e.g. for this decision and this character (for each situation)

 Code example:
class IConsideration { public: void load(const DataNode& node); Appraisal Evaluate(const Context& c); }
 * Data node is XML or whatever with the parameterization (maybe tool generated, part of bigger AI spec)
 * Context contains all the information the AI needs to make a decision (info about the game). Could be as simple
 as a pointer to the game. But obviously we want to make interfaces so we can carry between projects. If well
 implemented, is portable between games
 * Appraisal is generated by the Evaluate function, drives the final decision. Techniques:
 * Boolean logic (all appraisals return true)
 * Highest score
 * Weight based random
 * Optimize resource allocation to maximize utility

Experience has suggested that you should start as simple as possible and extend only when necessary.

Appraisals should have a base score e.g. floating point value of how good the choice is
Also a veto - prevent us from selecting the associated choice

Calculating total utility:
 * If any consideration sets veto to true, utility is 0
 * Otherwise add up all of the base scores together

 Weapon selection idea:
"Tuning consideration" provides a base score
 * Tuning consideration always returns the value specified in data regardless of the situation. Good for testing!
 * Range consideration can add utility or veto as needed (pistols are short range, rifles long)
 * Inertia consideration adds utility to the current choice (so we don't change weapons without a good reason, to avoid oscillations)
 * Random noise consideration so we don't always pick the same thing (blackboard architecture could do something more intelligent - who has what guns pulled?)
 * Ammo consideration - checks if we have ammo
 * Indoors consideration - prevent grenade use indoors

And at the end you select the best total score.

Appraisal with a final multiplier to replace veto:
 * Replace veto parameter with a "Final Multiplier"
 * Add all base scores together, then multiply by each of the final multipliers.
 * A multiplier of 0 is still a veto
 * Allows you to scale utility more smoothly/cleanly - for example, scale sniper rifle utility at shore range
 * Other things you could add: exponents, polynomials etc

Multi-utility appraisal
 * Add a priority attribute to the appraisal
 * When combining appraisals, take the max Priority
 - In other words, if one consideration sets the priority to be high, keep that priority
 * Only consider choices with max priority
 - Allows you to say "If X is true, only consider this subet of options"
 - For example, force the use of a melee weapon at short range, a ranged weapon at long range

Summary, utility based AI is:
 * Modular
 * Extensible
 * Reusable
 * Used in - Kohan 2, Iron Man boss AI, Red Dead Redemption for weapon selection, dialog selection, event selection in All Heroes Die

 What is it good for? Places with loads of possibilities and choices, RPGs, RTSes. Not good for:
 * No elaborate decisions, NPCs that are dead very quickly.
 * FSMs good for stuff really simple.

Single agent can do multiple things at once. Maybe an agent has a brain for their legs and their weapons.
The animation guys at that point ask this - the programmer just sets up multiple reasoners (brains).

Building decision momentum/interia/hysteresis

How do you factor in possibility of failure? Consider probability of success - modify utility by percentage of success?
Or have costs of success/failure and balance it out. In multiplayer games you have to use inference of how other things
look like they might turn out.