Potential new resource : help me help you
by Michael Austin · in Torque Game Builder · 07/27/2005 (4:38 pm) · 16 replies
Hey guys!
I'm mulling over adding a resource for T2d Scripting(though I imagine it would apply to TGE). Some of the most frequent issues I've seen come up in the forums are: Where do I start a game design, How do I apply Object oriented programming in TorqueScript, What is the mysterious thing called a "scriptObject", What about testing?....
Basically, it all boils down to design techniques. I'm an experienced Software engineer, who came to T2d looking to make a commercial game. Naturally, when first dealing with torque I sought how to apply the design practices that I've picked up over the years to torqueScript, to make my code development faster, more maintainable, and more robust. Yet, the information on how to use ScriptObjects in design, methods to organize torqueScript so that code creep doesn't kill understandability, and how exactly to APPLY namespaces was spread out and difficult to locate. In fact, I spent a couple of days redoing previous work that wouldn't have been needed if this had been laid out.
The point of all this? I think the community would benefit from centralized design and practices guide. And seeing as I've put in the work to approach this very thing, and GG/Melv are busy getting stuff working (Thanks Guys! Loved the .Plan today), I figured I could work on this guide, and maybe pay back the community for all the help I've gotten or will have gotten.
I'd just like a warm fuzzy that people would enjoy this, and I would like a list of questions, experiences, and topics that you feel I should include. Or, tell me that nobody would care :P I'd rather be told that, then waste the time that I could spend USING T2d. Just remember in your recommendations: this will not be a nitty-gritty T2D guide. I won't go into anything here other than code design, and how to apply it to torqueScript. Obviously, a heavy emphasis will be on ScriptObjects and thier sets, inheritance, file modularity, function modularity, comment practices, and general layout recommendations.
Let me know what you think,
Mike
I'm mulling over adding a resource for T2d Scripting(though I imagine it would apply to TGE). Some of the most frequent issues I've seen come up in the forums are: Where do I start a game design, How do I apply Object oriented programming in TorqueScript, What is the mysterious thing called a "scriptObject", What about testing?....
Basically, it all boils down to design techniques. I'm an experienced Software engineer, who came to T2d looking to make a commercial game. Naturally, when first dealing with torque I sought how to apply the design practices that I've picked up over the years to torqueScript, to make my code development faster, more maintainable, and more robust. Yet, the information on how to use ScriptObjects in design, methods to organize torqueScript so that code creep doesn't kill understandability, and how exactly to APPLY namespaces was spread out and difficult to locate. In fact, I spent a couple of days redoing previous work that wouldn't have been needed if this had been laid out.
The point of all this? I think the community would benefit from centralized design and practices guide. And seeing as I've put in the work to approach this very thing, and GG/Melv are busy getting stuff working (Thanks Guys! Loved the .Plan today), I figured I could work on this guide, and maybe pay back the community for all the help I've gotten or will have gotten.
I'd just like a warm fuzzy that people would enjoy this, and I would like a list of questions, experiences, and topics that you feel I should include. Or, tell me that nobody would care :P I'd rather be told that, then waste the time that I could spend USING T2d. Just remember in your recommendations: this will not be a nitty-gritty T2D guide. I won't go into anything here other than code design, and how to apply it to torqueScript. Obviously, a heavy emphasis will be on ScriptObjects and thier sets, inheritance, file modularity, function modularity, comment practices, and general layout recommendations.
Let me know what you think,
Mike
About the author
#2
Really looking forward to something like this, sending warm fuzzy feelings your way. :)
bob
07/27/2005 (6:53 pm)
This is exactly what I need right now actually. I've read plenty of posts on ScriptObjects, namespaces and the like, but I'm still confused as how it all fits together in any useful way in a design sense. One question: you mention that this will generally be a design guide; does that mean you'll be talking about these practices in an abstract sense, or will this be wrapped around a demo so we can see how it's applied in a "real world" situation?Really looking forward to something like this, sending warm fuzzy feelings your way. :)
bob
#3
07/27/2005 (7:00 pm)
This would be a great guide, and i'd definately find it very useful.
#4
As an example, just today I was thinking of a small system that I would like to be able to implement in various places: 1) an object you need to destroy has an electrical shield. 2) the shield is powered by a generator 3) the generator is protected by a physical shield (which is probably pretty easy and not necessarily part of a 'system').
So as I was thinking about it my first reaction was that it will need to be placed and tracked in a map, have a hirearchy that can be tracked, and react to the player. From a scripting perspective I know I'll need an entry to load an image, an entry to define the location, collision callback for a non-destructible object, and associated AI for the gun / person / whatever behind the shield and most likely several other things I'm forgetting.
Now, to do this once, I know I could do the scripts in short order. But what happens when I have a dozen of these little 'systems' I want to use? 2 dozen? How do I make sure that my partners can make use of these systems for their tasks?
Is that the kind of scenario a resource like you're proposing could help with?
Thanks for the generous offer, Mike!
- Don
EDIT: spelling =P
07/27/2005 (9:08 pm)
I personally would find this awesome to have. I'm an artist with a technical bent, but there's a world of things that I just don't think of until I hit them and then I have to stumble around finding out about them. A guide that would help me to lay out a plan of action would be awesome and any actual implementation detail would just be a bonus. As an example, just today I was thinking of a small system that I would like to be able to implement in various places: 1) an object you need to destroy has an electrical shield. 2) the shield is powered by a generator 3) the generator is protected by a physical shield (which is probably pretty easy and not necessarily part of a 'system').
So as I was thinking about it my first reaction was that it will need to be placed and tracked in a map, have a hirearchy that can be tracked, and react to the player. From a scripting perspective I know I'll need an entry to load an image, an entry to define the location, collision callback for a non-destructible object, and associated AI for the gun / person / whatever behind the shield and most likely several other things I'm forgetting.
Now, to do this once, I know I could do the scripts in short order. But what happens when I have a dozen of these little 'systems' I want to use? 2 dozen? How do I make sure that my partners can make use of these systems for their tasks?
Is that the kind of scenario a resource like you're proposing could help with?
Thanks for the generous offer, Mike!
- Don
EDIT: spelling =P
#5
07/27/2005 (9:45 pm)
@Don: Pretty much, that exactly the sort of thing I'm talking about. Reusability is a huge feature of well designed code. In fact, that seems like your example is the perfect kind of system to use if I were to do a demo as opposed to code snippets. Hmmm... I'll keep this little example of yours in mind. I was kind of starting to wonder what type of system I would use to do a demo :) 
#6
07/27/2005 (10:13 pm)
I think this would help a lot of new users, breaking into Torque Data Structures and Code Design is a bit confusing and overwhelming at first, even moreso if your breaking into them for the first time. 
#7
This is a good idea. I would suggest talking to joshw@garagegames.com about this as we're always looking to add documentation that would help "join the dots" as such. If it could be TScript only then you'd definately get a wider audience and appreciation. Don't forget, that you could perhaps be a participant in TDN as well, just a thought.
-Melv.
07/28/2005 (1:30 am)
Michael,This is a good idea. I would suggest talking to joshw@garagegames.com about this as we're always looking to add documentation that would help "join the dots" as such. If it could be TScript only then you'd definately get a wider audience and appreciation. Don't forget, that you could perhaps be a participant in TDN as well, just a thought.
-Melv.
#10
@Melv: I'm going to make it generalized to TScript as much as possible, but I don't have TGE, so I can't be sure that everything I've learned will carry over. If, however, when I'm done the guide is general enough, I'd be happy for it to be shared accross the board.
Unfortunately, I woke up with a migraine, so i'm out of commission today. Tommorrow I'll email Josh and post a preliminary Table of contents for everyone to comment on. Thanks everyone.
Mike
07/28/2005 (1:11 pm)
Alright, Overywhelming support. I'm a little surprised to see Melv and Matt in on it, but hey - what better encouragement could I ask for!@Melv: I'm going to make it generalized to TScript as much as possible, but I don't have TGE, so I can't be sure that everything I've learned will carry over. If, however, when I'm done the guide is general enough, I'd be happy for it to be shared accross the board.
Unfortunately, I woke up with a migraine, so i'm out of commission today. Tommorrow I'll email Josh and post a preliminary Table of contents for everyone to comment on. Thanks everyone.
Mike
#11
08/16/2005 (9:23 am)
So, are you still working on this?
#12
I have had some presentations and work stuff come up in the last couple weeks. I'm still working on it partial time. I keep wanting to put different things in as I learn more about torqueScript.
Also, I have not been able to post to the forums. Haven't tried in the last week, but...
Mike
Edit: Yay! I can post again, apparently!
08/16/2005 (6:41 pm)
Will this post make it through?I have had some presentations and work stuff come up in the last couple weeks. I'm still working on it partial time. I keep wanting to put different things in as I learn more about torqueScript.
Also, I have not been able to post to the forums. Haven't tried in the last week, but...
Mike
Edit: Yay! I can post again, apparently!
#13
08/19/2005 (9:19 am)
Another angle that could help people is to define a sample problem (keep it concise) you wish to solve, and then show the solution in other languages AND torquescript. So, you could have, say, a php, perl, javascript, java, c#, c++........ and then a torquescript solution. This would allow users who are familiar with one or more other languages to immediately see how the solution translates into torquescript.
#14
Scripting Style Guide; Helpful tips for xTalk, Lingo, and other 4GLs could also be utilized by the Torquescript programmer I think.
08/19/2005 (10:31 pm)
Sounds like a good resource. This Scripting Style Guide; Helpful tips for xTalk, Lingo, and other 4GLs could also be utilized by the Torquescript programmer I think.
#15
08/20/2005 (7:40 am)
The sooner the better! I hope you won't wait until it is "perfect" to share it. It sounds like the kind of document that will evolve over months, if not years. But it wouldn't take a lot to help me out.
#16
08/20/2005 (4:59 pm)
Maybe you could just release an explanation for scriptObjects first :P 
Torque Owner Jacob Wagner