There seems to be an inconsistency in the trigger system design. Surely triggers should always use events? However I find in the UT04 sources classes like 'LandMine' derived from trigger which simply change the state of the actor that touches them. This behaviour is similar to a pickup. So should a LandMine not be a trigger or maybe a pickup should also be derived from triggers? I'm confused.... [Edited by - algorhythmic on October 20, 2004 4:15:42 PM]

UnrealScript, in my opinion, has extreme internal consistency problems along with other issues (like inflexable, unmodular design) which make it a painfull system to deal with.

I think it'd be easier to make a bug-free game from scratch than to implement the same thing in UnrealScript, unless maybe you buy a license and can edit the whole design of the UnrealScript part (I curse the natives they implemented at just the wrong levels so you can't make any real design decisions).

Quote:Original post by Anonymous Poster
Care to elaborate on that? I'm currently looking at designing a similar system (as UScript) and any detailed input on it's flaws would be most appreciated. Thanks

- algorhythmic

In Unreal Tournament 2004, there is a thing called 'adrenaline', and when you gather 100 you can do special combos (that make you run faster, or make your weapons more powerfull, etc for a limited time).

In one case, they handled this correctly - there is a base class 'Pawn'(that is native) that represents players, but it has nothing related to the adrenaline system in it, and it merely handles the most basic of actions. Classes that derive from Pawn(that are not native) are used to implement this functionality that is only applicable to the UT2k4 game itself and probably not to any real mods.

In another case, they weaved bad design through several layers:
1) There inventory class(native) has functions and members that only apply to weapons
2) The weapon class(native) has functions and members that are only usefull for 'adrenaline combos'
3) The weapon fire class(native) has simmilar functions and the weapon class really just passes call to the fire classes

There is no reason for the methods to exist, so they just clutter up the namespace. In unreal, there is no function overloading (each time you override a function it has to have the same signature). All they did was create an interface that won't be used 99% of the time. They should have instead put such game-specific code into game-specific classes, like UnrealWeapon that derives from the native Weapon class.
Oh, and the parts of the code I don't like - its that 1% of the UnrealScript mixed with native code, such that they could have easily moved it up the heirarchy to the proper level, because it wasn't coded into the engine.

This isn't the best example, but it is the first one I could find.

Another poor design decision IMO is the fact that there are 2431 unorganized unrealscript source files, with many classes that do absolutely nothing (classes that just derive from something to 'rename' it so to speak). 8MB of code is just too much to go through when you're making a mod, but there isn't any clear division between Unreal Tournament code and code that mods need to reimplement in many cases, so you have to go through tons of code and do things like repleace 'xWeapon' with 'MyWeaponBase' because you want the code to work with your custom weapon class (and all the function needs is the Weapon class's interface).

Basically, keep in mind where interfaces can go, and put the unchangable ones as low as possible in the class but leave them as generic as possible so you aren't forcing strange and pointless interfaces upon people. Also, organize your code in a clean 'Required for Engine' and 'Required for Game' type of division, so people can easily see what needs changing.

Quote:i have full sources access

You bastard!