This chapter covered the theory and common properties behind reactive techniques:
A reactive component is a deterministic mapping from inputs to outputs.
Components with some internal memory are often considered reactive, despite not being so in theory.
It's possible to express nondeterministic components (with internal states) as a reactive mapping by using additional inputs.
We've also learned the difference between reactive behaviors and planning:
Planning algorithms are nondeterministic, because the output depends on the goal.
Planning generally uses an internal model of the world, whereas reactive behaviors generally do not.
Planning is better suited to some problems because it sacrifices computation in favor of memory.
This chapter also covered the many reasons for using reactive behaviors and techniques:
Reactive behaviors are suited to games due to their efficiency, reliability, and predictability.
Reactive behaviors are ideal for animats because they enhance embodiment as well as learning.
Reactive techniques are often at the base of more sophisticated systems.
Finally, this chapter covered reactive architectures as amalgamation of hierarchical components:
Components are treated as black boxes with the same interfaces regardless of the implementation. Components can be nested transparently.
Reactive architectures must react quickly to external requests or stimuli from the environment.
There are different ways to decompose the problem to build architectures, simplifying the development.
Many approaches to combining the output of multiple components were discussed.
The next chapter looks at ways to put all these ideas together practically so that the actual development of NPCs is slightly easier!