Game Development Community

Introduction and the Future of Torque

by Kenneth Hamilton · in Torque 3D Professional · 06/08/2014 (6:08 pm) · 36 replies

Let me start off by introducing myself. My name is Kenneth Hamilton, or you can call me Kenny. I don't really consider myself a developer. I have no published titles or experience in the gaming industry, indie or otherwise. I do consider myself an artist. I have been drawing for well over 30 years and transitioned into the world of 3D a little over a decade ago. I very rarely speak to people, in real life or otherwise. Because of this, I feel that my communication skills may be lacking, but please bare with me. I guess one could call me a self-imposed pariah. I do, however, research and observe things, a lot.

I grew up in the days of 4bit graphics on the Atari 2600 transitioning over to 8bit NES and so on. I got my first PC when I was in high school, almost 25 years ago. Ever since I discovered the possibilities of the computer, I've been fascinated with learning everything I could, including a desire to make games. I have been an avid user and supported of open source software for over a decade. That's what in turn led me to this community when Torque went MIT.

I have noticed a lot of talk lately about the future of Torque. People saying Torque can't compete with what's out there, and needs features, features, features. I've seen that some people are afraid that since Torque is now open source it will fade away because open source projects rarely succeed. I've seen the community fractured in places, and some people leave, while others just remain silent. I've seen a lot in this community in the short time I've been here. Having said that, I am no stranger to these things as I have seen many open source communities go through these same struggles. In way, I guess one could call it growing pains. As I said, I have been around open source software for well over a decade and was there when Blender was initially released as an open source project. And if anyone were to visit blenderartists or some of the other blender forums, they would probably find a lot of similarities to this community with one notable exception... size. Because this community is so much smaller, things that might be par for the course in larger forums automatically sticks out like a sore thumb here and gets noticed more. Case in point, if you go to blenderartists, you will probably find way too many threads started for feature requests, or other threads talking about how blender's UI sucks or this or that. What sets that community apart is that Blender is techinically a success in the open source community.

I don't think Torque MIT has truly had enough time yet to gain traction to be the success that Blender has become. And I think that might be why so many people are wary of its future. But we have to remember, Blender has been at this a lot longer and had to take some big strides to get noticed. And that brings me to my next point. Development. As I said before, I don't consider myself a developer, so take anything I say with a grain of salt, and feel free to correct me if I am wrong in any of my assumptions. I think that in order to get Torque up a level playing field with Blender as an open source project, there are certain things that need to happen. First and foremost, we need to grow the community. The problem is, how to do it? Depending on who you ask you'll get a different answer, and this is mine. Although it is only an opinion, I think what would help grow the Torque community is a closer relationship with Blender. Don't take that the wrong way, I don't mean the Blender Foundation, but rather the Blender community. If Torque can leverage the size of the Blender community and start getting people to adopt Torque as their engine of choice, then the user base could grow exponentially. I think this is why Valve and Epic have started to develop a closer working relationship with the Foundation because they see the huge potential that Blender has for the indie community, and let's face it, isn't that who Torque should be geared towards?

So how could we get that leverage then? I've been thinking about this too. I spend as much time at the blenderartists forums as I do here, I observe a lot of the converstaions that happen in the threads, the BGE threads in particular. I've seen a lot of the same conversations take place in there, as to why people use BGE.

1.) It's built into the editor. I have seen so many people use that as a primary reason, because they don't have to export their assets. I think Torque is already on its way to dealing with the import issue. If Assimp gets fully integrated into Torque for the importing of meshes before caching them out to DSTs it would help tremendously especially since Assimp reads blend files. I don't know how well that would work with animated meshes, but its a start.

2.)Python. Many of the BGE users use it because they can script in python. One user compared it to programmer's crack because it was so addictive. Personally, I am not the biggest fan of python, but to each their own. I do think if we had access to other scripting languages besides TorqueScript it would at the very least tempt more users to try it out. I believe that there was some talk on getting other scripting languages implemented, but I don't know if its still an ongoing thing.

3.)Linux support. Many Blender users are very picky about their operating systems and refuse to use Microsoft prodcuts at all, which completely cancels out DirectX. Once the the Linux and OpenGL ports of Torque is completed, I think that in itself will add to the adoption rate.

