Request for this Scripting/File mess.
by Bo Bjering · in Torque 3D Professional · 05/01/2009 (6:07 am) · 12 replies
So, ive been looking into the source/coding ect in the T3D beta.
It might just be me, but it seems madly messy, so many scripts (.cs) files required in tons of folders all over the place.
I wanted to use my own directory structure (to make it more clean because of the side of my project), but without having to have script files [u]at all[/u] for the game.
Its quite ok for editor, but its still extremely messy.
What i cant grasps, is, why there isnt a "Directories.h" file or something where ALL base directories is setup and quickly editable.
Right now, there is some file links, directories spread out in the cpp/h files, directory links and resource links inside 20+ different script files, and so on and so on, it quickly gets very confusing.
I wanted to have (use) something like this for my project
ect ect..
You know, a clean working enviroment, for my game as its faster for the team to find what they need :)
Right now, you have to change several cpp,h files, main.cs, core/main.cs, and virtually any other script (cs) file.
Would have been smarter if a "Directories.h" file was there, with (excample)
String ShaderCoreDir = "shaders/common";
and in shaders.cs instead of
DXVertexShaderFile = "shaders/common/debugInteriorsV.hlsl";
have
DXVertexShaderFile = "%ShaderCoreDir%/debugInteriorsV.hlsl";
Or something :)
It might just be me who missed something, if some sort of quick system is already in like that, let me know :)
And, i know this is just beta, just thought ill throw in a concern of mine :P.
It might just be me, but it seems madly messy, so many scripts (.cs) files required in tons of folders all over the place.
I wanted to use my own directory structure (to make it more clean because of the side of my project), but without having to have script files [u]at all[/u] for the game.
Its quite ok for editor, but its still extremely messy.
What i cant grasps, is, why there isnt a "Directories.h" file or something where ALL base directories is setup and quickly editable.
Right now, there is some file links, directories spread out in the cpp/h files, directory links and resource links inside 20+ different script files, and so on and so on, it quickly gets very confusing.
I wanted to have (use) something like this for my project
Game Folder
/Data
/Textures
/Terrain
/Foliage
/Levels
/Shadersect ect..
You know, a clean working enviroment, for my game as its faster for the team to find what they need :)
Right now, you have to change several cpp,h files, main.cs, core/main.cs, and virtually any other script (cs) file.
Would have been smarter if a "Directories.h" file was there, with (excample)
String ShaderCoreDir = "shaders/common";
and in shaders.cs instead of
DXVertexShaderFile = "shaders/common/debugInteriorsV.hlsl";
have
DXVertexShaderFile = "%ShaderCoreDir%/debugInteriorsV.hlsl";
Or something :)
It might just be me who missed something, if some sort of quick system is already in like that, let me know :)
And, i know this is just beta, just thought ill throw in a concern of mine :P.
#2
IS this a c++ engine to 100% code (c++) a game in, or a .cs "scripting engine", because, i cannot see how you can possible make a game without scripting tons, c++ source code or not.
As i also have TGEA (didnt have for that long though) it has the same "problem" in my eye's, and i have never seen anyone actually make a game without using those script files *yet* (correct me if im wrong).
Well, i guess i can boil the question down to: is it possible to make a game without scripting (.cs) ?
05/01/2009 (8:03 am)
I have to ask this from you guys, as im kind of confused..IS this a c++ engine to 100% code (c++) a game in, or a .cs "scripting engine", because, i cannot see how you can possible make a game without scripting tons, c++ source code or not.
As i also have TGEA (didnt have for that long though) it has the same "problem" in my eye's, and i have never seen anyone actually make a game without using those script files *yet* (correct me if im wrong).
Well, i guess i can boil the question down to: is it possible to make a game without scripting (.cs) ?
#3
05/01/2009 (8:08 am)
Sure you can, just do everything the scripts do in your C++ source... But what would be the point?
#4
Thanks :)
Point is -> Code Control.
also i want a really clean game "programming" enviroment (also reason for my path issues in initial post), getting set up right in the beginning will save time in the end :)
Rather have a tidy c++ dev enviroment then 50 cs scrips flying around in directories all over (also i know c++, and not so much of the torque script stuff).
05/01/2009 (8:15 am)
@MichealThanks :)
Point is -> Code Control.
also i want a really clean game "programming" enviroment (also reason for my path issues in initial post), getting set up right in the beginning will save time in the end :)
Rather have a tidy c++ dev enviroment then 50 cs scrips flying around in directories all over (also i know c++, and not so much of the torque script stuff).
#5
05/01/2009 (12:08 pm)
Torque 3D has mostly the same game scripting/coding guts as TGEA... which all in all has been pretty much the same even since TGE. It's always been designed to use C++ and Scripting in conjunction with eachother, they each have strengths and you are supposed to use the strengths of both :) 
#6
05/01/2009 (12:17 pm)
There's a time for C++ code and a time to script. Your game should really make use of both. If you're concerned about "code access/control" you can always enable dso generation before release. Directory structures are subjective to the person in charge, the team, and the project in question. It is yours -- you can technically set it up however you wish.
#7
True about the directory structure is my choice, however, the issue for me is the links/directorys are (some of them) inside the cpp/h source files, scattered all around.
That makes it hard to find them all, it would have been much nicer if all "external" links/files links ect was all in 1 file, thats all im saying :).
Time for C++ and time for scrips, sure i can see that, but there isnt any samples on how to do it in c++ (and not so much script) any where.
I hope that will ofcourse change later on, as this is still beta i just wanted to touch the area and voice my concerns, while i have my chance :)
05/02/2009 (6:06 pm)
@MichealTrue about the directory structure is my choice, however, the issue for me is the links/directorys are (some of them) inside the cpp/h source files, scattered all around.
That makes it hard to find them all, it would have been much nicer if all "external" links/files links ect was all in 1 file, thats all im saying :).
Time for C++ and time for scrips, sure i can see that, but there isnt any samples on how to do it in c++ (and not so much script) any where.
I hope that will ofcourse change later on, as this is still beta i just wanted to touch the area and voice my concerns, while i have my chance :)
#8
There is some mixing between art and script files. Which is different than it use to be. The cs files you may be seeing in art folders are just for allocating datablocks, materials, guiprofiles, basically loading assets on startup that will stay around.
All your "real" scripts where you implement game logic, functions, callbacks, and all that will go in the aptly named "scripts" folder.
You can essentially ignore the core and tools folders, they contain some script files among other things, but are separated so as to be out of your way.
05/03/2009 (5:53 am)
There is some mixing between art and script files. Which is different than it use to be. The cs files you may be seeing in art folders are just for allocating datablocks, materials, guiprofiles, basically loading assets on startup that will stay around.
All your "real" scripts where you implement game logic, functions, callbacks, and all that will go in the aptly named "scripts" folder.
You can essentially ignore the core and tools folders, they contain some script files among other things, but are separated so as to be out of your way.
#9
Maybe some $Path variables would be useful for a few of these, but really it just isn't designed to be directory structure flexible and to do so would be a pretty big change. I'm having trouble even imagining what kindof massive side effects moving folders around might have.
05/03/2009 (6:18 am)
Oh I see what you mean now. Well, there are several folders that you don't have control over, like shaders, core, tools, levels. That leaves art and scripts. Those two you should have complete control over.Maybe some $Path variables would be useful for a few of these, but really it just isn't designed to be directory structure flexible and to do so would be a pretty big change. I'm having trouble even imagining what kindof massive side effects moving folders around might have.
#10
We will need full control over all directories ofcourse, and while at it we will work on creating our "own" pack content system to hold our data (we have the system, just need to implement it).
We will be using multiple maps pr level (not pack, and we will create that system for ourselves ofcourse as T3D dont support that out of box).
Lets just say it like this :
We need full control (and the engine does support it, somehow :P).
Thats of course why we bought a c++ engine w/ source code :)
And, we know we can have it with T3D, its just very messy to get a overview on the source code at this point, and the paths ect, thats why i wantet to throw in the pot to GG that "some" of us are not 100% going to script it all and use there set up directory structure's, but rather having our own structure and good documentation on the c++ part (why give source if no source help/comments/coding samples).
As i said 100 times before, this is beta, im fully okay with the engine at this point, i cant be anything else then :) but for final i had to "voice" my concerns for atleast my project plan concerns for the engine at this point.
05/03/2009 (6:34 am)
@JamesWe will need full control over all directories ofcourse, and while at it we will work on creating our "own" pack content system to hold our data (we have the system, just need to implement it).
We will be using multiple maps pr level (not pack, and we will create that system for ourselves ofcourse as T3D dont support that out of box).
Lets just say it like this :
We need full control (and the engine does support it, somehow :P).
Thats of course why we bought a c++ engine w/ source code :)
And, we know we can have it with T3D, its just very messy to get a overview on the source code at this point, and the paths ect, thats why i wantet to throw in the pot to GG that "some" of us are not 100% going to script it all and use there set up directory structure's, but rather having our own structure and good documentation on the c++ part (why give source if no source help/comments/coding samples).
As i said 100 times before, this is beta, im fully okay with the engine at this point, i cant be anything else then :) but for final i had to "voice" my concerns for atleast my project plan concerns for the engine at this point.
#11
05/03/2009 (2:35 pm)
In any case, a "Directories.h" would be a good idea for some low risk paths at least.
#12
A good many of the hard-coded paths from TGE/TGEa have been removed/fixed I hadn't realized there were still some left in there, so yeah I can see where that could cause some organizational difficulties.
05/03/2009 (8:58 pm)
Think of datablocks as being art assets -- all those particle, explosions, sounds, etc. It they weren't split up and you had like say a datablock editor, and you wanted to edit a datablock your script methods in the file could get overwritten with the old everything-in-one-scriptfile setup.A good many of the hard-coded paths from TGE/TGEa have been removed/fixed I hadn't realized there were still some left in there, so yeah I can see where that could cause some organizational difficulties.
Torque 3D Owner Bo Bjering
To save a tiny bit of time, make the toolbox "save" last choosen option for c++ source edit selection (vs2008 as i use, so i dont have to select it each time). would be nice :)