Thoughts on TGE moving forward...
by Josh Engebretson · in Torque Game Engine · 10/01/2009 (3:07 am) · 30 replies
I completely understand why GarageGames is discontinuing TGE in 30 days... and support the move.
However, I strongly desire to see TGE have a future other than code rot. I have faith in GarageGames not stomping on a legitimate effort to improve TGE, the community, and as a direct result current generation technology. In fact, I hope/believe the vision to help facilitate this exists...
I think there are only a few with the necessary interest/time to kickstart an effort. I live in North Dakota... winter is coming on... the timing is perfect :)
Here's a roadmap for a start:
1) Setup a Subversion/Trac installation to house the work (trivial)
2) Setup CMake for the build system, which is *awesome* and capable of generating Visual Studio solutions, XCode projects, and Linux makefiles (also other IDE workspaces)
3) Replace the Windows/OSX/Linux platform layers with a unified SDL layer removing much code redundancy and platform maintenance. This includes the sound and TTF code as SDL also has support for these.
4) I am *currently* working on C#/Mono support and came to the realization that working with the much smaller TGE codebase and then bringing it over to Torque 3D (as a resource, addon, or in the core engine) would be productive. I've always had an issue with TorqueScript in terms of not being a standard, quirkiness, and its performance, so two birds one stone :)
I also have R&D into patching/streaming and embedded browser/Flash technology... all of which are directly related to my new indie game studio startup... and all of which could easily be moved from TGE -> Torque 3D :)
I am curious if others have specific thoughts on moving TGE forward?
However, I strongly desire to see TGE have a future other than code rot. I have faith in GarageGames not stomping on a legitimate effort to improve TGE, the community, and as a direct result current generation technology. In fact, I hope/believe the vision to help facilitate this exists...
I think there are only a few with the necessary interest/time to kickstart an effort. I live in North Dakota... winter is coming on... the timing is perfect :)
Here's a roadmap for a start:
1) Setup a Subversion/Trac installation to house the work (trivial)
2) Setup CMake for the build system, which is *awesome* and capable of generating Visual Studio solutions, XCode projects, and Linux makefiles (also other IDE workspaces)
3) Replace the Windows/OSX/Linux platform layers with a unified SDL layer removing much code redundancy and platform maintenance. This includes the sound and TTF code as SDL also has support for these.
4) I am *currently* working on C#/Mono support and came to the realization that working with the much smaller TGE codebase and then bringing it over to Torque 3D (as a resource, addon, or in the core engine) would be productive. I've always had an issue with TorqueScript in terms of not being a standard, quirkiness, and its performance, so two birds one stone :)
I also have R&D into patching/streaming and embedded browser/Flash technology... all of which are directly related to my new indie game studio startup... and all of which could easily be moved from TGE -> Torque 3D :)
I am curious if others have specific thoughts on moving TGE forward?
About the author
http://www.TheEngine.Co
#22
Honestly guys, I'd rather talk about bug fixes. There are plenty of them out there, posted as resources, blogs, forum comments, etc.
I guess what I'm saying is, I think there should be both "maintenance" and "development" branches in SCM.
10/05/2009 (10:32 am)
I have to say, this talk of SDL and .NET is leaving me somewhat less than enthusiastic about this project. Neither, IMHO, would be an improvement over the current approach.Honestly guys, I'd rather talk about bug fixes. There are plenty of them out there, posted as resources, blogs, forum comments, etc.
I guess what I'm saying is, I think there should be both "maintenance" and "development" branches in SCM.
#23
SDL simplifies maintenance across platforms and removes a pile of code redundancy between the Windows/OSX/Linux platform layers... and bugs, missing features, and incompatibilities unique to them individually.
Mono support will very likely be an optional module (compile in).
10/05/2009 (5:50 pm)
Consolidating bug fixes from all the posts with them is definitely an important priority.SDL simplifies maintenance across platforms and removes a pile of code redundancy between the Windows/OSX/Linux platform layers... and bugs, missing features, and incompatibilities unique to them individually.
Mono support will very likely be an optional module (compile in).
#24
It's also great to hear that bug fixes are an important goal. About this time last year I was actually writing a guide on 'fixing' TGE, had about 15000 words and 12 pages before I lost it all.
10/05/2009 (6:52 pm)
I'm kinda of curious about Mono after reading up on it, but yeah make sure it's an optional module and not a replacement -- some of us actually like Torque script ;DIt's also great to hear that bug fixes are an important goal. About this time last year I was actually writing a guide on 'fixing' TGE, had about 15000 words and 12 pages before I lost it all.
#25
It is also very difficult to debug/develop with if you aren't using Torsion, which is Windows only.
It is a decent configuration/callback language and gets the job done for serialization (however, I would argue that XML with the ability to kick out to sqlite binary representation for data size and be able to query data is preferable for the later).
I understand that TorqueScript works for some and there are good reasons for liking it... though it *definitely* isn't the future... been saying this for coming up on a decade... and it is now a serious performance/functionality/adoption liability for Torque technology in general, from mobile through desktop to console.
10/05/2009 (8:15 pm)
Unfortunately, TorqueScript isn't based on a standard, doesn't have robust data structures, interfaces or inheritance, is quirky, suffers from low performance, limits you to only using C++ libraries which you have to then expose to script yourself, and it doesn't come with batteries included standard libraries such as found in Python/Java/Mono/Lua/etc. It is also very difficult to debug/develop with if you aren't using Torsion, which is Windows only.
It is a decent configuration/callback language and gets the job done for serialization (however, I would argue that XML with the ability to kick out to sqlite binary representation for data size and be able to query data is preferable for the later).
I understand that TorqueScript works for some and there are good reasons for liking it... though it *definitely* isn't the future... been saying this for coming up on a decade... and it is now a serious performance/functionality/adoption liability for Torque technology in general, from mobile through desktop to console.
#26
10/05/2009 (8:51 pm)
Is there any internal push coming to add more scripting options to T3D in the future? Not sure how easy that would be to roll into TGE if that does happen (and of course the legality of it as well if it is released with the engine).
#27
I also like Python, Lua, and Java all for various reasons. However, Mono covers all the bases and you can actually code in Python/Java (and I believe Lua) on top of the CLR.
I would highly recommend reading into what Mono/.NET are all about... really exciting "next generation" language and runtime technology.
10/05/2009 (8:57 pm)
One other quick comment regarding the choice of Mono.I also like Python, Lua, and Java all for various reasons. However, Mono covers all the bases and you can actually code in Python/Java (and I believe Lua) on top of the CLR.
I would highly recommend reading into what Mono/.NET are all about... really exciting "next generation" language and runtime technology.
#28
Questions with purpose:
1. Is the Karma project still marching onwards?
2. If not, is there still interest in a project to bugfix, clean up, and eventually extend TGE as a hobbyist engine?
3. To any TP employees who read this: open-source TGE? ;) (Just want to keep the thought fresh in everyone's minds...)
11/26/2010 (2:18 am)
So it's been a while and some things have happened. I remembered this thread (and the Karma project) when I went to optimise Thomas Lund's message router resource and ended up falling down the rabbit hole of intending to implement an STL of sorts for Torque (needed to refactor tSparseArray, then LList, figured why not make some interfaces for Map and List... things are progressing from there...).Questions with purpose:
1. Is the Karma project still marching onwards?
2. If not, is there still interest in a project to bugfix, clean up, and eventually extend TGE as a hobbyist engine?
3. To any TP employees who read this: open-source TGE? ;) (Just want to keep the thought fresh in everyone's minds...)
#29
11/26/2010 (5:58 am)
I'm still developing with TGE so I'd be happy to help in any way I can, however I'm not a programmer but I can help in any way art is concerned. 
Torque Owner Daniel Buckmaster
T3D Steering Committee