Posted February 27, 2019 by cloudyheavengames
#object oriented programming #computer science #educational
I am still working on the Java book, but I wanted to address a topic that I find a lot of programming students have trouble with. So this short article is the first part of a write-up I will be including in the book, as I think my previous coverage still isn't quite clear in some cases. I'm making this discussion language-neutral for the most part, and there's no code samples...let's just focus on concepts for now.
A major point of misunderstanding I see with many of my students is the concept of object-oriented programming. Object-oriented programming is an approach to software design and coding, in which a program or application is based on "objects," which are entities (or "things") which have both behavior (expressed as methods or functions in a program) and data (information, stored as variables or constants in a program). These objects in a program often model real-world objects, with varying degrees of accuracy.
Furthermore, objects interact with the program and with each other in strictly defined ways, based on the methods, data, and other attributes we give to them.
I find that this whole concept is often difficult for new computer science students to grasp without a good example. Luckily, I also find that video games are a great way to illustrate it. Let's use a game that lots of people are familiar with: Nintendo's Super Mario Bros. If you haven't played the first game on the original Nintendo Entertainment System (NES), you might have played at least one of many games in the series since then, and there's also lots of gameplay videos of the series on Youtube, so hopefully, you'll be able to relate to this example.
Let me clarify, though, that this game was not created using an object-oriented programming approach and language, such as Java or C++. It was created in 1985, and as you can image, game development technology was very different from today. However, we can still look at the game from an object-oriented view, and we could create something similar using languages with which you might be more familiar.
For most of the games, including the first release on NES, the basic premise is pretty simple. You play an adventurous plumber who has stumbled into another world called the Mushroom Kingdom, which is filled with evil mushroom men called Goombas, stalking turtles known as Koopa Troopas, man-eating plants (Piranha Plants), and other villains, as well as moving platforms, bottomless pits, pipes, and all sorts of obstacles. You must make your way through the world to rescue the princess from the turtle-king, Bowser. To do so, you can run and jump over obstacles and on top of enemies, and eat power-ups that make you bigger and give you fireball power (and other powers and transformations in later games). You can also jump and bash blocks with your head; some of the blocks break, and others, marked with flashing question marks, release power-ups or coins. Some levels require you to swim. In most cases, if an enemy touches Mario, Mario will lose a life if he's in his small size, or will revert back to his small size if he's eaten a power-up mushroom. The main exception is when Mario is jumping on an enemy's head. While there's lots more detail in the game, this description is pretty much the game in a nutshell.
I'm sure you can imagine how all of these different characters and objects interact with the world and with each other. Enemies pose a danger to Mario if they touch him, but most of them can be defeated if Mario jumps on their heads, hits them with fireballs, or breaks a block while they are walking on it. In return for defeating them, Mario gets a certain number of points each time he dispatches an enemy. Mario can even use Koopa Troopa shells as weapons, using them to take out other enemies or to hit and break blocks. Blocks serve as obstacles, solid ground to walk on (for both Mario and enemies), and potential enemy death-traps, if Mario bashes a block with an enemy on top of it. Collect enough coins from blocks or just out in the open, and Mario gains an extra life. All of these objects have various purposes in the game, and interact with each other in a few strictly-defined ways.
Let's see how object-oriented design applies to this game. We have already described several different types of objects in this game, such as:
All of these, and many more, are examples of different objects in Mario's game world. And in fact, we might even think of the whole game world as an object itself!
Data and Characteristics
Now, what did we say about objects? They all have associated data and behaviors. Let's start by talking about some of the data that these objects might have. What information is associated with each of these objects in the game?
Let's take a look at the player character, to start. Some of the character information that might immediately come to mind might include:
These characteristics are pretty visible, being directly shown on the screen, so players might think of this information first. Let's dig a little further, and think of some character information that might not be so obvious at first glance:
These are just a few additional pieces of information, we won't go into a complete description, but these should give you an idea of some "hidden" data that sits behind the scenes of some of your favorite games.
Behaviors and Actions
We've talked about data, so what about behavior? What do the objects in the game actually do? Again, let's look at our player character. One way to approach this question is to ask what actions can the player make Mario and Luigi do. Here are a few, as well as what triggers the actions:
There are also some behaviors that happen to Mario that are not directly in the player's control. For example:
Your actions as the player can determine whether or not these resulting actions happen, but you can't just press a button and lose a life or gain a power-up. These things actions are still part of Mario's potential behavior, but you can only make them happen as a result of interacting with the game world according to specific rules.
To help visualize a player character, we can create a diagram that describes some of the characteristics and behaviors associated with the object. Of course, this diagram isn't a complete description, but it's a good way to think about how to organize the game components. We can also create diagrams for other game objects as well, and in fact, as a developer, this approach is a very useful, regular part of the development process.
Other objects in the game have behaviors, too, and many of them are a result ofinteracting with other game objects. Here are some examples:
So we can see that all across the game world, objects have behaviors that affect both themselves and other objects. For such a seemingly simple game (at least, in comparison to a lot of the big games that are available now), there's a lot going on in the Mushroom Kingdom; this brief treatment we've done so far doesn't even cover half of the features, objects, and actions of the game! As a player, you might not even have thought about many of these aspects, but when you're creating and programming a game like this, these are some of the details that you'd have to consider.
Hopefully, this article helped you to better understand the basic concept of objects in a program. I'll be posting a follow-up soon, and we'll continue our trip through the Mushroom Kingdom, learning more about object-oriented programming. Feel free to leave a comment or question for me!