When am I supposed to start my own project directory?

#1 Oh, I just realized I can change the default game it loads in main.cs... so what I did was copy the example folder to my deskot labled as my project directory, then deleted each of the game and mod folders except for common and tutorial.base which I renamed to "base" and edited main.cs to run from the base folder by default and it worked... so, basically I guess what I'm asking is this: is that what I'm SUPPOSED to do? :p

and then I guess just edit the script files from there and just compile new exe's from the cvs folder whenever I change any source code?

#2 There is no "supposed" to do with Torque - ALL the code is yours.
I think what you're doing is fine. I have my tests all using one folder (I combined common with starter.fps for example, and adjusted some scripts to all work with the one folder).

I think the key to knowing what you should do is knowing what you want to do. If you want a FPS and you're starting with tutorial.base, then doing what you've done is great. If you don't have a clear idea of a game but are still in "piddle" phase, then it doesn't really matter - the question becomes moot, as any folder structure would work equally well so long as your tests work.

-nerseus

#3 Right, sorry what I meant to say instead of "supposed to do" I guess is what is the recommended way of organizing things... anyway, I guess I'll just stick to what I'm doing for now. Probably once I just get into it and become comfortable with the engine and the scripts and stuff and actually know what does what, it'll be easier for me to get things together. So basically I think this thread was a complete waste of bandwidth... sorry. :P

#4

Quote:
So basically I think this thread was a complete waste of bandwidth...

Nonsense! This question is asked fairly often (once every couple months), but I've never really seen a great answer. Your solution looks really good. I haven't tested it, but if it works, it's very simple and understandable.

#5 I've been tinkering around with it, and actually I'd kindof like it set up so that there is no "common" directory accompanied by game or mod directories... is it possible to have the game run out of a single directory, like right next to the data, client, etc folders? Because it's getting frustrating to me to understand which folder the game is getting its data from sometimes - the game folder, or the common folder.

#6 Of course. "Just" merge what's in common with what's in the other directories. We set it up with a common directory so that we'd not have a lot of duplicated code between starter.FPS and starter.racing, but you're free to change it however you like.

#7 As I mentioned above, I've done this with very minimal changes (combined common with starter.fps). I think the only commonality is in the main.cs in both /common/ and /starter.fps/ (you'll have to manually merge, but it's not difficult). The only other issues I remember coming across were hard-coded paths to /common/. I fixed them by doing a search in files for something like "/common" or "common/" or something similar.

-ner

#8 @Correction: I would suggest you just stick with what works and stop trying to re-invent the wheel. The structure that Torque has out-of-the-box is pretty flexible one. Use common to keep the common stuff that your game will offer and start from tutorial.base, starter.fps, etc. and build on it for your game.

The advantage is that you'll be able to support a mod (like the show mod already included) and be able to add these in without breaking your current development tree. I find it difficult sometimes when some mod I find that I like requires that I change dozens of files in my base directory, only to find out that it doesn't work. Additionaly if you allow a user community to add to your game with ease.

If you're really bent on changing things, you can just merge tutorial.base (or whatever your starting point would be) into common and use that as your one and only game directory. I would not recommend trying to rebuild common from the ground up to start your game from scratch. Why? because probably in the end you'll end up with something like what's already there and have to go through the pain and suffering of finding all the little things you need for a singleplayer/multiplayer game setup. Just get to know the common files and how the game works first.

It's up to you in the end, personally I take the simplest route to solve a problem so if something is already done for me then I leverage that knowledge so I can focus on the issue at hand.

#9 Well the reason I want to combine them for one is to discourage modding of my game, and second because like I said before there are seemingly identical files in common and in the game folders, and I can't tell which ones will change the game when I change what they say... for example I had to change like three prefs.cs files before I finally got the screen resolution to change... it just seems alot more efficient and easier to understand if I'm running things out of one folder.

Anyway, thanks for all the replies. I've tried combining them but all I end up with is a DOS prompt that idles... I'm obviously not fixing up the main.cs right :p I'll keep playing around with this. I need to learn to script :x

#10 @Correction: Really it's a matter of understanding what the scripts are there for and why. They do have a purpose and are not just random bytes of filler.

Until you can master the script, the script will be your master (wow, that was profound)

Seriously though, it's like trying to do a lobotomy. You need to know how the brain works and what parts do what before you start cutting. Same with Torque. Get to know what scripts do what and why they're being called then you'll know that you really only have to change one file to get the resolution changed. It's neither rocket nor science, but taking random shots at moving files around will just produce a system that does nothing (like you've found).

#11 Yeah I know I only needed to change one file, but I'm saying I ended up changing like three before I finally found the right one... and you're right, it's just because I'm new to this and haven't gotten accustomed to it and learn how it all works, but it just seems like it'd be easier for me to figure out if it didn't all seem so... scattered about.

But yeah if it's alot of trouble, which it sounds and seems to be, I probably shouldn't worry about that right now. Besides, I guess if I really do get a big game going I'll eventually learn and understand enough to be able to change it later pretty easily, right? Thanks again for all the replies! :)

#12 Other than the prefs files, there isn't too much that's "duplicated" that isn't necessary. For example, you'll find main.cs and init.cs in each subfolder, but they allow a "plugin" type of architecture for building "mods". In reality, every game or tutorial you run is a mod - common provides the very basics of setting up client/server "stuff" and providing easy hooks into what it's doing.

Figuring out where and how to hook is the difficult part :)
Also note that are a *few* (maybe half dozen) functions that exist in common that will never get called. While very few, they can be misleading if you're reading code and see a call to functionA and find it in common/... only to find out there's another functionA in starter.fps/... and it's the one in starter.fps that's being called.

Because of that, I created some sequence diagrams that show the flow of scripts and the engine. They may or may not be helpful to you. If you want, I'd strongly suggest spending about 4-8 hours and walkthrough the scripts, more or less line by line, in the order the engine runs things. It will give you a much better sense of what the scripts provide and what's currently being used and, most importantly, how a "game" like starter.fps is using the hooks.

-ner

#13 Dan,

Great ideas. I'm going to spend the hours drilling down the scripts for sure. I was wondering (and hoping) that someone had diagrams of the process. This community rocks. The more I use the forums, the more I see people dedicated to helping others learn the engine.