How should we promote T3D?

#101 I agree I always thought a key feature for indies and TGE was cross platform support, I was always surprised at the move to Direct3D 9 in TGEA.

I think if we ever look at replacing TorqueScript, it needs to be something more complete like C#, look at Unity most devs use C# (MONO). And there is a C# implementation about also for T3D.

https://www.winterleafentertainment.com/Products/DotNetTorque.aspx

I only don't use it as it is non-standard and what are the plans for it when T3D goes cross platform? MONO?

But I disagree with changing the whole way the editors work to make it easy for Unity devs to jump across, Unity isn't even the competition for Torque 3D. We are up against CryEngine 3 and UDK. In that case I feel our editors are infact quite there.

This to me means we need to show some great things that can be done with T3D and get it working also on Linux and MacOS. Ron's work on his recent blogs is a great example, and also shows we lack a fair bit of artistic talent around here. Because the engine is very capable.

#102

Quote:Open source isn't going to be a functional selling point

Bologna, that IS the reason I use this engine.

Quote:Move from TorqueScript to something like Javascript or Lua. TorqueScript is too specialized and most incoming newbies will want to use a scripting language they already know.

Done: You can use C#, Python or Javascript. It takes some assembly of existing resources, but it can be done now.

Quote:most incoming newbies will want to use a scripting language they already know

I don't really think Torque is focusing on newbies or the fly by night Unity crowd. The focus I see is professional developers.

There is a port to Linux for T3D already, but I am not sure of the status.

I don't see a huge push to run things as a 64 bit app. The main limit there would be memory usage. I think if that were an issue you could potentially run multiple processes.


Also, you do realize non adherence to standards is often done because of speed issues in the standard libs, right?

#103 Peter,
I agree with everything but
6. A Unity style editor. Like it or not, this is going to be the way to convince more rookies to come over and use Torque.

Me from working with both T3D and unity. T3D's editors are a little more easier to use. Not taking anything from unity but I really think it depends on the user. I started with torque back when it was just TGE (2004). With that being my first introduction into game development I find that I've came pretty custom to the editors of T3D granted they can/should be expanded but I think T3D should stick with the style of editor it has and maybe build on it to make it a little more user friendly. I find the editors in unity are kind of confusing.
One thing that I think would make T3D more easier is to maybe change to a drag and drop type editor but the style and how to use the editors I feel are great. Just my thoughts!

#104 Yes, the editor is quite good, just add more drag and drop style functions, like in CryEngine, if you have used that you maybe know what I mean, the workflow is faster there. I think CryEngine is the most advanced Engine out there and we should orientate more on this.

#105 Demolishun: IMO professional developers would want to use professional languages... like C#, Python or Javascript :P. Do you mean there's a Javascript integration with the engine already? I was tempted to look into doing that, but it'd be a heck of a job to do it right.

#106 @Demolishun

Open source only goes so far, and open source isn't going to stack up if content, functionality, and support is not up to snuff. Furthermore, the non-adherence performance reasons may have flown many years ago, but not today. Modern standard libraries are a lot more efficient and performance friendly than older ones. This is the document on the standard that should be adhered to: https://www.securecoding.cert.org/confluence/pages/viewpage.action?pageId=637

To be blunt, I worry greatly that Torque has a lot of security vulnerabilities in it from what is, to be blunt, crappy coding practice. I only need to point you to the following link which demonstrates why this is a problem: http://seclists.org/fulldisclosure/2013/May/109

As for the existing wrappers for other scripting languages; if they aren't in there out of the box, and supported by default, it's not worth bringing up. That's not a feature you can advertise as out of the box, and because of that most people won't care.

Furthermore, Torque needs to bring in the newbies, as that's the way to bring in new people to the actual community. Professionals should get attention, but if you don't bring people who are new in to learn, they will just go with something like Unity and stay with Unity. If that happens they likely won't ever try Torque. This is the exact same way Microsoft still holds platform dominance while Linux is a vastly superior operating system.

As for the editor, I'm going to try out Cryengine 3. I'll see how that editor is, maybe it is better than Unity.

#107 Yes I think we should be looking at CryEngine and UDK's editors as they are closely matched to T3D's one and the style of engines also.

The more tools we have to construct levels faster/easier/simpler the better. As mentioned elsewhere to easily put together modules is an increasing trend in game design.

#108 @Peter,
If you think there are security issues with "crappy" coding then how about you head up some fixes and get those in the engine? It sounds like you have some advanced knowledge on this. Perhaps you can be the security expert?

There are reasons why other languages are not in the engine "out of the box". One is because C# is a professionally supported solution by WinterLeaf. They also are providing bindings for the T3D engine out of the box. They even have a tool that can recreate bindings to any new functionality someone adds to the engine. IMO, that is an excellent tool for using any .NET language with T3D.

Python is not in there because I found issues with dependencies on the PythonXX.dll. So I am keeping that as a separate interface. Ultimately that is developed for my projects so usage by the community is welcome, but there does not seem to be enough interest to justify inclusion (IMO). It is simple enough for a developer to include and there are step by step instructions.

Another thing I should mention. Because I did the hard work of digging into the engine and making it work with Python via SWIG it makes the other languages SWIG supports potentially available. It will take more work to use those languages as extensively as Python, but the framework is there. SWIG supports like 14 languages or something crazy like that.

As for newbies that is fine, but the turn over for "game developers" is high as ppl somehow think this stuff is easy. Most come in without any kind of CS or Art background. In all honesty they might be better off weaning themselves on an engine that is more suited to beginners. I would prefer to provide middle ware solutions to professionals who want and need to power of T3D/T2D, but have the maturity to keep going when the going gets tough. I come from a CS background so I have never had issues with Torque engines, but that would not be a beginner perspective. So in all reality I am probably extremely biased. ;)