These are just a few things that could be done to help integrate some people over to using Torque. But by itself, it isn't nearly enough. I said before that Blender had to take some major strides to be noticed. One thing it did to really set itself apart from other open source projects was when it produced the open film projects. Starting with Elephant's Dream, the Blender Foundation started using Blender in a production environment and developing tools as it went. That was actually a very good decision, not only for publicity, but it allowed the developers to focus on areas that were lacking in the current toolset and target those areas specifically. To apply this to Torque, I think what would work is a community developed game. Although I've never actually played it, I heard that Tribes was a very good game and the backbone of what Torque is known for. If the community could come together and develop something similar, developing the tools as they go, then the end product would be good for marketing but also serve to further engine development. I think spilitting the focus for this project would be what's best however. I know some people would want those tools to be focused on graphics but I don't think that would be best. I think for the initial development it should primarily be focused on usability. I also think if every step of the production was documented, whether through text or visually like a developer's diary so that others can see how things are done. I think it could actually help get more people involved in the development phase if they know how things are working. And example might be just making a basic asset and importing it into the engine and getting it set up. Or using various modular assets in conjunction with each other to flesh out a level. If it's simple enough that a caveman can do it, then people might actually start coming in from other communities to help.

As for the graphics side of things, I do agree that to remain relevant the graphics are going to need to be upgraded at some point. That's just the simple truth of technology. But I think that would work better as a tech demo. Think Samaritan or Infiltrator. Those were realtime demos, but they weren't games. I think if we had just a 3 or 4 minute demo showcasing what Torque was capable of as part of an upgrade that would have mass market appeal. Again though, it would have to be a community driven effort.

All of these things are well and good, but the question remains, where do we start? Honestly, all I can say is what I would do if I were the one in charge. I think it would be ideal if the steering commitee got together as a group and decided on a future roadmap. If the idea of leveraging the Blende community lies within that roadmap, then I would draw a proposal for a Blender integration pipeline and present it to the community. I can't speak for anyone there, but I do think if you were to show that you are sincere in your attempt to bridge the two softwares, you'd be well received. I would think about doing myself except as I said at the beginning of the post, I very rarely talk to people. Not to mention that I think it would be better if it were coming from an "official" representative of Torque.

In closing, I'd just like to add my own personal thoughts on the engine. I whole heartedly believe that Torque as an engine is great. I think that in the right hands, stock Torque could do things that would make people question whether its Torque or not. If we focus more on the usuability right now and try and lighten the perception of a programmer's engine, and focus more on the artists side, with things such as nodal logic we could get a lot more people to use the engine. I think that's why Unity took off the way it did. As I said at the beginning of the post, I don't consider myself a developer so everything written here is just my own personal opinion and is probably very wrong in many instances. I'd also like to apologize for my long-windedness. Please feel free to correct me where I'm wrong.

About the author

Recent Threads

Page«First 1 2 Next»
#21
06/15/2014 (7:34 am)
Torque 3D + Blender under MIT would be awesome.

However, I do worry about the MIT license as Blender is not currently under a MIT license and that could complicate the things a little.
#22
06/15/2014 (11:25 am)
@Mark

Yeah, I'd read over that roadmap some time ago, and remember it talking about how Ton's plan was to convert the BGE into some sort of "interactive mode". I don't know if I'm off-base, but I'm thinking that besides the physics side of things, it might make the viewport a little more interactive as well. Something akin to Marmoset as far shader creation and realtime previewing. Then again, I could just as well be wrong, but I do think it would be step in the right direction as far as easing the transition to other engines outside of Blender. I completely agree with your assessment as far as both communities benefiting though.

@Dwarf King

I'm not so sure that Blender being under the GPL license would create much of a problem if all you're doing is exporting assets. The biggest problem with Blender's GPL has primarily been with the BGE side of things. It adds an unnecessary burden to publishing your game, as is evidenced by the number of GPL question threads that pop up in the Game Discussion forum on blenderartists. From my understanding all blend files are your own IP and you can license them however you want since their program output. The problem comes when you try to integrate those blends into any kind of executable file. As far as Python scripts, I think I read somewhere that the Blender Foundation got a special exception in the place of Python scripts, again, as long as they aren't bundled into an executable file. That's one the reasons I am so glad that Torque went MIT instead of GPL. GPL's just too much of a headache sometimes.
#23
06/15/2014 (3:54 pm)
Lua should be pretty easy to do - I use a slightly modified version of Luna to expose class functionality to Lua (contact richard at roostertail games dot com and I can mail it to you). Then you can just expose a piece at a time, slowly so it's easier to test. I only shied away from tolua++ because I didn't feel like dealing with Boost.
#24
06/15/2014 (5:06 pm)
@Richard

