specific and interest a thread to discuss enhancements and improvemets for T3D

#1 J,

I am going to be completely honest here. (at least by my observations and experience). Here is a NO SHIT, calculated assessment. DO SOMETHING WITH THE ENGINE!

Honestly, I can do everything from tessellation, to single bounce GI, (all in DX 9c by the way....IF YOU ARE READING THIS... DX 10 and 11 SHOULD be called DX9...d and e!)Everything they did was NOTHING but marketing.... Look it up if you think I am full of crap. Anyway, I even have a simple game in the works that has garnered some attention from the 'game player' community.(my peeps..and they should be ALL of our peeps!) All while making some 'pretty good' videos.... (Really, I am at best a mediocre artist and I get comments that say... WOW nearly next gen...WTF!). (I am not bragging... really, my YouTube numbers SUCK but they are better than many, and I never intended to make game 'dev' popular.)

Honestly. we NEED A FREAKIN GAME! When was the last semi-sucessful game published with Torque? Think Tanks? Marble Blast? (good games... but, come on, we CAN do better!) Come on, we have spent the LAST 1000 days talking about... Well, I need this feature or that feature. REALLY? Come on.... Games are about PLAY not TECH! I TROLL this site EVERY FREAKIN DAY! I have tried to answer as many tech questions as I could... I have even joined the damn steering committee.... all in an effort to MAKE GAMES! NOTHING.

This thread falls under my statement... are we Garage Games or are we Garage Games Engines? SERIOUSLY.... we are NOT dealing with 'basic' tech here.... can we support ALL the systems out there... F...NO. However, I remember a little game called 'Wolfenstein' or even 'DOOM' that ONLY supported PC play. MOST EVERYONE THAT VISITS THIS SITE HAS A FREAKIN PC. WTF! We have the tools and with a bit of research... hey we can MAKE A DAMN game.... and it would NOT be bad! Instead we focus on features and 'modern features' in order to make our game 'real'.... REALLY? Was freaking Super Meatboy modern? Was Fez...Modern? STOP focusing on 'wiz-bang graphics and SUPER SMART AI' and MAKE YOUR GAME FUN! (seriously.... I am going to call this the 'CALL OF DUTY' syndrome. ASS GAMES... and they ALL PLAY THE SAMe! (have been for years....) but they sell because somewhere along the line they became a freakin benchmark. F..k em... Make a game... not a freaking 'We are the most modern engine out there so please buy my stuff....'

I think that makes my point PRETTY freaking clear... If you NEED 'X' feature to be successful... well hey, your idea, concept and execution SUCKS from the get go. Make your game FUN no matter WHAT fancy features you have... those 'nifty features' should be BONUS... not the PURPOSE of your game.

Ron

#2 I agree with Ron.

But we do need to clean up lighting - that leaking issue is really annoying....

#3 @Ron

Absolutely a fair point.
Once the component system stuff I've been trucking on has happened one way or another my plan is to use it to get a game done. I've been working on the design and concepts of it so it's pretty solid for when development on that knuckles down, but my intention with the work I'm doing is to make it easier for me to work on stuff.

What Kory's asking after isn't really features like 'OMG PLS AD DX13 LOL'.
But stuff that people think would actually make the engine better to facilitate actual game development.

I'm only half tooting my own horn with it, but I think it's fair to say something like the component system can make development and testing of a game a lot easier. And if it's easier to make a game(front-end features aside) it's a valid thing to implement, no?

So yeah, this isn't really a 'add hed bob 2 enigne plz', but more of a 'what features do people need to actually WORK'. Feature fluff is fine, but actual MEAT is important too.

#4 I agree with Ron.

But as someone who enjoys programming almost for its own sake (a little too much, I'm beginning to think... but I digress), I am interested in becoming a part of a community for 'Garage Game Engines'. I'm just speaking for myself, of course.

So here's what I'll be doing in the future to improve T3D:

1. Finishing my recast tutorial for the official repo.
2. Updating Walkabout. This is probably my main obligation, since people have paid for it!
3. Waiting for Jeff Raab's component system to hit. Seriously, it's where the engine needs to be at if it wants to continue to compete as an option for new game makers.
4. Rebooting the T3D repo. Seriously, 800MB is not a reasonable download size for an engine. Once the script situation gets sorted and the component system is in place, I'll be shouting very loudly about making a new repository with a less troubled childhood. Whether it's GG that does this, or the T3DCE, or Jeff, or if I have to do it myself. Whether it's marketed as the main repo, or 'mini T3D' or 'T3D lite' or 'T4D' (following *nix naming convention, of course).
5. Finishing vlrtt and hopefully one or two other little prototype games I have rattling around in my head. And maybe expanding vlrtt to be more than a prototype. We'll see.
6. Expanding t3d-bones as a base for script projects. Developing its module system, writing modules for it, writing tutorials for it, etc. And along with that, developing some easy ways for developers to share generic content (assets, scripts, etc) in a plug-and-play fashion (allowing the base repo to be smaller - because it's easy to pull in starter content that isn't included).
7. UNLESS Mike releases his own modular script templates and I really like them, in which case I'll jump on board and port over my existing t3d-bones work to apply to these templates.

I have a couple more ideas in mind that are fairly embryonic. I'm also on the cusp of realising that maybe game dev isn't for me. But hey, that's a question to ponder when the dust has settled and T3D is on a new steady course.

#5 I also have to agree with Ron here.

I'm just a hobby programmer, I've got graduate school and other commitments to content with from time to time. Don't get me wrong, it's not that Torque is "lacking" in any way, there's just some nitpicky things about the engine itself that need to be fixed for it to perform well (notice how I'm keeping all talk of visuals out), the main thing is performance. As long as it performs well, it will do well. :)

