A Better Torque? Start with the Editor.
by Marty · in Torque 3D Professional · 05/04/2013 (5:24 pm) · 26 replies
I'm wondering, will T3D 3.0 or later bring the Torque editor up to the level of Unity3D's editor?
For new users (and bread-and-butter users too for that matter) the Torque interface *is* Torque. Working in U3D, the editor is the only interface that you ever need to deal with. If the Torque interface is fractionated and cumbersome and limited to one platform, it's going to be more of a barrier than a gateway.
One universal, all-encompassing editor, that looks the same and acts the same on Windows and Macintosh - that should be the first goal for the next iteration of Torque.
For new users (and bread-and-butter users too for that matter) the Torque interface *is* Torque. Working in U3D, the editor is the only interface that you ever need to deal with. If the Torque interface is fractionated and cumbersome and limited to one platform, it's going to be more of a barrier than a gateway.
One universal, all-encompassing editor, that looks the same and acts the same on Windows and Macintosh - that should be the first goal for the next iteration of Torque.
About the author
#2
Tbh, the tools are where they need to be to be able to create a succesfull game, I can't see why you would spend lots of time writing new tools and editors just so it "feels nice". On the long term? Sure! But.. Really long term.. Imo genre-cleanup, bugfixing, cross-platformability is all way more important than new editors.
You have to remember, this is not Unity, nor UDK. It will take too much work to compete with Unity on the low-entry field.
What Torque3D have talking for itself is that it's open source and free.
You will not get a feel for what low-level game development is through Unity, nor can you modify the code as you want.
And Unreal is.. Well too expensive for indies, and the free version does take a fair amount of royalties on any bigger games so Torque3D really is standing strong already, we just need to get the word out there so people will notice it.
Imo Torque3D is not for the people who consider the interface to be "the engine". It's for the people who want power and non-restricted use from their game engines.
05/04/2013 (6:25 pm)
First goal? Not really.Tbh, the tools are where they need to be to be able to create a succesfull game, I can't see why you would spend lots of time writing new tools and editors just so it "feels nice". On the long term? Sure! But.. Really long term.. Imo genre-cleanup, bugfixing, cross-platformability is all way more important than new editors.
You have to remember, this is not Unity, nor UDK. It will take too much work to compete with Unity on the low-entry field.
What Torque3D have talking for itself is that it's open source and free.
You will not get a feel for what low-level game development is through Unity, nor can you modify the code as you want.
And Unreal is.. Well too expensive for indies, and the free version does take a fair amount of royalties on any bigger games so Torque3D really is standing strong already, we just need to get the word out there so people will notice it.
Imo Torque3D is not for the people who consider the interface to be "the engine". It's for the people who want power and non-restricted use from their game engines.
#3
Still, I think that nothing is more important to the success of an authoring tool than the number of people who use it to actually author. Today, even Unreal is going out of its way to make itself more affordable and more accessible to the "casual" developer. There's something to be said for adoption numbers - even if those adoptees aren't as hardcore as you'd like them to be.
And as far as the limited resources issue goes, to use the Unity example one more time - the first version of Unity (the engine, the interface, the ability to export to Mac/Win/Web) was created by three guys over the course of a couple of years back in the mid-2000s. Surely Torque can muster comparable resources today.
Torque seems to be in an interesting position right now under the MIT license. The world needs an "open" interactive 3D authoring tool and Torque looks like it could be that thing. But first, IMHO it's going to need be more accessible. Everything else is just that: everything else.
05/04/2013 (6:36 pm)
Good points all around.Still, I think that nothing is more important to the success of an authoring tool than the number of people who use it to actually author. Today, even Unreal is going out of its way to make itself more affordable and more accessible to the "casual" developer. There's something to be said for adoption numbers - even if those adoptees aren't as hardcore as you'd like them to be.
And as far as the limited resources issue goes, to use the Unity example one more time - the first version of Unity (the engine, the interface, the ability to export to Mac/Win/Web) was created by three guys over the course of a couple of years back in the mid-2000s. Surely Torque can muster comparable resources today.
Torque seems to be in an interesting position right now under the MIT license. The world needs an "open" interactive 3D authoring tool and Torque looks like it could be that thing. But first, IMHO it's going to need be more accessible. Everything else is just that: everything else.
#4
05/04/2013 (6:48 pm)
3 guys in 2 years is approximately $150K to $180K (probably more). So no, those kinds of resources are NOT lying around. The Unity folks are getting a return on that investment. What is the return in investment for doing this for T3D?Quote:The world needs an "open" interactive 3D authoring toolTorque is a game engine. If you want an authoring tool then get coding.
Quote:more affordable and more accessible to the "casual" developerUnity fills this need. Why does Torque need to?
#5
Torque is already a whole new level of simplicity in game development, maybe you should look at other open source engines how things work there.
05/04/2013 (6:51 pm)
You can spend a few years and write one yourself, since Torque is totally open source now, open source builds upon this principle, these projects usually do not have lots of paid developers who do the things, you can be happy, if you got any at all.Torque is already a whole new level of simplicity in game development, maybe you should look at other open source engines how things work there.
#7
Wanted features, bugfixes, usability improvements, etc.
The editors are plenty workable now, but the stuff I've been looking at is mostly for the sake of streamlining workflows, making it easier to use, etc.
You mention UDK and Unity's editors. I haven't worked with UDK, but I have worked with the older verisons of Unreal Editor, and what I've seen so far of UDK, the interface is pretty similar. And my only real exposure to Unity is tutorial vids on some features and addons I thought looked interesting.
So without getting into the meat itself, just a glance, I find both editors pretty atrocious from a ease-of-use standpoint.
Unreal's always had an incredibly cluttered editor, and it only got worse over time. It's why they've completely overhauled it in UE4 to make it actually comprehensible.
Unity looks to be much the same way. Those videos I'd seen of people working with features in the editor interface was just a gigantic wall of options and properties windows, dragging and dropping between made for a fuzzy, directionless mess.
While T3D's editors aren't as powerful or robust, at least the editors are easy to use and comprehend. Diving into the editors with the sole intention of catching up to UDK or Unity, I think, is a huge mistake.
Additional features, streamlined editors and bugfixes are excellent ideas, and as said, I've been accumulating a list and trying to find the time to work on it, but just blinding chasing after the competition's approach seems to be a bad idea. You want to improve and expand T3D's clean, approachable editor interface, not bog it down to make it feel empowering.
05/04/2013 (7:01 pm)
Improvements to the editors is something I've been building a todo list for for the past couple months.Wanted features, bugfixes, usability improvements, etc.
The editors are plenty workable now, but the stuff I've been looking at is mostly for the sake of streamlining workflows, making it easier to use, etc.
You mention UDK and Unity's editors. I haven't worked with UDK, but I have worked with the older verisons of Unreal Editor, and what I've seen so far of UDK, the interface is pretty similar. And my only real exposure to Unity is tutorial vids on some features and addons I thought looked interesting.
So without getting into the meat itself, just a glance, I find both editors pretty atrocious from a ease-of-use standpoint.
Unreal's always had an incredibly cluttered editor, and it only got worse over time. It's why they've completely overhauled it in UE4 to make it actually comprehensible.
Unity looks to be much the same way. Those videos I'd seen of people working with features in the editor interface was just a gigantic wall of options and properties windows, dragging and dropping between made for a fuzzy, directionless mess.
While T3D's editors aren't as powerful or robust, at least the editors are easy to use and comprehend. Diving into the editors with the sole intention of catching up to UDK or Unity, I think, is a huge mistake.
Additional features, streamlined editors and bugfixes are excellent ideas, and as said, I've been accumulating a list and trying to find the time to work on it, but just blinding chasing after the competition's approach seems to be a bad idea. You want to improve and expand T3D's clean, approachable editor interface, not bog it down to make it feel empowering.
#8
05/04/2013 (7:05 pm)
It would need a dedicated technical lead with strong UX experience who is ruthless in his evaluation of the tools most-used by the industry and who keeps both technical direction moving with the usability focus for anything user-oriented, but also can manage creating a robust backend that the user will never see. Unity had that with Nicholas. He was both a brilliant engineer and had a keen sense of usability that he used as a meter in the design of the editor. 
#9
but it's interface is awesome for level designing
some of them also helps coders and plugin makers.
not hard to make the interface like u3d.but it needs considerable amount of time.and need someone who is very much familiar with u3d.
and it will take considerable amount of time.
not a person's job.
05/04/2013 (7:21 pm)
i think this is a good idea.personally i do not like u3d.but it's interface is awesome for level designing
some of them also helps coders and plugin makers.
not hard to make the interface like u3d.but it needs considerable amount of time.and need someone who is very much familiar with u3d.
and it will take considerable amount of time.
not a person's job.
#10
Unity is great and when I properly used it I was wowed at the ease of use to get a arcade game up and running so easily.
But try and make a FPS with Unity or a game that needs top notch multiplayer you are going to need to get outside what it provides.
Torque3D is for those that want total control but that also means it will be more work to do the smaller things. We are trying to tighten that gap with more examples for different genres and I think that maybe enough to be competitive and attract those that want more out of Unity or UDK.
An interface more akin to UDK is more doable in this type of engine. Unity3D is another type of beast, I tend to think of it as a VM. Because the interface isn't in the game its outside of it.
05/04/2013 (9:02 pm)
I think it's the idea that all these engines are equal which isn't true.Unity is great and when I properly used it I was wowed at the ease of use to get a arcade game up and running so easily.
But try and make a FPS with Unity or a game that needs top notch multiplayer you are going to need to get outside what it provides.
Torque3D is for those that want total control but that also means it will be more work to do the smaller things. We are trying to tighten that gap with more examples for different genres and I think that maybe enough to be competitive and attract those that want more out of Unity or UDK.
An interface more akin to UDK is more doable in this type of engine. Unity3D is another type of beast, I tend to think of it as a VM. Because the interface isn't in the game its outside of it.
#11
I'm actually of the opinion that to make Torque really accessible, and to highlight the fact that you can modify the code, we should be making it much easier to create games using scripting. I should be able to start up the engine, load a level, and create a simple camera and object with just main.cs.
When I started using T2D, I was just blown away by how easy it was to get started, even with no editor at all. Granted, it has an AppCore module that does some of the lifting, but after that, it was a matter of declaring a new module, adding a script that created some SceneObjects, and there they were on the screen!
I think Torque can do for game programming what Processing did (albeit crappily, and yes I am going to link to that essay every time we talk about usability) for graphics programming. Want to draw a rectangle in Processing? It's one function call, and you can see the result.
Mike Hall demonstrated to me an 8-line main.cs file that loads up a blank canvas, but I failed to extend that to loading a simple level - the client/server interaction defeated me. But I dunno, I feel like that'd be an awesome direction to take the engine.
05/04/2013 (9:17 pm)
We should probably stop telling people who ask about Torque's editors to 'make your own'. I'm going to hazard a guess that it is not what they're here for. I say this with all respect, but it doesn't seem like a very constructive response.I'm actually of the opinion that to make Torque really accessible, and to highlight the fact that you can modify the code, we should be making it much easier to create games using scripting. I should be able to start up the engine, load a level, and create a simple camera and object with just main.cs.
When I started using T2D, I was just blown away by how easy it was to get started, even with no editor at all. Granted, it has an AppCore module that does some of the lifting, but after that, it was a matter of declaring a new module, adding a script that created some SceneObjects, and there they were on the screen!
I think Torque can do for game programming what Processing did (albeit crappily, and yes I am going to link to that essay every time we talk about usability) for graphics programming. Want to draw a rectangle in Processing? It's one function call, and you can see the result.
Mike Hall demonstrated to me an 8-line main.cs file that loads up a blank canvas, but I failed to extend that to loading a simple level - the client/server interaction defeated me. But I dunno, I feel like that'd be an awesome direction to take the engine.
#12
The issue is people want some unknown "entity" to make this "stuff". I think it is straightforward to let people know that this "entity" does not exist. If the person asking does not make it, then nobody is going to.
05/04/2013 (9:33 pm)
@dB,The issue is people want some unknown "entity" to make this "stuff". I think it is straightforward to let people know that this "entity" does not exist. If the person asking does not make it, then nobody is going to.
#13
Anyway, if we had such a resource then perhaps people would have a better picture in their minds of the effort involved with such a request.
05/04/2013 (10:05 pm)
Maybe a tutorial on how to extend the editor is in order. I started fiddling with a conversation system and an accompanying editor extension for it - there are some "peculiarities" where the editor is concerned to say the least....Anyway, if we had such a resource then perhaps people would have a better picture in their minds of the effort involved with such a request.
#14
I've done....3? editors now for various internal toolstuffs, and while most of the time it's fairly straightforward, there are definitely some weird things involved to get it happy.
In light of that, I think I'll jot down on my 'editor todo' list is to streamline adding new editors some. I think some steps, like having to drop the toolbar gui/files into the world editor instead of contained in it's own folder, etc just complicates things unnecessarily, etc, etc. Automating small things like that so you just drop in a single folder(and if necessary, compile an engine file or two) into the tools directory to get a new editor would be awesome for the add-on side of things.
As for what Dan was saying, one thing I'd run into on my current project was the lack of level-scripting. By which I mean items, events or elements that are solely used in one level and never again. Torque isn't really built for this, so I'd mulled on ways to deal with that, and so I was working on 2 hyper-script oriented classes to be added into the engine: 'Actor' and 'StaticActor'.
Actor would be like shapebase, but massively streamlined and lightweight, with tons and tons of script callbacks. It'd be good for lots of lightweight objects so you can hash them out quickly and be done with it. Once you get into full production mode, you can always go into the engine, make a new class etc, but it'd be very useful for prototyping and level work to just script stuff out.
StaticActor would be an object that you never have to open a script file to get it to do stuff in a level because it has several command properties you would click in the editor, toss some scripts on, and be done. An example would be a door object.
Drop a static actor in the scene, pick the model, open the onCollision or maybe onInteract command, and have a small code snippet to play an animation on the model of the door opening. And bam, functioning door object, didn't need to leave the editor to script, didn't even need to leave the World Editor itself.
Stuff like that, I think would be more important to the overall usability of the engine than overhauling/replacing the editors and would be a good starting point.
That got a bit tangential haha, but this is good discussion, I think.
05/04/2013 (10:25 pm)
I think I'd agree with that.I've done....3? editors now for various internal toolstuffs, and while most of the time it's fairly straightforward, there are definitely some weird things involved to get it happy.
In light of that, I think I'll jot down on my 'editor todo' list is to streamline adding new editors some. I think some steps, like having to drop the toolbar gui/files into the world editor instead of contained in it's own folder, etc just complicates things unnecessarily, etc, etc. Automating small things like that so you just drop in a single folder(and if necessary, compile an engine file or two) into the tools directory to get a new editor would be awesome for the add-on side of things.
As for what Dan was saying, one thing I'd run into on my current project was the lack of level-scripting. By which I mean items, events or elements that are solely used in one level and never again. Torque isn't really built for this, so I'd mulled on ways to deal with that, and so I was working on 2 hyper-script oriented classes to be added into the engine: 'Actor' and 'StaticActor'.
Actor would be like shapebase, but massively streamlined and lightweight, with tons and tons of script callbacks. It'd be good for lots of lightweight objects so you can hash them out quickly and be done with it. Once you get into full production mode, you can always go into the engine, make a new class etc, but it'd be very useful for prototyping and level work to just script stuff out.
StaticActor would be an object that you never have to open a script file to get it to do stuff in a level because it has several command properties you would click in the editor, toss some scripts on, and be done. An example would be a door object.
Drop a static actor in the scene, pick the model, open the onCollision or maybe onInteract command, and have a small code snippet to play an animation on the model of the door opening. And bam, functioning door object, didn't need to leave the editor to script, didn't even need to leave the World Editor itself.
Stuff like that, I think would be more important to the overall usability of the engine than overhauling/replacing the editors and would be a good starting point.
That got a bit tangential haha, but this is good discussion, I think.
#15
Not everyone can write their own editor or would like to spend their time writing it. Is Torque not for them? IMHO, it should be for those who are making games.
If those who can help out a user now, by writing an editor for him, that particular user might learn to use Torque today. Tomorrow, he might be helping out others in using Torque.
05/04/2013 (10:47 pm)
@DemolishunNot everyone can write their own editor or would like to spend their time writing it. Is Torque not for them? IMHO, it should be for those who are making games.
If those who can help out a user now, by writing an editor for him, that particular user might learn to use Torque today. Tomorrow, he might be helping out others in using Torque.
#16
When someone mentions a useful function, the answer should NOT be "make it yourself". If the people here wanted to program everything themselves, they'd make their own engine to start with. Torque, UDK, Unity... They're really entry-level engines whose vast majority of users are pretty new and often don't know how or are capable of covering all the areas such as UI programming.
I know for an unfortunate fact that Torque's weak editor tools are a big reason it isn't as big as some of the others. I've introduced quite a few people to Torque and none of them stuck. Every single one of them complained about the tools. So maybe the "make it yourself" response isn't entirely the way to go.
05/05/2013 (1:25 am)
Daniel already expressed my thoughts, but I thought I'd reiterate it because frankly, it's an attitude that pretty much kills this community and is a reason I've become much less active over the years...When someone mentions a useful function, the answer should NOT be "make it yourself". If the people here wanted to program everything themselves, they'd make their own engine to start with. Torque, UDK, Unity... They're really entry-level engines whose vast majority of users are pretty new and often don't know how or are capable of covering all the areas such as UI programming.
I know for an unfortunate fact that Torque's weak editor tools are a big reason it isn't as big as some of the others. I've introduced quite a few people to Torque and none of them stuck. Every single one of them complained about the tools. So maybe the "make it yourself" response isn't entirely the way to go.
#17
It wouldn't be too far fetched to improve the current engine and streamlining it a bit. There is room for improvements no doubt.
@Richard agreed, we need tutorials on how to extend the engine with our own stuff so it suits our specific needs. A tutorial on how to extend the editor would be warmly welcomed.
@dB I had the exact same experience when running T2D for the first time. I was like "Oh shit I finally have a completely bare bones project in a Torque engine!". It makes it so much more manegeable to write a game when you know exactly what happens and you have complete control of how it boots up. A barebones example like the one in T2D should really be a high priority thing (mostly due to the fact that if someone knows how to do this it wouldn't take that long to make a quick tutorial about it)
05/05/2013 (1:26 am)
I think Jeff had some good points.It wouldn't be too far fetched to improve the current engine and streamlining it a bit. There is room for improvements no doubt.
@Richard agreed, we need tutorials on how to extend the engine with our own stuff so it suits our specific needs. A tutorial on how to extend the editor would be warmly welcomed.
@dB I had the exact same experience when running T2D for the first time. I was like "Oh shit I finally have a completely bare bones project in a Torque engine!". It makes it so much more manegeable to write a game when you know exactly what happens and you have complete control of how it boots up. A barebones example like the one in T2D should really be a high priority thing (mostly due to the fact that if someone knows how to do this it wouldn't take that long to make a quick tutorial about it)
#18
It's not that we don't care about the editors neither would we mind seeing them being improved. But it's just not necessary, so why spend the additional manpower on this? If you are looking for a GameEngine where you can do everything from the editor, you should use Unity.
I mean.. Why not use Unity? It has got everything you request and it's free. Granted the free version have some limited features, but then you can always buy the pro version.
Although before being too dismissive @all does anybody know if the editor work from T2D can be brought over to T3D? That might give T3D an interesting starting point if we want to improve the editors at some point.
I don't see it as being a high priority issue but if we could just get the tools framework from T2D it would always be an open option.
Torque2D editor plan
It's all plug-in based so it would be simple to remove the T2D plugins and install T3D plugins instead, keeping the plugins that suits both engines.
05/05/2013 (1:36 am)
Also @martyIt's not that we don't care about the editors neither would we mind seeing them being improved. But it's just not necessary, so why spend the additional manpower on this? If you are looking for a GameEngine where you can do everything from the editor, you should use Unity.
I mean.. Why not use Unity? It has got everything you request and it's free. Granted the free version have some limited features, but then you can always buy the pro version.
Although before being too dismissive @all does anybody know if the editor work from T2D can be brought over to T3D? That might give T3D an interesting starting point if we want to improve the editors at some point.
I don't see it as being a high priority issue but if we could just get the tools framework from T2D it would always be an open option.
Torque2D editor plan
It's all plug-in based so it would be simple to remove the T2D plugins and install T3D plugins instead, keeping the plugins that suits both engines.
#19
A very valid point, however part of the problem is deciding what constitutes a general-enough tool or feature to make it worth implementing. Improvements to something like the terrain editor are easily visible as a project-agnostic gain.
Someone saying 'X needs to be an editor' is oftentimes focal to their project specifically and depending on how specific the editor or feature in question would be, it frankly does sometimes boil down to 'make it yourself'. That said, I don't think that should necessarily be the default response.
I would like to get some outside perspective from people who didn't stick with T3D because of the apparently weak tools. I think that sort of feedback would go a long way to figuring out what, in the baseline toolset, should be targeted for improvements first.
@Lukas
Personally, I don't like the idea of segregating the editor from the game engine. It's something I despised way back from working with UT, and I think pulling the editors and putting them into a separate application, even if it has hooks to the game, is a step in the wrong direction.
T3D's approach to editors isn't terrible, it just needs polish. You can *almost* just simply drop a folder into the tools directory and get it to appear in the editor. It just needs some polish and documentation.
05/05/2013 (1:41 am)
@JacobA very valid point, however part of the problem is deciding what constitutes a general-enough tool or feature to make it worth implementing. Improvements to something like the terrain editor are easily visible as a project-agnostic gain.
Someone saying 'X needs to be an editor' is oftentimes focal to their project specifically and depending on how specific the editor or feature in question would be, it frankly does sometimes boil down to 'make it yourself'. That said, I don't think that should necessarily be the default response.
I would like to get some outside perspective from people who didn't stick with T3D because of the apparently weak tools. I think that sort of feedback would go a long way to figuring out what, in the baseline toolset, should be targeted for improvements first.
@Lukas
Personally, I don't like the idea of segregating the editor from the game engine. It's something I despised way back from working with UT, and I think pulling the editors and putting them into a separate application, even if it has hooks to the game, is a step in the wrong direction.
T3D's approach to editors isn't terrible, it just needs polish. You can *almost* just simply drop a folder into the tools directory and get it to appear in the editor. It just needs some polish and documentation.
#20
Many experts or modern games do not use this way of building levels anymore, because they want complicated high detail and organic shapes, but beginners may be satisfied with making simple block walls and rooms and giving that a texture.
If I would improve something then it would be this: Update the sketch tool with a few more primitive functions and a way to apply generated even texturing, without having to use UV-mapping.
05/05/2013 (2:17 am)
I noticed what many peope are missing and me also is a direct way in the editor to create things, you have a terrain system and can place objects made in another program on it, but nothing for direct shapes, only the sketch tool, which is just for sketches.Many experts or modern games do not use this way of building levels anymore, because they want complicated high detail and organic shapes, but beginners may be satisfied with making simple block walls and rooms and giving that a texture.
If I would improve something then it would be this: Update the sketch tool with a few more primitive functions and a way to apply generated even texturing, without having to use UV-mapping.
Duion
Imagine the complexity of a modeling program, do you really want to reprogram such a thing from scratch just to make it a little easier?