Thanks for the info. TBH I haven't done much in the way of serious programming in 20 years. Last time I did any "hardcore" programming was messing around with mode 13h after discovering the Second Reality demo by Future Crew. Damn I feel old now! Aside from a few lua scripts I did for effects in Aegisub, I haven't really coded much. That being said, I'd like to at least look over Luna. I might not be too familiar with the language specifics, but I'm sure I can still follow the logic of the code, so I'll probably take you up on your offer. Thanks again.
#25
06/15/2014 (8:57 pm)
Note that Luna is a template-based solution - not super complex but still tough to follow if you're not familiar with templates.

That being said, I'll be answering email on that account after the 21st.
#26
06/16/2014 (2:02 pm)
@Richard

Like I said before, it's been a long while since I've done any real programming, so my knowledge is lacking to say the least. When you say template based, do you mean that it's some kind of barebones framework that you can "plug" functions and other code into? If that's the case, wouldn't it be something like a node-based logic system, where each node is its own little independant shell that links to other nodes to form a higher program? But in this case, should I assume that everything would end up encapsulated within the template?
#27
06/20/2014 (9:39 am)
Torque doesnt needs features. Torque needs documentation, books and samples. Why does Unity has the place that belongs to torque? Because even the street dogs knows Unity. You search in torrent sites and find 3-4 books covering from beginning to advanced topics, plus a couple of video packages showing advanced techniques, etc. Besides, the engine is intuitive.
What do you find when you search torque3d (which is not an intuitive engine)? A single book, and it is not even oriented to beginners, it is a recipe book. The only one engine with worse documentation that I have seen is Unigine.
In my opinion, developers can stop coding features and start creating samples, tutorials and videos. Probably that will boost Torque popularity much more than integrating python or whatever language you want.
#28
06/20/2014 (10:26 am)
@Kenneth - C++ Templates - it's a language feature of C++ designed to enable various generic programming techniques.

Torque needs plenty of love. If it were my personal project I would focus on bug-fixing and documentation/tutorials first. This has three benefits; bugs get fixed, documentation is up to date, and it helps develop intimate familiarity with the code. Benefit number three makes adding features (my personal "phase 2") much easier. Just thinking out loud, not criticizing.

There are several Torque books, but the majority are very old. Finney's first book 3D Game Programming All In One has been updated for T3D, but it's not the MIT release. If you search for "T3D" you're going to miss most of them, but even old TGE books still retain a good deal of relevance and converting examples over from them is a great learning experience. I recommend finding them used if you can, they represent what most would call "tribal knowledge" - stuff that helps explain why things are the way they are.
#29
06/20/2014 (10:41 am)
I've said it before and I'll say it again, if GarageGames (or the steering committee) approached the Blender Institute about doing a OpenProject together, great things would happen. Could you imagine the support that would come in for an open, Tribes-like game?

This would allow significant funds to go into improving the Torque code base and also improve the workflow between Blender and Torque.
#30
06/20/2014 (12:06 pm)
@Roger

I think you're misunderstanding me. I'm not necessarily advocating for new features. I think Torque as it is now is a great engine capable of creating a AAA game in the right hands. Of course, at some point in the future it will be necessary for new features to be added, but that's just the way it is if you want to remain competitive. But, what I'm looking at right now is just a way to grow the brand so to speak. I think one of the problems with what you mentioned about the documentation, books, samples, and so forth, is that there just isn't enough knowledgeable people in the community to fill those roles while also maintaining their own projects. What I'm basically looking for is a way to lower the barrier to entry. Right now I'm just thinking out loud and throwing out ideas to see what sticks. Nothing more. I will agree with you about Unity though, But I think what helped it grow didn't come from the tutorials and books alone, but also because it was much easier for a beginner to use than Torque currently is.

@Richard

Thanks for the info. And, no, I'm not taking any offense. I completely agree with your focus. Bug-fixing and documentation are absolutely necessary in any software. While I agree that Torque does need plenty of love, I still maintain that even as it is now, it is a very capable piece of software. I've actually looked at some of the TGE books, and watched the TGE videos on Youtube and Vimeo. I agree, that a lot of what is in these videos is still relevant to the current version of T3D. It might be done a little differently now, but the methods are still viable. It kind of reminds me of when Blender first went open source. Finding tutorials was next to impossible for quite a while. So instead, what I did was look at tutorials for other software and see if I could adapt those workflows and techniques in Blender. I still do that today. I've watched many game development tutorials for other engines and looked for ways to adapt it to Torque. The problem is that I don't think many people think that way, so they just want to find the shortest path from point A to point B.