With that in mind, I'm working on my next pack currently. I was actually in the process of writing a lovely blog for it when my Browser decided to crash on me, might as well start over. :(

I'm mainly just looking to crank out these packs as a way to generate just enough profit for me to push my own project to the next stage of development, community building would be a nice thing. Also along with Daniel, this pack is kind of my little sitting on the edge of development kind of situation. I've put some solid time into this pack, and if it's not really received well (Like my prior packs, which I will reveal now, have honestly not even done well in terms of sales), it might just be time for me to step aside and just leave game-dev.

#6 Hey guys,

I re-read what I put out... Little harsh, I will admit. In the end though I think I was spot on. It's not REALLY about the tech. Its about the game. I believe Richard said once that AI does not need to be 'smart' it just needs to appear smart. I think this philosophy needs to be adapted by the community. 'What can I do NOW'... Work within the confines of what is available. Really, there is NO need to 'expand' the engine. We CAN do some really good stuff... Basic AI is there. Thanks to Daniel, SOLID pathfinding is there. Graphics... well that is all on creative artists.... Look at Nils' 'skylight' resource. Believe it or not, it does pretty much the same thing as my GI single bounce shader and.... (yeah I was suprised too...) it has 1/2 the FPS and MSPF cost of my (admittedly, NON-OPTIMIZED shader solution.) Here is a GREAT and FITTING example of what I am talking about:
.
www.polycount.com/forum/showthread.php?t=130038
.

This was used in 'Rise'... the latest game using CryEngine. Why is this 'cool'?... because it is SO old school and really.... it freakin works and is efficient and MORE than possible in T3D as well.

I know many of you are thinking...well heck.... why did I not think of that? It's because we have been SO ingrained in HOW we SHOULD think, that we refuse to look at 'simpler' options.... period.

Again, sorry for being 'harsh'. I am just really fed up reading the same post after post... 'if T3D supports DX 10 or 11 then I will use it!'... sad to say... if you need THAT.... then your gameplay concept is lacking already.

To Daniel... I applaud your work and I am an admirer. YOU know this. I LOVE what you have contributed and I always look forward to what you do.. This goes out to ALL of the great coders and scripters out there.... I love all you do and look forward to what is next. However, we have an engine that can WAY more than anything TGE could do.... why are there no games???? You all know I am a bit of an 'engine' guy! I live and breath T3D. Why am I talking about games? Because, T3D will live and breath on what WE make. Not what we can DO.

I will step back now... thanks for reading.

Ron

#7 @Ron

Again, definitely fair points.

That said, just simply saying 'you can make games with what you have now, deal with it' is a fantastic way to stagnate on all fronts. I mean, heck, you could code your entire game in assembly but that's the worst thing in the world, which is why we have specially designed tools and languages to make our jobs easier.

