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

#21 @Gibby
I totally agree, unfortunately, for people that want to design and not code, the editor can be a deal breaker. Still not user friendly, still an issue.

#22 @Kory

what was Alphios comments?

#23 I'm going to have to agree with Daniel here. Coding the tech is what gives me the most kicks. And this isn't anything new, Melv May did this back in the days of TGE and improved several subsystems (usually related to visuals) which later got integrated into stock TGE.

These improvements had nothing to do with making games and you could make a game without them. So, this isn't anything new. Different people like different things.

If you want to release a game though, it's not a good idea to dabble too much deep in engine internals.

#24 @ Paul
here is his reply:
www.garagegames.com/community/forums/viewthread/136026/3#comment-854150

#25 I think we need to split into two teams. Half of us put on our helmets and digging gear and venture into the core of T3D, the other half stay up top and revamp the toolset. With new features like path and cinamatic tools I think the entire layout of the editor could use a revamp. Not a rewrite, just a revamp.

I'm only a few months out from launching my game and while we're having no issues with performance, I wouldn't mind starting to work towards a better engine now rather than later.

#26 Andrew
I with you on that. As I'm not as far as you are with my game. I'm willing to halt advancing my game to improving the engine!
As it sit now, without continued development or some improvements. I would finish the game project (or try) then be done with the engine in it's current state. If a group come together a tackle some of these issues. I could see myself using it for other future projects and even suggesting it to others.

#27 This is my roadmap, I have some experience in each:

• Linux/SteamOS
• OSX
• iOS
• Android
• Lua
• Multithread
• AI
• OpenGL4

Quote: 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.

@James, you're right, remove TorqueScript is a lot of work.

#28 I will throw in my two cents as a newbie to T3D

Making games with the engine can be fun and is something I'm trying to do but I agree with the guys saying that the tools could use a revamp.

I'm slowly learning the ways Torque works but I must admit a lot of the time it's spent looking for code or trying to work out how I can actually do something and less time on the actual game it's gotten to the point that I spend hours searching and trying to get some code to work than implementing the gameplay or level design but that is to be somewhat expected of a game engine.

A new interface would be great but I think it comes back to documentation/tutorials on doing specific stuff which I hope to expand on.

I will probably do this myself but making available game mechanics in script form with a basic break down would be a lot more helpful to someone like me to understand why it's written this way and being able to implement it as well.

I tend to find ways around issues that could easily be fixed with a source code change or some scripting but cause my skillset isn't there yet I tend to think about the basics of torque and what I know I can do and work out a solution (Perfect example is rotating the world I instead used multiple models of the same room with each rotated and teleported into each room so I could walk on walls and the ceiling)

As a newbie i'd rather see more on actual gameplay or mechanics and use the engine as is first then go on improving the engine.

#29 Personally I don't think the "make a showcase game" argument really holds - it's clear to most people that the engine CAN make good looking games.
The problem is in how much of a headache it is to do so.

For most indy developers learning a whole new scripting language, hacking deep into the C++ core and spending hundred of hours implementing missing features or porting to different platforms is just beyond the bounds of possibility.

T3D can make games. But (assuming no prior knowledge of any engine) you could probably make the same game much faster and with Unity, JMonkey, NeoAxis etc.

Where T3D really shines is that it has a better editor and world building tools than those others and a fully free and open license.

Where it struggles is on TorqueScript being confusing and a big learning curve. It's not properly object oriented so it's hard to structure the code in a way that feels clean and comfortable and the IDE tools are out of date.
It is also let down by being bound to the PC and DirectX 9. Most people making games now, particularly in the indie sector, can't really afford to ignore mobile as that is where it is easiest to get a game to the market. Not to mention the fact so many more people use Macs now compared to a few years ago.

I personally feel the future of T3D lies pretty much in the hands of Luis and his OpenGL work. If T3D can be ported to Linux (+SteamOS), OSX, Android and iOS it will gain popularity very very fast, as the only existing solid free 3D engines that cross platform barriers in that way right now are really only rendering engines and lack the awesome editor and most game engine components.
When that happens, TorqueScript will be seen not so much as a down side but as a plus side. Because now we have the benefit of being able to write games in one scripting language that can be interpreted and run on all these different platforms without the need for modifying the code and compiling for all the different devices.

On the TorqueScript front though I think the language does need to be cleaned up and better documentation made. The Object Oriented stuff needs to be better explained and templates made with a nice OO structure.
Most importantly though, there should be a modern and updated IDE with code completion for torquescript - perhaps definitions could be made for Sublime Text 3, Netbeans, Eclipse or MonoDevelop?

