|
Object-Oriented Game Design(12) As I claimed in the section on State objects, entities can affect each other without explicitly being created to do so, and they use the Action object to fulfill this claim. State objects drive the functionality of the Action objects, and specific action events are implemented to use predefined State objects. In this way, Action objects can be created separately from the game tokens that intend to use them, and yet be guaranteed work regardless of what game token they become a part of. This makes the Entity objects, and the eventual game tokens created from them, remarkably robust, and reusable. An invoked Action object works through its references to Entity objects. One reference contained in an Action object represents the "UserEntity", and this is the Entity that invoked the Action. If the "UserEntity" has Game States that affect the Action they are handled through this reference, and the way the Action functions is altered by those states. Another reference is the "TargetEntity". The "TargetEntity" represents an Entity, other than the "UserEntity", that the Action object was invoked against, and its State objects are generally the states altered by the Action object. If there is no "TargetEntity", in other words if the "TargetEntity" reference is NULL, then the Action that was invoked by the "UserEntity" also affects the "UserEntity". The third Entity reference is a "TargetSet", which is used to define an Action that can affect groups of Entity objects. This set could be built from any of the entities contained in a game space, and is essentially a subset of a game space. Any Entity in the "TargetSet" whose State objects are valid will be affected by an Action invoked upon the set. Having stated that Action objects are invoked, one might be wondering how they are invoked. An action can be invoked in two ways only. The first, and most obvious, method by which Action objects are invoked is input. A user provides an input event, and this input event can be mapped to a specific Action object that exists in a specific game token. The input invokes the action event and the action event continues to execute until it completes or until another input event cancels the action. This system can also allow for an AI user to provide action-invoking input, and provide feedback to inform the AI module of the results. However, such an AI entity would have to be designed with the framework of this system in mind. The second way an Action object can be invoked is through another Action object. This method can be subtle, and may not be easily understood. As an example, a game token, which represents an avatar, is going to invoke its Shoot action. The avatar, controlled by a user, invokes the Shoot action using an input event, a key-press. The Shoot action has as its "TargetEntity" another game token, the bad-guy. The Shoot action is one that is "self-canceling", in other words, it uses game constraints to determine its interval in time rather than waiting on input to cancel. While invoked the Action object checks for a collision with the bad-guy token, and if that collision occurs, it operates on State objects contained in the bad-guy. Since the Action object is already interacting with the bad-guy token, it checks that token’s Health state, and, if that State object meets certain constraints, the Action object invokes the Die action of the bad-guy token. This method of Action invokes Action is essentially a kind of ambient artificial intelligence. The Action Interfaces Core Services Relationship
|
