OOP for Games
Object Oriented Programming [OOP] has quickly become the standard for applications. These concepts can be applied for any project the developer is working on. There are cases where good design is better than visual quality. This is because graphics, images, layouts can be quickly modified, updated or replaced with better ones prior to release. However, it is harder to fix design problems after the project has been released. But how does this relate to games? Well in previous articles I have discussed AI methods and basic combat. These are two areas that benefit from good OOP design. Because they can be compounded on each other or extended depending on what the requirements are for the situation.
Before I can explain the potentially complex interactions it is important to understand why the classes should be extended. If the developer thinks about game design from a dynamic perspective then the follow chart is a good way to view the basic structure of all objects within the game.
This chart breaks down the hierarchy of objects within the game environment. There are more layers in a game project however this is the simplest form of the chart. The first block is the Static Object. This is something within the environment that is for visual appeal only. It typically has two behaviors which are solid and passable. This is for the collision detection and pathfinding engines to know if it will block moving objects. The next is an Interactive Object. The Interactive object has a special behavior attached to it. Some of these behaviors can be Pickup, Move, Activate, among others. These behaviors are normally things that the Player must do to make them work. The Move and Activate can be complicated since they involve the object physically doing something. This behavior could be also handled by the Mobile Object [Mob] class but because it is a simple state it can be handled here.
The Mob class is derived from either the Static or the Interactive Objects. The Mob must provide the ability to Move, and Interact with the world around it. It is typically an abstract class that has several predefined parameters that are common to all Mobs. This is because there is more to the other instances of Mobs and they need to be treated differently.
The Non-Player Character [NPC] is a mob that the player will interact with constantly. NPC’s can be venders, enemies, quest givers or any other item that the player would have complex interactions with. They also have the ability to be animated which is inherited from the Mob class. This is a critical distinction between the NPC and the Interactive Object.
The Player Character [PC] class is similar to the NPC class but because the player has more flexibility it is in a class by itself. Both the PC and NPC classes have the same base statistics however the PC may have advanced modifiers that need to be processed through its special functions. These modifiers could come from skills, abilities or equipment. The NPC does not have this benefit because it is a simple form. Because of the similarities it is possible to have the PC derived from the NPC class however it is not recommended because the two may need to be modified or tweaked differently and the potential for cross over is to great when they are inherited.
I have talked a bit about behaviors and I’m sure some developers reading this are asking “what are they?” Well simply put a behavior is an action that can be done by or to an object within the environment. Some common behaviors include Pickup, Drop, Destroy, Activate, Open, Close, Attack, Talk, and Shop. Most games provide these behaviors to the interactive and mob classes. They are often in a class by themselves which allows the developer to keep them isolated but also easily added to any object within the game. There is often a base class called Behavior and then the actions will extend it. By doing this the developer can place them within an Array that can be walked through looking for the specific action that is asked for. However, sometimes behaviors can get very complicated and sometimes will need to be broken out into different groups. This is often done with combat based behaviors because Attack, Defend, Cast, Use Item, and Use Ability each need to be treated differently and may have different parameters.
It is important to remember that games typically follow a strict hierarchy both in class structure and the environment. This hierarchy allows the game to be rendered correctly and makes it playable. The normal breakdown for the environment would be World->Zone->Area->Object. The Object can be any previously mentioned or another that is designed to be within the game. These concepts are the basis for game development and following them will produce an easy to maintain project even if it has a hundred classes, thousands of objects and millions of combinations.