It's why we have bone-based animation instead of vertex animation, and it's why Dan and the others come up with those add-ons that make the work you're trying to accomplish easier.

Making the engine better at actually letting people make their games is a goal worth having, I think.

Obviously that's no replacement for a core understanding, which is why techniques like the moss in Ryse still shine, but if someone with the understanding can do the same job with less work, it lets them make more game.

#8 Adding my two cents. ..I don't think we as a community showcase our work enough. Maybe I'm wrong but I don't see the showcase section updated much. Steve writes great blogs on his game and experiences and hats off to the guy. there is I'm sure a lot of other good game dev work going on and we see snippets through blogs but they get lost as they roll off the main page.

I personally feel there should be more showcase development section forum use.

If I were new to torque is want to see what I could make with the engine and while Yes a released game will assist, seeing 30 on development on the showcase section would certainly get my interest.

So acknowledging that this topic is slightly off piste at the moment I suggest more centrally located showcase of game dev work might be a half way house as I don't see a game being released just yet.

Having worked on our mmo for 3 years and personally defying the words don't make a mmo I'd be happy to showcase some work of game dev.

I'm sure there's offers or there that have stuff to show so money where mouth is I'll pull something out later this evening.

Tim

#9 Totally agree with Tim. I think the engine is been used, but we all have to show our progress. Think the engine is versatile enough to let us do whatever (or almost) we can imagine. Of course multi-platform, OpenGL, rewriting the entire rendering system..., and new features are very welcome, BUT we don't really need to make funny games! Well, in my case serious games...;)

Of course, there are some modifications we had to make to the engine to implement some effects (tactical AI, Silverlining skys, etc.), but that the great advantage that we have with this engine, we can do whatever we need, and then SHARE.

#10 My thoughts....

-The codebase needs to be tidied up a bit. When extracting libDTSShape I noticed quite a few classes which essentially did the same thing, not to mention completely dead code.
- The github project needs an active group of maintainers.
- There needs to be some sort of automated test suite for verifying large changes don't break functionality for others. (see the TorqueScript fiasco for a good example of what happens when this doesn't exist)
- TorqueScript needs a bit of TLC. The hacks which have been applied to it over the years combined with engineAPI have made the internals look like frankenstein. Compared to similar scripting engines, performance is as ever suboptimal, especially on more embedded mobile devices.
- There has been talk in the past of replacing TorqueScript in the past so newcomers don't have to go "eeew! TorqueScript!" but TBH replacing it entirely is not a trivial matter as a lot of important stuff in the engine relies on TS (i.e. editors, shader updates). Also some things in TS (such as dynamically creating a class based on an objects name) don't have direct equivalents in other languages.
- Perhaps as an alternate to pure script some sort of reloadable game dll system would be more useful.
- I've heard some criticism of the GFX material system, e.g. it can be difficult plugging in custom shaders. It's the sort of thing which if you stare at it for a couple of months you kind of get it, so maybe it just needs more documentation.
- It would be nice if it was easier to have an offline scenegraph without ghosting out of the box. For games like Endzone, we use prefab'd scene objects heavily but waiting for them to ghost down to the fake client leads to a delay, so we've had to hack things around a bit (i.e. skipping the ghosting entirely).
- It would be nice if the DTS format had support for IK constraints and face morphing out-of-the-box.
- The repository size is a fair point, but It's only going to get bigger - instead it would be better to have a downloadable SDK (see OGRE for a good example of this).

I appreciate people talking about this stuff but unfortunately experience has taught me that its one thing to say "we're going to do X", it's another thing to actually coordinate and do it.

Also without going too much off on a tangent, I'd say if you want to attract more people into using Torque3D, it would really help if there were more showcases of projects, both on the website and on youtube. Some sort of active development team would also help, because otherwise it just comes across as yet another dead/dying project in the open source graveyard.

Getting the Mac and Linux ports into the main tree would also be a really good idea.

#11 All thanks for the comments.
@Ron, I started this thread because Daniel, Jeff, Luis and I've been going back and forth through emails and they became quite long, plus for some thing like this the community input would be great.
I've told you a number of times,"maybe I should just go ahead with developing my game", but lately I've had the passion to help make the engine more user friendly. Also remove the "FPS/TPS engine only" from the engine. Of course most of us that's been around for a LONG time know that the engine can do more. Others just finding out or may have left may not.
I figured (if the SC) is not doing anymore active development. We have MORE than enough people that have done some great stuff to the engine to keep active development going. I guess you can call me a dreamer!!

