Game Design the Object Oriented Way

Object Oriented Game Design Written by B.L. Hannah

Introduction

It is fairly common knowledge that producing computer games is somewhat time intensive. Normally, a high-quality computer game project involves a fairly large team of individuals. A list of such a team might include designers, programmers, animators, graphical artists, and sound effect artists, not to mention the business side of a project. The amount of work that it takes to bring this type of project to completion is spread fairly well throughout an entire team, yet most of the time involved is due to implementation of the software. The reasons for this are many. However, it is not impossible to reduce the time it takes to go from conception to completion of a game project.

I believe that utilizing a system developed with object oriented programming techniques, we can drastically improve the way we create computer games. Through the wise use of inheritance and over-ridden methods, and thoughtful, careful design of the implied base classes I believe key game components can be made extremely versatile and absolutely reusable. Reusable in such a way that two entities created oblivious to each other could, utilizing such a development system, work together with NO changes to their code, and work together so efficiently that there will be minimal impact on highly optimized, time-intensive rendering code. I believe that this type of system could cut substantial amounts of time from the implementation process by providing game implementers with flexible, re-configurable, and efficient, game objects.

Because of these beliefs, I have spent a great deal of time designing an object oriented game development system that can aid programmers do their jobs more efficiently. This system is currently in a prototype stage, yet it has the capacity to produce mid-range quality games in as little as three months. It has been implemented thus far using only C# and the .NET framework. I do not claim that it is the best way to approach game implementation, nor do I claim that it is completely flawless and fully functional, but the potential of a three-month turn around on game completion time can not be ignored. And, even in its current state, it stands, as my proof that an object oriented system is possible. At the very least, such a system can be used to prototype games extremely rapidly, which has its own benefits.

Game Development System Overview

The core of this system will not be unfamiliar to game programmers. In all, there are five software systems that must be utilized by any game development system. These are; display systems, audio systems, input systems, persistence systems, and communications systems. However, I have taken the approach of utilizing these systems as services to a game application rather than making them an integral part of the game itself. As services, these systems can be developed separately from a game, which allows them to be implemented in almost any way desired, and the game design system can set up access for these systems through interfaces, as Figure 1 suggests.

The model represented by Figure 1 is very simple, yet possesses many implications in the details which it does not show. Notice that communications is one of the core services. If the communications system is properly implemented in the relationship implied by the diagram an interesting possibility arises. A game could potentially be designed and implemented without network capabilities, and then later revisited to add in those capabilities. This is something that is considered nearly impossible using current technologies. Yet, although not fully implemented, the prototype I mentioned earlier has just this potential. How this is possible comes down to acknowledgement of relationships. For every type of core service in the figure there exists a relationship between that service and a game. A proper game development system, such as the one modeled in Figure 1, acknowledges these relationships, and therefore makes it possible for any game to utilize any of the services. If a game suddenly requires communications, since the relationship to communications services already exists to this game development system, it is no big deal to add the capabilities. Over the course of this article I will attempt to provide an explanation of how such a system might operate.

So, what is a game development system? What does one consist of, how does it work, and why would anyone want to use one? To start, one must establish a good understanding of all the parts a game consists of. Traditionally programmers define this on a game by game basis without considering games in general. In fact, most programmers view game objects as extremely specialized, and this view forces their implementation to be just as extremely specialized. However, if one takes the approach that more than one game will be developed using the same system, and, more importantly, differing types of games, one can begin to define all the necessary components of a versatile game design system.

All computer games can be broken down into 5 basic objects. These are as follows:

1. The Game Entity – This represents the concept of a game token. It can be anything that exists in the game including the player’s avatar, an obstacle, or whatever the designer wants in the game.
2. The Game Entity Form – Not to be confused with the Game Entity, this component represents the form or appearance that a Game Entity takes, and is meant to be represented virtually with a mesh. The reason for this distinction between an entity and its appearance will become clear with further explanation.
3. The Game Action – This component generally models the game mechanics and other rules or constraints of a game. It is essentially the virtual representation of an event. Some examples might be run, jump, shoot, accelerate, explode, and many, many more. Actions are performed by a Game Entity, and affect other Game Entities.
4. The Game State – Used to temporarily track the data of an entity or its form. States can also modify the way an action functions. States of a Game Entity represent data that is not relevant to most game mechanics, such as a name, while states of the Game Entity Form are typically used exclusively for game mechanics.
5. The Game Space –These are simply collections (or sets) of the other four components. The reasons why one would want multiple collections of the various other game objects is diverse and the objects are generally sorted into collections for optimization purposes, which includes rendering, and A.I. updates. In concept it represents the world of the game, and it is where all the effects of the actions are applied.

