Which is simpler? UScript or torque script
by Patrick Rho · in Technical Issues · 01/25/2004 (2:34 pm) · 26 replies
I have a question
I just want to know which is a simpler programming language..
Unreal Script that Unreal engines use or the Torque script
ive asked many people but they 100% said Unreal Script.
but i just want to ask garagegamers what they think
thank you
I just want to know which is a simpler programming language..
Unreal Script that Unreal engines use or the Torque script
ive asked many people but they 100% said Unreal Script.
but i just want to ask garagegamers what they think
thank you
About the author
#2
01/25/2004 (4:03 pm)
I personally think UnrealScript is a bit more powerful.
#3
I've never seen unreal script.
@ Ben, just wondering what is more powerful about it?
And John, I see "IMHO" etc everywhere but I have never found out what it means? maybe most do but it seems to never make too much sense.
01/25/2004 (4:54 pm)
I wouldn't say there programming languages...I've never seen unreal script.
@ Ben, just wondering what is more powerful about it?
And John, I see "IMHO" etc everywhere but I have never found out what it means? maybe most do but it seems to never make too much sense.
#4
01/25/2004 (4:58 pm)
IMHO = In My Humble Opinion
#5
01/25/2004 (5:16 pm)
Lol, I had no idea it would be that...
#6
Anyway, TorqueScript shall someday be reincarnated, and then it'll totally rock out. ;)
01/25/2004 (5:42 pm)
UnrealScript is really well OOP-ed, it's got types, and I think it has some powerful constructs in the language - network bindings and such... TorqueScript is definitely a very good language for game dev, but I think that it's sort of like comparing C to Java... C is definitely a very, very good language but Java can be more powerful in some ways.Anyway, TorqueScript shall someday be reincarnated, and then it'll totally rock out. ;)
#8
01/25/2004 (6:19 pm)
Unreal Script.
#9
01/25/2004 (6:52 pm)
Torque script is very easy and logical, I don't know how anyone could have trouble with it.
#10
I think of the two that TS is easier than US for non programmers to hack on...
01/25/2004 (9:14 pm)
Yeah, me either. :PI think of the two that TS is easier than US for non programmers to hack on...
#11
Whether UnrealScript is more powerful or not, after Torque I can't adjust to not having access to the C++ engine source. Problems which would take 5 minutes to solve in Torque take hours of experimenting with the closed engine and trying to infer functionality from external behaviour. I can't imagine working on any engine in the future without access to the source code. I used to call it the Scripting Jail, but it feels more like the Scripting Ghetto. I generally do 95% of my debugging or more by sight-reading code, and getting on a test-debug treadmill because there is no source code to read isn't fun.
The UnrealScript debugger is broken hard (causes GPFs on breakpoints). So debugging devolves into instrumenting code, and often you'll break code in the retail code base which is difficult (or impossible) to instrument because the retail code shouldn't (or can't) be recompliled. You'll have to make a subclass of the retail class, override the method causing the problem, instrument the method, then figure out how to instantiate the replacement class instead of the original. So debugging turns into mostly trying to second guess the engine or retail code base.
The Unreal code base is very uneven, and looks every bit like an early OO project that has been hacked over several years. Poor functional decomposition, class factoring and dependency management abound. Unsophisticated OO frameworks tend to get into architectural rot very quickly, and the Unreal code base needs badly to be refactored at this point. You'll find methods which run on for pages of deeply nested conditionals (look at the AI or ScoreBoard code), broken object encapsulation, and type-dependent code (i.e. conditionals where polymorphism should have been used).
There are also latent bugs in the script execution engine. I've had it fail to call functions or cause GPFs on script code. Debugging these is a nightmare, and often results in a kludged workaround.
Both Torque and UnrealScript suffer from being homegrown languages and don't have the audience or attention or polish of languages like Python and Lua. UnrealScript tends to be very idiomatic and promote application-level functionality into language constructs. For instance, state machines are part of the language, meaning that their behaviour is part of the game engine black box and the implementation cannot be changed by mod authors. State machines should be implemented using the script language, so that scripters could, for instance, readily instrument the state machine code.
The simplicity of Torque is in many ways an advantage, because added complexity does not necessarily equate with added power (even leaving aside notions such as Turing Machine Equivalency).
It got so frustrating trying to work with UnrealScript again that I put the code back away. I hate losing sweat equity in code, but the effort wasn't worth the potential reward. Most of the frustration isn't related directly to the langauge design, but is baggage from the attached game engine and existing source code base.
I strongly recommend against using any engine where you don't have first class access to the source. In the last few years I've measured the value of my tools in terms of cost versus productivity, and that value proposition favours Torque and as part of the big picture, TorqueScript.
01/25/2004 (11:06 pm)
I wrote a lot of UnrealScript for a mod a few years back. I got curious and tried picking it up again with some old code I had abandoned, thinking I could finish it off and use it in a resume or portfolio in the future.Whether UnrealScript is more powerful or not, after Torque I can't adjust to not having access to the C++ engine source. Problems which would take 5 minutes to solve in Torque take hours of experimenting with the closed engine and trying to infer functionality from external behaviour. I can't imagine working on any engine in the future without access to the source code. I used to call it the Scripting Jail, but it feels more like the Scripting Ghetto. I generally do 95% of my debugging or more by sight-reading code, and getting on a test-debug treadmill because there is no source code to read isn't fun.
The UnrealScript debugger is broken hard (causes GPFs on breakpoints). So debugging devolves into instrumenting code, and often you'll break code in the retail code base which is difficult (or impossible) to instrument because the retail code shouldn't (or can't) be recompliled. You'll have to make a subclass of the retail class, override the method causing the problem, instrument the method, then figure out how to instantiate the replacement class instead of the original. So debugging turns into mostly trying to second guess the engine or retail code base.
The Unreal code base is very uneven, and looks every bit like an early OO project that has been hacked over several years. Poor functional decomposition, class factoring and dependency management abound. Unsophisticated OO frameworks tend to get into architectural rot very quickly, and the Unreal code base needs badly to be refactored at this point. You'll find methods which run on for pages of deeply nested conditionals (look at the AI or ScoreBoard code), broken object encapsulation, and type-dependent code (i.e. conditionals where polymorphism should have been used).
There are also latent bugs in the script execution engine. I've had it fail to call functions or cause GPFs on script code. Debugging these is a nightmare, and often results in a kludged workaround.
Both Torque and UnrealScript suffer from being homegrown languages and don't have the audience or attention or polish of languages like Python and Lua. UnrealScript tends to be very idiomatic and promote application-level functionality into language constructs. For instance, state machines are part of the language, meaning that their behaviour is part of the game engine black box and the implementation cannot be changed by mod authors. State machines should be implemented using the script language, so that scripters could, for instance, readily instrument the state machine code.
The simplicity of Torque is in many ways an advantage, because added complexity does not necessarily equate with added power (even leaving aside notions such as Turing Machine Equivalency).
It got so frustrating trying to work with UnrealScript again that I put the code back away. I hate losing sweat equity in code, but the effort wasn't worth the potential reward. Most of the frustration isn't related directly to the langauge design, but is baggage from the attached game engine and existing source code base.
I strongly recommend against using any engine where you don't have first class access to the source. In the last few years I've measured the value of my tools in terms of cost versus productivity, and that value proposition favours Torque and as part of the big picture, TorqueScript.
#12
01/26/2004 (9:49 am)
Excellent points. I spoke only from a "language amateur" perspective (ie... "ooh, that's a neat feature") - I've never worked with Unreal in depth. Your experience clearly reveals much more. :)
#13
Just my view :)
01/26/2004 (10:25 am)
I like the way how Torque script integrates with C++ code. And of course the availablitity of the C++ engine source code.Just my view :)
#14
yea i agree with the C++ codes part..
but Engine-wise, which is more powerful? torque or unrealengine?
i know that torque is a good engine for a indi game developers but nothing can beat UnrealEngine right?
01/26/2004 (11:16 am)
Hmmmyea i agree with the C++ codes part..
but Engine-wise, which is more powerful? torque or unrealengine?
i know that torque is a good engine for a indi game developers but nothing can beat UnrealEngine right?
#15
01/26/2004 (2:23 pm)
My reply was too long for this forum, so I posted it to my blog: fragball.com/b2/.
#16
Summary - UnrealEngine has better high-end graphics stuff. But is that really a good thing when you give up a lot of control over your engine..?
01/26/2004 (3:25 pm)
Excellent thoughts, Brad.Summary - UnrealEngine has better high-end graphics stuff. But is that really a good thing when you give up a lot of control over your engine..?
#17
and I found out that Unreal Engine offers A LOT better graphics and lighting as well as advanced shadowing.
For networking, torque is little bit faster and can hold more little more people, but they are basically similar
Unreal Engine also contains Karma Physics engine which is very helpful in developing a game
AI for Unreal Engine is crazy...they offer so much..
and unlike Torque script, unreal script suits me more, in a sense that it is much similar to Java and it conveys idea of OOP strongly. Even though you do not have that much control, I would still prefer Unreal Script over Torque because of its easy of use and features.
01/26/2004 (7:47 pm)
I've researched quiet a bitand I found out that Unreal Engine offers A LOT better graphics and lighting as well as advanced shadowing.
For networking, torque is little bit faster and can hold more little more people, but they are basically similar
Unreal Engine also contains Karma Physics engine which is very helpful in developing a game
AI for Unreal Engine is crazy...they offer so much..
and unlike Torque script, unreal script suits me more, in a sense that it is much similar to Java and it conveys idea of OOP strongly. Even though you do not have that much control, I would still prefer Unreal Script over Torque because of its easy of use and features.
#18
Makes sense..but most commercial games use Unreal...
is there any reason for that?
01/26/2004 (7:56 pm)
I just saw what Brad posted...Makes sense..but most commercial games use Unreal...
is there any reason for that?
#19
But then again, I havent seen any good games using the unreal engine that didnt have access to the source code (mods or TCs).
Also the fact I can choose to sell a game I make with Torque is worth it ;)
01/26/2004 (8:14 pm)
TorqueScript is as OO as you want it to be, its just not forced onto you. I like both of them, however, the ability to edit a script and recompile it from the engine without having to restart is a bonus that I love about TorqueScript. That and you can just add a variable without having to go back and declare types and such. To me, scripting is experimentation and I want to be able to test an idea out quickly. Overall though, I think its easier to make a game with Unreal due to the engine being more complete. But then again, I havent seen any good games using the unreal engine that didnt have access to the source code (mods or TCs).
Also the fact I can choose to sell a game I make with Torque is worth it ;)
#20
I take your quote 'most commercial games use Unreal' to mean 'more AAA commercial games use Unreal than Torque'. udn.epicgames.com/Powered/WebHome -- I don't know what a similar list would look like for the Tribes engine that Torque is based on.
Lately Unreal-powered games have been provoking a mixed reaction from the industry, the exception being the Tom Clancy series from Ubisoft, which gets great reviews regularly. UT2003 is almost dead just a year after it's release. Legends Entertainment, most lately the developers of Unreal 2, recently was disbanded by Atari/Infogrames. Digitalo, developers of Devestation, are now defunct. Many considered Deux Ex: Invisible War to be a disappointment. I think at least some developers used to license the Unreal engine as a marketing device -- being able to say that your game was Unreal-powered moved boxes a few years ago. The Unreal engine might not be the best choice for a mod, or you might at least wait until UT2004 releases in a few months to see if the franchise is going to break out of its current funk.
Also, don't take my comments about the Scripting Ghetto lightly. You have third-class status as a mod developer (no technical support, limited access to technical information), and cannot take commercial advantage of your project in the future. Most neophyte mod authors don't realize the amount of promotion it takes to popularize a mod -- it can take years to build an audience. But, it's really not your audience -- it belongs to the developers or publishers of the original game. Chances are that you'll end up with little or nothing in exchange for all the sweat equity put into a mod. If it is purely a lark, purely for your own amusement, that's okay -- but it seems most mod teams have an unrealistic expectation that they'll eventually be able to go commercial.
01/26/2004 (9:21 pm)
If you are strictly interested in modding (which you must be, if you are considering the Unreal engine), Half-Life mods have a larger potential audience, and Valve is intending to open Steam to mod authors so that they can sell their mods. BF1942 mods get a lot of attention, but the game offers no scripting language or real SDK. Call of Duty offers a scripting language, but I haven't seen a viable mod community form around the engine yet (it is mostly an improved Quake 3 engine). There are plenty of choices even if you are determined to mod an existing game.I take your quote 'most commercial games use Unreal' to mean 'more AAA commercial games use Unreal than Torque'. udn.epicgames.com/Powered/WebHome -- I don't know what a similar list would look like for the Tribes engine that Torque is based on.
Lately Unreal-powered games have been provoking a mixed reaction from the industry, the exception being the Tom Clancy series from Ubisoft, which gets great reviews regularly. UT2003 is almost dead just a year after it's release. Legends Entertainment, most lately the developers of Unreal 2, recently was disbanded by Atari/Infogrames. Digitalo, developers of Devestation, are now defunct. Many considered Deux Ex: Invisible War to be a disappointment. I think at least some developers used to license the Unreal engine as a marketing device -- being able to say that your game was Unreal-powered moved boxes a few years ago. The Unreal engine might not be the best choice for a mod, or you might at least wait until UT2004 releases in a few months to see if the franchise is going to break out of its current funk.
Also, don't take my comments about the Scripting Ghetto lightly. You have third-class status as a mod developer (no technical support, limited access to technical information), and cannot take commercial advantage of your project in the future. Most neophyte mod authors don't realize the amount of promotion it takes to popularize a mod -- it can take years to build an audience. But, it's really not your audience -- it belongs to the developers or publishers of the original game. Chances are that you'll end up with little or nothing in exchange for all the sweat equity put into a mod. If it is purely a lark, purely for your own amusement, that's okay -- but it seems most mod teams have an unrealistic expectation that they'll eventually be able to go commercial.
Torque Owner John Vanderbeck
VanderGames
What I can say is that TorqueScript is pretty easy to use, once you learn but many peopel have trouble learnign due to lack of documentation. This has vastly improved recently, and Torque is, IMHO, pretty much to the point where its relativly easy to learn.
Personally, i'd pick Torque over Unreal hands down because or a few factors.
1) Flexability. Let's face it. What's more flexible; A 3d engine with source code that you can do whatever you want to, or a game that you mod by making scrpits? Duh. Having the source is always better than simply hacking at a game.
2) Price. Torque cost me $100 bucks. One less trip to the movies a month for a year and its paid. Unreal if I want the source (Like I get in Torque) is going to cost me a heck of a lot more.
3 License. If I mod Unreal I can't sell it. Period.
Just my 2 cents on the subject, though I know I drifted. The problem is I see no comparison. Modders need to start realizing how much more is out there for them.