Using C++ instead of TorqueScript
by Caolan ODomhnaill · in Torque Game Engine Advanced · 06/19/2009 (9:01 am) · 13 replies
Hello everyone,
I am new to Torque and maybe its there but not entirely obvious. How do I make my game completely out of C++? I do not wish to use the TorqueScript for any of it.
The documentation implies that I can however I was unable to find samples that show this.
If someone can point me in the right direction, that would be great!
Thanks!
-Caolan.
I am new to Torque and maybe its there but not entirely obvious. How do I make my game completely out of C++? I do not wish to use the TorqueScript for any of it.
The documentation implies that I can however I was unable to find samples that show this.
If someone can point me in the right direction, that would be great!
Thanks!
-Caolan.
#2
Also, Torque takes a while to compile- I read books while it compiles. Going through script is much faster for development time, even if you know you're going to port some of those functions over later on. It lets you test things out so much faster.
06/19/2009 (11:49 am)
Manoel's right, you should pretty much look toward porting any "heavy" (math intensive or otherwise performance-slowing) script functions to C++ on a case-by-case basis.Also, Torque takes a while to compile- I read books while it compiles. Going through script is much faster for development time, even if you know you're going to port some of those functions over later on. It lets you test things out so much faster.
#3
:)
Also, if the missions, gameplay, and other items are in script, how do I prevent the user of the app from modifying all of that when they install it? This is a nother reason why I wanted to embed it all within the app instead of using script...
Thanks,
Caolan.
06/19/2009 (12:15 pm)
Thanks Manoel and Ted for the pointers and information. I program in C++ professionally on a daily basis which is why I wanted to do this. I am comfortable with it as a language, I just wanted to know how to do it with the engine. It looks like I will want to know this anyway regardless if I use TorqueScript or not. So my initial question still stands unanswered then: how do I put the code into my application?:)
Also, if the missions, gameplay, and other items are in script, how do I prevent the user of the app from modifying all of that when they install it? This is a nother reason why I wanted to embed it all within the app instead of using script...
Thanks,
Caolan.
#4
As for Torque Script itself, it's a very C-like language and is easy to pick up. Personally, after 6 years of working with Torque tech I wouldn't think doing an entire game solely on the C++ side worth the effort. Moving performance bottlenecks from script into code sure, but not the entire thing.
06/19/2009 (12:34 pm)
The engine compiles scripts into .dso files at runtime, which you would ship in your finished game in place of the scripts themselves. After that there are other precautions you can take such as putting everything into an encrypted zip which there is a resource on here for.As for Torque Script itself, it's a very C-like language and is easy to pick up. Personally, after 6 years of working with Torque tech I wouldn't think doing an entire game solely on the C++ side worth the effort. Moving performance bottlenecks from script into code sure, but not the entire thing.
#5
re compile times,
a complete recompile takes a couple minutes for me,
but recompiling just say player.cc and re-linking takes only .. six seconds.
but of course script can be re-loaded without even quitting the app.
06/19/2009 (12:59 pm)
i'll just chime in as well and echo what others here have said. the C++ side is good for low-level stuff like core physics, networking, rendering etc, while high-level game logic, GUI, etc is just much easier in script.re compile times,
a complete recompile takes a couple minutes for me,
but recompiling just say player.cc and re-linking takes only .. six seconds.
but of course script can be re-loaded without even quitting the app.
#6
Thank you everyone!!
One more thing, should I create a separate thread for how to actually add my code to C++ files and how to tell Torque to use it? So far everyone is dodging this question. ;)
-Caolan.
06/19/2009 (2:41 pm)
Okay so I'll do it all in in TorqueScript for now then.Thank you everyone!!
One more thing, should I create a separate thread for how to actually add my code to C++ files and how to tell Torque to use it? So far everyone is dodging this question. ;)
-Caolan.
#7
I suppose forum thread. Just ask away. :) But C++ isn't easy.
06/20/2009 (4:46 am)
Seperate thread as in forum thread or CPU core-thread?I suppose forum thread. Just ask away. :) But C++ isn't easy.
#9
06/20/2009 (12:55 pm)
Unless i'm mistaken all that opengl code is unusable for windows versions of tgea
#10
It's not so much that people have dodged your question, it's that this is a very complex subject that can't really be described in a forum post in any broad but useful sense. If you want to create a game entirely in C++, you will, for the most part, have to scrap the reference game implementation that is at the core of any simple "getting started" plan, and you'll really have to have an in-depth knowledge of how the engine works before you can realistically start thinking about doing that.
The engine was designed around the concept of using scripts, at the expense of ease of use on the C++ side.
But I do most of my work in C++ and have very little script usage in my projects, so it can be done, but it will take some work.
My advice would be to learn how to build off of the scripts first, and start adding objects and behaviors to the scenes with C++, until you have a good feel for the engine architecture. And then when you feel like you know it well enough, you can start whittling away the script dependencies, and if you have some more specific, targeted questions, myself or others will be glad to help you.
06/21/2009 (10:15 pm)
Quote:
One more thing, should I create a separate thread for how to actually add my code to C++ files and how to tell Torque to use it? So far everyone is dodging this question. ;)
It's not so much that people have dodged your question, it's that this is a very complex subject that can't really be described in a forum post in any broad but useful sense. If you want to create a game entirely in C++, you will, for the most part, have to scrap the reference game implementation that is at the core of any simple "getting started" plan, and you'll really have to have an in-depth knowledge of how the engine works before you can realistically start thinking about doing that.
The engine was designed around the concept of using scripts, at the expense of ease of use on the C++ side.
But I do most of my work in C++ and have very little script usage in my projects, so it can be done, but it will take some work.
My advice would be to learn how to build off of the scripts first, and start adding objects and behaviors to the scenes with C++, until you have a good feel for the engine architecture. And then when you feel like you know it well enough, you can start whittling away the script dependencies, and if you have some more specific, targeted questions, myself or others will be glad to help you.
#11
But I see that's not the case.
Thank you everyone for your replies! You have all been very helpful!
-Caolan.
06/21/2009 (11:35 pm)
Fair enough thanks. I am happy with that response. Being new to this engine, I wasn't too sure how easy it was to create the game in C++ or not. My initial thought was that the authors wanted to steer people away from it and to use the script since it would be much easier to learn. Kind of how some companies purposefully ignore certain older technologies in order to push their latest and greatest. But I see that's not the case.
Thank you everyone for your replies! You have all been very helpful!
-Caolan.
#12
I see you come from a deep C++ background like me, so one more quick warning. At first the internals of the engine will be kinda scary, as much of the design will go against the modern OO design paradigms that you may be used to.
Keep in mind that this is an engine that started as a game (Tribes) many years ago when low-level optimizations were paramount, and has evolved over that time by people who wanted to provide a low-cost engine to indies, but was never completely refactored. The graphics layer was refactored and is fairly well designed now, but you'll come across a lot of other stuff, like the scene graph, that will make you say "Why?!?!?". (There will also be a few things in the graphics layer, like only using 16-bit indices, that will be annoying too... but not too many.)
Anyway, it will take some time to get your head around it all, but eventually it will all make sense and you'll be able to bend the beast to your will.
Good luck.
06/22/2009 (1:25 am)
No problem. I see you come from a deep C++ background like me, so one more quick warning. At first the internals of the engine will be kinda scary, as much of the design will go against the modern OO design paradigms that you may be used to.
Keep in mind that this is an engine that started as a game (Tribes) many years ago when low-level optimizations were paramount, and has evolved over that time by people who wanted to provide a low-cost engine to indies, but was never completely refactored. The graphics layer was refactored and is fairly well designed now, but you'll come across a lot of other stuff, like the scene graph, that will make you say "Why?!?!?". (There will also be a few things in the graphics layer, like only using 16-bit indices, that will be annoying too... but not too many.)
Anyway, it will take some time to get your head around it all, but eventually it will all make sense and you'll be able to bend the beast to your will.
Good luck.
#13
I am trying to debug a crash when loading the ISO example that comes with the Isometric3D genrepack. It gets an unhandled exception upon destruction of a Stream object. I have some things I need to check before I continue down that path any further though.
I am looking at integrating a O(1) priority queue for event handling. It is specialised for massive numbers of discrete events. But that's a "nicety". I more interested in extending the AI to include a classification system for AI agents using GA's.
I have a lot of plans. :) Hopefully I'll have the opportunity to implement them all.
06/30/2009 (12:40 pm)
I am figuring that out! :) I am trying to debug a crash when loading the ISO example that comes with the Isometric3D genrepack. It gets an unhandled exception upon destruction of a Stream object. I have some things I need to check before I continue down that path any further though.
I am looking at integrating a O(1) priority queue for event handling. It is specialised for massive numbers of discrete events. But that's a "nicety". I more interested in extending the AI to include a classification system for AI agents using GA's.
I have a lot of plans. :) Hopefully I'll have the opportunity to implement them all.
Associate Manoel Neto
Default Studio Name
A question: do you have your game already running in script and is unhappy with performance, and is exploring the option of porting your scripts to C++, or you don't have anything done in script yet and want to use C++ because you know it will run faster and/or you don't know torquescript too well?
If its the latter, its futile. Porting a build of performance-critical script code into C++ is only viable when you have a reasonable grasp of the script flow and which functions are eating most of your time. If you don't know the scripts, you won't have enough understanding to replicate their behavior using C++ anyway.
Again assuming you're not familiar with the scripts: they do mostly three things: initial game setup (initialize graphics, sound, create the window, execute other scripts), object creation (GUIs, datablocks and missions) and high level callback logic. You don't have a frame loop in script, nor you execute physics with it. But you might be doing stuff like pathfinding or sorting items in an inventory, or some fancy AI. Those can benefit from being ported into C++ (after the script versions are working).