Building off of these five basic objects almost any computer game can be implemented, if not every computer game.

Having identified the major objects required, the next step is to define how to make those objects work together to become a game. Standing alone the five objects listed above has little meaning. In context with game development these five objects possess special relationships. These relationships are the true heart of the system, and understanding these relationships is the key to using the system effectively. The following class diagram illustrates the relationships.

Each of the objects from Figure 2 and their associated relationships will be explained in turn. However, most of these objects are derived from extremely general base classes, and the purpose of the base classes needs to be addressed. In a computer application, two broad categories of object types can be established. These two categories can be labeled Renderable Objects and Non-Renderable Objects. If one considers this categorization for a moment they will conclude that objects defined from this concept possess intrinsic states. In other words, these two types of objects possess states that will not change, and can be guaranteed to exist so that they can be operated on at any level of an object-oriented framework. However, adding any states but those that are truly intrinsic to a base level object is superfluous, and therefore much consideration must go into what states belong to a base class. In this case, defining those intrinsic states was a matter of examining the two broad types mentioned above.

The Renderable Object, as the name implies, is one that can be rendered to a display of some kind. As such, this object needs data that will allow this rendering to occur if rendering is desired. There are only two possibilities that currently exist for computer rendering, however, if more arise, this system is fully capable of adjusting. Two-dimensional and three-dimensional rendering are the types most likely desired by game developers. To be rendered in either of these mediums an object needs but two qualities: position and orientation. Thus, if the data needed to represent these two qualities is included with every Renderable object, and no other data, then it is likely that the object can always be rendered to a display system. Most of this data is shown in detail in Figure 2-A.

For an object that needs rendered, the data illustrated in Figure 2-A is the minimum data necessary to execute that rendering. Adding any more data is not required in the base class. The reason that more data is not required is that we, as yet, have no idea what is going to be rendered. We would know where the object was and what its orientation was, but there is no possible way to know its shape, therefore adding more data at this point is extraneous. The implication is that a concrete object will be derived from this base class that represents an objects shape, and that is exactly what this system does, but that will be defined later. For now, we have established all the data necessary for any object that we need to render.

The next broad category to consider is Non-Renderable Objects. This one is rather easy. It represents any type of object that does not need to be drawn to a display. This is just about anything that one could imagine, and therefore, it is quite impossible to define intrinsic data that all such objects might need. This base class is simply an empty abstract class that is used to differentiate it from Renderable objects. The reason it exists is primarily for identification purposes, and to maintain the concept of categorization of entities within the system. The class diagram of Figure 2-B is a good representation of this framework.

Having established that the five objects in Figure 2 derive from generalized base classes, they can now be further detailed. However, the manner in which the five basic objects interact can become somewhat complex, and explaining how just one of them operates will not necessarily make the understanding of the game development system they are a part of become immediately clear for every reader. All of these objects are intricately interconnected through important relationships, and explaining the system requires providing the reader with an understanding of all the objects and their associated relationships.

The Game Space Object

As depicted in Figure 3, the Game Space Object holds other objects within itself. It represents a set or sets of game entities. In most computer games the game tokens interact with each other in some fashion, and are generally sorted into collections. However, in most computer game implementations the collections are created arbitrarily as needed. This system is designed with the realization that the game entities will always need to interact, and therefore requires a standard way to organize collections of game tokens. In this way, the sets could be made reusable if necessary.

