OO does mean Object Orientated, yes. How to explain. Oookay, this is gonna get long...
In most programming languages, you can define your own "types". Then you can declare variables of that type (which store that sort of information, which use your "template", however you want to look at it). VB will do this.
Now, objects contain methods - code - as well as data.
Don't understand? A record (NOT an object) is a "type" that contains ONLY data. Like:
MyType = record
Age: Integer;
DOB: Date;
Height: Integer
.....
etc.
etc.
So then you can declare variables of type "MyType" , eg. Person1: MyType, Person2: MyType, and do
Person1.Age = 23
or
Person2.Height = 100
or whatever.
Now, with objects, your type could also have code (methods) in it. So as well as that, you could also do
Person1.ShowDetails()
which would run some code, ShowDetails, associated with that type which - presumably - popped up a nifty little window showing their details.
I think the later versions of VB can do this, too. It's still not full object orientation.
With proper OO, your type can "inherit" from another one. For example, I could do
MyNextType = class(MyType)
end;
and I've got a new type which AUTOMATICALLY has all the variables, methods (code), and so on that MyType had. And I can add more in, of course.
Now the clever thing is, say some code is expecting me to give it a MyType variable. I *could* give a MyNextType and it'd still work perfectly OK - after all, it still has all the data and code that MyType does! So it works fine.
This is cool, then. You can have general types that all your code works on, and then a few more specific cases you store EXTRA data, methods, and so on - but all your old code will still work with it, since you've just *added* stuff on. All the data the old code needed is still there in your new data type.
This STILL isn't OO though! For PROPER OO, you need abstract and virtual methods.
What THIS means is: Say I've got a type, TPerson (like the MyType I showed above). It contains these properties:
Name
Age
Height
And it contains these methods (code):
ShowDetails()
GetTelephoneNumber()
(presumably, ShowDetails pops up a window with details in it, GetTelNo looks up their number in a database or something. Who knows. Who cares.)
Now, say we declare ShowDetails() to be ABSTRACT. What THIS means is, we don't write any code for it! Seems silly? All will be revealed .... all we define is the name of the method and what parameters it takes (any data we need to give to it, for it to work).
Now, we declare two NEW types, TCustomer and TEmployee. They obviously both "inherit" from TPerson (they're more specific examples of a Person, so they need everything a person has - plus some more specific data, like Rank for an employee, or CustomerNumber for a customer).
Now, in both of those, we now write code for the ShowDetails method! The employee ShowDetails obviously needs to do different stuff to the customer one, so each has its own version.
Now comes the clever part. Say you're dealing with a person. You've got a variable P of type TPerson. What you can do now is call P.ShowDetails(). But Person doesn't have a full ShowDetails() method, I hear you say! Well, this is the clever part. You could actually have an Employee variable here - since Employee is a kind of TPerson! Or you could actually have a Customer variable. Now, the language will either call the Employee or the Custom ShowDetails() code for you. You don't have to tell it which one to use! You don't have to test, "oh, what type of person is it, well, if it's this type, run this code, otherwise, run this code" - the computer will figure it out for you. In fact, YOU don't need to know exactly what type of Person it is at all. The computer will figure it out even if all you know is "there's SOME sort of Person here".
I hope you understood that 
I probably didn't explain it very well. But trust me, OO is VERY useful. The Remake engine relies on it for practically all of the rendering (display) and input code, and believe me, it saved me hours of work.