Jeff has some fantastic ideas with what should be done with his behavior system. Daniel is full of great ideas (one of the MAIN) reasons I decide to contact him. To my surprise him and Jeff were already on it! :)

The MAIN issue I see is when Jeff does his campaign that it may still not get the community behind it, and if so what happens?
Also the third party developers, what happen to the engine if no more active development goes on with the engine? Soon people are going to leave the community going to get smaller and smaller, then the engine will die off.
I've invested TOO much time, money, and etc to sit by and watch it happen. So that why I believe in keeping development alive for the engine is a good thing. Plus at the end of the day would help learn the engine a little better, plus I could finish my game!!

Off topic...As it sit now I could finish my game but would have to strip down what I originally had planned (in which this project is a stripped down version of an even bigger project, NO it's not all that feature heavy either, most can be done with stock engine). The issues I'm having is the lack of knowing how to rig and animate. Pretty much everything else is ready to go and has been for awhile. Of course, the stuff I contacted you about was to make things more next gen (preeeettttyy). Like Ron told me "it's about gameplay not graphics"...

Back on topic...With all this awesome stuff being done with T3D it would be a shame to see it fade because there is no official repo with active development going on. I don't think blender would be were it is today if there was NO active development going on. All the individuals that do third party content would lose out, so my motive is noble...NOT for my own self goal but for everyone as a whole!!!

With that being said I would like to put forth a little roadmap/list of thing that could get improved..(next post tho!)


***EDIT: I second, or third the idea of MORE projects showcased ***

#12 @Kory:

IMO that's been the issue with any project so far is that there is no strong leader base behind it. The T3D community is great and has a few innovators in it, but IMO (and just MY opinion) there is no direction. I watched a few good ideas get killed due to 'too many chiefs' (the inability to agree on something without someone having a 'final say') or the programmers that started it get lost in other directions.

The committee idea was great but besides a few exceptions, a lot of it was adding in github fixes. The committee didn't set forth a "buglist" that I saw (and if you did, was it made public enough?), but when they did ask for people to fix the bugs and then have people test a dev branch before it goes into the final executable, did it actually get tested? I saw a few people test, but not real testing.

This is why WLE came about and this is how we do business. We have a bug list (a growing one now that we have level designers blowing up everything and tryin to make things more user friendly) and we are working down the row one by one to have what we call OMNI out for a first revision. We put everything in for an internal testing BEFORE it goes ALPHA. Ask Lukas or anyone else that works with us. We are horrid about bug reports and saying "this needs fix before it makes it into the dev branch". Remember the RPG UI Kit? That little $5/$10 pack? I must have bounced it back for a month or 2 before it was allowed to see light of day. Was his code bad? No. but after the few initial bugs were out, it was about presentation, about quality, about..... about....

We also have definite leaders. Vince and I ok every bit of code that goes into OMNI. Tim, Steve, Lukas and others suggest, say "we really need this" and then it's discussed how and when and then put as a task. We have weekly meetings and I can pretty much tell you where EVERYONE is at (within reason). Yes, WLE actually has 2 teams of people.... one for the engine and one for the game. Yes, we have leaders for both sides of this who run everything and we all discuss what's happening and how will "X need" will effect the other sides.

Yes, this does become a full time job. No, it's not glorious. But this is why WLE went off to make OMNI but we still contribute back to T3D as we can. Vince, Tim and I lead up WinterLeaf Entertainment (and thus OMNI and Dawn of Ascension). Vince handles the programming, Tim handles the art and I pretty much handle business and make sure that all of this is heading in a direction that we feel is right. We needed to have the ability to say "This needs fixed, and this is what we see as an answer."

Sorry for the rambling, but Kory, if you are looking at doing this, this is the road before you. Im already doing it, so I know a lot of the pot holes in front of you. Email me, ill be happy to help out as I can.

#13 Thanks Paul, Love the work you guys are doing. The way you guys do stuff at WLE is fantastic and a good model to go by :)
Keep up the great work, oh I'll be sending you emails like I was working for you (lol)...

The following my presented roadmap for the future of T3D engine. Please let me know if you agree or not! Here we go!!!!!!!!!!!!!!

future direction to improve T3D:


-Centralize a main or new development branch all the ports, etc... (either the GG official repo or a new one; but only after the decision with the SC has been made).
-Elect a roadmap forthe new direction (rather it's a complete re write or improvements)
-Depending on how Jeff Raab's component system campaign goes, start implmenting some of the thing on the roadmap.
-Rebooting the or an official T3D repo (I'm with Dan on this). Seriously, 800MB is not a reasonable download size for an engine. Once the script situation gets sorted and if the component system is in place.
-Developing its module system, writing modules for it, writing tutorials for it, etc. And along with that, developing some easy ways for developers to share generic content (assets, scripts, etc) in a plug-and-play fashion (allowing the base repo to be smaller - because it's easy to pull in starter content that isn't included).
-UNLESS Mike releases his own modular script templates. (edited)


This list represents MY ideas of what should be done. My list slighly differs from Daniel's, and Jeff but I believe WE all have the same final product in mind.
It's what I'm going to try to do If NO solid plan is put in to place with the SC...

1.) strip down T3D (barebone), leave only the editors and a way to start the engine with a camera and groundplane. AKA (empty room and empty template).
2.) Add open source Verve...the reason is because lets face it T3D needs a cinematic tool. This in my opinion is a good start..
3.) Add open source guidebot...T3D also need stock AI (that thinks), but guidebot is incomplete (I know I purchased it as soon as it was released).
4.) Add a behavior tree editor for guidebot...I have a good idea that would work similar to a plug-in. you would pretty much plug-in the behavior(s) and action(s) you want for the select bot.
5.) Adding guidebot leaves you with two player classes so I would create a unified player class that combines the two classes.
6.) Intergrate the component system...a little different from Jeff's approach, but same idea..
7.) Fix some of the issue with rendering system..Try adding multi-thread, fix some of the issue with culling, etc... I would even like the user to have the ability to pull out the lighting and replace it one of there own choice. For example if they wanted to replace adv. lighting with cel shade, or Phyiscal based..(Was also thinking of revamping camera to seprate it from the player class. Have a drop down list of the different camera views (maybe adding the Adv camera resources views, but allowing the user to customized the selected view or add their own).
8.) Intergrate the modular system (mike's or how Daniel had planned).
9.) Push out to official/other branches for ports (openGL, MAC, Linux, etc...)


