Can I make an entire game with Torque using only C++?
by Daniel Azkona Coya · in Technical Issues · 06/28/2005 (7:12 am) · 11 replies
Hi everyone!
I've bought Torque one year or so ago...
I don't use it yet because script is not so comfortable for me, beacuse I'm use to work with C++.
I know that everyone can make his own classes on C++, and then call it from scripts. But I want to know if there is a way to do entire game only using C++.
Thank you very much!
I've bought Torque one year or so ago...
I don't use it yet because script is not so comfortable for me, beacuse I'm use to work with C++.
I know that everyone can make his own classes on C++, and then call it from scripts. But I want to know if there is a way to do entire game only using C++.
Thank you very much!
#2
Yes, but you'll miss out on the on-the-fly benefits of scripting. There's nothing that says that you *have* to use scripting, but it's a powerful solution that just about every engine on the market currently utilizes because of the benefits. It allows you to choose your battles, applying game logic in script while core engine and platform features in C++.
06/28/2005 (7:26 am)
Standard answer:Yes, but you'll miss out on the on-the-fly benefits of scripting. There's nothing that says that you *have* to use scripting, but it's a powerful solution that just about every engine on the market currently utilizes because of the benefits. It allows you to choose your battles, applying game logic in script while core engine and platform features in C++.
#3
06/28/2005 (3:19 pm)
It means the difference between getting started right away (using script) and getting started in 2 years (converting the scripts into C++ equivalents).
#4
Matthew, I've read the doc and it seems to say that is pretty similar programming with scripts or with C++, why do you say that we will spend 2 year developing? where do you see the difficult?
It's important for us, beacuse all of our programmers are use to code using C++.
My idea is to make one "framework" layer so other programmers of my team could use Torque with C++ on a easy way. Do you think that this is not possible?
07/01/2005 (12:36 am)
Thank you for all the answers!Matthew, I've read the doc and it seems to say that is pretty similar programming with scripts or with C++, why do you say that we will spend 2 year developing? where do you see the difficult?
It's important for us, beacuse all of our programmers are use to code using C++.
My idea is to make one "framework" layer so other programmers of my team could use Torque with C++ on a easy way. Do you think that this is not possible?
#5
This is the easy part....tedious (there are about 900 ConsoleMethods and ConsoleFunctions you would have to touch by hand)...but easy. You might even could skip this part and just jump directly into coding with C++ but that would require giving up all of the functionality that has already been implemented for you in script currently (which is considerable) and reimplementing it yourself. Forexample, the mission and terrain editors are fairly essential and core pieces of Torque and exist largely in script. Those alone would take me (who is already familiar with the code) a good month to port entirely into C++.
Next you are going to have to address the event driven nature of the script and move that functionality into C++ (and C++ isn't necessarily the most event driven of languages without a lot of structure and framework layered on top of it...which is what the scripting language does). This won't be too bad because those events are being driven by C++ at some level but it is going to get hairy moving the callback functions that are already implemented in script back into the engine. Some of these are fairly trivial (like ShapeBase::onDismount()) so could be ignored until later but others are core to getting a game up and running with Torque (GameConnection::onClientEnterGame()) and will have to be moved right off the bat. This is going to require you to become super intimate with every aspect of what the current scripts are doing and will not have clean ways to port straight back into C++ which means a *lot* of work on your part.
After that you get to deal with how to handle your data. Nearly every single piece of data (art assets - models, textures, sounds; configurable options - prefs, keybinds; customizable values - datablock parameters like how fast the player runs, spawn positions, which shape file to use with a vehicle, etc) is instantiated and set in script. You would have to move all of this over into C++ in some kind of structure/framework that makes sense which is not going to be fun.
Then you get to address issues like how to handle saving out a mission file (which is a script file)...do you dump it to a header...do you manually convert it to C++? What about the gui's (also scripts)? Are your artists going to have to code them in C++ and recompile everytime they want to move a button or change its text? Or do they just mock them up in Photoshop for you and the coder then become responsible for converting them when they have the chance?
But wait...you could leave the missions, the gui's, the datablocks, the keybinds, the mission loading, the server browser, the options menu, the prefs, and the editors as scripts so that your designers and artists can easily edit them. But then some artist on your team comes along with a model with ambient animation that he wants it to play automatically when the mission loads and he has to wait until one of your overworked coders has time to add that code functionality to the engine and even then it is tied to a specific animation name. What if he wants it to switch animations when a switch is thrown? More waiting on the coder...wouldn't it be handy if whenever a model is instantiated in the world it would automatically call the script function onAdd() and in there the artist can simply call %this.playAnimation("startup") and then when the player throws a switch a script function called onSwitchFlipped() is called where the artist puts in %this.playAnimation("cycle").
That would be really handy, wouldn't it? ;)
07/01/2005 (1:34 am)
You'd have to go through every single ConsoleFunction and ConsoleMethod (macros for exposing C++ to script) and convert them into pure C++ calls. Some of these would be trivial since they just pass the data right on through to the equivalent C++ function. Others involve a lot more code and you would have to create/copy this over into the properly named functions.This is the easy part....tedious (there are about 900 ConsoleMethods and ConsoleFunctions you would have to touch by hand)...but easy. You might even could skip this part and just jump directly into coding with C++ but that would require giving up all of the functionality that has already been implemented for you in script currently (which is considerable) and reimplementing it yourself. Forexample, the mission and terrain editors are fairly essential and core pieces of Torque and exist largely in script. Those alone would take me (who is already familiar with the code) a good month to port entirely into C++.
Next you are going to have to address the event driven nature of the script and move that functionality into C++ (and C++ isn't necessarily the most event driven of languages without a lot of structure and framework layered on top of it...which is what the scripting language does). This won't be too bad because those events are being driven by C++ at some level but it is going to get hairy moving the callback functions that are already implemented in script back into the engine. Some of these are fairly trivial (like ShapeBase::onDismount()) so could be ignored until later but others are core to getting a game up and running with Torque (GameConnection::onClientEnterGame()) and will have to be moved right off the bat. This is going to require you to become super intimate with every aspect of what the current scripts are doing and will not have clean ways to port straight back into C++ which means a *lot* of work on your part.
After that you get to deal with how to handle your data. Nearly every single piece of data (art assets - models, textures, sounds; configurable options - prefs, keybinds; customizable values - datablock parameters like how fast the player runs, spawn positions, which shape file to use with a vehicle, etc) is instantiated and set in script. You would have to move all of this over into C++ in some kind of structure/framework that makes sense which is not going to be fun.
Then you get to address issues like how to handle saving out a mission file (which is a script file)...do you dump it to a header...do you manually convert it to C++? What about the gui's (also scripts)? Are your artists going to have to code them in C++ and recompile everytime they want to move a button or change its text? Or do they just mock them up in Photoshop for you and the coder then become responsible for converting them when they have the chance?
But wait...you could leave the missions, the gui's, the datablocks, the keybinds, the mission loading, the server browser, the options menu, the prefs, and the editors as scripts so that your designers and artists can easily edit them. But then some artist on your team comes along with a model with ambient animation that he wants it to play automatically when the mission loads and he has to wait until one of your overworked coders has time to add that code functionality to the engine and even then it is tied to a specific animation name. What if he wants it to switch animations when a switch is thrown? More waiting on the coder...wouldn't it be handy if whenever a model is instantiated in the world it would automatically call the script function onAdd() and in there the artist can simply call %this.playAnimation("startup") and then when the player throws a switch a script function called onSwitchFlipped() is called where the artist puts in %this.playAnimation("cycle").
That would be really handy, wouldn't it? ;)
#6
Thank you! I think that I will work with the scripts... sigh
07/01/2005 (1:53 am)
Wow, great explanation, with lots of acid and ironic words :-) Great literary work!Thank you! I think that I will work with the scripts... sigh
#7
07/01/2005 (5:26 am)
It seems strange to me that this question comes up so much. Is the reason that you don't want to learn a new language? Torque script is very C/C++ like. In a way I think Torque script keeps me from getting more comfortable with C++. The first language I learned was C and I just haven't sat down and really worked in C++. Damn you Torque script. I hate that I love you. :)
#8
Second, I think that script is good for artists or designers, but for programmers, C++ give you more power to do modifications (this is the reason that you have to make games with Torque mixing script and C++ classes to improve the engine base), and using C++ we know some "tricks" to solve the problems that cannot use with a script.
Third, using C++ I can reuse lots of past code.
Fourth, If I cannot use breakpoints and going on debug, I cannot give my best, and I have try to debug Torque but is plenty of scripts-oriented code that makes it a impossible mission.
07/01/2005 (2:13 pm)
First of all, why I have to learn a new language if I am using the same (c++) for lots of years and I can say that I have a good control over.Second, I think that script is good for artists or designers, but for programmers, C++ give you more power to do modifications (this is the reason that you have to make games with Torque mixing script and C++ classes to improve the engine base), and using C++ we know some "tricks" to solve the problems that cannot use with a script.
Third, using C++ I can reuse lots of past code.
Fourth, If I cannot use breakpoints and going on debug, I cannot give my best, and I have try to debug Torque but is plenty of scripts-oriented code that makes it a impossible mission.
#9
For example, running collision code from script would be foolish (too slow, no access to the proper data without a lot of work, and the algorithms are just plain easier to write in C++). However, exposing an onCollision() script callback for whenever two objects collide makes it trivial for a designer or a game logic programmer to have playerX mount to vehicleY if there isn't already a player in the driver's seat. They can even check the player's team or class and write a couple lines of script code to determine if the player can mount the vehicle. Less than a dozen lines of really simple, really neat code utilizing a very clean interface sitting on top of very complex C++ code (collision and mounting and rendering and positional updating and networking and etc) and you have given your game logic (or gameplay) programmer really powerful and fast tools to work with.
For those of you who have written COM objects (or the like) it should be really intuitve. You build a black box and expose a high level interface that allows other objects to manipulate and interact with your object. It is also the very basis of any object oriented language (like C++) so it should be one you are already familiar with. If you are the writer of the black boxes then you *should* be coding in C++. If you are the guy wiring the black boxes together into an actual game then it is going to be a lot easier for you to work with the higher level interfaces that have been exposed to script.
You make it sound like learning TorqueScript when you are a C++ coder is hard. The syntax is virtually identical and all of the control structures you are familiar with are available (if-then-else, for, while, and switch). It really shouldn't take a competant C++ programmer more than a weekend to get up to speed syntacially with TorqueScript. After that it is a matter of learning the interfaces that have been exposed to script - which doesn't take long if you use dumpConsoleFunctions(); and.dump(); Grepping for ConsoleMethod and ConsoleFunction in the engine code will also expose these to you.
There is also a lot of good documentation:
See the official scripting docs, The Essential Guide to Torque (you can skip to the scripting chapter for T2D), Joel Baxters quick language reference is great, and Ron Yacketta made a thorough study of the built-in TorqueScript functions some time ago and its still very nice.
If that isn't enough there is even a very nice book all about TorqueScript that should be available at most large bookstores.
Also, you *can* debug TorqueScript.
07/01/2005 (6:33 pm)
If what you are doing is best run in C++, by all means code it in C++. The script is there for the designers, artists, and game logic programmers. It is often said that it is the "glue" that brings everything together. It instantiates your objects, sets up their data, and then makes high level decisions on how things interact.For example, running collision code from script would be foolish (too slow, no access to the proper data without a lot of work, and the algorithms are just plain easier to write in C++). However, exposing an onCollision() script callback for whenever two objects collide makes it trivial for a designer or a game logic programmer to have playerX mount to vehicleY if there isn't already a player in the driver's seat. They can even check the player's team or class and write a couple lines of script code to determine if the player can mount the vehicle. Less than a dozen lines of really simple, really neat code utilizing a very clean interface sitting on top of very complex C++ code (collision and mounting and rendering and positional updating and networking and etc) and you have given your game logic (or gameplay) programmer really powerful and fast tools to work with.
For those of you who have written COM objects (or the like) it should be really intuitve. You build a black box and expose a high level interface that allows other objects to manipulate and interact with your object. It is also the very basis of any object oriented language (like C++) so it should be one you are already familiar with. If you are the writer of the black boxes then you *should* be coding in C++. If you are the guy wiring the black boxes together into an actual game then it is going to be a lot easier for you to work with the higher level interfaces that have been exposed to script.
You make it sound like learning TorqueScript when you are a C++ coder is hard. The syntax is virtually identical and all of the control structures you are familiar with are available (if-then-else, for, while, and switch). It really shouldn't take a competant C++ programmer more than a weekend to get up to speed syntacially with TorqueScript. After that it is a matter of learning the interfaces that have been exposed to script - which doesn't take long if you use dumpConsoleFunctions(); and
There is also a lot of good documentation:
See the official scripting docs, The Essential Guide to Torque (you can skip to the scripting chapter for T2D), Joel Baxters quick language reference is great, and Ron Yacketta made a thorough study of the built-in TorqueScript functions some time ago and its still very nice.
If that isn't enough there is even a very nice book all about TorqueScript that should be available at most large bookstores.
Also, you *can* debug TorqueScript.
#10
The reason for purchasing a game engine is to give you a huge headstart on your technology base. There are both rewards and drawbacks to this. The reward is all of the time you save (which can be considerable) and how quickly you can get started. The drawback is that in order to properly leverage the technology you must conform yourself to its methods and practices...you must adopt its way of doing things. Sure, no tech is ever going to cover all of your needs or line up exactly to how you want to use it and you are going to have to spend time modifying/enhancing it to meet your needs but you need to look at each of the modifications you make and decide how much it is going to cost you to make the technology work the way you want it to versuses how much it would cost to change how you work.
I have laid out the cost of coverting all of the current scripts and setting up the framework you need to code completely in C++. I have even pointed out some of the benefits you derive from not going that route. It is up to you to decide if that cost is worth it. If it isn't and you still find yourself unable to accept scripting then perhaps Torque is not the right technology platform for you. Nothing wrong with that...technology is just a tool and some tools are better for certain jobs than others. There are a number of other engines that might work better with you and if you want I would be happy to point them out.
07/01/2005 (7:01 pm)
I wasn't merely being facetious in my earlier post. You *can* code entirely in C++ with Torque and the steps I laid out there are what you would have to do. I am sure someday someone will actually be stubborn enough that they will spend the time doing just what I have laid out here. I have found over the last four years that once people stop fearing script and take the time to try it out, they quickly begin to appreciate the benefits and rewards and after a short time they can't imagine ever going back to coding completely in C++. I have seen this happen a hundred times now (search the forums for how often this very question comes up) and I imagine I will continue to see it a thousand more times.The reason for purchasing a game engine is to give you a huge headstart on your technology base. There are both rewards and drawbacks to this. The reward is all of the time you save (which can be considerable) and how quickly you can get started. The drawback is that in order to properly leverage the technology you must conform yourself to its methods and practices...you must adopt its way of doing things. Sure, no tech is ever going to cover all of your needs or line up exactly to how you want to use it and you are going to have to spend time modifying/enhancing it to meet your needs but you need to look at each of the modifications you make and decide how much it is going to cost you to make the technology work the way you want it to versuses how much it would cost to change how you work.
I have laid out the cost of coverting all of the current scripts and setting up the framework you need to code completely in C++. I have even pointed out some of the benefits you derive from not going that route. It is up to you to decide if that cost is worth it. If it isn't and you still find yourself unable to accept scripting then perhaps Torque is not the right technology platform for you. Nothing wrong with that...technology is just a tool and some tools are better for certain jobs than others. There are a number of other engines that might work better with you and if you want I would be happy to point them out.
#11
Scripting is easy as pie to learn if you are fluent in C++. Learning to script or program in a new language seems much worse than it really is. I was like you. Then one day I sat down to learn torque script... within 30 minutes I was laughing at myself for having been so worried. It really isn't a big deal at all. You will like it a lot. It's just a few syntax differences really.
07/01/2005 (9:33 pm)
@DanielScripting is easy as pie to learn if you are fluent in C++. Learning to script or program in a new language seems much worse than it really is. I was like you. Then one day I sat down to learn torque script... within 30 minutes I was laughing at myself for having been so worried. It really isn't a big deal at all. You will like it a lot. It's just a few syntax differences really.
Torque Owner Chris Labombard
Premium Preferred