Really bothered by the Starter Kits

#21 Is your scenegraph named "mySceneGraph"?

#22 Stephen,

I don't really get how this exmple that you mentioned is bad documentation on Garages Games' part. Try this:

sceneWindow2D.getSceneGraph().setDebugOn(0);

I use both the 1.1.3 docs and the 1.7.2 docs frequently. The 1.1.3 docs are better for most of the scene object commands / console math but the 1.7.2 docs have muc better access to File Objects, Gui's and a bunch of classes I didn't even know existed before. That's just my opinion.

I started out using the Torque 2D Early Adopter when I was 13. I made Glatte with it. The most extensive game development I did prior to that was EB Worlds and Neverwinter Nights mods. You can find Glatte at my website: www.syrealgames.com. The best way to learn Torque is to make a game. You can't buy experience.

I love Torsion and TGB though sometimes when I'm frustrated with TGB I like to try to use the Game Maker demo, then I realize how much I like Torque again.

#23 I've changed the mySceneGraph name to the appropriate name for the scenegraph.
Under the Scene Graph Script, I gave the Scene the classname testScene when I was testing.
I then attempted to call it in the console using testScene.setDebugOn(1); and it came back to me that the function was not found.

#24 In the console of the TGB editor, or in your running game?

#25 Classnames are not object names. You cannot call a method on a class in that manner, only on the object itself.

#26 Why is it that 1.1.3 and 1.7.2 are so split up then?

#27 Running the Game.

#28 @Stephen
Then was I suppose to name it using the Name Field then? So maybe some clarification in the documentation is needed about this.
Instead of just saying to use the debug function you just need to call mySceneGraph.setDebugOn(0);
Say
To view the debugging information about a scene, first set the name of your scenegraph object to an appropriate name and then proceed to call the t2dscenegraph class function .setDebugOn(0);
For example, you name the scene desertlevel, you would be able to call the function through as desertlevel.setDebugOn(0);

#29

Quote:
To view the debugging information about a scene, first set the name of your scenegraph object to an appropriate name and then proceed to call the t2dscenegraph class function .setDebugOn(0);
For example, you name the scene desertlevel, you would be able to call the function through as desertlevel.setDebugOn(0);

Just going to jump in here...

That is not a documentation block. That's short-changing a very basic explanation of how object-oriented programming works in general.

Sufficient documentation for the method looks like this:

Quote:
t2dSceneGraph::setDebugOn( mask )

Enables debug rendering mode(s) based on the flags provided.

Valid flags are:
T2D_SCENEGRAPH_DEBUG_STATISTICS = BIT(0)
T2D_SCENEGRAPH_DEBUG_BOUNDING_BOXES = BIT(1)
T2D_SCENEGRAPH_DEBUG_MOUNT_NODES = BIT(2)
T2D_SCENEGRAPH_DEBUG_MOUNT_LINK = BIT(3)
T2D_SCENEGRAPH_DEBUG_WORLD_LIMITS = BIT(4)
T2D_SCENEGRAPH_DEBUG_COLLISION_POLYS = BIT(5)
T2D_SCENEGRAPH_DEBUG_COLLISION_HISTORY = BIT(6)
T2D_SCENEGRAPH_DEBUG_SORT_POINTS = BIT(7)

It is not the job of API documentation to explain the concept of an object any more than it is necessary to cite sources for 2 + 2 = 4.

#30 Funny then that the documentation doesn't go into that specifics. How do you deal then with people that don't have a background in say C++ or even for that matter Visual Basic?

#31 Let us assume you have two dogs in front of you, one called Bill and the other Ben. If you throw a stick and want Bill to fetch it, you'd say Bill.fetchBall(true); You could also say Dog::fetchBall(Bill, true); but you wouldn't just say fetchBall(true);, because the dogs get confused!

Edit: Object referencing is one of the biggest problems people face, you just have to make sure what you're referencing is what you want to reference.

I am terrible, I know.

#32 There's a semantical difference between object-oriented programming and C++. In other words, C++ is object-oriented programming, but object-oriented programming isn't solely C++. You don't need to have a background in C++ to grasp TorqueScript. I have no experience in C++ to speak unashamedly about, and yet I know TorqueScript quite well because I've used it a lot. Of course, a background in C++ is really helpful.

The block of writing you suggested to be included with the docs is a tutorial thing. You have to follow tutorials to grasp an understanding of such a complex tool as TGB. Reading the documentation isn't going to help at all until you start using the tool -- in this case -- making a game. Start by making a game you think you can make in one hour . . . it will probably take a week.