The purpose of the barebone/empty template would allow a user to download a smaller download.
This next part is kind of based off Jeff's idea and my own.

Now instead of having a theme based engine the user would pick (i'm going to use Jeff's idea name here) RPK (rapid prototype kits or gerne kits), those would be based on the different genre and theme of the modern game types.
For example if a user wanted to do a gear of war type game, they would just pick the proper RPK with the camera system, and or proper script. Plug it in and they are ready to go (finally the create my game button/method).
The user has the option to mix and match the RPK to create new unique gameplay.
The idea is to keep the core engine as small as possible, not cluttered by a bunch of art and scripts that you may or may not use :)
Let the user decide what they want. Of course we could always offer a default FULL template which would have all the script and art, but I think it should be a separate download.
With Verve and guidebot added, thirdparty developer or whomever could do complete RPK's include some basic art (if they like), proper genre scripts, AI, and cutscene camera paths, etc...

**EDIT IMO (i think Dan mentioned it) T3D would greatly benefit to have it's own skeletal system...

#14 Now people may not agree with this approach and that's fine. With this I'm not finished. So the original core engine stay smaller in size,
a separate software should be developed. This idea came to me years ago but Jeff had the same idea (great minds think alike).
A constructor 2, this is where people could go crazy with the idea so the main engine stays thin and only a base engine.

Features for Constructor 2 (note I copied alot of the stuff from the original):

--------------------------------------------------------------------
---------------------Constructor 2.0--------------------------
projected download size: 40mb - (50mb) - ??? smaller the better..
---------------------------------------------------------------------


Torque Constructor 2.0 is a Constructive Solid Geometry (CSG) WYSIWYG brush editor that supports export of buildings and structures to numerous industry-standard Dae model formats,
or seamlessly export directly into the T3D Game Engines through cached.dts..