Best of all would be if the scripting interface for T3D could be abstracted altogether and bindings made for other languages such as Lua and JavaScript. I think JavaScript in particular would be a great choice as Node.js, AngularJS and other JavaScript technologies are really trending at the moment and of course many Unity developers use it, so there are really good opportunities for people to switch over and maybe even code snippets and game logic that could be ported as well.

What might also make a big impact is if Winterleaf contribute their C# bindings and C# becomes the main language of T3D. That would right away open up the engine to the full Unity fan base, all existing .NET coders, be familiar to all Java and JavaScript programmers. The down side of course is that it wouldn't be as cross platform as Lua or JavasScript and Android or iOS ports would need to use the paid MonoTouch versions. But the benefits of C# would probably be worth that for most people.
Sadly from the look of it I get the impression Winterleaf are going to try to sell their C# integration for Torque rather than contribute it to the core. I can understand that, but I personally don't think it will be very usable for most people or have enough community behind it unless it's part of the core. It's always going to be a bit quirky and not fully integrated or considered by other contributions until that happens and more importantly it won't drive enough development in the core itself to keep the engine updated and current if it's just a paid extra.

Anyway, for now I think it's all eyes on Luis :D

#30 Having a meaningful showcase of projects is a great idea.

Quote: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)

A thousand times this. I'd jump right aboard that if I could get my mind around what a test suite for a game engine could possibly look like. I mean, at the very basic level, you check if it compiles. But that ranges all the way up to something as complicated as this PR I made. The code changes are completely simple - but how do you even test that it doesn't subtly break something? How do you test that game objects behave the same way? How do you test that collisions fire the correct callbacks in the correct order?

Testing the scripting engine is a less ridiculous task - I guess you simply provide lots of code that must work the same way for each change you make - but the script engine is going to be relatively stable outside changes like James' function call improvements; it's other parts of the engine that will be receiving the most pull-request attention.

I've just started using Travis CI for a personal project, and it's fantastic - especially the way it runs your unit tests on pull requests and hooks into the GitHub pull request page. I just can't even imagine how we could use something like that with Torque.

Quote:Also some things in TS (such as dynamically creating a class based on an objects name) don't have direct equivalents in other languages.

Some would say that's not a bad thing... ;)

Quote:It would be nice if it was easier to have an offline scenegraph without ghosting out of the box.

Heartily agreed. I've found that with t3d-bones I could actually sweep most of the client/server stuff under the rug, but that's just for local-only games. I guess you guys actually do use and rely on the networking stuff.

Quote:The repository size is a fair point, but It's only going to get bigger

I meant starting completely afresh, not with an existing fork. We wouldn't make the mistake of, for example, including binaries or art assets. But having a separate download is a good idea, too. Not everyone wants to install git first off.

James, if you don't mind me asking - why are Mode7 using T3D and not a competitor? Is it simply familiarity with the tech? Obviously the engine isn't a significant barrier to what you guys are doing...

#31

Quote: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.