Shown above are the two types of sets used by this system. Virtual space contains objects that are a virtual representation of an entity’s physical form. The set labeled as virtual space is a subset of logical space. The set shown contains a car, a plane, a flower and a boat. It is of importance to keep in mind that the objects in virtual space are merely a representation of an entity’s physical form, and are not the entity itself. Other aspects of an entity’s function are sorted into logical space. These two sets are derived from an abstract base class that enforces minimum functionality on every set. Essentially that minimum functionality is the ability to add and remove entities, but could be extended to include things like insert for ordered sets or sort. The primary reason for separating entities into the two types of sets is optimization. Virtual space is slightly different from logical space as it is also capable of being rendered to a display system, and therefore contains only renderable objects. In fact, the interface to the core services of this game development system expects to utilize virtual space sets for rendering. And, it is capable of using any such set, and even switching between virtual space sets at runtime.

The set labeled logical space in Figure 3 is where the work gets done. One could say that virtual space contains the virtual physical form of an entity, while logical space contains the entity’s virtual soul. This is the space where the work is done to make all the entity interactions occur. There can be as many types of interactions as there are entities to interact. An example might be a player’s avatar shooting a bad guy with his or her rail gun. When this interaction event occurs something must happen in the code to acknowledge the event, and this set is where that acknowledgement takes place. The objects in this set are optimized in a special way that eliminates inter-object conditional branching. The are no large switch/case structures being continually checked in the interaction system. No big if/else chains exist in the code. There is minor conditional branching within an object itself, but no program today can be implemented without using some conditional branching. Outside of that, the important thing to keep in mind is that the game space represents sets of interacting entities.

The Game State Object

To better define an object that is capable of interacting with another object, we use states. Objects that interact are essentially exhibiting behavior, and states can be considered as instantaneous behavior, or behavior at a specific point in time. And, this is where most game implementations throw reusability out the window. Game implementations tend to define very specialized objects with states carved in granite. Optimization is the primary culprit in this process of game implementation. There are places for primitive states in objects, but a reusable object needs to be considered extremely carefully before adding in states of that nature. This game development system uses state objects to represent data that entities use to interact with each other. These State objects help compose, or in other words define, the Form object and the Entity object, and are used by the Action object. In essence, the behavior of Form and Entity objects at runtime, as well as Action objects, is defined and modified through State objects in this system.

The benefits of using state objects instead of specialized primitive variables to constrain the behavior of entities are twofold. First, once a State object has itself been defined, the game development system can utilize that state in any game token or in any game implemented with the system. Secondly, entities can be queried for the existence of a State by another entity, and if the entity queried possesses that State the entity can be interacted with by the entity performing the query. The implications of this are quite interesting. Two game token objects could be created that are totally oblivious to each other’s existence (encoded without explicitly referencing the other object), and yet due to the nature of the State objects and the relationships they possess, they could still interact with each other. Whoa! Wait a minute, how is this possible? It is possible because we create an Action object that alters or modifies the State object and not Game Form objects or Game Entity objects. As mentioned above, State objects define and modify 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.

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 don’t want to do is to 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, 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.

Before continuing, however, the issue of reflection technology needs some mention. It could be argued that through reflection technology, which most modern OOP languages possess, primitive states could be used in a general way. Through reflection, most objects can be queried and their associated fields and methods can be discovered. Yet, the use of reflection technology would also keep the system dependent on the object-oriented framework through which it was utilized. Therefore, this game development system currently implements its own State objects to track the data of its Entity objects. In this way the game development system I am describing could itself be developed using any language desired or is important at the time.

The Game Form Object

The purpose served by a Form object is, usually, very simple. It is used to represent any shape that an entity needs to be implemented to possess. Thus, the Form object needs to contain a Mesh object. Utilizing this mesh, Form can be any shape a 3D Modeler can make. However, a relationship exists between Form objects and Space objects. Through this relationship a Form object can be composed of a set of entities as well as representing shape. This ability helps to further generalize an object into something that is capable of being any type of game token imaginable.

The Form Contains State Relationship