Modify and expand any of the basic scriptable functions with TorqueScript, from plugins, tools, and widgets to customization of the GUI. In no time you can automate repetitive tasks,
bind keyboard shortcuts to specific actions, and create an intuitive design environment built just for you.

Built for traditional 3D artists who are more comfortable working in highend modeling packages such as 3D Studio MAX, Maya, and Lightwave,
Torque Constructor 2.0 is easy enough for the novice and powerful enough for the veteran game builder.

Torque Constructor 2.0 also features basic and Advanced lighting (from T3D), delivering brilliant lightmaps, easy-to-use tools for manipulating light entities,
and dynamic real-time previews for rapid prototyping.

Torque Constructor 2.0 will allow user to create and export scenes directly into the engine. It will also take advantage of verve's sequence system giving the user the ability to record and export sequences.
It'll also have a plug-in system allowing for customized add-on, and plug-ins.

----------features

MODELING

Included Basic Brush Primitives (Cube, Cylinder, Sphere, Pyramid, Ramp)
User-Scriptable Custom Tools
CSG Subtraction, Intersection, Knife, Slice & Clip
Hide, Lock, Edit Selection Only for precise control
Face and Vertex Editing
Concave Brush Detection
Export and Import of Prefabricated Shapes
Support for various brush types (Detail, Collision, etc.) and groups
Duplication and Cloning tools
Custom Workplanes allow you to work off-axis


TEXTURING

Material Browser lets you view and organize your textures
Import textures into albums
Lift textures from selection
Copy and Paste textures from one face to another with coordinates intact
Justify, Fit, and Alignment tools
Multi-face texture unification


DTS/DAE and physics INTEGRATION

Place DTS Static Meshes in your scene for added detail
Static Meshes are baked into Constructor 2.0 DtS or DAE and act as part of the object in the T3D Mission Editor
Static Meshes receive lighting and cast shadows with their collision volumes as if they were part of your interior
Place Reference Shapes for scale comparisons
Ragdoll, cloth, etc physic; plug in to add Physx, Bullet, APEX, and other custom physics..

LIGHTING

Flexible Light entities
Basic, and Advanced Lighting
Support for custom lighting systems
Light maps created in constructor are used directly in T3D.


EXPORT

Export Constructor 2.0 DAEs with baked in detail meshes and light maps. Also backward Dif compablie.
Plug -in system to create custom formats for import/export
Support for creation of scene, and sequences directly to game engines!
Export Debug Previews allow you to view the results of the DAE export process on your map's geometry


TORQUE INTEGRATION

Detail shapes are baked into Constructor DAEs and act as part of the object in the T3D Mission Editor.
Legacy DIF format support for older versions of TGE and TGEA DIF convertion
Light maps created in constructor are used directly in T3D..
Also allow for sequence creation via verve.
Load and save whole .mis files and .seq files.

Extra

Import support for openAssimp
Terrain paging
Show-Tool (model tool)
kismetic tool (model)
Lip Sync tool (model)
Auto rigger tool to new skeletal system (model)
Record MOCap data directly...similar to Ecstasy Motion
World Design (Collaborative Tool)




In my opinion this tool would speed up development and help keep the core engine slim.
This is just my idea, maybe people agree or don't but I feel this would be the best approach.

KJ

#15 @KJ

my email is pyoskowitz@winterleafentertainment.com - feel free to ping me whenever. I left out a few things youll need (imo) also. that post was getting long enough as is.

For Constructor keeping it separate is great. the PROBLEM you run into is that youll get compared to Blender, Maya, etc quickly. be prepared. thwe scope creep on the project alone will keep a few people busy full time

#16 I've been focused on a getting a game finished. I don't post blogs, waste time on Facebook, etc., I put all of the time I have into getting a playable game released.

Problem is, I've had to become an engine programmer to get what I need for gameplay. I've added most of the mods the 'Greed' folks are talking about because I needed them. Have taken time out to work on ports of OSX and Verve because my game design idea, as manifested in my design document, calls for extensive machinima and cross-platform functionality. Despite having spent every bit of spare time I have since 2010, I still don't have a game done. I've been so caught up in the constant feature-creep/feature-reduction that I've recoded/rescripted some of the same functions two or three times.

