TGE 2.0 feature wishlist
by D Player · in Torque Game Engine · 03/07/2003 (2:48 am) · 69 replies
Alright, this thread is only about what changes/features you want to see in TGE 2.0, and the reasons. Now, other people seem to believe that the GG folk will descent from on high and tell us how things will be. Even if they have the time and inclination, this will turn out better if we discuss things. Let's find out what's good and what's bad. I'll start this thread off with features that I want to see.
1. A rearchitecting of TGE. I think we can all admit that the current engine is not well broken up into replaceable components, largely because many components are tightly coupled (either through #includes, or misplaced functionality). The real problem here is that to make any changes you have to read, understand, and take into account FAR too much code that will be inadvertently effected.
2. Reduce code duplication. There are plenty of places in the engine where the same thing is done in different places, ever so slightly differently. This could probably be simplified.
3. Assert. I've seen very little of this in use, Assert is an essential tool for catching bugs and logic errors. These need to be spread liberally throughout the engine. Also, these largely stand in for documentation in some cases. They stay both current and right in the code, while documenting the expected (pre)conditions.
4. Curved surfaces integrated tightly into a LOD system. Without curved surfaces, an artist created LOD system compensates for this lack at the cost of memory, effort, and visual quality.
5. Official replacement of cs with Python, or a performance analysis that shows this as being an unreasonable course of action.
6. Shaders; just because people will complain about this endlessly unless they are on the plan. At least the architecture to support shaders easily must be done.
7. More generic engine. TGE is really, truly a FPS engine. I realize that making something too generic will make it useless, but there is a lot of middle ground between here and there.
Also, what support structure do we need in place to get things happening?
1. Leadership that makes the final call on features and goals. This person needs to be cocky; don't allow decisions to be made by the community unless there is broad consensus. Just because one group browbeat another group into silence doesn't make them right. This person needs to understand the issues and make the calls. Good communication is a big plus.
2. A roadmap; a plan.
3. A group of core developers, who work on the most critical items
4. Checkin reviewers.
Seriously here, let's get this started. There is no reason to wait for others to do things that they may or may not get around to. If GG comes in and helps steer the decision making along with their insight, so much the better, but let's not depend on it.
1. A rearchitecting of TGE. I think we can all admit that the current engine is not well broken up into replaceable components, largely because many components are tightly coupled (either through #includes, or misplaced functionality). The real problem here is that to make any changes you have to read, understand, and take into account FAR too much code that will be inadvertently effected.
2. Reduce code duplication. There are plenty of places in the engine where the same thing is done in different places, ever so slightly differently. This could probably be simplified.
3. Assert. I've seen very little of this in use, Assert is an essential tool for catching bugs and logic errors. These need to be spread liberally throughout the engine. Also, these largely stand in for documentation in some cases. They stay both current and right in the code, while documenting the expected (pre)conditions.
4. Curved surfaces integrated tightly into a LOD system. Without curved surfaces, an artist created LOD system compensates for this lack at the cost of memory, effort, and visual quality.
5. Official replacement of cs with Python, or a performance analysis that shows this as being an unreasonable course of action.
6. Shaders; just because people will complain about this endlessly unless they are on the plan. At least the architecture to support shaders easily must be done.
7. More generic engine. TGE is really, truly a FPS engine. I realize that making something too generic will make it useless, but there is a lot of middle ground between here and there.
Also, what support structure do we need in place to get things happening?
1. Leadership that makes the final call on features and goals. This person needs to be cocky; don't allow decisions to be made by the community unless there is broad consensus. Just because one group browbeat another group into silence doesn't make them right. This person needs to understand the issues and make the calls. Good communication is a big plus.
2. A roadmap; a plan.
3. A group of core developers, who work on the most critical items
4. Checkin reviewers.
Seriously here, let's get this started. There is no reason to wait for others to do things that they may or may not get around to. If GG comes in and helps steer the decision making along with their insight, so much the better, but let's not depend on it.
About the author
#2
Surely you can just link the Cg runtime and call shaders from your render methods just like any other OpenGL call.
03/07/2003 (6:17 am)
I hate to go off the topic like this, but what does 'Shader support' or 'Cg support' even mean?Surely you can just link the Cg runtime and call shaders from your render methods just like any other OpenGL call.
#3
Some of the features I would like to see
1) (10 - 12 weeks) RTS/RPG game style, built into the engine. I spoke with Tim about this and he mentioned that it would be a decent addition. Make it modular so that it can or can not be used depending on developer need
2) (8 - 10 weeks) spruce up the eye candy; the first thing (_MOST_) gamers look at are the graphics and then they worry about game play etc.
3) ( 6 - 8 months) Modularize this puppy, make it like Nebula/CS/Jet. Developers can use what features that want when they want.
4) (6 - 8 weeks) make the exporters more user friendly, turn map2dif into a windown application.
Please keep in mind that these are my views and opinions and do not in any way represent the views and opinions of GG an or others in the community.
-Ron
03/07/2003 (6:22 am)
I agree with most of the above, althought I do not think we should focus on non idustry standard features (such as Cg). I think we setting ourselfs up for a let down if we go the way of Cg, personally I think GSlang will be vender inspecific and will have a better industry grasp than Cg.Some of the features I would like to see
1) (10 - 12 weeks) RTS/RPG game style, built into the engine. I spoke with Tim about this and he mentioned that it would be a decent addition. Make it modular so that it can or can not be used depending on developer need
2) (8 - 10 weeks) spruce up the eye candy; the first thing (_MOST_) gamers look at are the graphics and then they worry about game play etc.
3) ( 6 - 8 months) Modularize this puppy, make it like Nebula/CS/Jet. Developers can use what features that want when they want.
4) (6 - 8 weeks) make the exporters more user friendly, turn map2dif into a windown application.
Please keep in mind that these are my views and opinions and do not in any way represent the views and opinions of GG an or others in the community.
-Ron
#4
03/07/2003 (6:43 am)
A nice set of unit tests would be great so when modifying the c++ code you can see if you broke something quickly.
#5
03/07/2003 (6:52 am)
@Ron: At least the RPG "demos" should start shaping up soon. There's 3 of em underway at least 2 of them are open /shared source.
#6
Nice to hear that. Are they integrated into the HEAD? where a developer could choose to use them without hacking them in and or causing issues with a new co of the HEAD?
If I recall correctly, Tim mentioned something about mucking with the camera code etc to allow control over the player and camera at the same time.
Please do not take the above as flame ware or slander, just trying to get the point across that their are a fair number of RTS/RPG games being designed with TGE that could greatly use such an addition to TGE.
-Ron
03/07/2003 (7:28 am)
JD,Nice to hear that. Are they integrated into the HEAD? where a developer could choose to use them without hacking them in and or causing issues with a new co of the HEAD?
If I recall correctly, Tim mentioned something about mucking with the camera code etc to allow control over the player and camera at the same time.
Please do not take the above as flame ware or slander, just trying to get the point across that their are a fair number of RTS/RPG games being designed with TGE that could greatly use such an addition to TGE.
-Ron
#7
2.I'd like to see more of the "code snippits" getting checked into the engine.
3. Rather then adding another script language, I rather see an option to turn scripting off, if your like me (a slow learner) you are going to spend at least year learning script, and then you probably still wont fully under stand it.
4. the extra mods should be removed, racing, rw, show, and ziped up for optional downloading.
5. have you ever tried to code for q3? The q3 sdk lets you compile with batch files, it was very easy to do and didnt cost a dime. torque would realy benifit from someing like that.
[edit]
6. after reading this thread:
www.garagegames.com/index.php?sec=mg&mod=forums&page=result.thread&qt=6713
I think it would be a great idea if that kind of commenting support would be awesome.
03/07/2003 (7:37 am)
1. ok this aint a feature "wish" but i think there are things in the engine already that should be worked on, like: Sound, AI, player physics.2.I'd like to see more of the "code snippits" getting checked into the engine.
3. Rather then adding another script language, I rather see an option to turn scripting off, if your like me (a slow learner) you are going to spend at least year learning script, and then you probably still wont fully under stand it.
4. the extra mods should be removed, racing, rw, show, and ziped up for optional downloading.
5. have you ever tried to code for q3? The q3 sdk lets you compile with batch files, it was very easy to do and didnt cost a dime. torque would realy benifit from someing like that.
[edit]
6. after reading this thread:
www.garagegames.com/index.php?sec=mg&mod=forums&page=result.thread&qt=6713
I think it would be a great idea if that kind of commenting support would be awesome.
#8
1) Added physics so that when a player throws something it bounces and rotates.
2) Add a new realistically scaled human player model, with extra animations such as walk and crouch, including the required code to handle this. ;)
3) Fix the audio engine, but I believe that is already pencilled in. I couldn't get looping sounds working.
4) Property maps for terrain (and interiors?): I couldn't get these working.
5) Add an example of a vehicle with mounted weapon.
6) Add an example of a mounted weapon (not vehicle based).
7) Remove light map generation at runtime. ;)
I can't really think of anymore at the moment.
Cheers
03/07/2003 (7:46 am)
Hmmmm this is a toughy, as I'm sure there are loads of things I would like.1) Added physics so that when a player throws something it bounces and rotates.
2) Add a new realistically scaled human player model, with extra animations such as walk and crouch, including the required code to handle this. ;)
3) Fix the audio engine, but I believe that is already pencilled in. I couldn't get looping sounds working.
4) Property maps for terrain (and interiors?): I couldn't get these working.
5) Add an example of a vehicle with mounted weapon.
6) Add an example of a mounted weapon (not vehicle based).
7) Remove light map generation at runtime. ;)
I can't really think of anymore at the moment.
Cheers
#9
You don't happen to have links to these do you? I'd love to track their progress as I'm working on an RPG myself :)
03/07/2003 (7:47 am)
Quote:At least the RPG "demos" should start shaping up soon. There's 3 of em underway at least 2 of them are open /shared source.
You don't happen to have links to these do you? I'd love to track their progress as I'm working on an RPG myself :)
#10
Not an estimate for just getting it hacked in but for completed, debugged, polished, documented, professional code that you would not be embarrassed to say, "That is mine!"
Maybe people who have already posted can go back and add their estimates.
For Example:
1) (1 week) Add support for OpenWatcom
2) (8 weeks) Add Maya Exporter
03/07/2003 (9:02 am)
Just for fun as everyone posts their wishes include next to each item an estimate of how many weeks (whole weeks only, minimum 1 week) they believe it would take one person to complete that item. Be realistic.Not an estimate for just getting it hacked in but for completed, debugged, polished, documented, professional code that you would not be embarrassed to say, "That is mine!"
Maybe people who have already posted can go back and add their estimates.
For Example:
1) (1 week) Add support for OpenWatcom
2) (8 weeks) Add Maya Exporter
#11
Excellent idea, I went back and added estimates to mine. I added a fair amount of fudge to account for project slippage etc.
-Ron
03/07/2003 (9:08 am)
Rick,Excellent idea, I went back and added estimates to mine. I added a fair amount of fudge to account for project slippage etc.
-Ron
#12
03/07/2003 (9:33 am)
Just a thought, but I think a DTS export function would be awesome. Just strip the model out to a 3DS or OBJ format so that both MAX users AND MS3D users can see how they are setup, etc. That could be invaluable to the modelers around here IMO.
#13
Neither of these could realy be considered "demos" as such but both are open source RPG projects using Torque so....
03/07/2003 (9:56 am)
Ron and others: The two projects I was referring to are GORPE and ActionRPG. As for tacking of progress, talk to me in a week or so about GORPE the first official source files should start showing up in our SourceForge CVS tree. You'll have to talk to Joshua about ActionRPG.Neither of these could realy be considered "demos" as such but both are open source RPG projects using Torque so....
#14
03/07/2003 (10:04 am)
(An Eternity) Java like documentation of TorqueScript describing all the functions and the parameters they take.
#16
03/07/2003 (10:24 am)
Don't get me wrong Ron, it's definitely helpful, but by "Java like" I meant documentation like java. (C: It's organized in such a wonderful way that it is almost impossible NOT to find what you are looking for. This is a good resource Ron, and I didn't mean to say it wasn't helpful. But if it could be broken down by some common functionality or something...it's hard to explain....
#17
no worries mate, I am just in a odd mood today. Half joking / Half ticked off
03/07/2003 (10:26 am)
Jeremy,no worries mate, I am just in a odd mood today. Half joking / Half ticked off
#18
03/07/2003 (10:44 am)
I can dig, I've had my share of those. I understand that documenting something like that is a huge and tedious task. And what you've done is totally respectable. I imgaine that for Java they probably had a whole team of people working full time to produce theirs. It's definitely a good resource though...
#19
I strongly disagree. The TGE Scripting Language currently in place should stay in place. TGE script is leaps and bounds more understandable and straight forward than Python is, especially to the new folk who will be editing those scripts to create mods(if you so happen to allow them to do so in your game).
The TGE Scripting Language is a prooven game script. It has been around well over 5+ years. It has roots clear back into Tribes 1. I see no benefit of changing the core scripting language.
Sure, maybe make it easier to 'plugin' new scripting languages, with say Python, but don't replace it altogether. I think that would be a huge waste of a really good scripting language(probably the best scripting language for a game ever created).
03/07/2003 (10:45 am)
Quote:
5. Official replacement of cs with Python, or a performance analysis that shows this as being an unreasonable course of action.
I strongly disagree. The TGE Scripting Language currently in place should stay in place. TGE script is leaps and bounds more understandable and straight forward than Python is, especially to the new folk who will be editing those scripts to create mods(if you so happen to allow them to do so in your game).
The TGE Scripting Language is a prooven game script. It has been around well over 5+ years. It has roots clear back into Tribes 1. I see no benefit of changing the core scripting language.
Sure, maybe make it easier to 'plugin' new scripting languages, with say Python, but don't replace it altogether. I think that would be a huge waste of a really good scripting language(probably the best scripting language for a game ever created).
#20
1) A complete re-coding of the audio engine. This baby is a mess, partly because of the openAL drivers, but mostly because the engine is missing chunks of needed code and the code that is there is extremely hacked together(no offense Rick). I know that the OpenAL drivers are partly to blame, but then I see games such as UT2k3 and Jedi Knights: Jedi Outcast which use the OpenAL drivers and they seem to have no problems. The audio code is fairly contained within its own set of files but the technical know-how to fully intigrate an audio engine is fairly steep. I would say 10 to 16 weeks for a fully working implementation.
03/07/2003 (10:57 am)
As far as what I would like to see immediately ;)1) A complete re-coding of the audio engine. This baby is a mess, partly because of the openAL drivers, but mostly because the engine is missing chunks of needed code and the code that is there is extremely hacked together(no offense Rick). I know that the OpenAL drivers are partly to blame, but then I see games such as UT2k3 and Jedi Knights: Jedi Outcast which use the OpenAL drivers and they seem to have no problems. The audio code is fairly contained within its own set of files but the technical know-how to fully intigrate an audio engine is fairly steep. I would say 10 to 16 weeks for a fully working implementation.
Torque Owner J. Donavan Stanley
Sure why not?
1) A rearchitecting and refactoring focusing on modular components that only interoperate through clearly defined interfaces. This above all would be a huge benefit and make custom tree's easier to maintain. ( 8-12 weeks for basic refactoring then another 8-12 of a teams time to flesh it out)
2) A patch review commity that evaluates new patches for quality, clarity and general-purposefullness (is that a word?). And then either 1) Commits them to the official tree. 2) Rejects the patch and informs the submitter why (maybe with an appeal process). 3) Modifies the patch to bring it in line and THEN commit it. (1-2 weeks to setup then several hours each week to maintain)
3) Either replace cs with Python or, even better, make the scripting language an end developer choice by virtue of using a different scripting component (see #1 above). ( hmmm Python support is there but could benifit from "real" bindings so 2-3 weeks for the basic bindings. Replaceing scripts is another matter, don't have a timeline)
4) Comprehensive documentation. We're already using Doxygen for documentation, all we need is for folks to make the appropriate comments. Note: This is something I reccomend for 1.x TGE too. ( Ongoing task no real tiem quote possible)
5) Maybe some more wizbang features like Cg support but honestly a modular design that supports extension combined with better documentation would make it a straightforward process. ( If #1 is done then < 1 week. If not 1+ weeks per feature)
That's my "wish list" such as it is.