@Dark Tengu

I completely agree. That was the my whole point in starting this thread. I honestly think that if we can grow the userbase, we can get greater support for development. That's not to say that there isn't risks involved. When the Blender Foundation started on Yo Frankie!, they had originally planned to use the CrystalSpace engine, and were working pretty closely with their development staff. But from what I understand, the CrystalSpace guys kind of flaked out halfway through the project, which is what led to the Apricot branch of Blender. So if we were to take on a project of that scope, we would really have to make sure that we bring our A game and see the project through to completion. I think one more thing that could help is opening up the project even further and allowing the community as a whole to develop the game instead of just a set team of people. This way more people learn about Torque and game development in general, and the whole undertaking can be looked at as a sort of "use case" for the Blender to Torque pipeline. Issues could be raised as they are encountered, and it would be easier to find workarounds or fixes for said issues because more eyes would be looking at the code and the workflow. If we as a community could document things as we go, like a sort of how to video series, then that also takes care of part of the documentation problem by adding a tried and tested tutorial series that others could follow later on. Sort of like the mini FPS tutorial but on a much grander scale.
#31
07/13/2014 (5:38 am)
So, I recently made an example integration with Python based on Frank Carney's SWIG interface for the engine. It may interest some Blender people who are used to working in Python...
#32
07/13/2014 (9:35 am)
Nice, Daniel!

Hey, any thoughts on adding an "examples" repository? My thought is that it sort of needs to be kept in sync with but shouldn't necessarily be part of the main repository. Literally, things like your example.
#33
07/13/2014 (11:03 am)
Yes, definite thoughts on doing this. The wheels are in motion. Might try to do it in sync with 3.6, we'll see.
#34
07/13/2014 (1:13 pm)
@Daniel

Nice example, man. I agree with Richard that an examples repository would be a nice thing to have, particularly for new users. Just a random though, this is probably outside the scope of what you're wanting to accomplish, but have you considered maybe a writeup of function call comparisons? As an example, let's say I wanted to add constant rotation to an asset. In BGE the syntax would be something like this

applyRotation(rotation, local=False);

whereas in Torque it would be something like this

rotation = "1 0 0 0";

I'll admit that my knowledge of BGE scripting and TorqueScript is seriously lacking so my example isn't the most accurate or in depth, but it does illustrate what I am trying to say. Even though both programs have different formats in the way the functions are set up, the end result should be the same. So if there were examples of how one might accomplish basic tasks in BGE with python and then show them the same way to accomplish those tasks in Torque it might go a long way to easing the barrier between the two. The one issue I could see would be that for this to work, it would take a somewhat intimate knowledge of how both programs operate. If there were a BGE guru to consult with, it would probably make things a little easier though.


#35
07/13/2014 (3:12 pm)
Quick reply for now - I'm actually not at all familiar with BGE unfortunately, or I'd think about more specific ways of reaching out to that audience with my work... sounds like I might have to put some effort into it.

Unfortunately I'm not yet sold on Frank's approach to using Python with T3D. It's really cool, but internally it still goes through the TorqueScript console somewhat, and the abilities of the Python scripts are in some ways constrained by how torquescript works. So I'm still not totally throwing my weight behind this. But if we at least get some people interested, maybe we can work on it. I'm sure if Frank were around he'd have more to say on the subject.
#36
07/13/2014 (4:10 pm)
@Daniel

I totally get where you're coming from. I honestly wasn't thinking of Python being an absolute 1:1 equivalent to TorqueScript. I'm just trying to find ways to drum up support for the engine by looking at ways of tapping into an outside community. I think, if I'm reading your response right, that you're thinking the same thing as I am. Even integrating limited Python support is a step forward to opening Torque up to that community. I still personally think that finding a way to incorporate Blender's logic brick system would be a big help at getting people to at least test out the engine. But I also understand that would be a lot of work, and would probably require developers from both communities working together to come to a consensual solution that would benefit both sides. That being said, I'd still like to thank you for your continued efforts.
Page«First 1 2 Next»