December 28, 2009 by Stone
For the people who are not nerds that are reading this (all 1 of you), you may be wondering what Object Oriented Programming (or OOP) is, and why you should care. Really, you probably don’t need to care about it, but for someone like me, it represents an efficient and scalable way of writing code. The idea is that anything you might interact with in a program is actually just an existence of that type of object. To put it another way, you might have a dog. I also have a dog. If this were a program, both of our dogs would be part of the Dog class. This handles things that all members of the class Dog should be able to do, such as eat, bark, and poop. These are things our dogs have in common. If caring for your dog were a computer program, you wouldn’t be caring for just any dog, but your specific dog. My dog is named Chester. Chester is a different dog than Fluffy. They are completely separate, and have no relationship beyond both being dogs. They can have different names, different species, different eating habits, whatever, and what happens to one doesn’t affect the other. My dog is a Cocker Spaniel. His breed has no effect at all on Fluffy. In a programming sense, this makes sense. Suppose I write a game in which you catch a ball. Any time you play the game, the ball is the same, right? Now suppose I make another game in which you have a ball and you bounce it on the ground (these are boring games, but good examples).
Which sounds better to you:
a)Taking the same ball you just caught, and bouncing it on the ground.
b)Taking the ball you just caught, putting it away, getting a new one (making a new one in this case), that is nearly identical to the first one, and bouncing that.
I hope you said A. This is the big benefit to object oriented programming. I can re-use the ball anywhere I need a ball. If in a new game, I want the ball to be deflatable, I can add the property to the ball in that game without changing the rest of them (by extending it for those who know the terminology). If I decide that I got the concept of a ball wrong, and it should be square instead of round, I can change the ball class to match this, and it will become square in all the places that it is used. But still, only the one set up to be able to deflate will be able to.
I hope that made sense. In terms of the Roguelike I hope to write, this should mean that things in the game can be simplified heavily. A dragon is the same thing as a cockroach: both are part of a group called “monsters” (or maybe “enemies”). What makes the dragon big, scary, green, fire-breathing, or two-headed is all set after the program already understands that it is a monster, and has the properties of a monster (HP, experience point value, etc.). I could set up any number of monsters in this way no matter how different:
name:”giant ant”
description: “a giant ant. Quick, get a can of bugspray!”
HP: 1
exp value: 1
damage: 1
message to the player: “I’m a giant red ant. just step on me.”
and
name:”big ogre”
description:”A big mean looking giant with one eye. It is staring directly at you, as though it can see your soul.”
HP: 150
exp value: 200
damage: 100
message to the player: “ROAR! BIG OGRE CRUSH YOU, PUNY HUMAN!”
and the game can handle both of those. In this way, you can encounter a wider variety of enemies, and I didn’t have to script each one on it’s own, just fill in a few blank spots.