Design Log - Actor behaviors and the strategy pattern
In which Q attempts to record his design knowledge.
Nerdy little secret - I never took OOP in college. I was trying to graduate, I had a choice between two classes, and picked graphics over OOP. My graphics class got me into the game industry, but my understanding of OOP was self-taught through reference books and code that was created for performance rather than maintainability. For a while, I had the mindset that I would teach myself eventually, but for now I've gotta focus on .
I finally found a decent book that taught design patterns, rather than acting as a reference guide. As a student, I always learned better from humans, and this book does a pretty good job of replicating the human-taught experience. This series will represent my efforts at codifying this information for future reference.
First Design Log - the strategy pattern.
When confronted with a family of algorithms, encapsulate them, and make them interchangeable. This way, the algorithm you use will be independent of the clients that use it. The example the book gives is that of a company creating ducks for a game.
There are multiple types of ducks, so the programmer creates a duck base class with flying and quacking behavior. The display behavior differs per duck. However, as the company adds more duck types, the subclasses require more maintenance as certain types of ducks fly differently, or not at all. Likewise for quacking, where certain types of ducks squeak (rubber duckies), or not at all (decoys). In this case, the appropriate solution was to create a quack and fly interface where each type of behavior is represented by a different implementation of the interface. The duck baseclass has pointers to a flybehavior and quackbehavior, and has methods that activate flying or quacking, but each duck subclass instantiates a specific subclass of fly or quack.
We apply this pattern in our game engine through the use of actors and their behaviors. In our game engine, actors are the basic entity for game play. Actors serve as NPCs, PCs, walls, static objects, etc. The engine defines each actor's behavior through a series of behavior objects. Because the engine is made to deal with any combination of user-defined behaviors, the actors call on the behavior base class method Evaluate whenever a condition is satisfied that causes a behavior to be triggered. The specific subclass instance of the behavior gets called and executes whatever behavior it is specifically tailored to do.
For instance, we have several different types of move behaviors. Some move behaviors override any previous velocity on the actor, while other move behaviors blend their movement vector with previous velocity. Some move behaviors apply a constant force on an object, while other move behaviors apply an impulse only. All the move behaviors share a common interface, which is what we call whenever we want the actor to move.
Nerdy little secret - I never took OOP in college. I was trying to graduate, I had a choice between two classes, and picked graphics over OOP. My graphics class got me into the game industry, but my understanding of OOP was self-taught through reference books and code that was created for performance rather than maintainability. For a while, I had the mindset that I would teach myself eventually, but for now I've gotta focus on .
I finally found a decent book that taught design patterns, rather than acting as a reference guide. As a student, I always learned better from humans, and this book does a pretty good job of replicating the human-taught experience. This series will represent my efforts at codifying this information for future reference.
First Design Log - the strategy pattern.
When confronted with a family of algorithms, encapsulate them, and make them interchangeable. This way, the algorithm you use will be independent of the clients that use it. The example the book gives is that of a company creating ducks for a game.
There are multiple types of ducks, so the programmer creates a duck base class with flying and quacking behavior. The display behavior differs per duck. However, as the company adds more duck types, the subclasses require more maintenance as certain types of ducks fly differently, or not at all. Likewise for quacking, where certain types of ducks squeak (rubber duckies), or not at all (decoys). In this case, the appropriate solution was to create a quack and fly interface where each type of behavior is represented by a different implementation of the interface. The duck baseclass has pointers to a flybehavior and quackbehavior, and has methods that activate flying or quacking, but each duck subclass instantiates a specific subclass of fly or quack.
We apply this pattern in our game engine through the use of actors and their behaviors. In our game engine, actors are the basic entity for game play. Actors serve as NPCs, PCs, walls, static objects, etc. The engine defines each actor's behavior through a series of behavior objects. Because the engine is made to deal with any combination of user-defined behaviors, the actors call on the behavior base class method Evaluate whenever a condition is satisfied that causes a behavior to be triggered. The specific subclass instance of the behavior gets called and executes whatever behavior it is specifically tailored to do.
For instance, we have several different types of move behaviors. Some move behaviors override any previous velocity on the actor, while other move behaviors blend their movement vector with previous velocity. Some move behaviors apply a constant force on an object, while other move behaviors apply an impulse only. All the move behaviors share a common interface, which is what we call whenever we want the actor to move.