T3D Newb Learning Log #1
by Ron Barbosa · 06/05/2011 (9:29 am) · 24 comments
I've been a licensed Torque owner since about 2004. I've held licenses for TGE, TGEA, and T3D. I've become a recent license holder for T2D since the rebirth of Garage Games, not because I had a game in mind, but to support the comeback. I really like these guys and I want them to be in business for a long time.
There have been some stumbling blocks for me while trying to learn the 3D engine, and I've never truly committed myself to seeing my way past them.
I'm a bit more patient now...and the docs have come a long way, and I've decided to take another crack at it.
I'm reading through the docs, following faithfully...even when the subject matter seems to lie in the "common sense" realm. Over the next few weeks/months or as long as it takes, I'll post my findings here for anyone who cares to read, help, or learn.
1. The product page...
Every product that GG supports should have a product page like the new T3D product page. Not really sure that any more needs to be said about this...it's pretty tight and really had access to everything you'd need both as a customer as well as a developer.
2. The documentation is getting much much better...
But I think it leaves out some things that are maybe common knowledge amongst the Torque savvy and probably even echoed a million times in the forums. For example, I've read through the TorqueScript overview and syntax guide, but I still don't know how the TorqueScript process begins. I don't know if there's a "main" function that gets called somewhere that sends TorqueScript into a game loop that processes each frame. I know that it's happening, but I don't know where it starts.
As a developer (especially one trying to hunt down and fix a bug) the entirety of the stack trace is often the only way to fully appreciate why some of our code seems to be misbehaving. If I don't know where the whole process begins, then it can be tough trying to find the whole picture.
This may be mentioned later in the docs, but I have not seen it in the overview or the syntax guide. In my opinion, I should have seen it by now.
3. The tutorials are a bit broken now...
I went through the Changing The Player tutorial which looks like it was made for Gideon and the Boombot. Problem is, that it doesn't work any more.
The rocket launcher no longer works as described in the tut, and I couldn't find the Boombot asset (the missing asset wasn't really a big deal...a little common sense can get you around this).
Also, I chose to substitute Gideon for the Boombot. I started the tutorial with the new soldier model as my player avatar, and I changed him back to Gideon...this worked to replace the character, but for some reason Gideon seemed to be cycling through every animation he had in his repertoire. This I could overlook, but it didn't give me the feeling that I was "doing it right."
When you're making an effort to learn something new...step-by-step instructions that don't work can be a bit of a pain and a discouragement.
4. What does Torque know (or need to know) about my game?
As I was going through the tutorials, I found it a bit confining that TorqueScript and the "PlayerData" datablock seemed very concerned about my character/avatar. I don't know how much of this is due to the template I chose to use (Empty vs. Full), but I just got the feeling that it "cared too much" about my game. This may be why Torque has the reputation that it can only be used for FPS titles.
The PlayerData and DefaulPlayerData blocks, make assumptions that I have a player that can jump, shoot, take damage when landing, etc. That made me a bit claustrophobic. The fact that I still don't know what .cs files house these data blocks makes me just shy of infuriated. I went to the project folder and did a search for "PlayerData" and "DefaultPlayerData" but did not find any matching files. This lead me to believe that these might be defined in the engine code itself...which made me a bit more concerned about how much Torque was playing Big Brother over my game.
Never highlight a problem without proposing a solution...
Item #2 in my list above could probably be remedied with a quick intro (early in the TorqueScript guide) of how TorqueScript works as part of the game engine. Explain how the TorqueScript calls originate from the engine and become part of your game's functionality. Does the engine have a pointer to a "TorqueScript Arbiter" and once each frame, the engine tells the arbiter to update everything? Does the engine start a TorqueScript virtual machine that just has its own memory space and runs a confined loop without having to be told by the engine when to update everything? I don't know...but I'd like to know.
Item #3 is an elbow-grease item. Someone just needs to go over the tuts and validate their reliability. It's a thankless job fit for an intern.
Item #4...I think this is a case of Garage Games wanting to provide some minimally useful functionality to actually start a proper game. This seems like it's trying way too hard and has gone well past the point of minimally useful and into the realm of "YOU WILL DO IT THIS WAY!"
I will refer to another GG product...one which I've grown pretty fond of and familiar with despite its recent demise. Torque X does a great job of providing the developer with a very simple...movement component that let's the player put an avatar on screen and move it around with an Xbox 360 game pad. Love it. It's simple...it tells you exactly which file is handling game pad input...but it doesn't suggest that you are making a game of any particular type. It just tells you where to find and edit the code that responds to player input.
I feel like, if I were making a non-shooter game, I would have to remove everything that the base game templates have put in place in order to get back to basics and just have a playing field and way to respond to player input.
Maybe the base templates should be:
These could be made to be very basic and non-suggestive as to the type of game being made. A structure this basic would lead the tutorials in a pretty intuitive way.
This is total newb stuff...and I get that. Maybe I shouldn't be so dumb when it comes to T3D, but I am having a hard time with the signal to noise ratio. I don't really get what parts of what I'm reading and doing apply to all games (or Torque inherently) and what parts apply to the game types that are being "force fed" to me by the stock game templates.
I am a learner who wants to be shown the minimum requirements and learn the mechanics (that's a personal preference). Then I will use my understanding of the minimum requirements to tie in with the mechanics to make my game.
All that being said...I'm really having a lot of fun with this, and this is not meant to be a slight. I know that GG is working very hard on the docs. I also understand that empty rooms and vacuums with no player avatar might be a turn off to someone who really wants to see activity on the screen immediately. Some people will never pick it apart and know or care what the stock TorqueScript code is doing for them...some people will forever be content to just let those things do what they do. But that's not me...I'd like to have less done for me and learn how to do all those things myself. It's the difference between being given a fish and learning how to fish, I guess.
More to come...
There have been some stumbling blocks for me while trying to learn the 3D engine, and I've never truly committed myself to seeing my way past them.
I'm a bit more patient now...and the docs have come a long way, and I've decided to take another crack at it.
I'm reading through the docs, following faithfully...even when the subject matter seems to lie in the "common sense" realm. Over the next few weeks/months or as long as it takes, I'll post my findings here for anyone who cares to read, help, or learn.
1. The product page...
Every product that GG supports should have a product page like the new T3D product page. Not really sure that any more needs to be said about this...it's pretty tight and really had access to everything you'd need both as a customer as well as a developer.
2. The documentation is getting much much better...
But I think it leaves out some things that are maybe common knowledge amongst the Torque savvy and probably even echoed a million times in the forums. For example, I've read through the TorqueScript overview and syntax guide, but I still don't know how the TorqueScript process begins. I don't know if there's a "main" function that gets called somewhere that sends TorqueScript into a game loop that processes each frame. I know that it's happening, but I don't know where it starts.
As a developer (especially one trying to hunt down and fix a bug) the entirety of the stack trace is often the only way to fully appreciate why some of our code seems to be misbehaving. If I don't know where the whole process begins, then it can be tough trying to find the whole picture.
This may be mentioned later in the docs, but I have not seen it in the overview or the syntax guide. In my opinion, I should have seen it by now.
3. The tutorials are a bit broken now...
I went through the Changing The Player tutorial which looks like it was made for Gideon and the Boombot. Problem is, that it doesn't work any more.
The rocket launcher no longer works as described in the tut, and I couldn't find the Boombot asset (the missing asset wasn't really a big deal...a little common sense can get you around this).
Also, I chose to substitute Gideon for the Boombot. I started the tutorial with the new soldier model as my player avatar, and I changed him back to Gideon...this worked to replace the character, but for some reason Gideon seemed to be cycling through every animation he had in his repertoire. This I could overlook, but it didn't give me the feeling that I was "doing it right."
When you're making an effort to learn something new...step-by-step instructions that don't work can be a bit of a pain and a discouragement.
4. What does Torque know (or need to know) about my game?
As I was going through the tutorials, I found it a bit confining that TorqueScript and the "PlayerData" datablock seemed very concerned about my character/avatar. I don't know how much of this is due to the template I chose to use (Empty vs. Full), but I just got the feeling that it "cared too much" about my game. This may be why Torque has the reputation that it can only be used for FPS titles.
The PlayerData and DefaulPlayerData blocks, make assumptions that I have a player that can jump, shoot, take damage when landing, etc. That made me a bit claustrophobic. The fact that I still don't know what .cs files house these data blocks makes me just shy of infuriated. I went to the project folder and did a search for "PlayerData" and "DefaultPlayerData" but did not find any matching files. This lead me to believe that these might be defined in the engine code itself...which made me a bit more concerned about how much Torque was playing Big Brother over my game.
Never highlight a problem without proposing a solution...
Item #2 in my list above could probably be remedied with a quick intro (early in the TorqueScript guide) of how TorqueScript works as part of the game engine. Explain how the TorqueScript calls originate from the engine and become part of your game's functionality. Does the engine have a pointer to a "TorqueScript Arbiter" and once each frame, the engine tells the arbiter to update everything? Does the engine start a TorqueScript virtual machine that just has its own memory space and runs a confined loop without having to be told by the engine when to update everything? I don't know...but I'd like to know.
Item #3 is an elbow-grease item. Someone just needs to go over the tuts and validate their reliability. It's a thankless job fit for an intern.
Item #4...I think this is a case of Garage Games wanting to provide some minimally useful functionality to actually start a proper game. This seems like it's trying way too hard and has gone well past the point of minimally useful and into the realm of "YOU WILL DO IT THIS WAY!"
I will refer to another GG product...one which I've grown pretty fond of and familiar with despite its recent demise. Torque X does a great job of providing the developer with a very simple...movement component that let's the player put an avatar on screen and move it around with an Xbox 360 game pad. Love it. It's simple...it tells you exactly which file is handling game pad input...but it doesn't suggest that you are making a game of any particular type. It just tells you where to find and edit the code that responds to player input.
I feel like, if I were making a non-shooter game, I would have to remove everything that the base game templates have put in place in order to get back to basics and just have a playing field and way to respond to player input.
Maybe the base templates should be:
- Indoor Game: A game template with a box as an interior.
- Outdoor or Indoor/Outdoor Game: A game template kind of like the one we already have with a terrain to navigate.
- Empty Game: A game template that is (you guessed it) empty.
These could be made to be very basic and non-suggestive as to the type of game being made. A structure this basic would lead the tutorials in a pretty intuitive way.
- Here you have the "game world" that you've created (or the vacuum in the case of the empty game).
- Let's add a player character.
- Let's add gravity.
- Let's add a bad guy.
- Let's add a game piece to your 3D chess game that's floating in the vacuum of the "Empty Game" template because the empty game template doesn't know what the crap gravity is.
This is total newb stuff...and I get that. Maybe I shouldn't be so dumb when it comes to T3D, but I am having a hard time with the signal to noise ratio. I don't really get what parts of what I'm reading and doing apply to all games (or Torque inherently) and what parts apply to the game types that are being "force fed" to me by the stock game templates.
I am a learner who wants to be shown the minimum requirements and learn the mechanics (that's a personal preference). Then I will use my understanding of the minimum requirements to tie in with the mechanics to make my game.
All that being said...I'm really having a lot of fun with this, and this is not meant to be a slight. I know that GG is working very hard on the docs. I also understand that empty rooms and vacuums with no player avatar might be a turn off to someone who really wants to see activity on the screen immediately. Some people will never pick it apart and know or care what the stock TorqueScript code is doing for them...some people will forever be content to just let those things do what they do. But that's not me...I'd like to have less done for me and learn how to do all those things myself. It's the difference between being given a fish and learning how to fish, I guess.
More to come...
About the author
#2
I know these days that might not be considered a "proper gaming rig," but it's probably better than the average PC in the average household.
The game levels/missions take quite a while to load. That concerns me for the projects I'm playing with now that basically have terrain and 1 character.
I don't know if this is because I'm running debug builds...or maybe because the TorqueScript needs to compile.
I've never played a commercially-released game based on Torque 3D, but what is the vibe on this? Is this a non-issue...or is this something that could become serious to someone making a complex game product?
Thoughts would be great on this.
06/05/2011 (10:48 am)
Another afterthought that popped into my head after I posted this blog...I have a (fairly) beefy rig. It's a 2.8GHz x 6 core box, with 4GB of RAM, and SATA drives at 10K RPM.I know these days that might not be considered a "proper gaming rig," but it's probably better than the average PC in the average household.
The game levels/missions take quite a while to load. That concerns me for the projects I'm playing with now that basically have terrain and 1 character.
I don't know if this is because I'm running debug builds...or maybe because the TorqueScript needs to compile.
I've never played a commercially-released game based on Torque 3D, but what is the vibe on this? Is this a non-issue...or is this something that could become serious to someone making a complex game product?
Thoughts would be great on this.
#3
Are you a novice T3D user yourself? How are you finding the stock product templates?
I have to be fair...I'm reading the docs...but I've got the game engine open the whole time. I'm going back and forth between the docs, reference guides, tutorials, and the game and editors themselves. I don't know if that's a function of ADD...or if it's the way the docs are constructed that are leading me all over the place like that.
06/05/2011 (10:55 am)
@Andy...thanks for making me feel like I might not be a total idiot. ;)Are you a novice T3D user yourself? How are you finding the stock product templates?
I have to be fair...I'm reading the docs...but I've got the game engine open the whole time. I'm going back and forth between the docs, reference guides, tutorials, and the game and editors themselves. I don't know if that's a function of ADD...or if it's the way the docs are constructed that are leading me all over the place like that.
#4
I am back with Torque as I think it is the best engine for it's price.
To your question: I find the stock templates not too bad. But as you say, what is clearly missing is more step by step guides for novice useres:
- Cameras: how to set up sidescrollign cameras, rts cameras, fps cameras (this is partially done in the docs)
- how to create your own avatar (in the new docs, however I could not try it yet, and after I read your experience I was astonished that despite it's brand new docs, they contain mistakes...this is very bad for new users)
- how to set up a basic enemy
- how to create physics shapes
- how to create menus and in game hud
- how to load/save
- Create a grappling hook
- Make changes to the player (C++)
- create a flying vehicle and use it
Basically it would be nice to have lot's of such small "how to docs". To be fair, the community has done a few of them, but it should come from GG and be maintained by GG.
I think GG really has the best engine for the price. What they absolutely need to do is improve on the docs even more, so that the experience for new users is better. Then they will stay. I know I will this time around.
Ron, if you are coming from TX, you will see that T3D is not built upon components, but it uses the inehritance model. Therefore, a lot of the core functionality for the player is actually defined in C++, and if you want to change it, you need to change it in C++. This still makes the engine harder for beginners than some other engines out there. But still, you really get a really capable engine for the price.
06/05/2011 (11:42 am)
I have a licences for many Torque products for many years, and also others like unity. I am one of the guys who has a dream in his head of creating a game. The problem so far is that I never just stayed with an engine and really learned it. I was tinkering with TGE, when there was actualyl no useful docs at all. I got frustrated and changed to antoher engine....same happened with the other engines so I came back again, went again....all that I learned is that really the grass is not greener on the other side ;-)!I am back with Torque as I think it is the best engine for it's price.
To your question: I find the stock templates not too bad. But as you say, what is clearly missing is more step by step guides for novice useres:
- Cameras: how to set up sidescrollign cameras, rts cameras, fps cameras (this is partially done in the docs)
- how to create your own avatar (in the new docs, however I could not try it yet, and after I read your experience I was astonished that despite it's brand new docs, they contain mistakes...this is very bad for new users)
- how to set up a basic enemy
- how to create physics shapes
- how to create menus and in game hud
- how to load/save
- Create a grappling hook
- Make changes to the player (C++)
- create a flying vehicle and use it
Basically it would be nice to have lot's of such small "how to docs". To be fair, the community has done a few of them, but it should come from GG and be maintained by GG.
I think GG really has the best engine for the price. What they absolutely need to do is improve on the docs even more, so that the experience for new users is better. Then they will stay. I know I will this time around.
Ron, if you are coming from TX, you will see that T3D is not built upon components, but it uses the inehritance model. Therefore, a lot of the core functionality for the player is actually defined in C++, and if you want to change it, you need to change it in C++. This still makes the engine harder for beginners than some other engines out there. But still, you really get a really capable engine for the price.
#5
06/05/2011 (11:44 am)
HAve to add, as it might sound liek I am bashing T3D and the docs, that since Mich took over the docs department, they have improved quite a bit. And I am sure they will even more. I hope GG will now make a break in engine dev and spend some time on getting more docs.
#6
@GG & Mich...HUGE improvement on the docs...undoubtedly 10s of thousands percent improvement over the TGE non-docs.
My blog post for tomorrow (GG only allows one post per day) is already written and relates to the absence components and trying to find my game's heartbeat (which components encapsulated so well).
06/05/2011 (12:01 pm)
@Andy...thanks again for the deeper insight.@GG & Mich...HUGE improvement on the docs...undoubtedly 10s of thousands percent improvement over the TGE non-docs.
My blog post for tomorrow (GG only allows one post per day) is already written and relates to the absence components and trying to find my game's heartbeat (which components encapsulated so well).
#7
1. We went through all the T3D docs and made sure that what was there was accurate and up to date. (we also did this with iTorque, but we had a lot less time).
2. We added a few docs, sparingly, in the time that we had.
3. We converted the Torque 3D Product page into a sort of "T3D support Hub" - everything accessible in one place. FYI: this is still ongoing - what you see now was as much as we could get done by launch.
4. I personally worked with a few Torque developers, chiefly Dave Young, to create the Getting Started section. Its mostly geared toward beginners. It's not comprehensive, but it does fill in some of the gaps that really should be covered by our primary docs.
For example, we 'kind-of-sort-of' cover Ron's question in # 2 of the original post where he says:
If you look in the Getting Started Section, under Important Concepts > Exec'ing Torque Script, you can see I indirectly address that issue.
But the point still stands: We need to improve the docs much more to make the first 48 hour experience for people with no Torque knowledge much better. In doing that, we will be helping people who have intermediate and even advanced torque skills as well.
We should have step by step tutorials to help people get started. We actually have some video tutorials for beginners coming soon that didn't make the launch. Right now, Community tutorials are just made up of a few pulled from Resources. Our "Official" Tutorials are just sections pulled from our primary docs. But longer term, I'd like to see our Tutorials section take on a life of its own. I want it better organized. I want the menu on the left to be hierarchical by subject matter, and I want it to be search enabled. I think I'd like to get away from the reliance on Resources for community Tutorials. I *think* I'd like to see us create a dedicated tutorial format, with a submission process for community generated tutorials so that we can ensure quality is good (and avoid having 30 different tutorials that cover the same subject). I'd like to see user voting or ratings on tutorials as well.
Docs and tutorials are a big priority for me. I have not wanted to say too much in the last few months because I wanted to have some tangible improvements to show the community before I started making promises. I hope that now that we have released the new docs, the new T3D Product page (ie "Support Hub"), and released a much more stable version of T3D with some cool new art, that I have credibility with you guys when I say that things are going to get even better.
But to really make things better, I need good feedback. So this thread is really important. I will be looking at it closely. I hope we can keep it structured and focused. The more it stays on topic, and the less repetitive posts, the better because I will be able to dial in on whats important more to you more easily.
06/05/2011 (12:24 pm)
I'm on the run today so I only had to skim through what has been posted so far. I am glad you find that the docs are much better. But as you can see they do still need improvement. Here is what we did (since I bought the Company): 1. We went through all the T3D docs and made sure that what was there was accurate and up to date. (we also did this with iTorque, but we had a lot less time).
2. We added a few docs, sparingly, in the time that we had.
3. We converted the Torque 3D Product page into a sort of "T3D support Hub" - everything accessible in one place. FYI: this is still ongoing - what you see now was as much as we could get done by launch.
4. I personally worked with a few Torque developers, chiefly Dave Young, to create the Getting Started section. Its mostly geared toward beginners. It's not comprehensive, but it does fill in some of the gaps that really should be covered by our primary docs.
For example, we 'kind-of-sort-of' cover Ron's question in # 2 of the original post where he says:
Quote:I don't know if there's a "main" function that gets called somewhere that sends TorqueScript into a game loop that processes each frame.
If you look in the Getting Started Section, under Important Concepts > Exec'ing Torque Script, you can see I indirectly address that issue.
But the point still stands: We need to improve the docs much more to make the first 48 hour experience for people with no Torque knowledge much better. In doing that, we will be helping people who have intermediate and even advanced torque skills as well.
We should have step by step tutorials to help people get started. We actually have some video tutorials for beginners coming soon that didn't make the launch. Right now, Community tutorials are just made up of a few pulled from Resources. Our "Official" Tutorials are just sections pulled from our primary docs. But longer term, I'd like to see our Tutorials section take on a life of its own. I want it better organized. I want the menu on the left to be hierarchical by subject matter, and I want it to be search enabled. I think I'd like to get away from the reliance on Resources for community Tutorials. I *think* I'd like to see us create a dedicated tutorial format, with a submission process for community generated tutorials so that we can ensure quality is good (and avoid having 30 different tutorials that cover the same subject). I'd like to see user voting or ratings on tutorials as well.
Docs and tutorials are a big priority for me. I have not wanted to say too much in the last few months because I wanted to have some tangible improvements to show the community before I started making promises. I hope that now that we have released the new docs, the new T3D Product page (ie "Support Hub"), and released a much more stable version of T3D with some cool new art, that I have credibility with you guys when I say that things are going to get even better.
But to really make things better, I need good feedback. So this thread is really important. I will be looking at it closely. I hope we can keep it structured and focused. The more it stays on topic, and the less repetitive posts, the better because I will be able to dial in on whats important more to you more easily.
#8
I can't stress enough...that despite being stumped...and often bewildered...I'm really engaged in this experience, and that's in large part to how far the product and docs have come. I'm having fun here.
I have faith that the product I paid for does just about EVERYTHING that I need it to do, and that I have full source code access to implement those things that it doesn't do yet. I just felt that it would be helpful on many levels for me to chronicle my learning experience.
I expect feedback from the whole spectrum of "hey, idiot, you do that this way..." to "yeah...that kinda confused me too."
Admittedly, Erik...I've been bouncing back and forth between the docs and the tutorials section...and I've barely even touched the "Getting Started" section. I will add that page to my rotation of spots that I check out while continuing to learn the product.
One other thing...I'm not trying to change the engine. I'm trying to learn it. My references to Torque X are just an example of how a similar experience has worked for me in the past. It gives me the opportunity to search for analogs in the T3D project. If those analogs don't exist, I'm hopeful that the TX references I make will at least paint a picture to the readers of what I'm trying to accomplish so that those more informed than me can maybe make a recommendation that will help me learn about this engine.
I already have a blog post written up for tomorrow's installment. I'm hoping to get past some of the initial bumps and start looking into how to implement gameplay mechanics from a general level.
@Erik...I never really thought about my "first 48 hours" as a T3D user. But you're absolutely right. If you build the buyers confidence that this is a product they can use and work with within the first couple days of usage, then they will stick with the product and recommend it to everyone they know.
06/05/2011 (12:42 pm)
@Erik...thanks for dropping by and huge...huge props for what Graham Software has done to inject immediate credibility into the future of Torque 3D.I can't stress enough...that despite being stumped...and often bewildered...I'm really engaged in this experience, and that's in large part to how far the product and docs have come. I'm having fun here.
I have faith that the product I paid for does just about EVERYTHING that I need it to do, and that I have full source code access to implement those things that it doesn't do yet. I just felt that it would be helpful on many levels for me to chronicle my learning experience.
I expect feedback from the whole spectrum of "hey, idiot, you do that this way..." to "yeah...that kinda confused me too."
Admittedly, Erik...I've been bouncing back and forth between the docs and the tutorials section...and I've barely even touched the "Getting Started" section. I will add that page to my rotation of spots that I check out while continuing to learn the product.
One other thing...I'm not trying to change the engine. I'm trying to learn it. My references to Torque X are just an example of how a similar experience has worked for me in the past. It gives me the opportunity to search for analogs in the T3D project. If those analogs don't exist, I'm hopeful that the TX references I make will at least paint a picture to the readers of what I'm trying to accomplish so that those more informed than me can maybe make a recommendation that will help me learn about this engine.
I already have a blog post written up for tomorrow's installment. I'm hoping to get past some of the initial bumps and start looking into how to implement gameplay mechanics from a general level.
@Erik...I never really thought about my "first 48 hours" as a T3D user. But you're absolutely right. If you build the buyers confidence that this is a product they can use and work with within the first couple days of usage, then they will stick with the product and recommend it to everyone they know.
#9
06/05/2011 (1:32 pm)
Quote:@Erik...thanks for dropping by and huge...huge props for what Graham Software has done to inject immediate credibility into the future of Torque 3D.Well I'd like to take all the credit, but its really been more about allowing the guys at GarageGames, like Mich and Eric, do the things they always wanted to do.
Quote:I just felt that it would be helpful on many levels for me to chronicle my learning experience.We need more guys like you doing exactly this. We (including me personally) are definitely listening.
Quote:I've barely even touched the "Getting Started" section. I will add that page to my rotation of spots that I check out while continuing to learn the productI view the Getting Started as a stop-gap measure. Ultimately we need to improve the primary docs. You may find a few tid-bits in the Getting Started section that help, but just because we have something there doesn't mean it shouldn't be in the primary docs. So please keep that in mind as you go. If you imagine that someday we will remove the Getting Started section, what do you think should be in our primary docs.
#10
One thing I'd like to float out there...just as an exercise that perhaps someone internally could take on as not only a documentation effort but as a "boundary identification" exercise; It'd be interesting for someone to write a "Pong" tutorial. 3D paddles and ball, but restricted to a single plane for 2D game play (for simplicity).
<MyHumbleOpinion>
I'd be curious to know how much "bloat" is in the game after it's done. I'm looking through some of these docs in much more detail and I'm seeing things like ShapeBase::applyRepair(), ShapeBase::getRechargeRate(), and ShapeBase::canCloak(). I doubt that ANY of that would be needed to make Pong.
It seems like the engine has built in "death" as a concept (that is not meant to sound dramatic or morbid). Things can be damaged and repaired, but not in all games. Some things just exist at full health until they don't exist anymore (like a captured chess piece). It seems wasteful to carry around all of this "damage management" functionality or "recharge" functionality (whatever that is) if none of it applies to the type of game I'm creating.
ShapeBase is the class from which Player derives, so that means all of that code makes its way down to my Player object. It just feels like too much...and since it's all there...I have to train myself to overlook what doesn't apply to my game while keeping in mind what does (signal to noise).
In fairness, ShapeBase::canCloak() is not implemented yet (at least the docs say that it is not), but I am curious why the game engine would ever support a cloaking mechanism? Isn't that the developers job? Now, exposing isVisible() or setVisibilityLevel() to adjust the alpha and make something translucent...that wouldn't pose a problem for me...that's a perfectly acceptable rendering engine feature.
I guess I'm not quite sure why the engine wants to provide me those features. Those are game specific features, that should be the job of the game developer to provide.
It's tough to know where to draw the line. Game engines should provide "world simulation" features, like the ability for objects to be affected by physics. But it's true there will be games that don't use physics at all, and rely on the code to position objects in the game world based on timing rather than laws of motion (a la Tetris).
</MyHumbleOpinion>
06/05/2011 (2:35 pm)
@Erik...Eric Preisz and Mich (and countless others, Scott, David) are doing a great job. I'm really glad you all collectively found each other and have made T3D 1.1 a possibility.One thing I'd like to float out there...just as an exercise that perhaps someone internally could take on as not only a documentation effort but as a "boundary identification" exercise; It'd be interesting for someone to write a "Pong" tutorial. 3D paddles and ball, but restricted to a single plane for 2D game play (for simplicity).
<MyHumbleOpinion>
I'd be curious to know how much "bloat" is in the game after it's done. I'm looking through some of these docs in much more detail and I'm seeing things like ShapeBase::applyRepair(), ShapeBase::getRechargeRate(), and ShapeBase::canCloak(). I doubt that ANY of that would be needed to make Pong.
It seems like the engine has built in "death" as a concept (that is not meant to sound dramatic or morbid). Things can be damaged and repaired, but not in all games. Some things just exist at full health until they don't exist anymore (like a captured chess piece). It seems wasteful to carry around all of this "damage management" functionality or "recharge" functionality (whatever that is) if none of it applies to the type of game I'm creating.
ShapeBase is the class from which Player derives, so that means all of that code makes its way down to my Player object. It just feels like too much...and since it's all there...I have to train myself to overlook what doesn't apply to my game while keeping in mind what does (signal to noise).
In fairness, ShapeBase::canCloak() is not implemented yet (at least the docs say that it is not), but I am curious why the game engine would ever support a cloaking mechanism? Isn't that the developers job? Now, exposing isVisible() or setVisibilityLevel() to adjust the alpha and make something translucent...that wouldn't pose a problem for me...that's a perfectly acceptable rendering engine feature.
I guess I'm not quite sure why the engine wants to provide me those features. Those are game specific features, that should be the job of the game developer to provide.
It's tough to know where to draw the line. Game engines should provide "world simulation" features, like the ability for objects to be affected by physics. But it's true there will be games that don't use physics at all, and rely on the code to position objects in the game world based on timing rather than laws of motion (a la Tetris).
</MyHumbleOpinion>
#11
I think the cloaking is a holdover from Tribes. There are a few little nooks and crannies that have stuck around from then. Like a switch to turn on certain red lights in the interiors -- I recall that was at least in TSE still.
It can be funny to try to decide where to draw the line between "engine stuff" and "script stuff". The line is generally the result of two specific centers of gravity: flexibility and performance. Want to give the scripters and artists more leeway? Generalize a feature and make it accessible to the script system. Need a feature to work fast? Move it into the engine itself. Iterate a thousand times during the development process and you get a bit of an uneven surface area, especially if pushing a _specific_ game.
Then if you're trying to systematize everything to a general-purpose engine later, you keep having to ask "what am I going to break when I pull this out"? Lots less breaks the more modular the design. One of the big reasons I appreciate the push to make the interior of the engine less interdependent.
W/R/T non-physics-sim games... I'm wondering if there isn't a place in the engine you can just write "GravitationalAcceleration = 0;". ("Just change the gravitational constant of the universe!" --Q, ST:TNG) That may or -- if you were lucky -- might NOT have unintended consequences. A space-flight-sim would need to start there, after all. (Hmm... and if I do that I can also add local gravities with pzones... [thinking aloud].)
(You could also make everything stay put more or less where you scripted it by increasing friction quite a bit. Hmm..)
I'm going to enjoy following along as you blog about T3D... I have a lot to learn, myself... I may do the same... :-)
06/05/2011 (4:18 pm)
@RonI think the cloaking is a holdover from Tribes. There are a few little nooks and crannies that have stuck around from then. Like a switch to turn on certain red lights in the interiors -- I recall that was at least in TSE still.
It can be funny to try to decide where to draw the line between "engine stuff" and "script stuff". The line is generally the result of two specific centers of gravity: flexibility and performance. Want to give the scripters and artists more leeway? Generalize a feature and make it accessible to the script system. Need a feature to work fast? Move it into the engine itself. Iterate a thousand times during the development process and you get a bit of an uneven surface area, especially if pushing a _specific_ game.
Then if you're trying to systematize everything to a general-purpose engine later, you keep having to ask "what am I going to break when I pull this out"? Lots less breaks the more modular the design. One of the big reasons I appreciate the push to make the interior of the engine less interdependent.
W/R/T non-physics-sim games... I'm wondering if there isn't a place in the engine you can just write "GravitationalAcceleration = 0;". ("Just change the gravitational constant of the universe!" --Q, ST:TNG) That may or -- if you were lucky -- might NOT have unintended consequences. A space-flight-sim would need to start there, after all. (Hmm... and if I do that I can also add local gravities with pzones... [thinking aloud].)
(You could also make everything stay put more or less where you scripted it by increasing friction quite a bit. Hmm..)
I'm going to enjoy following along as you blog about T3D... I have a lot to learn, myself... I may do the same... :-)
#12
I agree that there should be a way to "shut off" physics, or perhaps more effective would be a way to "bolt on" physics.
Maybe there is always a running physics simulation, but not all objects in the game are forced to be a part of it. Maybe some object has a physics management add-on that registers it in the physics simulation and tracks its position, rotations, movements, forces, and collisions with other physics objects.
Other non-physics objects could just exist in the game space and callbacks could be used to process collisions and/or entry into trigger zones in a physically unrealistic (or physically indifferent) way. For example, collecting a health kit has a lot to do with collision, but very little to do with physics. The collector of the kit might have to be part of the physics simulation while the health kit itself does not...but since they both exist as game objects, we'd still need the ability to detect collisions between them.
I'm enjoying this process and the discussion it evokes. Hopefully tomorrow's post will be equally thought-provoking.
06/05/2011 (6:19 pm)
@random...thanks for coming around and providing your input. I'll be putting up a second blog post tomorrow, so swing in and take a look.I agree that there should be a way to "shut off" physics, or perhaps more effective would be a way to "bolt on" physics.
Maybe there is always a running physics simulation, but not all objects in the game are forced to be a part of it. Maybe some object has a physics management add-on that registers it in the physics simulation and tracks its position, rotations, movements, forces, and collisions with other physics objects.
Other non-physics objects could just exist in the game space and callbacks could be used to process collisions and/or entry into trigger zones in a physically unrealistic (or physically indifferent) way. For example, collecting a health kit has a lot to do with collision, but very little to do with physics. The collector of the kit might have to be part of the physics simulation while the health kit itself does not...but since they both exist as game objects, we'd still need the ability to detect collisions between them.
I'm enjoying this process and the discussion it evokes. Hopefully tomorrow's post will be equally thought-provoking.
#13
With respect to the '48 hour experience' I would suggest that there needs to be a '2 hour experience' component. I purchased both T3D and T2D, not because I had any particular need, but rather a hedge on whether the documentation would improve before pricing changed. For me the biggest failure for many similar products is one of not addressing the need for the user to walk-through several workflows, independent of actual knowledge or understanding of the steps. Superficial by design. As an example I expect the following,
* what's required
* how to install (easy)
* Walk-through with TorqueScript just placing a cube or model on the screen. I don't need to understand any details, just the process. Next make it move followed by interaction with keyboard or other input device. Nothing complicated.
* The same for all other modes of accessing the engine
That out of the way, then talk about all of the cool stuff the engine has under the hood. In fact, I would go as far as suggesting that a collection of just basic tutorials leaves the user with the option of integrating for more complicated scenarios.
Finally, clean PDFs makes for a nice format; There is nothing wrong with linear flow of information, especially for the basics.
06/05/2011 (6:25 pm)
First, I have only skimmed what is written above.With respect to the '48 hour experience' I would suggest that there needs to be a '2 hour experience' component. I purchased both T3D and T2D, not because I had any particular need, but rather a hedge on whether the documentation would improve before pricing changed. For me the biggest failure for many similar products is one of not addressing the need for the user to walk-through several workflows, independent of actual knowledge or understanding of the steps. Superficial by design. As an example I expect the following,
* what's required
* how to install (easy)
* Walk-through with TorqueScript just placing a cube or model on the screen. I don't need to understand any details, just the process. Next make it move followed by interaction with keyboard or other input device. Nothing complicated.
* The same for all other modes of accessing the engine
That out of the way, then talk about all of the cool stuff the engine has under the hood. In fact, I would go as far as suggesting that a collection of just basic tutorials leaves the user with the option of integrating for more complicated scenarios.
Finally, clean PDFs makes for a nice format; There is nothing wrong with linear flow of information, especially for the basics.
#14
http://docs.garagegames.com/tge/official/content/documentation/Engine/Reference/classTSStatic.html
They're a "lightweight" rendering class, branched off fairly early in the inheritance tree but with a few bits of functionality (e.g., "time ticks") re-implemented there -- so they still participate in _some_ of the simulation and are script-able. They were meant for things like lamp-posts, trees, scenery, and generally elements of the environment that didn't move.
Or moved, with scripting help.
Which is the kind of thing you want in a puzzle-piece in a game where the puzzles pieces don't run about sniping the players.
I'd forgot it until earlier this evening... useful.
I like the idea of a blank game template. That emphasizes to me as a game designer, "Yeah, you could make an FPS/TPS/RTS .. or you could make, well, you know ABSOLUTELY ANYTHING .. just sayin'." (FPS was a natural first template since it gets requested a lot and since we're talking about the great-grandchild of the Tribes engine. But we all know this kid has possibilities.) A blank template is as intimidating as it is open, though. There's a lot of set-up handled by the scripts that you don't realize the engine isn't doing automatically [merely _capable_ of doing, flexibly, the way the script specifies] until you start to dig through the stack for both the client and the server. (They also look to be the kinds of things you need to revisit before launching a game but can largely skip for most of the prototyping.) Maybe a blank template would also be instructive in that it'd have only this housekeeping/scaffolding still there. Then maybe we'd see the line between it and the other templates more clearly.
Funny how the example of knowing which scripting file is the entry point came up. I remember encountering that rather distinctly, not in the docs, but in stumbling about and later reading a bit more. I remember learning there were command-line switches you could call which would select different games or change mods or so on, and that these weren't processed in the engine but instead in the top of the script. So I told Windows to search through the scripting files for a mention of one of the scripting options and started inspecting the file from there. "main.cs" is the entry point in the engine executable directory, and if you read it you can see the function which processes those command line switches -- very much like C/C++ programs do.
I'd say that over time my experience with Torque has been 1/3rd bumbling like this, 1/3rd book reading, and 1/3rd docs. Had I been more industrious and completed more work it would have been 80% learning by stumbling into things. Current state of the documentation, were it as good when I'd started, it would have been 50% reading the docs, might not've needed the books, and 50% stumbling like this. Looking forward to better documentation yet. Stumbling like this is incredibly useful and productive and .. never feels like it at the time and rarely results in moving a project forward. It's just great information later when you didn't know you needed it. Technically accurate and clear reference documentations let projects keep momentum. Technically accurate and clear tutorials let people familiarize, generate ideas, and gain momentum. I've learned they're both necessary with a product this complex.
Accurate tutorials in T2D were my friend. Especially the way the tutorials increased in complexity. The class reference section is my go-to... I should say the OFFLINE one that is downloaded with the install. The online one is missing a lot that the offline one has. I'll be taking myself through the T3D tutorials and other tours. It'll be worth it. Parts will be redundant, parts won't.
I _almost_ wish I weren't on vacation now. I'm that enthusiastic in wanting to play with T3D. Sadly, my notebook isn't good enough to run it -- only my desktop. (I dearly wish T3D's world editor weren't forced into windowed mode -- my notebook's "old" 8600M GPU runs well in full-screen, not so well in windowed mode.)
--random
06/05/2011 (9:06 pm)
Thought about using TSStatic for a Torque-tris-esque test game?http://docs.garagegames.com/tge/official/content/documentation/Engine/Reference/classTSStatic.html
They're a "lightweight" rendering class, branched off fairly early in the inheritance tree but with a few bits of functionality (e.g., "time ticks") re-implemented there -- so they still participate in _some_ of the simulation and are script-able. They were meant for things like lamp-posts, trees, scenery, and generally elements of the environment that didn't move.
Or moved, with scripting help.
Which is the kind of thing you want in a puzzle-piece in a game where the puzzles pieces don't run about sniping the players.
I'd forgot it until earlier this evening... useful.
I like the idea of a blank game template. That emphasizes to me as a game designer, "Yeah, you could make an FPS/TPS/RTS .. or you could make, well, you know ABSOLUTELY ANYTHING .. just sayin'." (FPS was a natural first template since it gets requested a lot and since we're talking about the great-grandchild of the Tribes engine. But we all know this kid has possibilities.) A blank template is as intimidating as it is open, though. There's a lot of set-up handled by the scripts that you don't realize the engine isn't doing automatically [merely _capable_ of doing, flexibly, the way the script specifies] until you start to dig through the stack for both the client and the server. (They also look to be the kinds of things you need to revisit before launching a game but can largely skip for most of the prototyping.) Maybe a blank template would also be instructive in that it'd have only this housekeeping/scaffolding still there. Then maybe we'd see the line between it and the other templates more clearly.
Funny how the example of knowing which scripting file is the entry point came up. I remember encountering that rather distinctly, not in the docs, but in stumbling about and later reading a bit more. I remember learning there were command-line switches you could call which would select different games or change mods or so on, and that these weren't processed in the engine but instead in the top of the script. So I told Windows to search through the scripting files for a mention of one of the scripting options and started inspecting the file from there. "main.cs" is the entry point in the engine executable directory, and if you read it you can see the function which processes those command line switches -- very much like C/C++ programs do.
I'd say that over time my experience with Torque has been 1/3rd bumbling like this, 1/3rd book reading, and 1/3rd docs. Had I been more industrious and completed more work it would have been 80% learning by stumbling into things. Current state of the documentation, were it as good when I'd started, it would have been 50% reading the docs, might not've needed the books, and 50% stumbling like this. Looking forward to better documentation yet. Stumbling like this is incredibly useful and productive and .. never feels like it at the time and rarely results in moving a project forward. It's just great information later when you didn't know you needed it. Technically accurate and clear reference documentations let projects keep momentum. Technically accurate and clear tutorials let people familiarize, generate ideas, and gain momentum. I've learned they're both necessary with a product this complex.
Accurate tutorials in T2D were my friend. Especially the way the tutorials increased in complexity. The class reference section is my go-to... I should say the OFFLINE one that is downloaded with the install. The online one is missing a lot that the offline one has. I'll be taking myself through the T3D tutorials and other tours. It'll be worth it. Parts will be redundant, parts won't.
I _almost_ wish I weren't on vacation now. I'm that enthusiastic in wanting to play with T3D. Sadly, my notebook isn't good enough to run it -- only my desktop. (I dearly wish T3D's world editor weren't forced into windowed mode -- my notebook's "old" 8600M GPU runs well in full-screen, not so well in windowed mode.)
--random
#15
Torque X didn't have great docs online, but it did have John Kanalakis' book which was incredibly helpful.
As for an empty template...maybe "empty" is a bit harsh. A new Torque X 2D game project gives you a black background and a GG logo that you can move around on the screen.
Maybe T3D could benefit from an empty space template with a single scene object put in place as a reference point, another scene object as an avatar, and a freely moving camera.
That would at least give you a reference point for how to place non-player scene objects in the game, how to place a player object in the game, and how to respond to player input.
It seems like maybe T3D has some missing parts between ShapeBase and Player that could have been made to have good general purpose without implying game type.
I will read up on TSStatic...but if TX is any good as a reference point, T2DStaticSprite (which I'm assuming is kind of a TSStatic analog) was not animated.
I will do more digging and post more learnings. Anyone interested, please feel free to share your experience here or make course corrections to my experience. For anyone savvy enough who thinks I'm heading down the wrong path...please advise!
06/06/2011 (5:13 am)
@random...I agree that the docs and tutorials being accurate can mean the difference between someone feeling confident that they are learning and continuing to move forward and someone just continuing and waiting for something to "click."Torque X didn't have great docs online, but it did have John Kanalakis' book which was incredibly helpful.
As for an empty template...maybe "empty" is a bit harsh. A new Torque X 2D game project gives you a black background and a GG logo that you can move around on the screen.
Maybe T3D could benefit from an empty space template with a single scene object put in place as a reference point, another scene object as an avatar, and a freely moving camera.
That would at least give you a reference point for how to place non-player scene objects in the game, how to place a player object in the game, and how to respond to player input.
It seems like maybe T3D has some missing parts between ShapeBase and Player that could have been made to have good general purpose without implying game type.
I will read up on TSStatic...but if TX is any good as a reference point, T2DStaticSprite (which I'm assuming is kind of a TSStatic analog) was not animated.
I will do more digging and post more learnings. Anyone interested, please feel free to share your experience here or make course corrections to my experience. For anyone savvy enough who thinks I'm heading down the wrong path...please advise!
#16
This ties directly into today's planned blog post. I'm going to do a bit more research on this guy.
I'm at work right now though...so maybe not today. Cursory glance, though, shows nothing about animations.
[EDIT: Follow up]
I just went through all the docs for GameBase and even though the docs suggest this object handles tick processing, it makes no mention of how to make it process ticks. ;)
Also...one pattern I see in the class reference guide that's a bit unnerving...the docs seem to highlight everything but the method name and signature. All the method docs look like this:
You see how the 2nd method blends in to the previous method's Notes section? It makes it tough to see where one ends and the next begins. Maybe boldface the method signature or add in some horizontal rules to separate one method from the next.
06/06/2011 (5:32 am)
The docs describe GameBase objects as:Quote:Base class for game objects which use datablocks, networking, are editable, and need to process ticks.
This ties directly into today's planned blog post. I'm going to do a bit more research on this guy.
I'm at work right now though...so maybe not today. Cursory glance, though, shows nothing about animations.
[EDIT: Follow up]
I just went through all the docs for GameBase and even though the docs suggest this object handles tick processing, it makes no mention of how to make it process ticks. ;)
Also...one pattern I see in the class reference guide that's a bit unnerving...the docs seem to highlight everything but the method name and signature. All the method docs look like this:
Quote:
return_type className::methodName(param0Type param0, param1Type param1)
Description.
Parameters:
Param list with description.
Returns:
Return value description.
Notes:
Notes about the method.
next_method_return_type className::nextMethodName()
Next method description.
Parameters:
Param list with description.
Returns:
Return value description.
Notes:
Notes about the method.
You see how the 2nd method blends in to the previous method's Notes section? It makes it tough to see where one ends and the next begins. Maybe boldface the method signature or add in some horizontal rules to separate one method from the next.
#17
Also, from what I know, ShapeBase is an excellent place to start for a generic player controlled object. It may have some useless functionality built in, but not in a limiting way. Another (more advanced) tutorial people might benefit from is deriving a new class and datablock from ShapeBase.
And now that it's been brought up, I remember one of the things I found I had to come to terms with while learning Torque was to not look for a full call stack, or main loop, or anything like that. Because so many things are a callback of a callback of a tick event or suchlike, I found that the correct question was not "where did this come from?" but rather "where did this just come from?."
The one thing, I'd say, that made learning Torque possible for me was Find In Files. For scripts I use TextPad, and set the search location to the game folder. For C++, visual studio's search in solution tool, or "go to definition" served that purpose. That way, I can trace the path of execution around all the various files, see where things are defined, and navigate the large codebase a little more easily.
As a final thought, even if you don't plan on doing any C++ coding, reading through one of the files can be pretty informative. I would recommend a "most derived" class, like maybe StaticShape, or if you want something a little more complex, Item.
06/06/2011 (9:19 am)
Speaking as a non-noob, I would still quite like to see a tutorial that starts with an empty folder (give or take a few art assets and the editor scripts) and builds it up step by step to a basic game. I imagine this would help people get over the initial "holy **** there are so many files" reaction.Also, from what I know, ShapeBase is an excellent place to start for a generic player controlled object. It may have some useless functionality built in, but not in a limiting way. Another (more advanced) tutorial people might benefit from is deriving a new class and datablock from ShapeBase.
And now that it's been brought up, I remember one of the things I found I had to come to terms with while learning Torque was to not look for a full call stack, or main loop, or anything like that. Because so many things are a callback of a callback of a tick event or suchlike, I found that the correct question was not "where did this come from?" but rather "where did this just come from?."
The one thing, I'd say, that made learning Torque possible for me was Find In Files. For scripts I use TextPad, and set the search location to the game folder. For C++, visual studio's search in solution tool, or "go to definition" served that purpose. That way, I can trace the path of execution around all the various files, see where things are defined, and navigate the large codebase a little more easily.
As a final thought, even if you don't plan on doing any C++ coding, reading through one of the files can be pretty informative. I would recommend a "most derived" class, like maybe StaticShape, or if you want something a little more complex, Item.
#18
Another handy function is "trace(true);" which will dump a list of every executing script function to the console ("trace(false);" turns this off).
Probably the biggest concept you have to wrap yourself around is that TorqueScript is an even-driven language rather than one that iterates constantly over a loop (for performance reasons there is no game loop exposed to script). The only "automatic" script that gets called is the main.cs file in the executable directory. Everything else is either directly called in a chain from there or is triggered by an in-engine callback (or a script scheduled event).
Just out of curiosity...in what ways is the Blank Template too complex? It just sets up a level with a single object (Ground Plane) and a free camera. Is it just that there is a lack of tutorials for taking that template and doing things with it (like spawning a player object or a static mesh)?
06/06/2011 (2:02 pm)
Using breakpoints in Torsion and walking through the callstack can be extremely enlightening.Another handy function is "trace(true);" which will dump a list of every executing script function to the console ("trace(false);" turns this off).
Probably the biggest concept you have to wrap yourself around is that TorqueScript is an even-driven language rather than one that iterates constantly over a loop (for performance reasons there is no game loop exposed to script). The only "automatic" script that gets called is the main.cs file in the executable directory. Everything else is either directly called in a chain from there or is triggered by an in-engine callback (or a script scheduled event).
Just out of curiosity...in what ways is the Blank Template too complex? It just sets up a level with a single object (Ground Plane) and a free camera. Is it just that there is a lack of tutorials for taking that template and doing things with it (like spawning a player object or a static mesh)?
#19
@Matt...I will certainly keep in mind that event-driven systems don't always have a very clear call stack. The asynchronous nature of it all can be a bit daunting to try to debug.
That being said, I've been a profession developer for around 17 years...so I've got the right skill set and experience...just not the right knowledge...yet. ;)
As for the blank template being too complex. It has a guy in it. And he has a gun. And he can jump. And his gun has 2 modes of fire. And the list kind of goes on.
It's possible that all of those things I mentioned are pretty easily "removable," but the notion I get is that they might not be so easy to remove and that you have to train yourself to ignore them if they don't apply to your game.
It's not complexity (I'm not sure that's the word I used) so much as it is just too much.
EDIT
I was wrong about the empty template. This might be useful for others to know...the "Emtpy Room" mission of the "Full" template is NOT the same as the "Empty" template.
@Matt...thanks for raising this here in the blog comments. I got the impression (from looking at the icons in the Toolbox) that these 2 were one and the same. They are not.
So that much being said...now what do I do? ;) Yes, Matt...I guess the next logical step would be to provide a tutorial that shows off some of what we can do with our empty space.
06/06/2011 (2:38 pm)
@Dan...thanks for the tips. My C++ is a bit rusty, but I have every intention of digging around in the engine code during this learning experience.@Matt...I will certainly keep in mind that event-driven systems don't always have a very clear call stack. The asynchronous nature of it all can be a bit daunting to try to debug.
That being said, I've been a profession developer for around 17 years...so I've got the right skill set and experience...just not the right knowledge...yet. ;)
As for the blank template being too complex. It has a guy in it. And he has a gun. And he can jump. And his gun has 2 modes of fire. And the list kind of goes on.
It's possible that all of those things I mentioned are pretty easily "removable," but the notion I get is that they might not be so easy to remove and that you have to train yourself to ignore them if they don't apply to your game.
It's not complexity (I'm not sure that's the word I used) so much as it is just too much.
EDIT
I was wrong about the empty template. This might be useful for others to know...the "Emtpy Room" mission of the "Full" template is NOT the same as the "Empty" template.
@Matt...thanks for raising this here in the blog comments. I got the impression (from looking at the icons in the Toolbox) that these 2 were one and the same. They are not.
So that much being said...now what do I do? ;) Yes, Matt...I guess the next logical step would be to provide a tutorial that shows off some of what we can do with our empty space.
#20
There has since been some valuable exchange in this thread that I have not had the time to digest and experiment with.
Rather than continue to go blindly through my original train of thought...I'm going to take a look at what's being posted here and see if I can use that to some effect.
Matt's highlight about the Empty template is a good reveal. I was (wrongly) under the impression that the empty room in the full template was the same as the empty template. This is not the case.
I will try to stay engaged during the week, but I have a busy day job and might not post much until this weekend.
06/06/2011 (3:09 pm)
I'm going to back off my next blog post. It was pretty much written about 3 hours after this one.There has since been some valuable exchange in this thread that I have not had the time to digest and experiment with.
Rather than continue to go blindly through my original train of thought...I'm going to take a look at what's being posted here and see if I can use that to some effect.
Matt's highlight about the Empty template is a good reveal. I was (wrongly) under the impression that the empty room in the full template was the same as the empty template. This is not the case.
I will try to stay engaged during the week, but I have a busy day job and might not post much until this weekend.
Torque Owner Andy S.
Default Studio Name