Documentation request: how to set up an RPG/RTS HUD

#1 @Judy - Way ahead of you =)

I currently have my intern writing the code to perform project/unproject commands so you can use mouse click behaviors outside of just shooting. The point is to have a mouse click interact with terrain (placing decals and sending AI bots to a location), or click on an object to select it.

He will also code an interface involving more mouse interaction, such as moving a free cam in a direction when the cursor moves to a certain location on the screen.

His project is a collection of tasks with three major goals:

1. Address and fix long time Torque bugs
2. Add functionality users have been wanting in the stock engine for years
3. Combine with written documentation to show users how to extend the engine, create more complex scripts, and get a head start on certain game types.

This is not intended to replace the Genre Kits being released, but to introduce newcomers to the scripting/programming parts of Torque 3D.

How does that sound?

#2 I think it's a step in the right direction. From a purely business point of view, though, I'd be hiring a bevy of tech writers rather than making it the third priority of an intern. Unity just announced a 100% increase in customers over the last quarter (? or was it month?). Adobe lists Unity as one of the middleware engines on it's latest survey and Torque is nowhere to be found. You guys are falling behind. And what is it that Unity has that Torque doesn't? DOCUMENTATION!!! Read the forums, that is the only thing people talk about in terms of choosing Unity. It's easy to use because it's well documented.

But, my immediate and more pressing problem is how do I get my camera to move when I right press the mouse and drag it. Nothing I have tried is working.

#3 @Judy - Much thanks for the insight. The intern is a very competent programmer,, with Torque experience currently attending school for his master's degree. He knows how to program, and I have confidence in his abilities. This isn't a third priority, it is his first and current.


I'm the main doc writer for Torque 3D, and I've spent a solid year working on nothing but Torque documentation as my paid job. I would love to have a bevy of writers helping me, which would give me back my free time to make some games. However, it has been proven that one person can do the job. I'm not doing it alone, though. The Torque 3D developers are also helping me write documentation:

Sickhead Games - Provided e-mails and overviews for Scatter Sky, Terrain, Sun, Lighting, PhysX, etc

Chris Robertson - Aiding in the documentation of TSShapeConstructor, Shape Editor, COLLADA

Steven Garcia and Matt Langley - 1 on 1 Tools guidance and updates

Matt Fairfax - General managements and tutorial direction

I could keep going, but those who are helping me know who they are and have my eternal gratitude.

Torque 3D Developer Blog - Documentation

In regard to Unity vs Torque for documentation: My Thoughts

As I mentioned in the thread and the blog, Torque 3D in its beta form is already surpassing previous documentation efforts for our engines. I still have time until 1.0 ships, but when it does your concerns will be addressed.

#4 Completely off topic, but to address what you said about Adobe listing Unity as an engine:

1. Torque 3D (then TGEA) has been compared to other engines in publications dedicated to game development, including the Frontline Awards where it received the 2008 Engine of the Year award.

2. At Casual Connect, Torque was mentioned during 3rd party framework discussions every day. Torque 2D was chosen as the best game engine to make downloadable casual games, and more than oner person claimed Torque 3D has far more to offer than Unity 3D. I showed additional documentation to people at the show, and they were very happy to see what was being produced for it

3. Unity and Adobe share the same focus: penetration numbers. They also cater to the same core audience: artists. Unity 3D is good tool, but Adobe is not focused on game engines. I'm sure you have read other publications related to game development, such as Game Developer Magazine, which has given Torque high accolades.

This whole thread could break down to Unity vs Torque, but I just wanted to address the two main comparisons you made.

All in all, comparing documentation of one engine to another is trivial. I know good documentation is a deciding factor for a potential user, but I don't think they are interested in page count comparison between two completely different products. My goal is that by the time I'm done writing Torque 3D docs, this example scenario will ring true every time:

Potential User: "How well documented is Torque 3D?"

Existing User: "Probably the most well documented game engine available. You can preview it here: Official Docs"

Potential User: "Excellent. I don't have to worry about not knowing how to use the engine."

=)

#5 Michael, all the work sounds awesome. I myself was going to ask this same question for mouse click interfaces besides just shooting. I can't wait for this to finish because it will help our project in so many ways instead of coding it all ourselves.

#6 in the mean time, AFX alread provides alot of the functionality you are looking for for TGEA 1.8.1

#7 @Edward - Correct. AFX has the selection and GUI stuff handled already, but porting to Torque 3D will not be easy. As I said, part of these changes fix a few longstanding bugs in Torque as well. This will benefit other modules besides object selection. It will be more barebones, making it a bit more flexible.

#8 Michael,