I reached a point last year where I had a stable running set of features and made considerable progress with modelling and gametype design. I now have over ten vehicles, two dozen weapons and a host of other shapes, as well as 5 different gametypes. I reached an impasse' a few weeks ago when , while playtesting my project with a room full of teenage boys, issues I hadn't noticed or thought to be minor became glaring big ones.

What's ironic is that I'm not straying to far from what T3D does - my project is a TPS-MOBA, so I'm not asking T3D to do anything it's not supposed to. Yet in my own experience, I'm about to try UDK again simply because I want to create games and I can't do that if I'm constantly having to reinvent the wheel every time I need something.

@Kory:

A 'Constructor 2.0' is a really good idea. I don't have a need for T3D 4.0 I need a much better editor. For me the biggest hurdle in finishing a T3D project is pressing F11. While it works and does most of what it claims to do, it has enough problems to make it a very time-consuming tool to use. FWIW I could stop changing the engine today and get my game out if I had a level-design tool that I didn't have to go back and fix every procedure with a text editor. Or terrain editing tools that worked at least moderately well enough to add a tweak or two here and there after adding a model to the scene. It's the little niggle problems that add up into real time-wasters...

#17 @Gibby

Im sure that a lot of the issues you have fixed Gibby has either been fixed OR other people have hit it and walked away and went looking for UDK or other engines. its great that T3D gives out the source code, but the overall feel is "you have the code, fix it". that's great for an engine community but this is supposed to be a "game making" community supposedly.

that's exactly related to an issue that WLE is trying to fix. We are trying to make OMNI more "user friendly" because our own game designers working on DoA demand it. why would you want to put out something for others to use that your own inhouse people hate? the old guard T3D people are USED to issues. you wanna pull your hair our Kory.... get a game dev group together and tell them to use T3D. youre wanting to put in great stuff but ill tell you, they will scream and cry and a much lower level than where you are looking.

that's one of the challenges that we are still facing at WLE.

#18 > 1.) strip down T3D (barebone), leave only the editors and a way to start the engine with a camera and groundplane. AKA (empty room and empty template).

I've done this, and it only leads you down a path of questioning why you can only get ~250 FPS when drawing nothing but the FPS number. Which leads to profiling the engine, which leads to a list of inefficient console-type functions, which leads you to james' work, at which point it's 6 hours later and you just give up and go to bed. At least that's what I did. I guess what I'm saying is.. good luck :D

The interesting part is that I get 250 FPS drawing nothing, loading no scripts, notta. Yet, in my scenes with physx, cloth, bunch of objects, the 50k poly character, etc.. I get about ~230 FPS. So dropping only 20 FPS is pretty good considering the difference in what's being drawn, but it still annoys me that I can't get it past a 250 FPS base line.

#19 @Paul:

To be fair, I have found quite a bit of help from the community in terms of adding needed features and fixing issues. Like most of us, I get a sense of pride out of having done most of the work myself. I just don't want to have to swear at my computer when I'm trying to get a level done anymore.

In my own experience, I didn't see Unity, OGRE, Esenthel or Shiva being any better than Torque3D. Without exception, the development environment / art pipeline was far superior. People use these engines because you can implement a gameplay idea in them without the need for a compiler. I have come back to T3D repeatedly because I don't think those engines look/run any better and I like having the flexibility to code my own. I simply want to finish a game and T3D's editor is a big hurdle...

#20 Andrew,
That's were I believe some work with the renderer would help. I don't believe a full re-write is the way to go, just fixing some of the stuff. Alfio made some valid points about certain things getting fixed. Maybe those are what's causing the issue..

@Gibby, I agree with you on finishing a game but I've notice a few things keep me from doing so. Some it NOT issue with the engine rather my own skillset being limited, but nothing a few tutorials, or videos couldn't help.
Ultimately I believe MOST of us would like to complete a game but to produce a AAA level type game(s) it's pretty much a fact that somethings engine core side needs to be done. The way I see it, why not do it right? or at least the most user friendliest route!
Making the engine non-genre specific IMO is one, another modularity. Add a behavior system, a few new editors and fixes to the rendering pipeline and I think it'll be a good engine that MOST would be happy with. Will in be prefect I'm sure it won't be but it would make the process of doing game a lot more easier IMO...This is coming from someone who has a very basic knowledge on coding and on art creation!