If I don't use script...

#1 If you don't use tge script, to the best of my knowledge you have a pretty huge job ahead of you to port over C++ versions of the stuff that is currently done in script. If you want my advice, as a fellow C++ programmer who hates learning wonky scripting languages, just bite the bullet on this one and learn it, it's very easy for C programmers to pick up and by the time you got done porting everything over you'd be an expert in it anyway.

#2 As far as i'm aware... C++ is only for the backend, if you want to change any other stuff in TGE (which no doubt you will) you have to use torque script.

Edit: Chris beat me to it.

#3 Torque is not an SDK--it's a game engine. The game engine includes an extensive and feature rich method of allowing multiple implementation styles and capabilities to give the maximum flexibility for projects.

You -will- need to learn Torque Script as you learn the Torque application, but once you understand exactly how the execution flow between Torque Script and the C++ object classes work, you will be able to decide on your own how you implement functionality in your game.

Nothing will stop you from doing every single thing you ever want to do with Torque in C++ except for having to re-write a very large portion of how the game engine itself works out of the box. You would in my personal opinion be much better served in figuring out how and why TGE is used by design, and along the way learn when it makes "sense" to use Script, and when it makes "sense" to use C++ source code.

#4 Good luck re-compliling everytime you want to perform datablock tweaks.

Just because you know C++ better, it doesn't mean it'll be faster, considering the engine structure. The script code is responsible for triggering object creation and performing basic response callbacks.

You don't write time-critical loops in script, that's not how the engine works. You don't write the basic game logic in script. What really matters (processing inputs, calculating physics, checking collisions, playing animations) is performed in C++.

The scripts are like vertex/pixel shaders: customizable code you can insert at certain points to modify the engine behaviors. It's very easy to add new functions to many Torque classes without any hassle, and you can use that to prototype some functions that might be ported to C++ if they start to bog performance.

AI is a good example of this. Torquescript is excellent for designing, tweaking and fine-tuning player AI. After you get it working the way you want, just port it to C++ and get the better of both worlds.

#5

Quote:The scripts are like vertex/pixel shaders: customizable code you can insert at certain points to modify the engine behaviors

I think that is the best one sentence explanation of the purpose of TGEScript I've ever heard!

#6 Why are you talking about porting stuff that is already done to C++, in order to work with c++? Taken from the documentation:

"The C++ game and engine code can be called from the scripts as described above, and the game code can also call into script using the console execute and evaluate functions"

It seems perfectly possible to call script code from c++.

Also, why are you so worried about compile time? Frankly, it is not a problem at all to compile Torque Demo after making changes. This takes < 4 secs on my machine, given the changes are modest. As an alternative, you could even isolate your specific code in your own DLL, in which case you would not have to recompile Torque Demo at all. (However, I realize that this option requires some major work to interface with the native datastructures.)

I am complete noob in Torque, but given these possibilities, I dont understand how you can dismiss every thought of avoiding scripting.

I agree on avoiding scripting altogether is a complicated path to follow. But if the above is true, it should also be said, that it will not cause problems as in showstoppers or dead ends.

Or maybe I am wrong? As I said, just a noobs opinion :-).

#7

Quote:
Why are you talking about porting stuff that is already done to C++, in order to work with c++? Taken from the documentation:

"The C++ game and engine code can be called from the scripts as described above, and the game code can also call into script using the console execute and evaluate functions"

It seems perfectly possible to call script code from c++.

Sure, you can call script code from C++ easily. However, if you're not using scripts, there arent any scripts to call, eh? :) The reference to porting was mentioning that if you didnt want to use scripts at all, you would have to rewrite all the existing scripts in C++.

I think anyone who says "it is not a problem at all to recompile" has not had much experience with a well integrated scripting engine. I used to be in that camp, but after working with Torque for a while then doing non-Torque development stuff, I really really hated the lack of scripting engine. Yes, recompiles are quick. But not as quick as editing scripts. Sure, maybe for modest changes it only takes 4 seconds. Change a header thats included in a lot of files, though, and that increases. Then factor in the multitude of times when the linker decides to corrupt the executable due to incremental linking, forcing you to do a full rebuild (or if you're lucky, just a relink). Now consider that with scripts, simple changes dont require you to restart the game at all. Prototyping new ideas is also much quicker.

At the end of the day, Torque is a tool. It was designed in a specific way, e.g. hybrid script + C++, and in that way it excels. If you ignore script completely, you are not using it as it was designed and, though you can still do the same things, it will take a lot longer to write, be more prone to bugs and increase the already too long dev cycle.

My suggestion to anyone who thinks that they want to do everything in C++ is to just work with Torque the way it was designed to be used for a month. If you're experienced enough to be capable of doing everything in C++, you will have no problem adjusting. Yes, it may be different to what you're used to, and yes it may take you a while to change your habits. But, once you've put that little bit of effort in, you will never want to go back to your old ways and will start adding scripting to your other projects, before long you'll wonder how you ever lived without it. Remember the first time you used syntax highlighting ? It's a bit like that :)

T.

#8

Quote:
Sure, you can call script code from C++ easily. However, if you're not using scripts, there arent any scripts to call, eh? :) The reference to porting was mentioning that if you didnt want to use scripts at all, you would have to rewrite all the existing scripts in C++.

I am not sure why you are making this remark, because you must surely understand, that I am talking about the possibility of integrating existing scripting and Jeons future c++ code, given that he is extending, not rewriting, the engine.

Quote:
I think anyone who says "it is not a problem at all to recompile" has not had much experience with a well integrated scripting engine.

You are talking about changing classes that are referenced in a lot of files, and stating that this will result in a time consuming rebuild. Ofcourse it will. But I am talking about stuff which COULD be made in scripting (ie modest changes), so the comparison is not really fair. However, I agree that "not a problem at all" is an overstatement :-).

At the end of the day, I think you are perfectly clear on my points above, and I am perfectly clear on the difficulties in completely abandoning scripting. Jeon is not getting any wiser by us quarreling over overstatements.

#9 Ulf,

I am confused. I thought you were arguing for doing everything in C++ and ditching script altogether. Maybe I misread you, sorry :)

T.

#10 Hey Tom, sorry for giving confusing messages :-).