Your preference for a new Template project? - Opinions/Discussion
by Michael Hall · in Torque 3D Professional · 08/06/2011 (11:46 am) · 18 replies
I've been sitting on a few different Template projects for a while now, and have considered submitting a couple of them as Resources.... but first, after the many requests over the past 2 years for a simpler template project, I feel that a standard for an even emptier "Empty" Template should be discussed.
I think most of you would agree that reducing the layered package structure would be of benefit to everyone. Simplifying the game scripts of the Empty Template is trivial, but there remains a lot of "fluff" in the core scripts that can safely be removed or reduced in complexity. My question to all of you is just how simplified would you want such a Template?
About the core: my current projects have had the core package stripped out - my game is not a mod on top of GG scripts! Back when TGE was packaged with several side-by-side projects in the same directory it was logical to have the common directory which contained the scripts and assets that were universally applicable. It's an almost perfect setup for in-house demos and testing prototypes, but this common / core concept has gotten more and more bloated over the years and is technically redundant with the advent of the Project Generator -- and many newcomers find it overly complex and unintuitive -- so I would rather see it gone! The Template itself obviates the need for separation of the commonly used functionality.
However, there are about 30 source code files, and 40 tools scripts that contain hardcoded references to images, textures, and shapes located in the "core/art" directory -- somewhat acceptable in the source but pure laziness (if not poor design) doing so in the Tools. To keep things fully compatible with stock code I was considering leaving those assets required by the source and the tools where they are and removing or transferring everything else to a "game files" directory.
What I'm looking at doing right now is a new Template project that retains the all of the package and mod functionality, the argument parsing, necessary initialization code, and all optional engine features, but only have an absolute minimum of game script. Game script, in my mind, is that which is necessary to kickstart level loading, dropping a player into a level and spawning a camera (or player object) with controls, and nothing more Theoretically, the setup I have in mind would be genre agnostic yet easily adjusted to suit a variety of game types.
This would be a basic, yet Full Template. This in turn would be followed by a stripped down to a very minimalist kick-start the engine and "give me nothing but a blank canvas" Empty Template. You can technically get things going with a main.cs containing a few lines of script for canvas creation with a default gui profile, some default preferences, and basic one-channel audio initialization. This minimal approach would forgo networking examples, scene creation, and postFx.
Any comments or feedback is welcome and will help structure this for the majority. Estimated timeframe will be from now to soon-ish and no later than eventually.
I think most of you would agree that reducing the layered package structure would be of benefit to everyone. Simplifying the game scripts of the Empty Template is trivial, but there remains a lot of "fluff" in the core scripts that can safely be removed or reduced in complexity. My question to all of you is just how simplified would you want such a Template?
- Retain all stock argument parsing?
- Tools access?
- Mod functionality?
- De-layer the core / game packages?
- Single player? Multiplayer?
- Client-server separation, or does it matter?
- What stock GUIs should be kept? Console, frameOverlayGui (for metrics), options dialog, loading gui, etc, etc, ... more? Less?
- Any thoughts or preferences about directory structure?
About the core: my current projects have had the core package stripped out - my game is not a mod on top of GG scripts! Back when TGE was packaged with several side-by-side projects in the same directory it was logical to have the common directory which contained the scripts and assets that were universally applicable. It's an almost perfect setup for in-house demos and testing prototypes, but this common / core concept has gotten more and more bloated over the years and is technically redundant with the advent of the Project Generator -- and many newcomers find it overly complex and unintuitive -- so I would rather see it gone! The Template itself obviates the need for separation of the commonly used functionality.
However, there are about 30 source code files, and 40 tools scripts that contain hardcoded references to images, textures, and shapes located in the "core/art" directory -- somewhat acceptable in the source but pure laziness (if not poor design) doing so in the Tools. To keep things fully compatible with stock code I was considering leaving those assets required by the source and the tools where they are and removing or transferring everything else to a "game files" directory.
What I'm looking at doing right now is a new Template project that retains the all of the package and mod functionality, the argument parsing, necessary initialization code, and all optional engine features, but only have an absolute minimum of game script. Game script, in my mind, is that which is necessary to kickstart level loading, dropping a player into a level and spawning a camera (or player object) with controls, and nothing more Theoretically, the setup I have in mind would be genre agnostic yet easily adjusted to suit a variety of game types.
This would be a basic, yet Full Template. This in turn would be followed by a stripped down to a very minimalist kick-start the engine and "give me nothing but a blank canvas" Empty Template. You can technically get things going with a main.cs containing a few lines of script for canvas creation with a default gui profile, some default preferences, and basic one-channel audio initialization. This minimal approach would forgo networking examples, scene creation, and postFx.
Any comments or feedback is welcome and will help structure this for the majority. Estimated timeframe will be from now to soon-ish and no later than eventually.
About the author
Been dabbling with game-programming since the age of 10 when I got my first computer, a Commodore. Got serious about game-development after modding Tribes for several years. Doesn't sleep much. Drinks rum. Teaches guitar. Plays cello.
#2
Even for "FPS" creators there are some design decisions in the starter FPS kit that i can't wrap my head around.
+1 again for the "well commented part"
08/06/2011 (8:36 pm)
That would be really cool! +1Even for "FPS" creators there are some design decisions in the starter FPS kit that i can't wrap my head around.
+1 again for the "well commented part"
#3
I just started with Torque on monday and still try to figure out how all those scripts are working together. IMO the standard "empty" template is really messed up.
All I want in an "empty" template is an empty screen, haha.
"Core" and "Art" should be using one folder just because I don't see any advantages of this folder structure.
Anyway, I think that an more empty emtpy-template would help a lot to learn how to script, where to put your scripts and overall; how this thing works together.
08/07/2011 (2:05 am)
Sounds like an really good idea!I just started with Torque on monday and still try to figure out how all those scripts are working together. IMO the standard "empty" template is really messed up.
All I want in an "empty" template is an empty screen, haha.
"Core" and "Art" should be using one folder just because I don't see any advantages of this folder structure.
Quote:Client-server separation, or does it matter?As far as i understood it, the client-server structure is needed, or not? If not, would be nice to separate this.
Quote:Single player? Multiplayer?Single player would be more useful for beginners.
Anyway, I think that an more empty emtpy-template would help a lot to learn how to script, where to put your scripts and overall; how this thing works together.
#4
08/07/2011 (7:13 am)
Thoughts on a Full template:Quote:Retain all stock argument parsing?Keep just enough to show an example of how to implement.
Quote:Tools access?Yes, a commented line that includes the tools directory (assuming tools is separated out fully).
Quote:Mod functionality?No. Leave this as a resource or tutorial.
Quote:De-layer the core / game packages?Definitely!
Quote:Single player? Multiplayer?Hmmm... maybe need 2 full templates?
Quote:Client-server separation, or does it matter?I don't think it does, and if you look at the current scripts for full there is a lot of bleed over. I think the directories should be set up by function (ie all AI functionality within an 'ai' directory), not by client/server separation.
Any thoughts or preferences about directory structure?
Quote:What stock GUIs should be kept? Console, frameOverlayGui (for metrics), options dialog, loading gui, etc, etc, ... more? Less?This is a tough question, but console, definitely. The loading gui/etc can all be done with hardcoded values in script attached to simple buttons and commented for the programmer to figure out how to use. This would be easier than stepping through the current ad-hoc implementations for the level choosing/etc and trying to figure out what is REALLY needed. For the game I am developing, I have re-built every script based gui as they all have issues, be it bugs, UX problems, or just poorly thought out implementation.
#5
08/07/2011 (8:02 am)
Client-server functionality mirrors the way the single and multiplayer versions of the system work. I think this should be emphasized because many people post with questions about single player games and why do they need a server, etc. Obfuscating this distinction would, in my opinion, cause further confusion for new users.
#6
Keep in mind that there are hardcoded references to assets in the core directory that will require a re-compile if my example completely removes them. Some people don't like modifying the tools scripts, but those would have to changed as well - unless it's preferred that I make changes for the new Template beforehand?
Currently I have the core scripts and the game scripts merged. No re-factoring as yet since I'm trying to remember what all was absolutely necessary, what was (and still is) useful, and what is fluff.
08/07/2011 (10:09 am)
Quote:Given some of the commenting that was written for some of the newer things in T3D's version of the scripts, I'm probably not the best person to ascribe "well commented" to ;)
A clean, refactored, pared down, well commented 'Full' template...
Quote:The client-server structure I was referring to deals more with the script organization than the actual client to server process that the game uses.
As far as i understood it, the client-server structure is needed, or not? If not, would be nice to separate this.
Quote:That is a result of the bloated and convoluted separation of "commonly used scripts" and "game scripts" that GarageGames has used over the years, which in my opinion is an obsolete distinction for T3D - especially since a good sized chunk of what should be game-specific script & gui got merged into the core.
"Core" and "Art" should be using one folder just because I don't see any advantages of this folder structure.
Keep in mind that there are hardcoded references to assets in the core directory that will require a re-compile if my example completely removes them. Some people don't like modifying the tools scripts, but those would have to changed as well - unless it's preferred that I make changes for the new Template beforehand?
Currently I have the core scripts and the game scripts merged. No re-factoring as yet since I'm trying to remember what all was absolutely necessary, what was (and still is) useful, and what is fluff.
#7
By the way: I made my own Level Editor (World Editor, Terrain Editor and GUI Editor) because i like it to separate Editor and Game. This way i have only the files i need and NOT the stuff from the editor.
To your question: A minimal template makes only sense if you separate Editor and Game.
08/07/2011 (1:05 pm)
@Michael Hall: I had the same problem as beginner. The amount of scripts was not very user-friendly. So i made for both TGE and TGEA my own framework from scratch. Sure, it is more work but in the end i have a very clean framework. By the way: I made my own Level Editor (World Editor, Terrain Editor and GUI Editor) because i like it to separate Editor and Game. This way i have only the files i need and NOT the stuff from the editor.
To your question: A minimal template makes only sense if you separate Editor and Game.
#8
08/11/2011 (11:19 am)
So is there a template out in the wild that is minimal. I have tried to gut and having nothing but issues. Seems like everything is tied in very nicely.
#9
GG seems to be really trying to attract the FPS creators ( which is understandable, look at the e3, every studio and their dogs are making a FPS or TPS game ), which is kinda making it hard for those who don't wanna do an FPS, or who are just trying to learn the ropes in general.
I think they need a empty template, a menu template, a gameplay template, and a full template
For an "Empty Template" I want just a blank black screen, with no function, no menus or buttons, no key bindings, nothing.... And no code from the c++ part.
For a "Menu Template" just show how to navigate menus with buttons, change text and images, and such.
For a "Gameplay template", i would just want them to show how to load a level, load a terrain, set the camera, how to spawn a model, how to make that model move, and how to make that model show different animations. But nothing game specific.
A full template would be a combination of all of them
ALSO, i want the editor to be an external game-independent tool.
08/12/2011 (5:10 pm)
I so agree with this.GG seems to be really trying to attract the FPS creators ( which is understandable, look at the e3, every studio and their dogs are making a FPS or TPS game ), which is kinda making it hard for those who don't wanna do an FPS, or who are just trying to learn the ropes in general.
I think they need a empty template, a menu template, a gameplay template, and a full template
For an "Empty Template" I want just a blank black screen, with no function, no menus or buttons, no key bindings, nothing.... And no code from the c++ part.
For a "Menu Template" just show how to navigate menus with buttons, change text and images, and such.
For a "Gameplay template", i would just want them to show how to load a level, load a terrain, set the camera, how to spawn a model, how to make that model move, and how to make that model show different animations. But nothing game specific.
A full template would be a combination of all of them
ALSO, i want the editor to be an external game-independent tool.
#10
- Client/server - yes keep them seperate not everyone will want to ship server code with their game and it helps people understand which elements are client side and which are server side.
- Editors/tools - haven't tried this but can't you just delete the tools folder before shipping a game to remove the editors anyway, if so it's fine the way it is.
- Core folder - kill this, it bugs me too having to remember which scripts are in core and which are in other folders.
08/13/2011 (2:28 am)
My thoughts:- Client/server - yes keep them seperate not everyone will want to ship server code with their game and it helps people understand which elements are client side and which are server side.
- Editors/tools - haven't tried this but can't you just delete the tools folder before shipping a game to remove the editors anyway, if so it's fine the way it is.
- Core folder - kill this, it bugs me too having to remember which scripts are in core and which are in other folders.
#11
As far as the Core folder, I think you're right. I have to change the server prefs in 4 different files right now because they're repeated all over and I don't feel like sorting them out or figuring out what order they're in....
08/13/2011 (6:25 am)
Indeed, by default the tools are not included in a shipping package and you won't need to really modify them much for most projects anyway.As far as the Core folder, I think you're right. I have to change the server prefs in 4 different files right now because they're repeated all over and I don't feel like sorting them out or figuring out what order they're in....
#12
I agree with Andy that it does help in understanding what is used by the server and client, but well-named functions and a few concise comments would get you there, too. I can see the benefit, but it obviously is a major source of confusion, and if the point of this project is to reduce that as much as possible...
Another peeve of mine are the script files in the art folders. Those aren't art. It is just one more place to have to track down a function.
08/13/2011 (7:45 am)
The client/server separation is misleading, as evidenced by this very discussion. The current server files are still required for single player games - the server just runs locally and does not permit outside connections.I agree with Andy that it does help in understanding what is used by the server and client, but well-named functions and a few concise comments would get you there, too. I can see the benefit, but it obviously is a major source of confusion, and if the point of this project is to reduce that as much as possible...
Another peeve of mine are the script files in the art folders. Those aren't art. It is just one more place to have to track down a function.
#13
For arguments, tools, mods, multiplayer, and guis you could have a little utility where you check off boxes of what you want and it puts together the template for you.
@Larry: The problem with the blank-screen-nothing template is it would be useless except as the starting point of a tutorial, code for starting a menu, creating and/or connecting to a server, local or otherwise, loading missions are things that basically 100% of games need.
An editor - game separation wouldn't be too hard actually, just look at how the T3D launcher starts into the editor, and separate all that code out.
@Jameson: There shouldn't be any functions in there, just datablocks and materials.
Also FYI, find in files is your best friend. Get Textpad or Notepad++.
I think the problem being that every game has different requirements, a tick-the-box template creator would work out best for everyone.
08/13/2011 (11:22 pm)
Core / game separation is good, because typically stuff in the core folder does not need to be modified. Although some of this could be rearranged, and the distinctions clarified, which should clear up the confusion for most people.For arguments, tools, mods, multiplayer, and guis you could have a little utility where you check off boxes of what you want and it puts together the template for you.
@Larry: The problem with the blank-screen-nothing template is it would be useless except as the starting point of a tutorial, code for starting a menu, creating and/or connecting to a server, local or otherwise, loading missions are things that basically 100% of games need.
An editor - game separation wouldn't be too hard actually, just look at how the T3D launcher starts into the editor, and separate all that code out.
@Jameson: There shouldn't be any functions in there, just datablocks and materials.
Also FYI, find in files is your best friend. Get Textpad or Notepad++.
I think the problem being that every game has different requirements, a tick-the-box template creator would work out best for everyone.
#14
Torsion has find in files too, think it's my most used function in any IDE I use and certainly gets my vote for most useful function EVER!
I like the idea of tick box to select which elements to include, it could even go as far to allow you to select which art assets to include i.e. Gideon, Soldier, Boombot as my first step with the templates was removing the ones I didn't want.
08/14/2011 (2:22 am)
Unfortunately all too often I have to modify the core scripts too, some of which could be helped by cleaning it up.Torsion has find in files too, think it's my most used function in any IDE I use and certainly gets my vote for most useful function EVER!
I like the idea of tick box to select which elements to include, it could even go as far to allow you to select which art assets to include i.e. Gideon, Soldier, Boombot as my first step with the templates was removing the ones I didn't want.
#15
08/21/2011 (7:44 am)
PhysX template is required, with so little information available in the documentation(atm) there is little advice on getting PhysX working correctly and quickly. 
#16
08/21/2011 (7:48 am)
In all honesty, I think that people would learn more by having templates documented, even if its the GG full template. The engine and TS docs nicely list functions and explain how, but very little explains why
#17
Right now at this time I'm doing very little Torque related development. My new dream job working as a studio musician keeps me out of action in a rock 'n' roll lifestyle :) But it's looking like the studio has a couple of weeks of downtime next month, so if motivation (and lack of rum) strikes I'll work on this again.
And if I "document" anything I will most likely just write up a couple Resource style tutorials on starting from a blank, empty template that is nothing more than an art directory, a couple of scripts (could do it as one file (main.cs), but organization is cool too!), and the stupid core/art crap that's hardcoded in the engine. These will be the only requirements to get you started on an app that does nothing. From there comes subsystem (audio, graphics, etc.) initialization, then menu building, and eventually loading a non genre-specific level for world building. Just don't expect anything until nearer to Christmas time! We're recording now so I've got to go.
11/22/2011 (7:19 pm)
Just to update on this: I actually held off completing the planned Templates which where mostly complete at the time of my last posting. Thought I would wait for the changes/fixes/improvements I was expecting from what the 1.2 "ground up" tutorial would bring.... but now I see I could have finished them with little or no interference.Right now at this time I'm doing very little Torque related development. My new dream job working as a studio musician keeps me out of action in a rock 'n' roll lifestyle :) But it's looking like the studio has a couple of weeks of downtime next month, so if motivation (and lack of rum) strikes I'll work on this again.
And if I "document" anything I will most likely just write up a couple Resource style tutorials on starting from a blank, empty template that is nothing more than an art directory, a couple of scripts (could do it as one file (main.cs), but organization is cool too!), and the stupid core/art crap that's hardcoded in the engine. These will be the only requirements to get you started on an app that does nothing. From there comes subsystem (audio, graphics, etc.) initialization, then menu building, and eventually loading a non genre-specific level for world building. Just don't expect anything until nearer to Christmas time! We're recording now so I've got to go.
#18
Maybe I could finish it up, and follow up with a Resource guide on how to move the final bits of the core directory, and what will need to be changed to allow it, without forcing everyone to follow my chosen directory structure -- it's obvious by this very discussion that there is no consensus about desired organization.
03/24/2012 (2:04 pm)
Reminded of this again... no it was never finished. Part of that was frustration because the intention was to offer up a minimal functionality Template without affecting the source or the operation of the Tools mod. I chose to merge the core scripts into the game scripts moving or eliminating everything but some bits of the the core/art directory. To completely remove the core directory entails the need to edit the source and the Tools mod - which is an exercise in tedium. The core directory is so cluttered and unorganized I didn't want to merge into it.Maybe I could finish it up, and follow up with a Resource guide on how to move the final bits of the core directory, and what will need to be changed to allow it, without forcing everyone to follow my chosen directory structure -- it's obvious by this very discussion that there is no consensus about desired organization.
Torque 3D Owner Jameson Bennett
I think you're right on with your targets for 'Full' and 'Empty'. I feel this is far more important for beginners wanting to really understand the engine than the big fat FPS tute that is being produced for 1.2... There are plenty of tutorials on that stuff already, and marketing-wise keeps the engine pigeonholed as FPS only. Meh, not my decision, just seems to be the same approach rather than hunkering down and cleaning up the construction mess that has polluted TGE/TGEA/T3D since forever.
A clean, refactored, pared down, well commented 'Full' template as you describe would have shaved a year off of the time I've spent learning/misunderstanding/re-learning torque. No joke.