The Form object is designed to be instantiated as a member of a set contained in virtual space, or space that simulates real space. Generally, game designers and implementers want the game token to appear as if its exhibiting the behavior it would be expected to exhibit if it were real, and states are used to make it happen. Usually, most people don’t make the distinction between the Avatar and the Avatar’s mesh object. However, the distinction does exist in the virtual world, and this relationship embodies that distinction. In clearer terms, States meant to modify the behavior of a mesh form in a virtual three-dimensional space should be contained in the Form object. After all, the Form object is the only object such states are ever likely to affect.

However, the fact that State objects ARE contained in the Form object is more important than what or why. The power of making "fast" faster rather than making a specific type of game token faster has already been mentioned, and this relationship enforces that doing so affects a general object rather than a specialized object. In essence the game system is acknowledging the relationship rather than the state data or the Form object. In this way the system can utilize all Form objects in the same manner regardless of what shape the Form object is supposed to be or what behavior the state data is intended to represent. This is a powerful concept in creating reusable entities.

The Form Contains Space Relationship

This relationship is part of recursive set. As Figure 2 shows, Entity contains Form, Form contains Space, and Space uses sets of Entity objects. This relationship has more meaning in relevance to the Action object, which works within the Space objects. For now it can be said that an Entity object can be implemented to represent a virtual space, as illustrated in Figure 3. This Entity object can contain a Form object, which can be used to represent the volume of that space. Since a Form object can contain Space objects, other entities can be implemented, and contained within the Form object through its relationship with Space objects. As mentioned, Action objects work within Space objects, and can be implemented to affect entire sets of entities. An Action object could make use of the mesh data contained in the Form object to impose constraints on the positioning of the entities contained within the Form object’s virtual space. It could just as easily utilize any State object data associated with the Form object to alter the States of all the entities in the set. This would make it a trivial matter to move sets of entities contained in other entities around in virtual space.

The Game Action Object

An Entity can be composed of Action objects. As the name implies, an Action object is an implementation of some task that an entity can perform. More precisely, it is the incarnation of an event. Generally, when an event occurs there is some way to tell that it occurred. The Action object is the code that represents this event. Thus, it is a virtual representation of an event. Action objects are designed to modify State objects, which indirectly alter the apparent behavior of Form objects and Entity objects. As I stated earlier, the State object is somewhat like a snapshot of a behavior, or behavior at a specific point in time. In counterpart to this, the Action object is like a movie, and almost quite literally as it drives the visuals and sounds in this system. More precisely, the Action object is a sequential expression of the states contained within an Entity object. To clarify, an Action object has no meaning at a specific point in time, as it exists across an interval of time. And, while the Action object exists it exposes the current state of the Entity object that invoked it, and can even alter the current state of another Entity object.

The Action Contains Entity and Uses State Relationship

As Figure 2 shows, Action possesses a bi-directional relationship with Entity, and therefore contains Entity references within itself. These references represent target entities that the Action object is invoked to affect. Through the Entity object relationship, Action also has references to all the State objects that define an instantiated Entity object. This ability to reference the State objects is a very important relationship. As stated, the entities and their forms are merely a composition of states and actions, and therefore modifying a part of an entity through this relationship is, in effect, altering the entity. The State objects are implemented in an Entity object using hashtables. The Action object queries an Entity object’s hashtable for a desired State object, and if it is present then the Action can operate on that State. The State object may affect how the Action functions or the State object may be altered by the Action, and in turn, can affect the functioning of some other Action. This relationship is naturally recursive as it cascades through the Entity objects in a running game.

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 does this through its references to an Entity object. 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 works 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 Game States 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 it 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 it is already interacting with the bad-guy token, it checks that token’s Health state, and, if that State object meets certain constraints, invokes the Die action of the bad-guy token. This method of Action invokes Action is essentially ambient artificial intelligence.

The Action Interfaces Core Services Relationship

Figure 5 displays the relationship between the Action object and the core services, and, before going on, it is beneficial to point out that the Action object drives a game’s visuals and sounds in this system. Essentially, it does this by using interfaces to the core services. However, sound and visual effects can require optimization in order to work appropriately, and therefore Action does not have full control over visuals or sounds. The Action object is more like a natural manager of these aspects. It merely makes demands that a visual or sound be initiated, and the core services does its best to provide the appropriate graphics or sound effects to go along with the action event that is occurring. Usually, if the core services are properly implemented and optimized, there will be no problem providing display and audio service updates on demand.

