Is Torque right for my school?
by Davey Jackson · in Torque in Education · 12/19/2005 (6:14 pm) · 6 replies
This forum thread is for schools that are currently evaluating Torque as a course offering. Please tell us a little about your program and what you are looking for in a development platform. What other game engines are you considering, and what are your reservations about teaching Torque?
#2
I'm not sure I am particularly concernted about using TS in terms of the editor. You could always edit it inside devstudio anyway.
I agree that it really should be a typed language if you are going to teach properly, but I would have though it would have been easier non-typed.
12/20/2005 (7:45 am)
I would have thought that because it isnt strongly typed, it would be MORE friendly for students. I wonder why that isnt the case Stephane?I'm not sure I am particularly concernted about using TS in terms of the editor. You could always edit it inside devstudio anyway.
I agree that it really should be a typed language if you are going to teach properly, but I would have though it would have been easier non-typed.
#3
12/20/2005 (1:12 pm)
@Stephane: Thank you very much for re-posting this question here. A through understanding of Torque in advance will help schools to make an informed decision. I think you raise a good point that visual studio or other engines may be initially easier to work with, however, our experience has been that schools who have only been using those programs eventually find themselves looking for a more robust platform. So while the initial learning curve may be steeper, some schools have determined Torque's capabilities, ability to customize the editors, and source code access warrant the extra time spent.
#4
An example of one of our exams is using the engine (3d gamestudio at mo :( ) and making a level using wed (proprietary map editor).. texturing it.. adding self made models.. adding basic gui displays with some scripts hooked in.. and adding some basic coding to enact basic movement or clocks or other simple things..
torques documentation is setup as a reference rather then as tutorials.. YOU pick where you start and finish..
it is somewhat arranged alphabetically with little bias given to complexity..
i think the tutorials on codesampler.com are more suitable to our type of course in particular...as each tutorial has clear objectives.. we focus on the practical more then the academic...
i must state that the tutorials we follow for gamestudio are written by the lecturer and are not written by conitec..
The reference format is good for more mature people who know where their objectives are and are following a plan, whereas the tutorial format normally has a carrot at the end .."Tutorial on how to make cool particle effects!" which is good for students unsure of there objectives...
torque can be hard but i guess its the age old ratio of complexity::control ...and the fact you can delve into the c++ is very appealing to me.. cus its really where all programming roads lead eventually!
a tutorial on how to replace the default character with your own mesh would be good.. i have one if your interested? .. i was making my own custom animations, crappy as they were long before i could replace the character in the default animations..
12/20/2005 (2:15 pm)
The course i go to (Cghnd@bcfe ireland) is one of the more hands on type of courses and the way it is structured is done in a very tutorialised way. An example of one of our exams is using the engine (3d gamestudio at mo :( ) and making a level using wed (proprietary map editor).. texturing it.. adding self made models.. adding basic gui displays with some scripts hooked in.. and adding some basic coding to enact basic movement or clocks or other simple things..
torques documentation is setup as a reference rather then as tutorials.. YOU pick where you start and finish..
it is somewhat arranged alphabetically with little bias given to complexity..
i think the tutorials on codesampler.com are more suitable to our type of course in particular...as each tutorial has clear objectives.. we focus on the practical more then the academic...
i must state that the tutorials we follow for gamestudio are written by the lecturer and are not written by conitec..
The reference format is good for more mature people who know where their objectives are and are following a plan, whereas the tutorial format normally has a carrot at the end .."Tutorial on how to make cool particle effects!" which is good for students unsure of there objectives...
torque can be hard but i guess its the age old ratio of complexity::control ...and the fact you can delve into the c++ is very appealing to me.. cus its really where all programming roads lead eventually!
a tutorial on how to replace the default character with your own mesh would be good.. i have one if your interested? .. i was making my own custom animations, crappy as they were long before i could replace the character in the default animations..
#5
While we're not on a tought course, as a society we used Torque 1.3 for a Cel-Outlined fighting game. While Torque provided us with good features such as a mission editor and a more wysiwyg approach than other game engines we looked at this was a good move as our members easily picked up the engine and worked on it.
The main downfall for the engine was serious lack of documentation, bugs and no clear starting point with the engine. The file structure for Torque is still a little odd, specifically in relations to assets. Students coming from a more Quake and Unreal background found the setup very strange. The coders and designers found the amount of config and preference files to be very scattered and somewhat duplicated. This is due to a lack of a clean visual explanation as to how the client/server file structure is able to superseed various scripts, etc...
The lack of documentation pushed a lot of the members to go mad, as they found themselves lost and unwilling to as small questions on the forums for fear of getting flammed. TDN is now here and it's a godsend. I've personally been working on it to make it as clear and precises as possible, so that you can achieve some good game development. The information is now accessible and doesn't requrie sifting through loads and loads of forum and .plan posts to find the solution. Since our game relied heavily on characters, which was an area that the documentation did not cover in enough depth, this affected our project quite dramatically.
Bugs, this is still a problem I see in Torque 1.4. TGE 1.3 had a very annoying world axis placement bug, to which the coders had to search through loads of forum posts to find a correct solution, that only somewhat fixed it. TGE 1.4 for example has a water placement bug, which means you can't place it. This is quite counter intuative to new and older game developers. The mission editor provides a fast and easy environment for things to work in, but when things break how do work around it? Well this annoyed our members drastically, as they were learning how to use and manipulate a 3D world which was broken. I would strongly advise a larger beta testing period, or more open. Either way, there should be possibly more fequence updates to fix such big bugs.
And yes, TorqueScript was an issue. The method in which TS is used is confusing at first, due to the number of files that are within the client and server base. The first thing that was entioned in our review of the first month was that TS was not strongly typed. This can be good and bad and I see both sides of the arguement. However, since we are talking about education a more strongly typed would be beneficial as the students then know their boundaries from which they can then expand from. It will be a hard learning curve no matter what, however, now with TDN, students have a stronger base from which to pull good information. Having spoken to some students from Phil's course, now working on PS3 games, they have told me that TS is just a pain at first, it doesn't make sense; but later once they learnt more about it understand it better, yet still this first impression erects a strong barrier for learning and development.
The actual conclusion of the use of Torque left the key members with a negative experience with Torque. I stuck with it due to pushing myself to understand it, but I spent three times more on it than anyone in the society, yet if we had 1.4, TDN and the new GG website a year ago, then I could assume that the experience would have been a better one. Having said this, it isn't to say that they all dislike it, it does relate to the difficulty of our project but the committee voted to use Half-Life 2's source engine as it features a more mod-directed engine. Whereas, Torque doesn't provide a typically FPS base, as much as the stater.fps tries to do that, it doesn't because it lacks some of the major features you would typically see in a FPS. I think that somewhat puts people away, RealmWars is not a completed game, nor is your Racing game; while HL2 is, which give people a stronger base for development. While Torque is a versatile engine, a more single-level mod with all features would be better demos than working on other tech demos or whatever. Take for example Warzone, this would be a good basis for a full one-level demo with all the features of torque being used - This would able students to load up the level and mess around with it, check it out and see how it all works.
Hope this info's been good and helpful, I'm still sticking with Torque, it's great fun! :D
12/22/2005 (4:53 am)
I've read the posts here and I've found it very interesting, I've touched on this subject a little with Davey already, but I wanted to share some of the thought here.While we're not on a tought course, as a society we used Torque 1.3 for a Cel-Outlined fighting game. While Torque provided us with good features such as a mission editor and a more wysiwyg approach than other game engines we looked at this was a good move as our members easily picked up the engine and worked on it.
The main downfall for the engine was serious lack of documentation, bugs and no clear starting point with the engine. The file structure for Torque is still a little odd, specifically in relations to assets. Students coming from a more Quake and Unreal background found the setup very strange. The coders and designers found the amount of config and preference files to be very scattered and somewhat duplicated. This is due to a lack of a clean visual explanation as to how the client/server file structure is able to superseed various scripts, etc...
The lack of documentation pushed a lot of the members to go mad, as they found themselves lost and unwilling to as small questions on the forums for fear of getting flammed. TDN is now here and it's a godsend. I've personally been working on it to make it as clear and precises as possible, so that you can achieve some good game development. The information is now accessible and doesn't requrie sifting through loads and loads of forum and .plan posts to find the solution. Since our game relied heavily on characters, which was an area that the documentation did not cover in enough depth, this affected our project quite dramatically.
Bugs, this is still a problem I see in Torque 1.4. TGE 1.3 had a very annoying world axis placement bug, to which the coders had to search through loads of forum posts to find a correct solution, that only somewhat fixed it. TGE 1.4 for example has a water placement bug, which means you can't place it. This is quite counter intuative to new and older game developers. The mission editor provides a fast and easy environment for things to work in, but when things break how do work around it? Well this annoyed our members drastically, as they were learning how to use and manipulate a 3D world which was broken. I would strongly advise a larger beta testing period, or more open. Either way, there should be possibly more fequence updates to fix such big bugs.
And yes, TorqueScript was an issue. The method in which TS is used is confusing at first, due to the number of files that are within the client and server base. The first thing that was entioned in our review of the first month was that TS was not strongly typed. This can be good and bad and I see both sides of the arguement. However, since we are talking about education a more strongly typed would be beneficial as the students then know their boundaries from which they can then expand from. It will be a hard learning curve no matter what, however, now with TDN, students have a stronger base from which to pull good information. Having spoken to some students from Phil's course, now working on PS3 games, they have told me that TS is just a pain at first, it doesn't make sense; but later once they learnt more about it understand it better, yet still this first impression erects a strong barrier for learning and development.
The actual conclusion of the use of Torque left the key members with a negative experience with Torque. I stuck with it due to pushing myself to understand it, but I spent three times more on it than anyone in the society, yet if we had 1.4, TDN and the new GG website a year ago, then I could assume that the experience would have been a better one. Having said this, it isn't to say that they all dislike it, it does relate to the difficulty of our project but the committee voted to use Half-Life 2's source engine as it features a more mod-directed engine. Whereas, Torque doesn't provide a typically FPS base, as much as the stater.fps tries to do that, it doesn't because it lacks some of the major features you would typically see in a FPS. I think that somewhat puts people away, RealmWars is not a completed game, nor is your Racing game; while HL2 is, which give people a stronger base for development. While Torque is a versatile engine, a more single-level mod with all features would be better demos than working on other tech demos or whatever. Take for example Warzone, this would be a good basis for a full one-level demo with all the features of torque being used - This would able students to load up the level and mess around with it, check it out and see how it all works.
Hope this info's been good and helpful, I'm still sticking with Torque, it's great fun! :D
#6
So, I am not by any means condoning the use of Torque/TorqueScript in teaching environments, I would just strongly recommend against using it to teach students who have never before been exposed to programming.
@Davey: Not a problem! My apologies for hijacking your thread in the first place!
About the script editor... you can always edit script inside of DevStudio (or any other editor for that matter), but there is no intelli-sense for the language (please correct me if I am wrong, for I have been looking for proper intelli-sensing for TorqueScript for a long time). That is single-handedly the largest reason that TorqueScript is very difficult to use to teach beginner programmers. The ability to right click on any use of a variable or function and get the definition/declaration of it is unbelievably useful to people that a) don't know the scripting environment very well and b) don't know scripting in general very well. If you are expecting the students to leverage any existing code without giving them some sort of intelli-sense ability, you could get into some trouble. Is it not also true (although this is a complete guess really) that the fact that TorqueScript is not strongly-typed is part of the reason that it is so difficult to do proper intelli-sensing/function look-up?
Anyway, thanks for questioning my statements and please do let me know if you are able to successfully take some completely inexperienced programmers and teach them effectively with TorqueScript as I would like to know how you did it!
12/23/2005 (9:17 am)
@Phil: I definitely see how it could SEEM that a non-strongly-typed language would be easier for students, it was certainly not. The main problem was that we were using TorqueScript to teach students that had NEVER laid eyes on code before. Since TorqueScript was not strongly-typed, it did not 'catch' a lot of the easier mistakes, making for many a headache. C++, C#, UnrealScript, etc. are far more strict than TorqueScript, which is really what you want for students that are just learning how to program. It is very difficult to teach students what 'int's, 'string's, 'float's, etc. are without the language being able to back that up concretely.So, I am not by any means condoning the use of Torque/TorqueScript in teaching environments, I would just strongly recommend against using it to teach students who have never before been exposed to programming.
@Davey: Not a problem! My apologies for hijacking your thread in the first place!
About the script editor... you can always edit script inside of DevStudio (or any other editor for that matter), but there is no intelli-sense for the language (please correct me if I am wrong, for I have been looking for proper intelli-sensing for TorqueScript for a long time). That is single-handedly the largest reason that TorqueScript is very difficult to use to teach beginner programmers. The ability to right click on any use of a variable or function and get the definition/declaration of it is unbelievably useful to people that a) don't know the scripting environment very well and b) don't know scripting in general very well. If you are expecting the students to leverage any existing code without giving them some sort of intelli-sense ability, you could get into some trouble. Is it not also true (although this is a complete guess really) that the fact that TorqueScript is not strongly-typed is part of the reason that it is so difficult to do proper intelli-sensing/function look-up?
Anyway, thanks for questioning my statements and please do let me know if you are able to successfully take some completely inexperienced programmers and teach them effectively with TorqueScript as I would like to know how you did it!
Torque 3D Owner Stephane Conde
Needless to say, the course was an utter disaster (partially due to the fact that many of the students were not interested in learning scripting, but also because TorqueScript is not particularily freindly to new scripters/coders).
Let me know if you have had any success in teaching non-scripting/coding students with TorqueScript and how in the hell you managed to pull it off!!
Cheers,
Stephane