Google+

Monday, August 29, 2011

Let's Make A Game! Episode 13: Let's Stay Classy

We've been going through the tutorial so far. It's interesting stuff, but it's not teaching us everything we really need to know.

I've been having this major mental block when it comes to "object-based programming." What are we referring to? Is it just splitting a big program into a lot of little programs? What are objects?
There are a lot of tutorials, but a lot of them talk in "programmer speak." You ask something simple like, "What's an instance?" and you get an answer like "An instance as an object as defined by a class."

Then you ask, "What's a class?" and get, "It defines an object."

"What's an object?" "It's defined by a class."

And around we go. The problem is that there are lot of programmers who are really good at programming but by nature aren't teachers. That's OK. They're not supposed to be.

After pulling and prying the information I need out of a programmer, I think we have an analogy that might help explain object-based programming without getting horribly technical.

Let's say I want to drink coffee. I would have to define what coffee is in order to drink it, so first of all, it's a beverage. The beverage is kind of like our class: We're defining the parameters of what we're working with, or defining our object.

Now, coffee is a type of beverage, but how does it differ from other beverages? We'll have to define that too. Now we've defined another class, this time called "Coffee."

So now we've defined Coffee, but what do we do with it? In order to actually drink it, we have to make some. Using our definition of coffee that we've created in the "Coffee" class, we put coffee grounds and water in a coffee pot and make our own pot of coffee.

We have now "instantiated" the coffee, or made our own separate "instance" of coffee, which we'll call "coffeePot". Now we pour the coffee in our cup. We've instanced the coffee again, using "coffeePot" to make "leesCoffeeCup."

Coffee has very specific characteristics. I wouldn't be able to take grass clippings and vodka and throw it in a coffee pot, because that's not coffee. However, there is a little room for modification within the "Coffee" class.

For example, if I want to make my coffee a little stronger, in the instance of "coffeePot" I'll change the variable "coffeeGroundAmount" to a little larger than the normal amount. If I want weaker coffee, I'll take "coffeeGroundAmount" down a notch.

Those variables now affect my second instance of "leesCoffeeCup." If I've made the modifications in "coffeeGroundAmount" in the "coffeePot" class, now my coffee will be a little different. However, now that I've instantiated the coffee into my coffee cup, I can't really go back to the previous instance of "coffeePot" from this instance of "leesCoffeeCup." I can only instantiate another cup of coffee into "leesSecondCoffeeCup" from "coffeePot."

This makes it easier to program for a variety of reasons. For example, if I want to modify coffeePot next time I make Coffee, all I have to do is change the coffeeGroundAmount in THAT instance.

Finally, when I decide what I want to do with the coffee, I'll use the method drinkCoffee. This method explains that I'll pick up the coffee, put it to my lips, and tilt the cup back into my mouth until my mouth is full of coffee, then swallow it.

You still with me? Good, because here's the recap:
  • Coffee - Class, which defines our object.
  • coffeePot & leesCoffeeCup - Instance, which is this specific usage of our Class, Coffee.
  • drinkCoffee - Method, where I explain what I'm going to do with the instantiated Coffee.
This explains, then, how a game like Warcraft III works. In Warcraft III, you have enemy units. The unit type is the class, but the specific units you see onscreen are all instances of that class. The method explains that they're going to go attack enemy units.

In Super Mario Bros, "Goomba" is a class. The goomba you see walking across the screen is an instance of that class. The method is that he'll walk in one direction until he's killed or until he falls off a cliff. Then that instance is removed.

Now that I have all this information sorted out, we'll hopefully be able to focus on the big picture instead of worrying about things like "my frigging character is off the screen."