The Game Entity Object

The Game Entity is the concept of a game token. This is a very important distinction, for in actuality it represents the concept not the token. A game token embodies everything that the token is, while the entity is anything that a game token might be. What this means is that, once an entity is defined as a car, it becomes a token that is a car in the context of a game, but until that definition occurs an entity is everything and nothing. In other words the token is an entity that has form, possesses state, can perform actions, and exists in the game space. The relationships that the Entity object possesses with the other objects in the system provides the potential for the Entity object to meet the preceding criteria. This system recognizes that all entities will be composed of form, state, action, and even of space as well as in space. By acknowledging these five relationships, the system is a framework in which the entities can work cohesively. And, they do so, very well. Once the point of implementation is reached the programmer can use a game development system entity to create a fully defined game token that already has the potential to interact. By not having to design this interaction framework, the programmer can focus on what he/she wants or needs the game token to do rather than on how he/she is going to make the token do it, and such an ability can be a tremendous time saver.

The Entity Contains State Relationship

Data not meant for rendering or game mechanics is realized through this relationship. A game token is likely to need many different states in order to keep track of everything its doing, or is being done to it, in a game. Most of these states will have relevance to the virtual physical form of a token; however, some states may not be critical to the game action. These states will be things like names or other superfluous data. Such states are best kept within the entity itself to promote reusability of Form objects. By keeping data inside the Entity object that is not critical to the way a Form object interacts with other objects in virtual space, one can make Form objects that are very robust, and useable by many different types of games.

The Entity Contains Form Relationship

This relationship makes the statement that all Entity objects have shape or form. The shape can be any shape that can be represented by a Mesh, or it could even be no shape at all. The shape an entity might need to have is, obviously, determined by the type of game token a designer wants to represent, and this relationship guarantees that the Entity object can fulfill the role. Better yet, this relationship allows one Entity to have more than one type of form. The Entities form could be represented two-dimensionally or three-dimensionally, and it would still be the same entity. This could allow a programmer to prototype a game in two-dimensions, and then switch to three-dimensions with only minor or no changes to the entity itself. There are many possibilities for using this relationship in a game.

The Entity Uses Space and Contains Action Relationship

The relationship that allows an Entity to interact with other Entity objects is the Game Space object. As mentioned earlier, the Space object represents sets of Entity objects. An Entity uses references to these sets to acquire Action object references, which the Action object then uses to affect the entities that it ‘targets’ or references.

For example, we could define an Entity as, for the sake of argument, a planet surface. To represent this planet surface we create a mesh of various terrain features, and incorporate this into our Form object and reference the Form object with our Entity, which we have dubbed planet surface. Since all Form objects can contain Space objects, and Space objects are sets of entities, we can define a multitude of other entities and make them part of that set. Since all entities in the set are composed of Form objects and contain all the states necessary to be positioned in any way desired in three-dimensional space, we can define Action objects for the planet surface entity that can easily affect this set of entities. The Action ‘ApplyGravity()’ comes to mind, as well as ‘SetEntityZToPlanetSurfaceZ@XY()’.

As one can see, the relationship Entity possesses with Action objects makes it possible to create very versatile game tokens. The Action object can take advantage of the other relationships that Entity possesses to interact through those relationships. This makes all of the Entity objects extremely interconnected, and very capable of simulating any type of game token a designer requires.

Putting It All Together

At this point one may be wondering exactly how it would be possible implement the five objects and their associated relationships to operate together. The answer might be Abstract Classes and Virtual Methods. Perhaps a virtual method called DoAction() might be employed, and overridden in derived classes. Something like this would make it possible to iterate through a collection of Actions and for each action in set Z perform Z.DoAction(). Since the framework I have been describing consists of sets of Entity objects, perhaps making all this work simply involves iterating through a collection of entities calling Entity.DoAction() for each Entity in the Game Space. And, each Action invoked in this manner causes a request for visual and audio servies, which reflect the action event. Then finally, the invoked Action object uses it target references to first modify the action, and then find and affect the State objects of an ultimate target entity. And that is basically how the system might work. The diagram below can help in visualizing this better.

