New User Questions
by Merrie Schonbach · in Torque Game Engine · 12/20/2005 (4:50 pm) · 13 replies
Im considering the Torque Engine and have a few questions, I apologize ahead if they have been asked before.
I know a little Python, little Basic, touched C. I know this has quite the learning curve, but for a beginner with a good idea can it be learned without alot of headaches? I have never programmed anything myself, I have adjusted some scripts, added some plug ins but if you said, 'Design a simple calculator with C++' I would be beyond my element.
My goal is to start small, a simple game then as I learn slowly work up to a RPG, but I know thats a ways down the road.
For art used in the game engine, I know there are quite a few sources you can get 3D models for free and/or low cost. Should one also learn how to do this art or there are enough artest, sources around to get by well.
Thank you for your help.
I know a little Python, little Basic, touched C. I know this has quite the learning curve, but for a beginner with a good idea can it be learned without alot of headaches? I have never programmed anything myself, I have adjusted some scripts, added some plug ins but if you said, 'Design a simple calculator with C++' I would be beyond my element.
My goal is to start small, a simple game then as I learn slowly work up to a RPG, but I know thats a ways down the road.
For art used in the game engine, I know there are quite a few sources you can get 3D models for free and/or low cost. Should one also learn how to do this art or there are enough artest, sources around to get by well.
Thank you for your help.
About the author
3D Artist, avid gamer, roleplayer, story-writer.
#2
you can get a feel for what Torque scripting is like with just the FPS Demo.
12/20/2005 (6:10 pm)
@merrie - sounds like you'll just be using script versus touching the C++ very much;you can get a feel for what Torque scripting is like with just the FPS Demo.
#3
You can of course take the base demo games and start plugging in other bits, but IMHO you learn nothing about how the fundamentals work that way. And trying to understand the demo code is next to useless, as objects are used with no explanation of why or what they are. Datablock names seem to be chosen at random sometimes, but at other times SEEM to have required names, but again, no explanation why they are named the way they are.
So you are left to flounder around aimlessly, experimenting at random by modding things and seeing what happens. A more inefficient software development process couldn't be found if you tried. The only saving grace are the forums where people are extremely helpful. But who wants to go online every few minutes to find the answer to basic stuff that should be to hand in downloadable docs?
The dev network may eventually be good, but is developing extremely slowly and at the moment is largely a reorganisation of stuff that is lying around elsewhere. And of course, more online time if you need to use it, as I haven't noticed any downloadable PDF or other files to read the content offline.
So in summary, I would say learning the language won't be a problem, but learning how to use it effectively will.
As for art, most of the advanced stuff on the dev network seems to be for 3DS max. If you can afford that, or can use it at work, you're in luck. If you're using Milkshape of something affordable for most people, then you're out of luck at the moment.
12/22/2005 (3:51 am)
One of my skills (perhaps my ONLY skill) is that I learn programming languages very quickly and can apply them in a practical way immediately. However, I am struggling with TGE/TSE because the documentation is truly terrible insofar as how everything fits together, and what objects to use for what purpose. So I don't think it would take you too long to get the syntax of the scripting language, but it might take you months to figure out how to build even a simple game from scratch (assuming you really want to understand what you are doing).You can of course take the base demo games and start plugging in other bits, but IMHO you learn nothing about how the fundamentals work that way. And trying to understand the demo code is next to useless, as objects are used with no explanation of why or what they are. Datablock names seem to be chosen at random sometimes, but at other times SEEM to have required names, but again, no explanation why they are named the way they are.
So you are left to flounder around aimlessly, experimenting at random by modding things and seeing what happens. A more inefficient software development process couldn't be found if you tried. The only saving grace are the forums where people are extremely helpful. But who wants to go online every few minutes to find the answer to basic stuff that should be to hand in downloadable docs?
The dev network may eventually be good, but is developing extremely slowly and at the moment is largely a reorganisation of stuff that is lying around elsewhere. And of course, more online time if you need to use it, as I haven't noticed any downloadable PDF or other files to read the content offline.
So in summary, I would say learning the language won't be a problem, but learning how to use it effectively will.
As for art, most of the advanced stuff on the dev network seems to be for 3DS max. If you can afford that, or can use it at work, you're in luck. If you're using Milkshape of something affordable for most people, then you're out of luck at the moment.
#4
As to learning, Im up for the process and know it will take me some time. I also hope to get on a game team so I can learn quicker from more advanced users.
Happy Holidays Everyone!
Good Gaming!
12/22/2005 (7:42 am)
I purchased TGE yesterday and ran through the tutorial, I did not find it too difficult at all. I do have 3D Game Programming All in One which I will go through as well. Im going to start with a really small game, just for learning and get help on the forums as such as I need it. Im going to make a running log of the process to help other people as well on my blog.As to learning, Im up for the process and know it will take me some time. I also hope to get on a game team so I can learn quicker from more advanced users.
Happy Holidays Everyone!
Good Gaming!
#5
12/22/2005 (9:18 am)
@Dave: Just curious--have you ever even looked at dOxygen generated pages? Because it does exactly what you are talking about. Please don't knock the documentation until you've actually used it.
#6
Nope, I admit to not having stumbled across them despite trolling around the TDN and the forums. Where are they, can you give me a link please? If they do exactly what I want I will post an unreserved apology here, absolutely no problem ... but I'm pretty sceptical at this moment judging by the quality of all the other docs I've seen.
Appreciate a link,
Thanks a lot,
Dave.
12/22/2005 (9:29 am)
Stephen,Nope, I admit to not having stumbled across them despite trolling around the TDN and the forums. Where are they, can you give me a link please? If they do exactly what I want I will post an unreserved apology here, absolutely no problem ... but I'm pretty sceptical at this moment judging by the quality of all the other docs I've seen.
Appreciate a link,
Thanks a lot,
Dave.
#7
Better to start with no knowledge and build than to be swamped with information and no way to relate it to the task at hand.
I have found the forums to be a very valuable resource, often other people have had similar problems in the past and a quick search opens up this world of knowledge, often linked to resources or relevant documentation pages. It does require that you have a connection to the net though.
From my own experience, I have to say that I've never had a problem with the documentation or the lack of it. The demos, although in some places cryptic do explain what is happening once you think about why something is happening in a particular way. They are simple enough to realise what's happening and once you learn the basic concepts the engine is built around, it all starts to fall into place.
I must admit, I have had Torque for a long time, since 1.2 and sometimes I've wanted to throw the mouse across the room in frustration at how seemingly complicated something simple appears to be to achieve..
But over time, I've come to realise that the problem isn't with Torque, it's with my understanding of Torque. Torque works really well because of the way it's written. It's architecture is designed to make your game work smoothly over a network. This feature can be taken out if need be but is worth getting used to.
I have played many Torque based games so I know for a fact that it is possible with the current set of documentation to build fantastic games.
But in a recent thread, garage games admited that the documentation isn't quite what they would like it to be which is why they set up the Torque Developer Network Wiki site.
To the new developers joining the Torque fold, I say you probably have much better documentation now than the earlier developers did. More people have understood and commented on the inner workings of the engine than when I first started and the knowledge is in the site, waiting to be discovered.
The 2 Books are also something I would have loved when I first started. I have them now and find them most useful.
@Merrie, Best of luck with your game and your blog.
Happy Holidays
12/22/2005 (9:31 am)
I find that sometimes it is better to find something out for yourself than to have endless tomes of documentation. Experimentation is a tried and proven way of discovering the unknown :-). Better to start with no knowledge and build than to be swamped with information and no way to relate it to the task at hand.
I have found the forums to be a very valuable resource, often other people have had similar problems in the past and a quick search opens up this world of knowledge, often linked to resources or relevant documentation pages. It does require that you have a connection to the net though.
From my own experience, I have to say that I've never had a problem with the documentation or the lack of it. The demos, although in some places cryptic do explain what is happening once you think about why something is happening in a particular way. They are simple enough to realise what's happening and once you learn the basic concepts the engine is built around, it all starts to fall into place.
I must admit, I have had Torque for a long time, since 1.2 and sometimes I've wanted to throw the mouse across the room in frustration at how seemingly complicated something simple appears to be to achieve..
But over time, I've come to realise that the problem isn't with Torque, it's with my understanding of Torque. Torque works really well because of the way it's written. It's architecture is designed to make your game work smoothly over a network. This feature can be taken out if need be but is worth getting used to.
I have played many Torque based games so I know for a fact that it is possible with the current set of documentation to build fantastic games.
But in a recent thread, garage games admited that the documentation isn't quite what they would like it to be which is why they set up the Torque Developer Network Wiki site.
To the new developers joining the Torque fold, I say you probably have much better documentation now than the earlier developers did. More people have understood and commented on the inner workings of the engine than when I first started and the knowledge is in the site, waiting to be discovered.
The 2 Books are also something I would have loved when I first started. I have them now and find them most useful.
@Merrie, Best of luck with your game and your blog.
Happy Holidays
#8
That is, say I want to create a sword for example. What class does it need to be? What datablocks should it use and are the datablock names mandatory or related to the object class somehow? What .cs files do I need to modify? How does it get picked up? How do I cause damage with it? What files need modding for damage stats?
There are no docs that I can find like that. A series of highly detailed and thoroughly explained examples under file names like "Melee weapons" or "Player" or "ranged weapons". Now I know there are things like that in the demo games, but bits are scattered all over the place with no nod towards comprehensive explanation of names, datablocks or objects being used. Does that seem clearer to you?
Anyway, a partial apology from me for not realising that I could generate doxygen docs. They certainly help in one way (although they seem out of date for parts of TSE) and cover my low level questions well. But the "big picture" questions still remain. If you can pull something out of the hat in that respect I will be eternally grateful.
All the best,
Dave.
12/22/2005 (12:52 pm)
Well Stephen, I downloaded doxygen and generated the docs from the latest HEAD download of TSE. What do I think? Very useful in some ways, answers a good part of my detailed queries. However, they still lack what I *really* need. That is, say I want to create a sword for example. What class does it need to be? What datablocks should it use and are the datablock names mandatory or related to the object class somehow? What .cs files do I need to modify? How does it get picked up? How do I cause damage with it? What files need modding for damage stats?
There are no docs that I can find like that. A series of highly detailed and thoroughly explained examples under file names like "Melee weapons" or "Player" or "ranged weapons". Now I know there are things like that in the demo games, but bits are scattered all over the place with no nod towards comprehensive explanation of names, datablocks or objects being used. Does that seem clearer to you?
Anyway, a partial apology from me for not realising that I could generate doxygen docs. They certainly help in one way (although they seem out of date for parts of TSE) and cover my low level questions well. But the "big picture" questions still remain. If you can pull something out of the hat in that respect I will be eternally grateful.
All the best,
Dave.
#9
Your next step might be stepping through the resources that people have created over the years--most of them go in depth in explaining what they accomplish, and how/why they were designed. For example, I know that there are at least 2 resources for melee fighting, and quite a few threads posted on the topic as well.
Regarding the general concept of "detailed examples of how to do things"--well, the main problem is that no two games want to do things exactly the same--so tutorials like that are in some ways a waste of time--it's too difficult to make something that is both useful, and generalized enough to apply to enough of an audience. It's a challenge in -any- environment, and at least Torque has 2 published books already, plus another on the way, as well as formal training available from GG (see Torque Boot Camps)...not many engines have either of the above.
12/22/2005 (1:51 pm)
Well, I'm glad that you've gotten part of your answer (the dOxygen generation--great tool especially if you generate them yourself, because if you follow the documentation standard for it, you can keep it up to date with your additions!).Your next step might be stepping through the resources that people have created over the years--most of them go in depth in explaining what they accomplish, and how/why they were designed. For example, I know that there are at least 2 resources for melee fighting, and quite a few threads posted on the topic as well.
Regarding the general concept of "detailed examples of how to do things"--well, the main problem is that no two games want to do things exactly the same--so tutorials like that are in some ways a waste of time--it's too difficult to make something that is both useful, and generalized enough to apply to enough of an audience. It's a challenge in -any- environment, and at least Torque has 2 published books already, plus another on the way, as well as formal training available from GG (see Torque Boot Camps)...not many engines have either of the above.
#10
BTW I just found this AI link from another thread. To me it is a perfect example of what I need, great job by the author. The only thing lacking is that it uses the "playerbody" datablock but neglects to mention if that is a random name or is hooked into the system somehow (and how you are supposed to guess you need it if there wasn't a tutorial).
http://tdn.garagegames.com/wiki/Torque/Script/Tutorials/Using_Basic_AI_Commands
Hi ho, hi ho, it's off to work I go. Gold, gold, gold, gold.....
Take care,
Dave.
12/23/2005 (2:49 am)
Stephen, I understand your point about games doing things differently. In fact that thought ocurred to me as well, after I had my rant. I guess that I just have to do things the hard way, and then write up specific articles to help others when I think I understand something. BTW I just found this AI link from another thread. To me it is a perfect example of what I need, great job by the author. The only thing lacking is that it uses the "playerbody" datablock but neglects to mention if that is a random name or is hooked into the system somehow (and how you are supposed to guess you need it if there wasn't a tutorial).
http://tdn.garagegames.com/wiki/Torque/Script/Tutorials/Using_Basic_AI_Commands
Hi ho, hi ho, it's off to work I go. Gold, gold, gold, gold.....
Take care,
Dave.
#11
(I'm at work and don't have access to the code, so please forgive any inaccuracies)
If you look in game.cs for the fps demo, there's some code to create an AIPlayer. In the statement which creates the instance of the AIPlayer, there's a part which specifies the datablock to create the AIPlayer with.
The datablock definitions are found here.
www.garagegames.com/docs/tge/general/apd.php
I may be wrong, but I believe the only things hard coded about a player object are the bone names, and they're only important for various animation and camera positioning tasks and are all documented.
www.garagegames.com/index.php?sec=mg&mod=resource&page=view&qid=4273
Hope this helps.
12/23/2005 (3:11 am)
My understanding is that none of the datablock names are hardcoded, only their basic definitions.(I'm at work and don't have access to the code, so please forgive any inaccuracies)
If you look in game.cs for the fps demo, there's some code to create an AIPlayer. In the statement which creates the instance of the AIPlayer, there's a part which specifies the datablock to create the AIPlayer with.
The datablock definitions are found here.
www.garagegames.com/docs/tge/general/apd.php
I may be wrong, but I believe the only things hard coded about a player object are the bone names, and they're only important for various animation and camera positioning tasks and are all documented.
www.garagegames.com/index.php?sec=mg&mod=resource&page=view&qid=4273
Hope this helps.
#12
Dave.
12/23/2005 (4:01 am)
Jason, thanks a lot. I was really using the AI link as an example of good docs rather than something I needed to learn. But those links are very useful, thank you! Dave.
#13
I'm glad you liked my tutorial =) Actually, both Stephen and I are in the process of writing a set of documents and tutorials like this one. There is a lot of ground we would like to cover in the "Getting Started" category but it is going to take time to build up since there is *so* many different things you can do with Torque.
I used "PlayerBody" because it is a pre-existing datablock in the demo and starter.fps (I need to sync up with tutorial.base also...slipped past me in 1.4). The only "magic" in the name is that it already existed in the scripts. There is nothing stopping you from going into server/scripts/player.cs and renaming the PlayerData datablock and using that name instead. I also didn't delve to deeply into the datablock side of things because that is a separate article I am writing/compiling ("Datablocks for Dummies" =P). Once it is written then I will retouch the AI article with a link to the more verbose datablock article.
The names of the types of objects and their corresponding datablocks (like Player and PlayerData respectively) are important and necessary (and covered in the dOxygen docs and the link Jason posted). However, there are only a handful of "magic" names for objects in the scripts that are hard referenced in the engine or in other scripts. Most of the names are completely arbitrary and a good "find in files" program can be invaluable for revealing them.
Anyway, we are working on it. Feel free to pitch in and help!
12/23/2005 (1:11 pm)
Dave,I'm glad you liked my tutorial =) Actually, both Stephen and I are in the process of writing a set of documents and tutorials like this one. There is a lot of ground we would like to cover in the "Getting Started" category but it is going to take time to build up since there is *so* many different things you can do with Torque.
I used "PlayerBody" because it is a pre-existing datablock in the demo and starter.fps (I need to sync up with tutorial.base also...slipped past me in 1.4). The only "magic" in the name is that it already existed in the scripts. There is nothing stopping you from going into server/scripts/player.cs and renaming the PlayerData datablock and using that name instead. I also didn't delve to deeply into the datablock side of things because that is a separate article I am writing/compiling ("Datablocks for Dummies" =P). Once it is written then I will retouch the AI article with a link to the more verbose datablock article.
The names of the types of objects and their corresponding datablocks (like Player and PlayerData respectively) are important and necessary (and covered in the dOxygen docs and the link Jason posted). However, there are only a handful of "magic" names for objects in the scripts that are hard referenced in the engine or in other scripts. Most of the names are completely arbitrary and a good "find in files" program can be invaluable for revealing them.
Anyway, we are working on it. Feel free to pitch in and help!
Ben Jones
It can't hurt you to learn how to make the art. You should download some free models, or buy a pack if you want, and play around with those models. Then when your ready to start up a game make a help wanted post.