Using C++ Instead Of Torque Script

#1 You'll want to do quite a bit more research on the purposes and uses of a scripting language within a game engine, but I will say this: scripting languages aren't added to any engine (and most engines have one) for "poor" reasons--they are extremely useful for their intended purposes.

Developing games in most of the Torque engines (Torque X and TGB being notable exceptions) is not "do everything in script"--it's "prototype in script if you wish for speed and agility", and then (or starting with if you so desire) coding c++ functionality, then exposing that functionality to script.

If you don't want to program in script, then don't--write your game code in c++ from the beginning, and any time you get a callback, remove the callback to script and handle it in c++ instead.

I will say this however--if you have any interest in becoming an indie or professional game developer, then I highly suggest you learn the benefits and advantages of scripting languages, and adapt to them--because they aren't going away, and are incredibly useful when used for the right reasons, and in the right places.

#2 TGEA uses C++ already :D

Quote: Full C++ Source Code
You receive the full source code with your license of Torque Game Engine Advanced. You are free to modify it as you see fit.

Quote: TorqueScript syntax is similar to C++, so if you are a C++ programmer, you already have a head start.

have a bit of a read here as well, has lots more info
www.garagegames.com/products/torque/tgea/features/

hope this helps u

#3 Well, I know the TGEA is in C++, but if the engine reads the script, I was wondering how I would replace that with just it reading the C++ code I put into it.

Stephen, I understand completely what you are saying, but I went into optimization a while ago and I can get loads of extra performance out of C++ when I optimize it. Thats why I've been contemplating it. The issue I have with the Torque Script is the fact that for one thing, its open source ( I'm not sure if its true, but I heard you could compile it so people can't just open and edit it ), and it also restricts how well it performs overall.

If you think the optimized C++ ( actually I break it down into assembly and go from there ) will perform about the same as the script, and there is no point, then please just tell me.

#4 Depends on what your project is ... for most, i doubt that the performace increase would be overly noticable

#5 Certainly you can (and should) optimize code once your project is complete, but it's really important to look at the entire development life cycle of any project and treat optimization as just one part of the process.

With the exception of some basic/casual games, it's just about impossible to make a quality game as one person--you'll have artists, level designers, sound designers, and a host of people that will want to interact with your builds to do their jobs--and if everything is hand written in assembly language, you'll have them knocking on your door to make minor changes 24/7/365.

Here's a concrete example: GUI's, player avatars, particle effects, sound--those are just 4 areas that have huge impact on a game's success. Do you want to be the person that has to issue 400, 600, 1000 builds a day of your c++/assembly language game so your artists, level designers, and game balancers can make their incremental changes?

I'll give another even more concrete example: I'm working on a project right now in my spare time, and spent the last 3 hours tweaking values in datablocks. Since datablocks are written in script, I haven't even opened up Visual Studio, much less had to recompile, all night--I simply tweaked my values, and restarted my prototype. I estimate I've made more than 80 tweaks just tonight.

If datablocks weren't available in script, I'd have to recompile each time--and your non-coders on your team aren't going to be able to work under those conditions.

Regarding "open source of TorqueScript"--I don't think you actually meant "open source", but more of "end user/player accessable". All you need to do is to provide your .dso files and strip out your .cs files, and the general user won't be able to look at or change your TorqueScript code (note that experienced Torque users can get around this basic level of restriction, but by the time you're ready to publish you'll have spent time locking things down more tightly).

#6 Very interesting. I do like the fact you don't have to recompile every time you make a change. And since I would have the source, I suppose I could make a different file type instead of .dso, or .cs or what not the Torque Engine reads, and modify the function to read the files. I'm sure the area where the optimizations would make the largest impact would be the actual engine itself. It looks like I'll just be using the Torque Script after all.

Stephen, do you have MSN or any form of contact other than e-mail?

#7 @ Kyle,

Since you're still in high school, my guess is that you [probably] lack the experience required to undertake the porting of such a complex engine.

Also, since you probably don't know why you'd want to use C++ (!) instead of TorqueScript, my guess is you want to stick with TorqueScript.

If you are up to the challenge (which, if you have enough sense, you shouldn't be), you probably want to do C# instead of C++. Two different beasts entirely.

Just because you've seen others post about why not C# instead of TorqueScript, doesn't mean that you should jump on the bandwagon without knowing what song they're actually playing.

#8 Torque Script is very much like C++. You shouldn't have a problem learning it if you already know C++.

#9 @mb

Exactly. Which is why I was wondering why he'd want to port it to C++ instead of C#

#10 Kyle:

I'll just chime in and say that I love TorqueScript. I've got a fairly complex little game going here, and easily 95% of all the coding I've done has been in script. Or, when needed, I've built-in functionality into the C++ engine and then called from script. I haven't felt limited in the slightest with TGB. It's really the best of both worlds, in terms of the ease of script plus the power to update the engine. If you're new to programming, there's nothing wrong with learning the fundamentals of a C++-like language via TorqueScript.

As far as optimization goes... you need to take into consideration Amdahl's Law*. Basically, not all optimization is justified. What you want to do is code up your game in script, then determine which areas have the most impact on the performance of your game. Then you optimize those areas first.

*[url]http://en.wikipedia.org/wiki/Amdahl's_law[/url]

EDIT: Do links just not work on this forum anymore? What am I typing wrong?

#11 Scripting is an incredibly helpful addition to any C++ program, engine or not. The fact that you don't need to recompile all the sources each time makes development so much faster. You also can get away with more in scripting languages since they are usually not strongly typed, and generally have a more simplified (and dare I say, more powerful) syntax. I like scripting so much that I added a second scripting language to my TGB engine :) Trust me, you really do want to use it, especially if/when your project grows bigger and needs lots of tweaking.

#12 @Chris Jorgensen

it won't link because it doesn't have .html or .htm, etc... on the end

#13 ...

#14 I've seen these types of posts several times. Instead of trying to do *everything* in C++ you should probably learn how to write expensive things in C++ and just call them from TorqueScript, if needed. Some things you may need access to from script, some things not. For those that you do, it is quite trivial to allow them to be called from script. In addition to the fact that you'd lose very little performance, you also have the flexibility to change the parameters you're sending your C++ function without having to recompile. Script provides a lot of benefits, and in cases where speed is the concern, you write your function in C++.

#15 I agree with you Ross. I want to utilize TorqueScript because I don't need to rebuild the engine and Garage has exposed 99.9% of what the engine can do, to script. It's very well written, simple and extensible.

But, I understand that some people really prefer C++. I don't use the GUI at all, I detest it. I use scene objects for buttons and static text. But, I know that many people live by the GUI.

#16 There are some issues with the GUI, but it's a pretty good system overall. However, I don't like GUIs in games much at all. I think every effort should be made to avoid them in favor of graphically representing information to the player.

I understand some people prefer C++, but it *would* be a pretty big productivity loss to use solely C++ for everything, much of which is data, or data plus logic which doesn't really fit well in C++. If the issue is disliking TorqueScript specifically, or being concerned about performance, then one could always implement their favorite language instead (Lua is a damn good choice, for instance, since it's fast and good at a fair amount of things that other languages aren't.)