Once I get that upgrade to 36-hour days, I will tackle that. – Mychaeel

Legacy:Unreal Object Oriented Programming

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

Overview

History of Game Mods

It didn't use to be this easy. Modding games used to be left up to those daring enough to know how to really hack into somebody else's binaries and change them all around. In reality, game modification probably has a lot to owe to piracy and old school code demos as those were the early 8-bit hobbies of doing something with somebody else's technology. Course, that's also why I didn't do it back then, it was just too damn hard.

Current State of Game Mods

Now, the developers of the game give you acces to their code, tools to edit it and programs to recompile it (well, some of them - others require you to hunt down a copy of Visual C++ or the like). This might give some unsuspecting people the idea that creating mods and mutators for a game like Unreal to be relatively easy. Well, that's pretty dependant on what you are relating it to. It's all still programming, and some of it advanced at that.

The Unreal Way

With the Unreal engine, the hardest thing new modders need to grasp is how object oriented (OO) it is. Unreal's OO design is what makes it possible to create a whole new game without having to actually touch any of the original code. It's what allows for mutators to alter an entire game with only a few lines of code. It makes the engine remarkably versatile to play with, but also somewhat easy to break.

Object Oriented Essence

OO design assumes you are not going to write one massive piece of code to run everything in the game. Instead, discrete parts will work with each other to form the greater whole. The nice thing about this is that if you want to make discrete changes to the codebase, you only talk to the relevant parts and can (usually) ignore the rest. Unreal Tournament 2003 is even more object oriented than Unreal Tournament was, putting smaller pieces of code into more classes and having a great of use of interfaces to get and set variables and properties.

A basic principle of OO is that two classes shouldn't be doing the same thing. For instance, both the Ion Painter and the Sniper Rifle in UT2003 do very similar things - consume ammo, fire an instant shot, do damage to a target, etc. There are so many similarities that much of the basic functionality can be done with the same lines of code. Instead of duplicating this between the two classes, they share a parent class which handles most of the basics. They then extend that class, assume all of it's properties and functions, and then only add or edit what they need.

This has many advantages. It makes it much easier to maintain the basic functions for all three classes, since they share code. In my UT mod, Freehold, I ended up creating one class that handled all of the round respawn code. Any gametype requiring rounds/lives just extended that class. Since custom round code in UT was somewhat tricky, it was much more efficient to work with one class and let it fix all of it's children. It also makes the subclasses more manageable, since the only things you see in those classes is the relevant code.

The Challenge to Know It All

The main problem most people have with OO is unexpected behavior. Since you are usually not staring at all the relevant code at once, it can be easy to misjudge the end result. For instance, the XPakII had a mutator which added a SlipSuit instead of a Translocator. When activated, it would increase the player's jumping and running. Unless, of course, you use the Sprint mutator from XPak. This mutator changes your speed based on the player's adrenaline. The way Sprint works overrides the way the SlipSuit works - making the running code in it useless while Sprint is running. There's no way to realize this without looking at the code for both mutators, or of course - in testing.

That is what Unreal modders are in store for. The UT2003 codebase has a lot of fun technology to it, but expect to spend a lot of time learning this hierarchy that you are to be expanding from drifting through the code and the inevitable unexpected behavior. If this hasn't scared you off, then the rest of the UnrealScript Lessons might be for you.

This tutorial was originally part of RegularX's UTutes series.

Related Topics

Comments

Tarquin: this is a fab page, and I'd like to give it more prominence. Any ideas for a more descriptive name?

EntropicLqd: A Preface to Writing UnrealScript

Jeeptrash: Beans, Beans, The Magical Fruit0: The More You Eat The More UTut0

CH3Z: Hehe. Nice, Jeeptrash ;) Well, this is sure a nice read. A very good introduction to what OOP is as it applies to Uscript. I would say it is "How UnrealScript OOPs".

CH3Z: If it should be more of a "procedural" name that follows the nameing convention for tutorials then maybe "Understanding UnrealSript as OOP"? Gets long though. Maybe we can get Britney Spears to sing us a song about it. "OOPs UScript It Again" =P

Tarquin: Possibly rename OOP to "abstract OOP" and this page "Unreal OOP" ... though on that page Wormbo points out we shouldn't use abbrevs. Hmm...

CH3Z: Its a tricky one, it is important that the names make sense. Looks to me like there's no getting around the abbreviation of term as long as "Object Oriented Programming". I'm think that "OOP Page1", "OOP Page2" is better than the way it is. I'll ponder it more... better to do it right.
I have to wonder about having What All This Is: as the first line of this page... not very imaginative or discriptive for this being its own page. Suggestion: OOP As It Applies To UnrealScript, or anything more than What All This Is:

Mychaeel: Those pages are intended for people new to OOP. It's little use naming them in a way that those people won't even realize that's what they're looking for. It's not like they have to type the page name every time they wish to access it.

We could possibly rename OOP to "Object Oriented Programming/Concept" and Unreal Object Oriented Programming to "Object Oriented Programming/Introduction"; and maybe a tutorial that very straightforwardly takes some UT2003 classes apart (from an OOP point of view) "Object Oriented Programming/Examples". The main page "Object Oriented Programming" would explain and link to those subpages, and "OOP" would redirect to it.

Sobiwan: Being the proverbial OOP n00b, I agree "Utut" is a vague name. If I had just landed from outer space and wanted to know how to program Unreal, then "Utut" would not mean anything because its not words I am already familiar with. I think it should read "Unreal Object Oriented Programming".

Tarquin: Done

Tychon: While I'm not going to bother reverting it, since either way is correct, orientated is a word. Dictionary - Orientated Scroll down.

Ironblayde: Well I'll be damned. I didn't think it was a word at all, but my dictionary does list 'orientated,' though only as a verb, the past tense of 'orientate.' It's not listed as an adjective (as an alternative to 'oriented') like it is on dictionary.com. I guess it's time to get a new dictionary. Thanks for the usage lesson. ;)

Tarquin: It's a Brit / US thing, actually :)

Retrieved from "https://wiki.beyondunreal.com/Legacy:Unreal_Object_Oriented_Programming?oldid=8915"