Whoa... overwhelmed
by Smaug · in Torque Game Builder · 03/20/2005 (2:52 pm) · 25 replies
So, I've got T2D. And now... I'm not really sure how to make it do anything.
The tutorial looks like an interesting excercise, but I'm not interested in working with TorqueScript at the moment. I'm a C++ programmer, so I'm interested in knowing what I can do with T2D from that perspective. I've taken a quick look at the source, and I found main(), but I'm not sure where it is that I'm even supposed to hook my code into. Is there some virtual object that I can derive from to begin adding my own logic, or is there something else I should be doing? I'm hoping that I don't have to actually modify the T2D engine just to add hooks for my code, but I've never used a Torque engine before, so I don't know how to get started.
Also, I can't seem to find the documentation on the Torque core stuff, like the GUI and the input system. How do I find that kind of stuff?
The tutorial looks like an interesting excercise, but I'm not interested in working with TorqueScript at the moment. I'm a C++ programmer, so I'm interested in knowing what I can do with T2D from that perspective. I've taken a quick look at the source, and I found main(), but I'm not sure where it is that I'm even supposed to hook my code into. Is there some virtual object that I can derive from to begin adding my own logic, or is there something else I should be doing? I'm hoping that I don't have to actually modify the T2D engine just to add hooks for my code, but I've never used a Torque engine before, so I don't know how to get started.
Also, I can't seem to find the documentation on the Torque core stuff, like the GUI and the input system. How do I find that kind of stuff?
#3
Quick summary of about 100+ posts all around the forums, in various areas (some of which you may not have access to).
Script != slow. TGEScript is bytecode compiled, and quite optimized for many, many things.
Script == one of the major mechanisms for implementing game logic in the TAP (Torque Application Platform--T2D, TGE, TSE, etc.). You are not forced to use TGEScript, but it is intended as one of the major mechanisms for implementation, especially for rapid prototyping. Side Note: One of the primary business visions of GG is to provide Independent Devs the ability to do good business for their niche. This results in providing as much flexibility as feasible, combined with the ability to prototype, prototype, prototype, so you can evolve a GOOD game by weeding out your own personal chaff with as minimal effort as possible. That's just one of the reasons why TGEScript is a strong focus in the TAP.
Now, all that being said, nothing requires you to use script. You can code to your heart's content in C++, but you will find that the underlying architecture is not designed with that in mind--it's not going to stop you or anything, but if you do take the time to work with TGEScript first, I think that you'll find it's worth the learning curve. Anything in the TAP is definately not presented as an SDK that you pick and choose from, but an integrated platform to develop your game.
For reference (and I am not a sample of the majority, I just take my time and learn my environment), my team spent the first 6-8 months of our experience with TGE accomplishing small tasks that in the long run did not directly relate to our desired game. However, the experience and knowledge of the platform TAP provides was incredibly effective--one we were finished our "puttering around" phase, we implemented some major game functionality in 3 weeks...and I do mean major. As another aside, we actually implemented 90% of this functionality in TGEScript!
Looking at the opposite side of the spectrum, you see things like the Missile Command clone you can find in this private forum, as well as David's T2D project that is currently featured in the Snapshot of the Day (top right of your browser)--these were both accomplished in under 3 weeks, and the Snapshot of the Day especially is top quality (not to dis the missile command clone, just that David had the artistic skills as well as dev skills to make a top notch game!).
Core TAP documentation is definately an issue right now, and one that they are working hard to overcome. The primary reason it is an issue is how the web page itself has been organized--source code documentation (including some aspects of script) have been tucked away in protected forums, and isn't easily expandable yet for the new portion of the TAP (T2D) that needs access to some, but not all, of that documentation. There have been some amazing examples of community contribution here in the forums to assist Melv and Josh in documentation, so feel free to look around, and if you have any questions, feel free to ask!
Summary: Do the tutorial--it really will give you a good, broad basis for diving into the depths of T2D. Also, take some time and read as many posts here as you can handle in one sitting, a lot of knowledge here as well!
03/20/2005 (3:40 pm)
Just like any other rather complex application, it really is best to get used to the environment based on the basics first--in this case, TGEScript.Quick summary of about 100+ posts all around the forums, in various areas (some of which you may not have access to).
Script != slow. TGEScript is bytecode compiled, and quite optimized for many, many things.
Script == one of the major mechanisms for implementing game logic in the TAP (Torque Application Platform--T2D, TGE, TSE, etc.). You are not forced to use TGEScript, but it is intended as one of the major mechanisms for implementation, especially for rapid prototyping. Side Note: One of the primary business visions of GG is to provide Independent Devs the ability to do good business for their niche. This results in providing as much flexibility as feasible, combined with the ability to prototype, prototype, prototype, so you can evolve a GOOD game by weeding out your own personal chaff with as minimal effort as possible. That's just one of the reasons why TGEScript is a strong focus in the TAP.
Now, all that being said, nothing requires you to use script. You can code to your heart's content in C++, but you will find that the underlying architecture is not designed with that in mind--it's not going to stop you or anything, but if you do take the time to work with TGEScript first, I think that you'll find it's worth the learning curve. Anything in the TAP is definately not presented as an SDK that you pick and choose from, but an integrated platform to develop your game.
For reference (and I am not a sample of the majority, I just take my time and learn my environment), my team spent the first 6-8 months of our experience with TGE accomplishing small tasks that in the long run did not directly relate to our desired game. However, the experience and knowledge of the platform TAP provides was incredibly effective--one we were finished our "puttering around" phase, we implemented some major game functionality in 3 weeks...and I do mean major. As another aside, we actually implemented 90% of this functionality in TGEScript!
Looking at the opposite side of the spectrum, you see things like the Missile Command clone you can find in this private forum, as well as David's T2D project that is currently featured in the Snapshot of the Day (top right of your browser)--these were both accomplished in under 3 weeks, and the Snapshot of the Day especially is top quality (not to dis the missile command clone, just that David had the artistic skills as well as dev skills to make a top notch game!).
Core TAP documentation is definately an issue right now, and one that they are working hard to overcome. The primary reason it is an issue is how the web page itself has been organized--source code documentation (including some aspects of script) have been tucked away in protected forums, and isn't easily expandable yet for the new portion of the TAP (T2D) that needs access to some, but not all, of that documentation. There have been some amazing examples of community contribution here in the forums to assist Melv and Josh in documentation, so feel free to look around, and if you have any questions, feel free to ask!
Summary: Do the tutorial--it really will give you a good, broad basis for diving into the depths of T2D. Also, take some time and read as many posts here as you can handle in one sitting, a lot of knowledge here as well!
#5
The issue is usability. I'm not talking about writing Missile Command or something small; I'l talking about writing a real, complex 2D game on the level of SNES-era epics or later-day 2D PC games. Games that involve dozens of tilemaps, rooms, and enemies.
Debugging is crucial to the day-to-day construction and maintainance of such games. I need to be able to put breakpoints in places and step through code. It does me no good in terms of releasing my game if I'm spending hours with printf's and other more primitive debugging tools trying to find some problem that VC++'s debugger could nail down in seconds.
Add to this the sheer volume of C++ code that's out there waiting to be used. If you have a problem that is even remotely usable in other situations, chances are that there's a C or C++ library with that code in it, or a snippet on some website. Between having highly useful things like Boost and other high-profile libraries available to me during development, having the resources of the C/C++ open-source development community is highly useful to development.
And let's not forget the advantages of having Visual Assist at your fingertips, another advantage lost when using a script-heavy method.
Knowing how to drive the game from code primarily rather than primarily from script would be really helpful in actual game development.
03/20/2005 (4:28 pm)
I know it's a common thing to dislike scripting due to performance issues, but that's not the issue here.The issue is usability. I'm not talking about writing Missile Command or something small; I'l talking about writing a real, complex 2D game on the level of SNES-era epics or later-day 2D PC games. Games that involve dozens of tilemaps, rooms, and enemies.
Debugging is crucial to the day-to-day construction and maintainance of such games. I need to be able to put breakpoints in places and step through code. It does me no good in terms of releasing my game if I'm spending hours with printf's and other more primitive debugging tools trying to find some problem that VC++'s debugger could nail down in seconds.
Add to this the sheer volume of C++ code that's out there waiting to be used. If you have a problem that is even remotely usable in other situations, chances are that there's a C or C++ library with that code in it, or a snippet on some website. Between having highly useful things like Boost and other high-profile libraries available to me during development, having the resources of the C/C++ open-source development community is highly useful to development.
And let's not forget the advantages of having Visual Assist at your fingertips, another advantage lost when using a script-heavy method.
Knowing how to drive the game from code primarily rather than primarily from script would be really helpful in actual game development.
#6
03/20/2005 (4:34 pm)
It should be pointed out that T2D is a development platform, and not an SDK. That being said, you can do everything in C++ anyway, so no problem, right?
#7
Torque works very well with working C++ with Script... there are advantages to both
03/20/2005 (5:58 pm)
True, though scripting has some pretty usefull tools, like "tree()" as well as others... and you can code your own scripting tools, debugging tools, etc... a lot of game companies will create their own level editors, script editors etc anyways so you can put full features in for your own set of games...Torque works very well with working C++ with Script... there are advantages to both
#8
I will definately take some time to see how I can achieve the same results in C++ so I can compare the two approaches. But, I just don't know how anyone can ship a game of any size without the ability to easily debug. I can see why I may want to have some parts of the logic scriptable -- those parts which will be worked on by designers and not programmers. But, as a programmer MSVC seems a much more robust development platform.
Perhaps there are some powerful debugging tools around that we just don't know about? In the thread referenced above Melv states, "There are excellent tools for debugging the scripts, line by line." But, he did not provide any links or further info.
Another thought is if I run a debug version of the core engine in my debugger, I still should be able to set breakpoints on the C++ side to see how it is handling the script code that it is fed. This does not solve all problems, but it might be a compromise worth investigating.
Anyway, I am trying to get a grasp on this issue is well, so please let me know how your research goes.
03/20/2005 (6:12 pm)
Smaug, just so you know you're not alone. I am a C++ dev and new to Torque. I went through the tutorial and have done some additional work using the scripting language. While the results are quite impressive, I find myself really disliking the scripting language for some of the reasons you mentioned and some you didn't -- like automatic variable instantiation.I will definately take some time to see how I can achieve the same results in C++ so I can compare the two approaches. But, I just don't know how anyone can ship a game of any size without the ability to easily debug. I can see why I may want to have some parts of the logic scriptable -- those parts which will be worked on by designers and not programmers. But, as a programmer MSVC seems a much more robust development platform.
Perhaps there are some powerful debugging tools around that we just don't know about? In the thread referenced above Melv states, "There are excellent tools for debugging the scripts, line by line." But, he did not provide any links or further info.
Another thought is if I run a debug version of the core engine in my debugger, I still should be able to set breakpoints on the C++ side to see how it is handling the script code that it is fed. This does not solve all problems, but it might be a compromise worth investigating.
Anyway, I am trying to get a grasp on this issue is well, so please let me know how your research goes.
#9
i belive that this editor can debug scripts.
I havnt tried it yet, but the help files in it shows you how to connect to torque to uses brain editors built in visual studio looking debugger.
www.garagegames.com/mg/snapshot/view.php?qid=691
i also found this, debugging using jedit with the TIDE plugin.
I think this is what Melv would recommend. :)
03/20/2005 (6:36 pm)
www.twinno.com/brainedpro/i belive that this editor can debug scripts.
I havnt tried it yet, but the help files in it shows you how to connect to torque to uses brain editors built in visual studio looking debugger.
www.garagegames.com/mg/snapshot/view.php?qid=691
i also found this, debugging using jedit with the TIDE plugin.
I think this is what Melv would recommend. :)
#10
03/20/2005 (10:55 pm)
If the only reason you don't want to use script is because you think TorqueScript isn't your kind of language, you might want to consider just using a different scripting language. I've pretty much seemlessly integrated Python in a couple of days, which at least is _my_ favorite language.
#11
This is definately an area of the TAP that could use some work, no argument there at all. As a small disclaimer, I use TCL professionally, and it sucks to debug itself.
For the "I'm used to C++ code" folks out there, I would suggest that you dig in and take a look at how script interfaces with source classes--the primary technique is ConsoleMethods, which acts as the interface between c++ classes and the scripting console. You will quickly find that for most of the code, the console methods are simply dispatchers to class access methods that accept string params (all transfers between script and c++ classes are strings), and then call your normal access methods you'd find in any c++ class.
There really is nothing wrong at all with bypassing the console entirely and using the class access methods that are at the c++ level--you just need to keep in mind that most developers didn't plan for you to do that, so you'll need to work out some minor issues. TGE itself isn't all that bad when it comes to how it uses classes, and Melv is excellent at both style and technique when it comes to implementing in c++--it will take some time, but I think that you'll be fine with your goals.
03/20/2005 (11:52 pm)
I will fully admit that TGEScript is hard to debug...but it's also extremely easy to develop in as well. There is a "remote debugger" capability in TGE, but quite honestly I have no feedback as to how beneficial it is regarding script debugging.This is definately an area of the TAP that could use some work, no argument there at all. As a small disclaimer, I use TCL professionally, and it sucks to debug itself.
For the "I'm used to C++ code" folks out there, I would suggest that you dig in and take a look at how script interfaces with source classes--the primary technique is ConsoleMethods, which acts as the interface between c++ classes and the scripting console. You will quickly find that for most of the code, the console methods are simply dispatchers to class access methods that accept string params (all transfers between script and c++ classes are strings), and then call your normal access methods you'd find in any c++ class.
There really is nothing wrong at all with bypassing the console entirely and using the class access methods that are at the c++ level--you just need to keep in mind that most developers didn't plan for you to do that, so you'll need to work out some minor issues. TGE itself isn't all that bad when it comes to how it uses classes, and Melv is excellent at both style and technique when it comes to implementing in c++--it will take some time, but I think that you'll be fine with your goals.
#12
I myself am working on a turn based strat. game and although initally run into a few snags it's mostly going smoothly.
03/20/2005 (11:57 pm)
And as said many times in the post, uu can do most things with script, look at some of the tge products you can purchase here such as lore and thinktanks.I myself am working on a turn based strat. game and although initally run into a few snags it's mostly going smoothly.
#13
First, I'm a C++ guy! When I started using the TGE, I did the exact same thing. I went to home-base, "main.cc" and started working my way through trying to understand the engine. Three months later I was tired, confused and just downright fed-up. That was years ago when there were only scraps of info available but there is so much documentation available now. This though was the wrong approach. I eventually started playing with the GUI system in C++ because it gave me a handle on how to get something visual done which is always a bonus. I then discovered the way that I could write code and get it actioned in the scripts. It all fell into place at that point.
The key to understand the engine is not to try to decompose the whole engine because that is just suicide. Don't try to wedge in your code in a mainloop. Instead, just use the scripts to to drive your C++ creations at first, then learn how to do the same in the engine. Use the T2D timebase first, then roll your own. Because T2D is event-driven, you can then focus on how to drive your code with events.
If you don't do this then you'll take a very long time to learn what you need to know. As soon as networking gets involved, it then becomes even more complex.
Ben Garney has posted in his plan about Torque Developer Network (similar to Unreal Dev Network) that will provide all the information you require. T2D is a branch of TGE (T3D) so lots of stuff is still applicable but there's also stuff that isn't. Some of the relevant TGE doco is private TGE owner stuff and we don't want to reformat only the applicable stuff for T2D. TDN will answer this problem and I am sorry for the lack of info.
One of the task on my TODO list is creating some T2D skeleton code that shows you how to do some of this stuff.
Don't dispair though! In the meantime, I'm more than happy to provide answers to more specific questions to get you up and running. It really doesn't take that much effort to be able to drive global/class-member functions from script, adding an object to the simulation and get an object running in a time-dependant manner, creating a custom T2D object or anything else but you won't find specific T2D class doco yet so I'm your reference and glad to answer your questions.
It might be beneficial having a seperate area for C++ related questions so I'll look into that ASAP.
- Melv.
03/21/2005 (2:22 am)
I'm here now, how can I help? ;)First, I'm a C++ guy! When I started using the TGE, I did the exact same thing. I went to home-base, "main.cc" and started working my way through trying to understand the engine. Three months later I was tired, confused and just downright fed-up. That was years ago when there were only scraps of info available but there is so much documentation available now. This though was the wrong approach. I eventually started playing with the GUI system in C++ because it gave me a handle on how to get something visual done which is always a bonus. I then discovered the way that I could write code and get it actioned in the scripts. It all fell into place at that point.
The key to understand the engine is not to try to decompose the whole engine because that is just suicide. Don't try to wedge in your code in a mainloop. Instead, just use the scripts to to drive your C++ creations at first, then learn how to do the same in the engine. Use the T2D timebase first, then roll your own. Because T2D is event-driven, you can then focus on how to drive your code with events.
If you don't do this then you'll take a very long time to learn what you need to know. As soon as networking gets involved, it then becomes even more complex.
Ben Garney has posted in his plan about Torque Developer Network (similar to Unreal Dev Network) that will provide all the information you require. T2D is a branch of TGE (T3D) so lots of stuff is still applicable but there's also stuff that isn't. Some of the relevant TGE doco is private TGE owner stuff and we don't want to reformat only the applicable stuff for T2D. TDN will answer this problem and I am sorry for the lack of info.
One of the task on my TODO list is creating some T2D skeleton code that shows you how to do some of this stuff.
Don't dispair though! In the meantime, I'm more than happy to provide answers to more specific questions to get you up and running. It really doesn't take that much effort to be able to drive global/class-member functions from script, adding an object to the simulation and get an object running in a time-dependant manner, creating a custom T2D object or anything else but you won't find specific T2D class doco yet so I'm your reference and glad to answer your questions.
It might be beneficial having a seperate area for C++ related questions so I'll look into that ASAP.
- Melv.
#14
03/21/2005 (4:49 am)
Python bindings for Torque would be nice :) - Are you planning to release any of your python integration code, Tomas?
#15
But I have to smoothen it out a bit and make it really really easy to use so that everyone can use it, even those not familiar with python. But you'll be amazed at how simple the Python<->Torque interface is.
03/21/2005 (5:45 am)
James, of course I am. Can't keep such a good thing to myself now can I?But I have to smoothen it out a bit and make it really really easy to use so that everyone can use it, even those not familiar with python. But you'll be amazed at how simple the Python<->Torque interface is.
#16
03/21/2005 (6:43 pm)
Actually, one thing I'd like to know is where is the main game loop. The function that calls all of the collision processing, physics, animation, rendering, scripts, schedules, etc.
#17
As you may have already guessed, I've just got my first taste of working with T2D; and the accompanying documentation is just awesome!:) And the particles...now that's exactly the type of stuff I've been looking for; very smooth without sacrificing quality and performance-couldn't ask for more!:) Great stuff Melv and Team and Thank you so very much!:) What a productive relief this is going to be for all of us!:)
Can't wait to help out with the tutorials and forums!:) We're indeed fortunate to have such a mature user base!:)
Cheers!:)
Gabor
03/21/2005 (7:38 pm)
Wow!:) Haven't seen docs like these anywhere for other 2D engines out there!:) As you may have already guessed, I've just got my first taste of working with T2D; and the accompanying documentation is just awesome!:) And the particles...now that's exactly the type of stuff I've been looking for; very smooth without sacrificing quality and performance-couldn't ask for more!:) Great stuff Melv and Team and Thank you so very much!:) What a productive relief this is going to be for all of us!:)
Can't wait to help out with the tutorials and forums!:) We're indeed fortunate to have such a mature user base!:)
Cheers!:)
Gabor
#18
@Smaug: The main-loop is in "\game\main.cc" (approx line 407). I would recommend that you not link custom code in here. There's a method of registration for your custom code into the simulation so that you can get per-frame or per-server-tick updates which is real easy to use. I start to describe it here but I'd be glad to elaborate on that or how to get your existing code up and running with minimal effort. Good Luck.
- Melv.
03/21/2005 (9:37 pm)
@Gabor: Thanks. Enjoy! :)@Smaug: The main-loop is in "\game\main.cc" (approx line 407). I would recommend that you not link custom code in here. There's a method of registration for your custom code into the simulation so that you can get per-frame or per-server-tick updates which is real easy to use. I start to describe it here but I'd be glad to elaborate on that or how to get your existing code up and running with minimal effort. Good Luck.
while(Game->isRunning())
{
PROFILE_START(MainLoop);
Game->journalProcess();
Net::process(); // read in all events
Platform::process(); // keys, etc.
TelConsole->process();
TelDebugger->process();
TimeManager::process(); // guaranteed to produce an event
PROFILE_END();
}- Melv.
#19
Im learning vb.net in school. Can i use that with t2d in the calling from scripts method you described above for c++.
03/22/2005 (6:21 am)
Melv,Im learning vb.net in school. Can i use that with t2d in the calling from scripts method you described above for c++.
Torque Owner Corey Martin