The bug list was (and still is) the 'issues' section of the GitHub project. And IIRC the committee themselves tested all submissions which was the reason the turnaround on pull-requests was longer than people would have liked. (I'm not criticising - I submitted a broken PR or two myself...)

Quote:Yes, this does become a full time job.

And that seems to have been what made the SC infeasible - people aren't doing it as their full-time job. And nor should they, so we need to come up with a more efficient process for managing the engine, unless we do find some people somewhere who want to spend significant amounts of time working on the engine.

Quote: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.

I need to follow your example, mate!

Quote: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.

Hear, hear.

Quote:Half of us put on our helmets and digging gear and venture into the core of T3D

Sign me up for that excellent metaphor.

Quote:As a newbie i'd rather see more on actual gameplay or mechanics and use the engine as is first then go on improving the engine.

That's been one of my ongoing goals with t3d-bones and vlrtt. I want to strip everything out of the scripts, and work with just the raw engine, and see how it works. See if I can make a project that's not first-person or shooty. See where I get hung up, see what's painful, but also see how easy it is to develop the basic mechanics like menus and loading levels (not to mention gameplay).

And at the same time, write tutorials documenting how I got things working. The closest I have to a decent example of this is the AIPlayer tutorial, which starts with a fixed camera and uses basic scripts to make an AIPlayer move to where you click the mouser. Which requires learning to do a basic raycast. Which you then, ideally, will apply to the game you want to make!

Quote:The problem is in how much of a headache it is to do so.

Amen.

Quote:I personally feel the future of T3D lies pretty much in the hands of Luis and his OpenGL work.

I agree, but I'd include Jeff's component work in that as well.

Quote:What might also make a big impact is if Winterleaf contribute their C# bindings and C# becomes the main language of T3D.

WLE does have an open-source version of DNT, but I haven't looked at it in close detail, nor its license. If the license is compatible it may be feasible for open-source T3D to start from this as a base, and presumably move in a different direction to OMNI, which seems to be taking the C# stuff to its logical conclusion.

#32 @Everyone,

The C# bindings aren't really that difficult. What made DNT/OMNI so cool was the static code analyzer and generator I wrote that ripped the callbacks, persists, and console functions out and put them in a nice object oriented model.

If you really want to start down that path, then your going to have to kinda follow what I did. Whether you want to hook in Mono, JavaScript, Lua, etc. there is cleanup that must be done first.

The first thing I did was get rid of as many of the Con::ExecuteF's as possible and replaced them with defined callbacks. I then made sure that objects never redefined a callback etc. I moved some of the callbacks down the object tree, some I had to change a bit, renamed a couple etc. But, now my callbacks are all nice and tidy.

Then we went through and convert almost all of the old style syntax consoleMethod, consoleFunction stuff over to defineConsoleMethod, etc.

I still have a few older style declarations left to clean up but they won't take long to get ride of.

Once you have those parts cleaned up, you can then start looking at the macro's for the trampoline. The trampoline is what does the near jumps inside the engine when functions get called, etc.

What T3D does is pretty neat, it basically exposes all of your definedConsoleMethod's etc as Externs. It then does near jumps to the externs to execute them.

Well, a bit of this logic might need to be re-evaluated. Especially if you want to put the hooks for a open API language swappable console in. But you can't start that process until it is all converted.

Finally, whether it is Jeff Rab's system or someone else's, T3D needs a component system.

This is a must.

I'm wasn't a big fan of Jeff's solution because it created so many damn simobjects. Then after thinking about it, I realize that that wasn't really the problem. I already had the solution to the ton-O-simobject problem Jeff was facing. My old object culling code fixed a good part of it. The second problem I fixed was I revisited the network system and threaded it so I use a pool of worker threads to send data to clients so I can send more information in the same amount of time.

This type of work is grueling, boring, and well massive. Without it though I really don't see any initiative really succeeding at swapping out the console for a different language.

Vince

#33 Oh, before I forget... Rewrite the damn simdictionaries to use unordered hashs' the current implementation blows chunks after 100k simobjects.

To be honest, the best approach would be to review all of the custom memory stuff they wrote and see if it can be replaced with STD.

I love how the simdictionary does an array copy every time you add a new element to it.

Guys, the engine is awesome, it can do some really marvelous things. Yes WLE has about a 3 year head start going down this path. But remember, we only have a handfull of programmers, if you could leverage a larger group of people.... wow the changes you could make.

Vince

#34

Quote:The first thing I did was get rid of as many of the Con::ExecuteF's as possible and replaced them with defined callbacks. I then made sure that objects never redefined a callback etc. I moved some of the callbacks down the object tree, some I had to change a bit, renamed a couple etc. But, now my callbacks are all nice and tidy.

Thanks for the info! I've been waiting till we have a component system to even look into this, since componentising everything will mean there are very few classes to do this for (even automatically). As in, eradicate everything below GameBase and that's a ton of stuff you don't even have to think about.

Quote:To be honest, the best approach would be to review all of the custom memory stuff they wrote and see if it can be replaced with STD.

Yes. Good point. Very good point.

#35 Regardless of what anyone is saying here, IF YOU DO NOT F"K FIX THE PHYSX ISSUE YOU WILL NOT MOVE FORWARD, PERIOD. We must gather talents together to fix this nemesis or get it the F"K out of the Torque engine.
I hope I got your attention, but many of your new potential users (you know, the ones that might continue your engine's continuance, and actually make games) come across this asinine, ridiculous, obnoxious, bizarre half-a## formulation of what could have been, but simply is not. Get the god damn PhysX out of the pipeline! Take this cancerous tumor out.
Who in the world would want splintering effects that bod up and F"k down a river if they have to give up on the ability to use a flying vehicle appropriately or collide (you know 1990's stuff) with objects. I know, it is awesome to have crashes because you delete an object that another PhyX object was on top of -- that makes great games!!! Also, lets introduce an object that can not be manipulated in anyway shape or form unless it is a bullet that hits it because that is a structure that allows us to make games that are all (super watered down) FPS shooters, and nothing else. Lets expand the concept for a mere second, that not everyone is looking to make a brain-dead FPS shooter when they are looking for engines(please take a minute to ponder on this).
NEVER SHOULD BE THE DAY THAT ANY (2000 and up worthy) ENGINE HAS USER COMPLAINTS ABOUT COLLIDING WITH ANOTHER 3D OBJECT (in a 3D engine, let me remind you) UNLESS THE FAULT IS ON THEIR MISUNDERSTANDING ON HOW TO EXPORT PROPERLY TO SAID ENGINE. Please... let this not only be a focus but a creed in the expansions to come. You may think this is simplistic, but I will tell you this, if you do make sure of this "simplistic" issue, you will not move forward because it is wasting people's time, and your engine is then thought as a waste of time because it does not do the most assumed processes in our current timeline. If a process does not support the collision of the engine then it does not belong in the engine.

#36 @Vince Gee

Have you considered putting your OMNI work into the core of T3D? I know you're kind of heading in the direction of having your own cross-platform, C# scriptable 3D engine at the moment, but as you said, you have a limited development team and even if/when you do get it done, people still have misgivings and concerns about the T3D core itself. There are other problems and limitations that need to be addressed and the community needs to work together to bring the engine forward - else by the time you're done there might not even be much of a core T3D any more. Plus, why would most people want to invest time and hard cash in a product with a small community, not really proven in the real world and with an unheard of brand name when there are things like Unity out there that are C#-first and free to a degree that is good enough for most indies?
With the whole T3D community behind a move to C# though and the extra development effort of people on this forum contributing into the core and those who are working on the OpenGL stuff, things could be achieved much faster and in a more integrated manner. The C# bindings could be first-class citizens and properly considered and tested with each new addition.

If that happened I can't see how T3D could fail to thrive and Winterleaf would be in a great position as the foremost experts on the C# core integration and could sell thousands of copies of their other products such as the advanced UI tools and IPS and be hired to give (pretty expensive) consultancy to companies that will no doubt use T3D to go on to make $1m titles.

I think there's an opportunity at the moment to make T3D the only MIT licensed, cross platform, game-ready, AAA quality engine out there. But it's not going to happen if everyone has their own agendas and just expects the engine and its community to still exist by the time they're done.

#37 @Travis CI
I did not know Travis CI, can be very useful to check pull request.

@Time for work on SC
If the committee is large enough, it could test "pull request" faster and more safely. It is not necessary that everyone has write rights to the repo, would help only to all the work is more distributed.

@New format for SC
I do not know if anyone know The Qt Governance Model. I think it would be a very good system for T3D.

Quote:
The Qt Project is a meritocratic, consensus-based community interested in Qt.

Anyone who shares that interest can join the community, participate in its decision making processes, and contribute to Qt development.

This document describes the current "governance model" for the Project, i.e. the five levels of participation and how community members get involved in making decisions.

The main objectives of the Governance Model are to:

• Put decision power in the hands of the community, i.e. the people who contribute to the Project success
• Make it easy to understand how to get involved and make a difference

The five levels of involvement: Users, Contributors, Approvers, Maintainers and Chief Maintainer are described below.

...

@C#, Lua and others
I think what is really necessary is to solve the dependence T3D with Torquescript. Once we can use T3D only in c++, it will be easier to add optional addons for other scripting languages.

@editors
My first move would carry the editors c++. The templates would be more simple, editor code would be easier to maintain and work in any script language added to T3D.

@Showcase projects
A section in the forum for serious projects a good idea. With requirements like having to update the status of the project once a month.

@mailing list for news
A mailing list to report 1 or 2 times per month for important news.

@bugs
While add and improve features a T3D engine can improve and attract new users, I think we should remember that to fix bugs present is very important because they can cause users to leave the engine.

#38 @Ron, You're right, but these are all games made with T3D as a base.

We need to have more contact with the developers to have an updated list of games using T3D and talk to them to see if it is possible to retain T3D logo on initial startup.

BeamNG.drive


Frozen Synapse


Frozen Endzone


Airship Dragoon

#39 ummm..was thinking since constructor was free, could parts of it be used. Let say for someone to create a tool or something; or even a constructor 2?
Maybe someone from garagegames can answer that?

Luis: I agree, it would allow people to see these were powered with T3D. I planned on doing on my games I used with it..

#40 @DreamPharaoh

Myself and a few others have been upgrading torque to PhysX 3.3 and fixing all the bugs along the way. Post any issues you've found in PhysX 2.8 in the PhysX 3.3 thread and we'll sort them out.