Object oriented programming in Game development
Introduction:
Object-oriented programming (OOP), in its most basic sense, is a programming style used to organize code. Video games can run anywhere from a few thousand lines of code millions of lines of code long . You can see why it’s so important to write code that can be easily modified and maintained. Programming styles, such as OOP, help to organize code in such a way that it becomes easier to maintain and modify.
OOP helps organize code by organizing it into what are known as objects. Objects hold information about state and behavior. States are the characteristics of the object, or the words you would use to describe it, and usually take the form of is or has descriptors. A computer is either on or off, a chair has four legs, and you have a name. Behaviors are the things the object can do, or the actions the object can perform, and are usually verbs that end in ing.
As stated earlier, OOP is helpful because it helps create maintainable code — code that is understandable, adaptable, and extendable. It also helps create reusable code by following the DRY (Don’t Repeat Yourself) method: write the code once and then reuse it, rather than copying and pasting. The OOP way of thinking also lends itself well to directly translating real-world objects and interactions into code.
There are some specific features that object oriented programming provides by which the we can see huge advantages of it in game development. Let’s see them one by one
1.Cohesion:
Cohesion is the principle of being or doing one thing well. In other words, cohesion means grouping together code that contributes to a single task. Considering game development there is untold rule is that don’t try to do too many games in one package. Individually, those each could have been good games. Together, they fought with each other.
The same rule applies to object-oriented programming. Each object should only have one responsibility. Every behavior of that object should only do one task. Any more than that and you’ll have a much harder time making changes to the code.
Code that is organized by functionality and does only one task is said to have high cohesion. Highly cohesive code is reusable, simple, and easy to understand. It also creates objects that are small and focused.
2.Coupling
Coupling is the principle of “separation of concerns”. This means that one object doesn’t directly change or modify the state or behavior of another object. Coupling looks at the relationship between objects and how closely connected they are. A Relations Diagram is a great way to visualize the connections between objects. In such a diagram, boxes represent objects and arrows represent a connection between two objects where one object can directly affect another object.
A relation diagram
A tightly coupled system
A loosely coupled system
other objects (also known as a ripple effect). Tightly coupled code is also harder to reuse because it can’t be separated.
A common phrase you’ll hear is “strive for low coupling and high cohesion”. This phrase is a helpful reminder that we should strive for code that separates tasks and doesn’t rely heavily on each other. Thus, low (or loose) coupling is generally good, while high (or tight) coupling is generally bad.
Encapsulation helps to create code that is loosely coupled. Because the details are hidden, it reduces the ability of other objects to directly modify an object’s state and behavior. It also greatly helps when you must change the data type of a variable. Lets say you decided to use string to keep track of time in “hh:mm:ss” format. After awhile, you come to realize that an int representing seconds might be a better data type for time. Not only must you change the data type in the object, but also every time you referenced the object’s time in the entire program!
Encapsulation can help to create more maintainable code by helping to prevent the ripple effect of code changes. It also helps with creating loosely coupled code by reducing direct access to an object’s state and behavior.
Abstraction is the principle of generalization. This requires that we move from a specific instance to a more generalized concept by thinking about the most basic information and function of an object.
This may sound a bit strange, but we are already familiar with the concept of abstraction. For example, if I say the word “car”, what do you think of? Odds are we weren’t thinking about the same car. I was thinking about a black Mustang Boss 302, which is a specific instance of a car. Neither of us were wrong because the word car is a very general concept of a vehicle that we use for transportation (or recreation in my case).
Thus, abstraction takes many specific instances of objects and extracts their common information and functions to create a single generalized concept that can be used to describe all the specific instances as one.
Abstraction is helpful because it strips everything down to its most basic principles. This can help when encapsulating functionality of an object because it can help identify the important information that should be made visible and the unimportant information which can be made hidden. Abstraction also helps with the Don’t Repeat Yourself principle. By taking what a group of objects have in common and abstracting it, we can help prevent redundant code in each object which in turn creates more maintainable code.
It is the principle of class hierarchy. It is the ability for one object to take on the states, behaviors, and functionality of another object. A real-world example of inheritance is genetic inheritance. We all receive genes from both our parents that then define who we are. We share qualities of both our parents, and yet at the same time are different from them.
Objects in OOP can do the same thing. Parent classes can have child classes (also known as super classes and subclasses respectively) which can have the same properties of the parent class, and can define new states, behaviors, and functionality of their own.
As you can see, inheritance can greatly help reduce code redundancy between similar objects by taking what those objects have in common and putting them in one place. This also creates more maintainable code because it helps to comply with the principle of DRY and to prevent the ripple effect in code changes. If all of this seems familiar, it’s probably because abstraction had very similar benefits (as well as most of the other principles of OOP). Abstraction is closely related to inheritance as an abstracted class can be used as a superclass to create subclasses. The only difference between an abstract class and a normal class is that an abstract class cannot be used to create an object.
How to apply all this:
Let’s suppose we are creating space adventure game where we are in one ship and our ship has been stuck into a asteroid belt. We just have to cross this asteroid belt without getting damage. So we will have following functionalities :
· Rotation
· Momentum
· Thrust
· Turning
· Moving
· Firing
· To understand the cohesion we can have a class called motion and in that we can turning, moving & firing. Now all our motions are in under single class from we can access them anywhere.
· After that to see how coupling works, we will have our ship, its bullets and asteroid they are interconnected with each other like we can destroy asteroids by bullets or by getting hit by asteroid ship will get damaged. So while writing a code we have to careful otherwise our game will end with very tightly coupled system.
· To have the ship fire a bullet, all you would have to do is call ship.fire How the code implements firing a bullet is not important, because all we care about is firing a bullet. This way, if you want to change the code to fire a laser blast instead, you just have to change the method fire( ) and not every call to ship.fire this is how encapsulation actually works
· To start applying abstraction to Asteroids, think about its objects common elements that all the objects share we are able to abstract those elements into a more generalized class. For example, a ship, an asteroid, , and a bullet would all share the same behavior for moving across the screen. You could abstract this behavior into an abstract class that holds the common qualities needed to move an object. These qualities would be states such as position and velocity, and the behavior of moving.
· Considering inheritance, the code needed to move the ship is taken care of suppose in the movable abstract class, so we can remove it from the ship class. All the other objects for Asteroids could also inherit from the movable class, making it extremely easy to change how to move an object.
So this is how OOP becomes best choice to game developers with all its features and provides best experience to users