@dB,
The ECMA script (Javascript) interface can be done in a couple of ways. One is by using the T3D engine as a plugin for a web browser. There are already hooks into the scripting language of the browser. (I am not sure if this updated for the latest version though.) The other ECMA interface is as a plugin (V8 Plugin) for Python. This to me is the preferred solution because I can absolutely sandbox that code in separate contexts. So users could literally write scripts in ECMA and not mess up the internals of the game. Other languages have similar bindings including LUA. Though the LUA binding I saw for Python had issues because they were allowing introspection back into Python. That is not a good sandbox. Python is a poor choice for sandboxing period.

@Edward,
I agree on the modules/components aspect. The default game objects are fine for demonstrating how the engine works, but a more comprehensive system of objects would be excellent. I would love to be able to create an object and then link it somehow to an object that handles networking. It would be great to be able to make it so the networking component could be made aware of variables/structures that need to be passed over the link. Ideally these relationships could be defined at runtime rather than compile time. I think this would require going below SceneObject in the class system to create objects without any networking in them.

@Duion,
I think CryEngine is setting some standards that would be very good to emulate. I fully agree that drag and drop especially with some components would go a long way for rapid development.

#109 Drag and drop should be easy to implement, at the moment you have your menu of items and a drop location, if you click an item it gets dropped to the drop location, it needs to be changed to snap to your mouse cursor by default and release, if you click, while doing so, the default alignment should be snap to terrain or snap to other objects if there is no terrain, since this is what you want to do most.
It is some little things like that, that make the workflow much faster. --> Look for settings that are used most and make them default, this way new people will feel good while using the editor for the first time.

#110

Quote:think if we ever look at replacing TorqueScript, it needs to be something more complete like C#, look at Unity most devs use C# (MONO). And there is a C# implementation about also for T3D.

.......

I only don't use it as it is non-standard and what are the plans for it when T3D goes cross platform? MONO?

Actually, yes. with our design we already have plans in place for a MONO implementation that should fit in nicely.

#111 Actually DNT is a viable solution.
You can download a DNT v1.1 version of T3D 3.0 for free at GitHub the license is very liberate except for the fact that you can't charge money for the DNT source code.

The only down side is that
1. You can't re-sell the engine or any engine that derives from it.
2. To generate new C# functions and objects you'd have to buy the DNTC, you are free to do it manually however. (Albeit that might take some work)

The only thing that costs money is the automatic generation of the C# "bridge" or whatever you call it.

I don't know if the license is liberate enough for T3D (it isn't really MIT compatible given that you can't charge money for the source code) but it is an option. You can still sell the games you made with it, tools, addons etc..
And if someone really needs to charge money for the source code, some kind of deal could probably be made with Paul Yoskowitz and Vince Gee.

#112 I came across Assimp library and I wanted to know what people think about adding it to the art pipeline of T3D?
assimp.sourceforge.net/lib_html/index.html
It would take care of the issue of trying to have different files formats for T3D.

#113 @Kory
Unless someone would add a assimp to dts converter one could just import "whatever file" then export it to a dae then convert it to a dts.
Very possible without too much work if it doesn't screw up somewhere in that process.

#114 I don't have a problem with the current pipeline but I've seen that some people say they would love other formats within T3D.
I think this would be a fair solution, plus I been following it and I believe their next step is adding .fbx support. As you said if a person was to be able to create an converter, problems that people are/were having would be solved.

Honestly..I like the art pipeline now and never really had major issues with it but came across it and thought I'd put it out there to see what people of the community thought of it.

#115 @Demolishun Maybe I will later, right now I have much higher priority projects on my plate that I have to deal with first. Hopefully by then Torque will run on Linux so that I can work in my native development environment. For now though, I have to focus on other projects that are *much* more important.

#116 Just came across this kickstarter for leadwerks.
www.kickstarter.com/projects/1937035674/leadwerks-build-linux-games-on-linux
From the looks of it they reached there goal. I know people are like what does this have to do with T3D. It really doesn't but I was thinking and this is simply my opinion. If leadwerks reached there goal of over 20K, why hasn't any T3D project done the same? T3D is a much better engine. Leadwerks uses an older lighting model. Honestly I would like to know what T3D needs to do to have success on these crowd funding sites?

#117 @Kory. Bump.
I think that is a very interesting discussion. Perhaps it simply have more users. Perhaps it's a matter of reputation. Perhaps it is a result of them being better to advertise what features it has. I believe it's a mix of all those.

#118 I'd have to agree. There still is a stigma about the engine. Though the right outreach could fix that.. Hell even new tech demo would help.. That honestly, I think is worth the effort.

#119 Smally and Lukas
Agree with both of you I guess it's up to us to change the stigma. By releasing either some good tech demos or some really great looking game with all the eye candy to demonstrate what is possible with T3D. Which I know has been the topic here for the better part of the year.
I was just surprise to see leadwerks with a kickstarter project that was actually successful and the kickstarter campaign for any of the T3D and T2D wasn't no were close.
I know we have it in us. I guess it's really time to push T3D to it's limits, or find out a way of killing the stigma so our projects if put on a crowd funding site would be successful.

#120

Quote:By releasing either some good tech demos or some really great looking game with all the eye candy to demonstrate what is possible with T3D.

Agreed.

Also, some tutorials of making non-fps style games from scratch. I am going to use my prototyping of a game as a way to show off T3D and its features. Although I will also be doing things in other scripting languages in addition to Torque Script.