Minimal modular code
by Bil Simser · in Torque Game Engine · 06/21/2003 (12:50 am) · 3 replies
Hi guys,
Just bought the engine tonight. I've been signed up on GG for a year or so now and watching this engine with some anticipation. I was a little disappointed to see that the last version to grab from CVS was 2002 but hopefully the T2 engine will be a nice update.
As with all n00bs, I have a few basic questions. I've done searching through the site but can't seem to find any good answers so here goes:
1. There's been talk of a minimal example app rather than the one that comes with the engine. I'm interested in seeing this or rather knowing what you can remove without breaking anything. I'm really more interested in learning the engine by adding the pieces one at a time rather than "here's 10,000 options and tools just remove what you don't need". I'd rather see a Hello World type set of script files to get you started (with a big flat ugly looking terrain and no editors). Which leads me to...
2. I'd like to know how modular the common pieces are. For example, if I was to totally strip the system down could I just add the Terrain Editor component (and GUI one I suppose) to get that or is there an interdepency here that one depends on the other. I'm really trying to get to a nice stripped down working system which I can add to. Kind of like a shopping cart approach to getting my base game running. Add an editor here, some common files here and a blank mission to start.
3. Everything is in the example directory and is self-contained according to GG. So I can zip this up (or whatever installer I want to use) and that's the distribution of the game. However I'd like to know two things here a) is everything essential to the runtime of the game or can I ship just certain files (like compiled stuff) without providing all the source to scripts and b) is there some way to package these up into a WAD, PK3 or something at runtime so it would look at a PK3 file first and then any files in the path would override the packaged one. This would be my preferred way of releasing the files but do want the individual files during testing/development. Might make some code changes to support this if it isn't in there because I think it's useful.
4. I've been spending the better part of the day scrounging through the forums and code snippets and there's lots there. For the core part of the code (and maybe the common scripts) is any of this making its way back into the codebase for us licencees to use or is it up to us to patch our own versions. I'm finding that each game might need some features patched into the C++ code but for the most part a lot of the mods I see should be put back into the base code so everyone can use them (if they want). If they don't , just dont' invoke it in your scripts. Or will every licencee have his/her own patched code with whatever features they want? Is this really the optimal way to go here.
Thanks for your time and happy coding!
Just bought the engine tonight. I've been signed up on GG for a year or so now and watching this engine with some anticipation. I was a little disappointed to see that the last version to grab from CVS was 2002 but hopefully the T2 engine will be a nice update.
As with all n00bs, I have a few basic questions. I've done searching through the site but can't seem to find any good answers so here goes:
1. There's been talk of a minimal example app rather than the one that comes with the engine. I'm interested in seeing this or rather knowing what you can remove without breaking anything. I'm really more interested in learning the engine by adding the pieces one at a time rather than "here's 10,000 options and tools just remove what you don't need". I'd rather see a Hello World type set of script files to get you started (with a big flat ugly looking terrain and no editors). Which leads me to...
2. I'd like to know how modular the common pieces are. For example, if I was to totally strip the system down could I just add the Terrain Editor component (and GUI one I suppose) to get that or is there an interdepency here that one depends on the other. I'm really trying to get to a nice stripped down working system which I can add to. Kind of like a shopping cart approach to getting my base game running. Add an editor here, some common files here and a blank mission to start.
3. Everything is in the example directory and is self-contained according to GG. So I can zip this up (or whatever installer I want to use) and that's the distribution of the game. However I'd like to know two things here a) is everything essential to the runtime of the game or can I ship just certain files (like compiled stuff) without providing all the source to scripts and b) is there some way to package these up into a WAD, PK3 or something at runtime so it would look at a PK3 file first and then any files in the path would override the packaged one. This would be my preferred way of releasing the files but do want the individual files during testing/development. Might make some code changes to support this if it isn't in there because I think it's useful.
4. I've been spending the better part of the day scrounging through the forums and code snippets and there's lots there. For the core part of the code (and maybe the common scripts) is any of this making its way back into the codebase for us licencees to use or is it up to us to patch our own versions. I'm finding that each game might need some features patched into the C++ code but for the most part a lot of the mods I see should be put back into the base code so everyone can use them (if they want). If they don't , just dont' invoke it in your scripts. Or will every licencee have his/her own patched code with whatever features they want? Is this really the optimal way to go here.
Thanks for your time and happy coding!
#2
Thanks for the response. I was referring to the Tag Name in CVS (Release_1_1_2 07/25/2002 The latest development "snapshot". This is the currently recommended release.) from the CVS page. Looking at the time stamps on the source files they're from July 2002. I guess the HEAD has the latest stuff but I'm waiting for an official stable update.
As for the coupling, that's too bad but workable. I would have preferred an additive approach but I see your point of having to end up reeling in most of the code. I guess I just don't get a warm fuzzy when I accept a demo program (the fps dir) as the basis for my game. I would rather know exactly what's going on everywhere so in case something fails I'll know where it is because I put it there. Just a bit of a mindset switch for me.
I'll try out the zip approach and zip up the content, although I didn't see anywhere in the docs where this mentioned.
As for the submissions I thought inclusion into the HEAD was also for improving the engine, not just bug fixes. For example I think the vehicle code should have the addition of keyboard control (as one snippet posted) but maybe that's me. I don't see that as something game specific. Reading some threads there are those with hundreds of hours of work patched into the codebase. I had looked at GTE as a more community (controlled) codebase with specific games using whatever scripting snippets they need and the C++ code be something that keeps getting base features added to it that enhance things (like Radiosity, etc.).
Thanks!
06/21/2003 (7:05 am)
Hi JDThanks for the response. I was referring to the Tag Name in CVS (Release_1_1_2 07/25/2002 The latest development "snapshot". This is the currently recommended release.) from the CVS page. Looking at the time stamps on the source files they're from July 2002. I guess the HEAD has the latest stuff but I'm waiting for an official stable update.
As for the coupling, that's too bad but workable. I would have preferred an additive approach but I see your point of having to end up reeling in most of the code. I guess I just don't get a warm fuzzy when I accept a demo program (the fps dir) as the basis for my game. I would rather know exactly what's going on everywhere so in case something fails I'll know where it is because I put it there. Just a bit of a mindset switch for me.
I'll try out the zip approach and zip up the content, although I didn't see anywhere in the docs where this mentioned.
As for the submissions I thought inclusion into the HEAD was also for improving the engine, not just bug fixes. For example I think the vehicle code should have the addition of keyboard control (as one snippet posted) but maybe that's me. I don't see that as something game specific. Reading some threads there are those with hundreds of hours of work patched into the codebase. I had looked at GTE as a more community (controlled) codebase with specific games using whatever scripting snippets they need and the C++ code be something that keeps getting base features added to it that enhance things (like Radiosity, etc.).
Thanks!
#3
The OO design of Torque could be better but all in all it's some amazing code. I think you'll finf that by the time you're done with your game you WILL know all of the scripts fairly well. Instead of adding it by hand you'll find yourself making choose it or lose it decisions which end at the same result.
hmmm I thought that was documented somewhere it might just be somethign I learned while digging through the code. I've worked with Torque since Oct and I STILL find myself going "ohhhhh so that's how that works".
Submissions to HEAD are for improvements. There's a few problems though 1) Many people don't submit things for inclusion to head. They submit resources which are different beasts altogether. 2) The "improvement" is either a) not of general interest b) badly written c) revinvents the wheel. I've been through a lot of the resources, very few actualy made it into my tree.
06/21/2003 (7:16 am)
1.1.2 was frozen in 2002. Work is underway now to put together a 1.2 release with new demo apps and better doco. You might want to start getting familiar with the HEAD source now, there are signifcant differences and improvments.The OO design of Torque could be better but all in all it's some amazing code. I think you'll finf that by the time you're done with your game you WILL know all of the scripts fairly well. Instead of adding it by hand you'll find yourself making choose it or lose it decisions which end at the same result.
hmmm I thought that was documented somewhere it might just be somethign I learned while digging through the code. I've worked with Torque since Oct and I STILL find myself going "ohhhhh so that's how that works".
Submissions to HEAD are for improvements. There's a few problems though 1) Many people don't submit things for inclusion to head. They submit resources which are different beasts altogether. 2) The "improvement" is either a) not of general interest b) badly written c) revinvents the wheel. I've been through a lot of the resources, very few actualy made it into my tree.
Torque Owner J. Donavan Stanley
1) Unfortunatly the grpahics, simulation and network code and scripting engine are fairly tightly coupled. While a hello world type application migth be of some use, in reality if you started with a hello world application you'd end up having to re-add most of the things you stripped out to make the hello world app.
2) Short answer, not very. There are lots of interconnections throughout the engine. While it's certainly possible things could be done broken out, you'd have to do quite a bit of refactoring to do so.
3) On the client yout need, the client scripts, terrain files (and I think all other mdeia). The datablocks can live on the server since they get transmitted anyway. Torque does support zip files. Just zip them up including their directories put them where torque can find them and torque will pull your files from the zip. I pretty sure it also allows you to override the zip by placing a file where it belongs in the directory tree.
4) Short answer, you're on your own in most cases. Unless a resource has been submitted to GG for inclusion into the HEAD source chances are you'll never see it in Torque. For inclusion into HEAD a patch must: 1) Be general purpose. 2) Be bug free. 3) Solve a real problem (as opposed to something the engine could already do easily if you knew how) 4) Have the maintainer agree that he thinks it should go in.