I'm not trying to rag on you. The docs currently provided are miles ahead of what was there before and there is no question that you've done a great job. If anything, I'm on your side. My question isn't whether you can do the job or not. It's whether GG is investing enough money in documentation and making it a sufficiently high enough priority. The current docs cover about 1/4 of what I need to know to build a game with this engine. And next to putting art in the game, controlling the input device is pretty mission critical to game development.

In the meantime, I'll take anything you have on input controls. I'm stepping through GuiCanvas::ProcessInputEvent() and wondering why the mouse movements are getting processed, but not the mouse buttons. I have axisX, axisY, button0 and button1 bound. I have the cursor set to ON. Only axisX and axisY events are caught by ProcessInputEvent(). This is true in both the game AND in the editor (which has the correct functionality for what I want for the mouse, but none of the scripts indicate why that is since the keybindings for axisX and axisY on the mouse are identical in the editor as they are in the game. My current guess is that the bind is being overwritten by cursor being on, but that doesn't explain why ALL the bind events aren't overwritten, just some of them.

I'm sure I'll figure it out, but it would be really nice to get even rough drafts of pages that cover these things. As I said before, I'll help proof read them for you! And in the meantime I can just X out all the info in Programmer's Guide that is no longer remotely relevant which is a lot.

Judy

#9 @Judy - Did not think you were ragging on me at all =)

I'm sure if there was more room in the budget we would double up on every position from programmer, to docs, to QA, etc. As for priorities, usability (which includes documentation) is at the top of the stack...higher than any other.

As soon as the rough drafts for the input docs are ready, I'll make sure they are posted online.

#10 Totally cool.

In the meantime, I have found the solution(s) to the problem.

1) in PlayGui,gui under the block of code that starts:

%guiContent = new GameTSCtrl(PlayGui) {
[\code]

change the line [code] noCursor = "1";

to 0. This turns the cursor on.

2) in default.bind.cs add the following code (top of the file works)

function freelook( %val ) {   
   if( %val ) 
      canvas.cursorOff();   
   else 
      canvas.cursorOn();   
}
globalActionMap.bind( mouse, button1, freelook );

To give credit where it is due, I got this from http://www.garagegames.com/community/resources/view/16527 which explains how and why it works as well.

3. Delete config.cs. This was what bit me for the longest time. The moveMap in default.bind.cs was being overwritten by the moveMap in config.cs. The reason this worked in the editor and not in the game was that the editor pushed an editor map on top of the moveMap (another option if you want to do a lot of project specific mappings and still have the defaults).

I feel so much better now. I'm curious whether having the GuiCanvas::processInputEvent() return false if there is no action mapped on the mouse press while the cursor is active would wreak unexpected havoc. It would be more symmetrical in terms of following the "if there's no action associated, drop down". And since there is a forceMousetoGui flag that could prevent the drop down, it would make having a cursor on the screen infinitely simpler. Just a thought.

Judy

#11 OK. So part of the tutorial is finished. When the next build of Torque 3D is released, the tutorial will ship along with new engine changes that will make this possible.

So far we have:

1. Keybind toggle mouse cursor on and off. Off allows you to freelook with camera
2. Keybind spawns a dummy AI (for target practice)
3. Game starts with the player as an AI controlled bot
4. Right mouse click sends player bot to location click
5. Left mouse click will select an object and cause your player to attack it
6. Pressing space button will place a 3D object on the terrain where mouse cursor is located

Very rough beginnings to an RTS or hack/slash. We are going to clean it up further and implement the following in the tutorial:

1. Moving mouse to edge of screen causes camera to pan
2. Mouse wheel zooms in and out. Alternate keybindings for this as well
3. Left mouse button selects objects or causes player to attack another AI
4. Right mouse button moves player
5. Group selection of objects
6. Decal placement of waypoints

Maybe a few other things, but this tut and code will go out with the next release.

#12 Michael,
Thanks for all your efforts, and thank your intern on behalf of the beta community. T3D is coming out swinging.

Nice work :)

#13 Awesome work Mich - or really should that be awesome work Mr Unnamed Intern?

Excited about Torque 3D and the possibilities but not having enough time to play with 1/10th of the new features

#14 @All - The intern's name is Andrew. MattF and I share the same list of really cool game related code samples that would be beneficial (such as object selection) that would be fun to document. MattF kicked off the plan, I'll be managing and documenting, and Andrew will be writing the code.

So far, not only has he got the stuff I mentioned working, but he also discovered a bug that is causing a memory leak with TSGameControl. At any rate, this is just one project we have him on. You should see the full list =)

#15 In post #11 you mentioned a tutorial for a lot of the RTS functionality. Is that out yet? I could really use that at this time! Thanks!