Large Project Files in Torque?
by Nate "Nateholio" Watson · in General Discussion · 11/02/2003 (4:52 pm) · 4 replies
How hard would it be to implement the use of large project files using this format in Torque? Everything covered in that description is contained in one large project file. I imagine that not only would the rescource loading code have to be modified, but the engine itself would also need to be changed. So would it be worthwhile to continue down this path of data organization, or just completely forget about it?
About the author
#2
edit: Wow, you got Brian to reply. I'm impressed. Listen to him!
11/02/2003 (10:34 pm)
I think it would be a big pain for little gain... the mission format as is is very very flexible, and could easily do what you want.edit: Wow, you got Brian to reply. I'm impressed. Listen to him!
#3
If a project file were to be used it wouldn't be built until all of the add-on code and data for the first version of the game is ready to compile into a .PRJ. The general idea for this format for use in K96 has been around since mid 1997 (and in use before that) and is pretty well documented in the K96 design document (which goes all the way down to explanation of bytes) - the link above was a brief I typed up to post here on GG. K96's .PRJ format is really flexible and allows updates to the engine code, game data, and scripts to be made easily by a patching program. A big plus is engine updates won't be run if they've been corrupted because they're not part of the engine - they're subroutines that are loaded from the .PRJ when needed and checked for continuity. Also it allows for the game version to be rolled back for each update that was made, like uninstalling a Windows service pack. I'm hesitant to use scripts but thats mostly due to the fact that they're pretty new to me.
However, since both an employee and associate of GG posted with their opinions against it, I think I'll hold off on using a .PRJ format until the project is closer to completion, then possibly consider using it again.
11/03/2003 (5:23 am)
Thanks for the feedback. One of the big reasons for the idea of a .PRJ file was saving RAM space. If I remember correctly, I never saw a game .EXE that was bigger than 700K at the time, so the .PRJ would allow the game to load engine components as needed. For example, if a mission called for only land units, then just the code to handle land units would be loaded.If a project file were to be used it wouldn't be built until all of the add-on code and data for the first version of the game is ready to compile into a .PRJ. The general idea for this format for use in K96 has been around since mid 1997 (and in use before that) and is pretty well documented in the K96 design document (which goes all the way down to explanation of bytes) - the link above was a brief I typed up to post here on GG. K96's .PRJ format is really flexible and allows updates to the engine code, game data, and scripts to be made easily by a patching program. A big plus is engine updates won't be run if they've been corrupted because they're not part of the engine - they're subroutines that are loaded from the .PRJ when needed and checked for continuity. Also it allows for the game version to be rolled back for each update that was made, like uninstalling a Windows service pack. I'm hesitant to use scripts but thats mostly due to the fact that they're pretty new to me.
However, since both an employee and associate of GG posted with their opinions against it, I think I'll hold off on using a .PRJ format until the project is closer to completion, then possibly consider using it again.
#4
Ultimately you've got to make the choice as to using what you're most comfortable with Nate. From my perspective, I've done it both ways and much prefer scripting. Most of the PC game industry switched to it 3-4 years ago and haven't looked back. I think if you learn more about it, you'll really like the power and flexibility it has to offer.
11/04/2003 (12:29 am)
If you're concerned about RAM usage, the Torque is pretty good about loading data resources and scripts that are only used in whatever mission is running. Sure there will be some engine overhead for AI, physics, etc, but the amount of RAM that is taking up pales in comparison to most data resources like textures. Unless you are developing for a console or a system req. that is really tight on RAM, it's not worth the effort to dynamically load that code.Ultimately you've got to make the choice as to using what you're most comfortable with Nate. From my perspective, I've done it both ways and much prefer scripting. Most of the PC game industry switched to it 3-4 years ago and haven't looked back. I think if you learn more about it, you'll really like the power and flexibility it has to offer.
Torque Owner Brian Ramage
One of the biggest hassles with those large files is that your file format is going to change many times during development, no matter how much you think you have it locked down. Having to rebuild those files and synch them with the rest of your team is a pain even if they are next door, much less across the country.
Keeping things in smaller data files organized through scripts is probably going to be much easier to manage and it won't require engine changes, so you can put that time into developing the game instead of new file formats.