EDIT:

Haha, at least your post makes sense, Phil!

#33 Ok, then I will restate it this way. How would you sit down and teach someone to use TGB that has absolutly no programming experiance at all then.
Oh and Kevin, mine doesn't? My issue with the documentation, the tutorials, everything else I have said has not made sense?

#34 Not to be nasty or harsh, but you've been told in countless posts that the way to learn it is to do it. The beginner tutorials "fish", "asteroids" and others that escape me at this time on TDN and the help files that were included in the build should be more than adequate to get you going and experimenting on your own regardless of coding experience. If you cannot understand those simple tutorials then maybe this isnt the engine for you, and maybe your just not ready to start even thinking about making a game.

#35 @Brian Carter, just so you know many of those tutorials are broken and no longer work as they have not been updated. Some do, some don't, but there has been lots of frustration as to the tutorials.

#36 So would the solution to be is to get those tutorials fixed, the documentation organized(Not sure why the change of the format for behaviours, but it doesn't seem to flow with the rest of the documentation) and make everything nice and tidy.
I believe the answer is Yes.

#37 Chris,

Which tutorials are broken? I don't recall any of the tutorials included with TGB or the tutorials in the Tutorials and Reference Guides section on TDN not working. If you are refering to tutorials now located in the archive section of TDN, then they are there for a reason - they were written for an older version of TGB and may no longer work correctly.

TDN is a community maintained resource - keeping everything up to date is our responsibility, not GG.

#38 This may not be the best place for me to do so, but I'd like to throw my two cents in regarding the documentation on TGB.

Clearly, the folks at GG know the documentation is sub-par. It could be improved, perhaps a lot, and they have acknowledged that much.

Speaking from experience as a technical writer (for software in the banking and credit card industry, among other things), I can tell you that producing quality documentation is a time consuming and effort filled experience. There is no getting around that fact, even if it may not seem like such an involving task from the end-user side of things.

Having said that, the first thing I would point out deals less with the documentation itself and more to the organization and availability of the material. Locating the bits you want to uncover is, well, difficult at times. The documentation is often sparse, spread out from different sources/locations, and lacks cohesive organization (and a quality means to search that organization).

The search features for locating information here just sucks. Sorry, I had to say it.

What a reader of technical material wants, I think in the majority of cases, is to be able to quickly locate relevant information, even if it is complex and difficult to absorb once found. Nothing is more frustrating that spending time--making it wasted time--trying to locate what you need before you can even dive in and try to understand it.

Beyond that consideration, tutorials hold only so much value when it comes to technical documentation. Don't misunderstand me! Tutorials are excellent at what they are designed to for--making difficult, new, or disparate bits of information easier to comprehend. The problem with tutorials, as someone in this thread mentioned (I think), is that they can include information that is unimportant or otherwise lacking in use to a user that is more acclimated with the engine.

That is why the starter kits have a lower information value, generally speaking. Only a select group of users will find them of greatest use and most will be using those to get a leg up on something they already know how to do. That is, the kits are great prototype jumper cables used to shock something into existence quickly. Am I wrong on this count?

A better method, I think, is small but very focused code excerpts that provide single, general demonstrations of a function (or object's property or function). Each should have a very small code sample (or even two) showing the "how to" in explicit terms. These should then be partnered with denser text explaining the "why to use" importance of the function or object.

The result would cater to the two major groups of users--those seeking to understand "how to use" and those seeking to understand "why to use".

I know, for myself, that I'm often in the former "seek" mode (i.e., "how" mode) when I'm actually coding and I need a specific reference. The latter comes when I'm researching in a more meta context; when I want to understand better ways of accomplishing some larger goal, set of tasks, or functionality. To understand what is technically feasible or ideal.

I think that most people fall into the same modes during their own development process. Regardless the mode, all of the information needs to be quickly found or it is almost certain that frustration and anxiety will work under the skin of the user--that much can be almost guaranteed.

#39 Oh and for any doubters that I haven't been trying to do anything. This is a test project that I had come up with about two weeks ago. It uses the Fish to move around using the Xbox 360 Controller. It was also being used as a sort of playground. I came home and fixed it so that you can call the fishtest.setdebugon(0); command now.
Fish Test

#40 Stephen,

I apologize, my comment about not making sense was directed at my last post, not at your prior posts.