My program doesn't have bugs. It just develops random features.

Legacy:UnrealScript For Non-Programmers/OOP For Nonprogrammers

From Unreal Wiki, The Unreal Engine Documentation Site
Jump to: navigation, search

This page is part of the UnrealScript For Non-Programmers tutorial which is broken down into a series of pages. It may not make sense if you haven't been following this series, then again, you never know, you might gain something from it.

What an OOP Program is and What it Does

First of all a program is a file (data) that changes other data. Your operating system (perhaps DOS) is a program. An example of the data that it might change would be the data that the computer is sending to your monitor. Your program might change that data from being no data sent to the monitor (resulting in blank screen) to data being sent to the monitor telling it to light up certain pixels on the screen in a pattern resembling letters that spell out "Hello World". An image file is data but it is not a program. While its data is a pattern of pixels to light up on the monitor, which will resemble a picture of something, that data alone changes nothing, therefore the image file is not a program. A program would change the data sent to the monitor to be the data that the image file contains. In an OOP program, subclasses of class objects change (override) data in their parent class and act as extensions of the program itself. This will become clearer as you read on.

Programs execute one line of code at a time in a linear fashion. Starting from the first line of code the program will continue to the second line of code and then the third, unless one of those lines of code instruct the program to jump to another line and execute it. If perhaps the fourth line of code instructs the program to execute the 27th line of code the program will do so and then resume execution of its code from line five. Line 27 of the program's code may be the beginning of a block of code that consists of 5 or 6 lines of code. All 5 or 6 lines would be executed before the program returns to line 5 to continue from there. One of those 5 or 6 lines of code may instruct the program to jump back up to line 14. The program will then execute line 14 and all lines that follow within the block that begins at line 14 and then return to the next line of the block that began at 27 and finish that block before returning to line 5.

Rather than bounce around up and down a list of instructions an Object Oriented Program will jump a lot of the time to code within a separate modular piece of the program. This modular piece of the program, perhaps a class file, is compiled and embedded into the program and becomes kind of a file inside of a file. An Exe file that appears to be one file that is the program may actually be made up of individual modules and compiled into one file. Just as the program would jump to line 27 of its code, a line of code in an OOP program may call (tell the program to jump to) code within another module. That module is kind of like one of the blocks of code mentioned earlier. Now when you look at the code you can see the core of the program in one module, and specialized sections of code contained in separate modules that might be extended even further other modules that hold even more specific code related to the module that they are extending.

Use your imagination. Depending on the type of program you are writing, you might imagine the modules representing different "real life" objects. For example, if you are writing a business program you may imagine different modules being different departments within the same office, each having specific duties where all departments work on modulated aspects of the office's one project. If you were writing a game some of the modules would be items and some would be players. Still yet some other modules in a game would be physics of world the game takes place in and some would be smaller components of one module that is an item in the game (like a bullets for a gun or guns for a player). If all of the code in the program was one long list of code to be executed in linear fashion it would be very hard to keep track of while you were writing it and almost impossible to fix or change the code later. That's how it used to be done, but we know better now. Another reason for programs being OOP is that you can actually use these modules in other programs that you write and save a whole lot of time for yourself.

An OOP program might have an object named "DoDraw" built into it that specifies pixels to light up which creates an image with a black border and an effect applied to the image. That object may have another object named "DrawDogs" linked to it that extends "DoDraw" and specifies an alternate border color or alternate image or alternate or alternate effect. This OOP "Program" is "Oriented" to evaluate a hierarchy of "Objects". When it is time for this program to "DrawDogs" it will see that "DrawDogs" extends (is a branch of) "DoDraw" and will execute all the commands in "DoDraw" with the data in "DrawDogs" overriding some of the data in "DoDraw". You see here that "DrawDogs" has extended "DoDraw" to do a more specific task.

Who Begat Who? Further down, the branch of the hierarchy that starts with "DoDraw" and branches off to "DrawDogs" may be even further extended by an object named "DogsPoodle" which overrides data in "DrawDogs" to draw a specific class of dog like a poodle, thus extending "DrawDog to do a more specific task. There may even be subclasses extending "DogsPoodle" such as "PoodleFrench". In effect, when it is time for the program to draw a french poodle, "PoodleFrench" will inherit all the code from "DogsPoodle" which inherits all the code from "DrawDogs" which inherits all the code from "DoDraw" therefore allowing "PoodleFrench" to draw a specific picture with specific borders and effects. In OOP when an object is a subclass of another object and therefor has access to all of its parents code, this is called inheritance.

So, What's In It For Me? If you were to write a mod for this program it might be to add a new class of dog, perhaps "DogsBull" or maybe you want to add a new class of animal to "DoDraw", perhaps "DrawCats". Can you imagine a subclass that would extend "DrawCats"? How about a subclass that extends "DogsBull"? For that matter, can you imagine another subclass extending "DoDraw"?

Consider how the hierarchy of this program would look.

Object
   +-SomeSubClass
   +-AnotherSubClass
   |     +-SubClass of AnotherSubClass
   |
   +-DoDraw
   |     +-DrawCats
   |     +-DrawDogs
   |     |     +-DogsBull
   |     |     +-DogsPoodle
   |     |         +-PoodleFrench

If you can imagine these modifications then you can imagine a new subclass to extend "Weapon" which extends "Inventory" which extends "Actor". It would be a specific type of weapon that the actor has available to add to its inventory.

One such subclass is "FlakCannon". What subclass does "FlakCannon" extend? See if you can answer that question before reading on. If you said Weapon, you are correct. So the first line of code that makes the FlakCannon exist in UT is simply:

class FlakCannon extends Weapon;

Just as a poodle has inherited characteristics from its parent that make the poodle what it is, part of an OOP program can inherit characteristics from its parent class. Just as the poodle may have a different personality than its parent, a part of an OOP program may override some of the characteristics that it has inherited. Just as a poodle is a class of dog, a dog is a class of animal, an animal is a class of life form, a life form is a class of "thing", makes a poodle a specific "thing", a class object in an OOP program is a subclass of an object higher in the hierarchy of objects within the OOP program.

Where should I go from here?

If this cleared anything up for you then you probalby have more questions to go with your new insight. Well if you go back to UnrealScript Lessons in the same section you found this tutorial, "Introductions", there are a few more on OOP there that might make more sense to you now. If they don't, don't sweat it, it'll come as you get more involved in this and you can always look at them again from time to time as you go.

If you've had all you want of OOP for now, click back to UnrealScript For Non-Programmers and read "What does it mean to 'Modify' a game?"

Note:Using this Wiki, you should notice and get used to a section that is on most pages like the following section, "Related Topics", it's what you'll find rather than this "Where should I go from here?" section you just read. For more tips on Legacy:UnrealScript For Non-Programmers/Using UnrealWiki, ummm nuf said. There is also a link on that page to a similar page for more tips.

Related Topics

Discussion

This tut is going nowhere. I (the author) will not be contributing to it anymore, and it needs much much more. No one else is contributing to it, so it's a waste of space and an eye-sore.[DeleteME]

Retrieved from "https://wiki.beyondunreal.com/Legacy:UnrealScript_For_Non-Programmers/OOP_For_Nonprogrammers?oldid=9017"