As can be seen in Figure 6, two sets exist inside a game entity, and the game entity exists within an application, which is providing the core services. A camera entity is providing the user with a view of virtual space, but could easily use ANY virtual space available to be displayed. The entities in logical space interact with each other through the Action objects, which can alter the virtual physical forms of their counterparts in virtual space, and the camera entity provides a new picture of the updates. How the Form object changes its mesh doesn’t matter. The Display service is doing the actual changing of the vertices of a mesh, and it could be anything from matrix calculations to motion capture animations. What matters is how fast can the Action objects perform updates?

Rendering systems typically need a lot of time to do their work, and if objects can’t update what they are doing fast enough then everything can’t get displayed in time. Therein lies one of the strengths of the system I am describing. Action objects are sorted into possible actions and current actions. When the system runs through the entities in logical space it is iterating through a current actions collection, and executing only the code of Action objects contained in that collection. When an action becomes canceled it is returned to the possible actions collection. Using this technique it is not possible to invoke the same action twice. Also, since only code in the current action collection is getting executed, a lot of processor time gets saved. If an entity is doing nothing then NO action code is executing. Not even a conditional check to see if it should execute something!

On the other side, to invoke an action, Human or AI input queries an entity’s possible action collection, and if the action is present, it can be invoked. Since these are generally input events, then no large conditional structures are required to see what actions are being invoked. The actions are simply invoked by the event. For example, a key pressed by a user makes a game token perform the run action. The same input event can cancel an action. The previous example’s user lets go of the key and cancels the run action. Some Action objects do use logic themselves to determine whether or not they need to continue executing, but this conditional logic is restrained within the Action object only. And, once such actions become invalid they return themselves to the entity’s possible action collection, while at the same time removing themselves from the current action collection. Exactly what an Action object does can only be determined by the desire of the game designer.

Figure 6 is a very high level logical view of what a running application might look like. I’ve made several references to the term game token, but one thing that game programmers may not realize is that a game is itself a token. And, by the nature of the framework I have described, falls into a class that can be included in the framework’s sets of game space. Figure 6 labels a box as ‘Game Entity’, and this is a literal Entity object in the system. It could have been drawn in the diagram as being contained in the logical space, for in truth it most likely would exist there. And, just as any other Entity object, it can possess actions and interact with other Entities. It would most likely have a Form object defined as None, and, through its Action objects, would exist as a natural interface between the other game objects and high level game mechanics/rules.

The concept of game is token can not be overstressed. If the game is itself an Entity object, then it has at its disposal the same interaction benefits as any token, and can use the interaction framework to manipulate ANY token in the game. As a more concrete example of practical uses for this, I propose the concept of an Entity Factory. A programmer creates the game tokens, but tokens in themselves are not the game. Since the tokens are meant to be self-sufficient designed with this framework, then they can be used in any game created from this framework. Therefore, a programmer could create an Entity Factory to instantiate game tokens from a configuration file. The configuration file can come from a tool designed for the purpose of creating game tokens, or it could even come from a script. To bring relevance, the game IS the Entity Factory. The game instantiates the entities and configures them from rules provided by a builder through a configuration file using the interaction framework, thus altering the looks and behaviors of entities. Though the end user will define the game by what he or she sees (which is defined by token configuration), this system allows every game to be essentially the same under the hood. And, that allows for extremely rapid game development.

So many things become possible when considering a game as an entity. Defined as an Entity object, an entire game becomes an instantiated object at runtime, and can be utilized as such. Not only that, but every child object of the Game Entity in this system is totally reusable and interchangeable between other Game Entities. Imagine developing a game while the game is running. Switching and interchanging parts of the game in real-time, perhaps over a network, and observing the impact of the changes while the game is already executing. It might sound a little ‘far-fetched’, but it IS possible, and this system could evolve into exactly what I am claiming. It isn’t quite there, but it’s heading in a good direction. And, now that I’ve put the notions into your heads, come on! It’s past time to break game development out of the twentieth century!