|
Object-Oriented Game Design(8) The benefits of using a state class instead of specialized primitive variables to constrain the behavior of entities are twofold. First, once a State class has itself been defined, the game development system can utilize that State class to define any game token in any game implemented with the system. Secondly, entities can be queried for the existence of a State object at runtime by another entity, and if the entity queried possesses that State object the entity can be interacted with by the entity performing the query. The implications of this are quite interesting. Two game token objects that were designed totally oblivious to each other (encoded without explicitly referencing the other object) could still interact with each other at runtime due to the nature of the State objects and the relationships they possess. Whoa! Wait a minute, how is this possible? It is possible because we design an Action class that alters or modifies a specific State object that is relative to the type of event that the Action class models. The reasoning behind this is that State objects define and limit the behavior of game tokens, and by altering State objects we indirectly alter the behavior of the entity they define. Therefore, we interact with states and not fully defined entities to keep the system general and flexible. In so doing we disconnect the game token from its dependence on specific data. And, this allows much greater freedom in the implementation of an Entity class. As an analogy, let’s suppose we have a game token that represents a car, the behavior of which we wish to modify. Let’s say the car is a fast car and we want to make it go even faster. However, what we do not want to do is make the car faster. If we were to make the car faster, we could only affect the behavior of that car. Instead, we make the "fast" faster, and therefore ANY game token car that can go "fast" can be affected if we so choose. Much more importantly, not only could any token representing a car be affected, also, ANY game token with a "fast" behavior could potentially be modified regardless of what it is meant to represent. And, it could use the same modification method. It may sound silly at first, but think about it for a while. Potentially, very powerful optimizations lie down this path. The definition of the Action object and its relationships, which lies ahead, will help make the way this system is designed become clearer.
|
