TGEA and Torque 3D

#1 Even if the structure of the common and/or game folder does significantly change there is no reason to hold off from learning what's there now. My directory structure looks nothing like the GG template, it doesn't even have a common folder. Anything script side and past the main.cs in your root directory is mostly a matter of how you want things organized. Even the main.cs can be rewritten on your own. From all of the hints and vague statements from employees and associates the source code and it's layout will probably see more of a change than anything else.

I say go ahead and study now and carry forward anything that you learn. Instead of modding the GG templates past, present, or future you can learn how to set up your own structure and make your game how you want it.

#2 I believe that Torque 3D is still a fair way off. I also believe that while there will be significant differences, there will be a huge number of similarities. Remember that Torque 3D will be built from the TGEA core.

Also, there is a great deal of value in keeping core features fairly familiar between the different engines.

#3 For Torque 3D we have already made some pretty deep changes to the directory structure (both at the SDK level and at the game level).

Mich is going to be spending the next chunk of his time documenting all of these changes. I might be able to persuade him to post that here when it is done.

#4 @Marcus - If the changes to the Torque3D directory structure are an immediate concern for you, I will post the appropriate documentation early.

By doing so, I hope I can help you while also getting some feedback on the quality of the doc.

#5 @Michael - I would love to see the documentation.

#6 Bookmark this thread: Torque 3D Documentation Discussion

I will unlock it so you can subscribe to it and post, when my next blog goes up (about 2 weeks).

#7 The first doc is available for viewing:

Torque3D Directory Overview.

Feedback is encouraged =)

#8 The documentation is good. But this sure does look like a painful porting process.

#9 @J.C. Smith - Not as bad as you think. The directory refactor might throw existing Torque users for a loop, especially ones that have been using it since TGE. However, individual project hierarchy is soooo much cleaner now.

I'll make sure we get a good porting guide ready for launch, or shortly after launch.

#10 The other thing to keep in mind is that we are making an effort to ensure that your existing projects will "just work" until you are ready to move to the new directory structure.

#11 @Matt: Now that would be great. Either way, if the upgrade is as nice as it sounds, then it would be worth porting. My thoughts were mainly just with all the different filenames and directory names wouldn't be an easy way to merge. The new directory structure does look more logical though, don't get me wrong.

#12 @Matt, Mich, From what I see there in the new structure we still don't have any place to easily put source art that is outside the main tree, allowing programmers to skip updating a crapton of useless max files and junk, unless I missed it. If not though, that's probably my #1 feature request :p.

#13 Ross I think part of the reasion there is because alot of teams, atleast the teams I work on, use a different system for source art then the main games structure. Alot of the teams I have been on tend to use SVN for source control and then a different application for all the artwork for the game. I've seen some use Perforce and some go with GridIron.

While I am in no way a artist I don't know the best system to use. But tossing in another folder to the mix just to hold source art doesn't seem like the best idea overall. I like to keep things clean and as few folders and files as possible.

#14 Michael, the new docs are looking absolutely awesome. Great work on the formatting. It makes reading and understanding what you have read much better. Kudos to all your hard work there.

Quote:But tossing in another folder to the mix just to hold source art doesn't seem like the best idea overall.

I agree. I tend to make my own folder structure anyway.

#15

Quote:But tossing in another folder to the mix just to hold source art doesn't seem like the best idea overall.

So a better idea is to have people that don't need source art waste time *every time* they update, downloading TONS of source art? It's even worse if you're trying to work remotely.

@Thomas, I know a lot of teams that put art source in SVN. It helps to have a top level folder to contain that stuff so that people that don't need it (programmers, level designers etc.) don't have to download GIGs of data for no good reason every time they update. Using a completely different (or commercial system) specifically for art seems pretty crazy to me. In any case, the folder structure wouldn't be significantly "cluttered" IMO by a simple folder for source art.

If you use a different system, it would be pretty trivial to simply not add the folder for source art to SVN (or whatever versioning system one might use). But I would definitely rather have GG put a folder of this nature in a place that makes sense in the hierarchy, rather than every individual team having to figure out where a good place for such a thing is by themselves.

By the logic of "I make my own folder structure" you might as well just not have a hierarchy at all. Why not just put every file in the root directory then, if you don't care about the hierarchy? (Yes, this is an exaggeration, but you get my point.)

I think we can all agree that such a thing would be undesirable.

#16 Handling raw assets is definitely 100% up to a team or individual developer. I've never seen another team set up their SVN or project folder the same as I have in the past. I wouldn't dream of pushing something like this on another project:

Docs
|-Design Doc
|-Tech Doc
|-Concepts
Assets
|-2D
|--Raw
|--Final
|-3D
|--Raw
|--Final
Projects
|-Tools
|-Prototypes
|-Ars Moriendi (Torque Project)
|-ZSB Shooter (Torque Project)
Website

See what I mean? I prefer to have base assets kept completely separate from my actual projects. Now, when it comes to absolutely Torque 3D specific (script files, DTS, terrain files), we should be the ones providing a hierarchy that makes sense.

#17 We did have an "art" folder in place at one point with the intention of pointing the artists to that for storing source art (since that is what we do internally in a lot of cases).

However, we found it to be confusing for non-pro developers. If we left it empty (a placeholder for the pros) then the inexperienced developers were confused by the existence of an empty folder called "art". If we put our source art into the folder then a lot of developers (inexperienced and experienced with little time to evaluate) struggled to figure out where the source art was when they were looking at the in-game art folders. We also had issues where we were duplicating textures in the source art folder (so it works in the tools) and in the game folder (so it works in game) which was becoming a logistical nightmare on our end.

In the end I made the call to just remove the empty source art folder and to expect that the developers experienced enough to know they need that separation (it does help!) would also be experienced enough to figure out the best location and naming scheme for their team.

#18 @Matt, fair enough.

@Mich, well I think that example tree is just overkill for anyone, but that's just my opinion :p