Jump to content
  • Advertisement
Sign in to follow this  
algorhythmic

[UnrealScript] Inconsistency?

This topic is 5396 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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]

Share this post


Link to post
Share on other sites
Advertisement
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).

Share this post


Link to post
Share on other sites
Sounds more like an easier way of doing it that a design flaw, since pickups ARE events that change the state of the pawn. :D
It's what they want isn't it? As long as it works, who cares?
I haven't done very much UScripting tho, so I couldn't tell you if there are any inconsistencies.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
I curse the natives they implemented at just the wrong levels so you can't make any real design decisions
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

[Edited by - superpig on September 26, 2004 6:59:00 AM]

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
I do work with UnrealScript now for 4 years, and i don't have any pb with the script...
BUT :
1• Use a good .uc editor like WotGreal (shareware), i used it since i started on UScript and it's really worth it (Don't think about modding .uc files without it).
2• Don't blame the existing games structure, it's hard to update all the engine sources, so we do prefer create our own content, well distinguished from engine content (thus the sub-classes just there for declaration) as this have NO IMPACT on performance.
3• as the native functions need to be in native classes, they're often found in their parent classes when their own is not native, as it's easier than to convert all classes to native (and this have a memory impact on the game). it's the way to code script, you must attune to it (or else you'll find the script inconsistent like you do, maybe it is, but there's so much to do with it).

The UScript is only a good OO finite state machine with engine events handling , you can do whatever you want with it (I do, of course i have full sources access, but you can overload so much stuff that you can make your own game using an UT2K4 base).

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!