I was wondering how Touch would compare performance-wise to unity for a 3d game?
Do you think it’s possible to handle something somewhat complex with multiple levels loading/unloading ?
Also would python be fast enough for game logic compared to their c#/js ?
I feel touch is an awesome drafting tool but wondering how well it scales up.
I’m sure my question is far too vague to be answered properly, and obviously this is not Touch strongest point, I was curious to read people thoughts though.
That’s an interesting question. I’ve used TD for large interactive projects as well as C++ and flash but have yet to dive into Unity. IMO TD’s real-time paradigm makes it better suited as a performance and prototyping environment than a full interactive engine. I’ve found myself working around the peculiarities of time slicing, chops and un-compiled code in the past when trying to do complex event based scripting. On the other hand, just loading a model and getting some decent lighting is a huge endeavor in C++ and takes seconds in TD. I get the sense that it’s more difficult to get a good look quickly in Unity as well.
Technically you could make a game with Touch no problem. However, TD’s interface and workflow wasn’t designed with making games as it’s primary goal. You will spend a lot of rolling your own workflows to match what you get ‘for free’ (or at least with less effort) than with other environments such as Unreal or Unity. Things like physics animations, state management, memory management, performance management (not everyone has awesome hardware!) and blend animations come to mind.
Of course, you can flip that argument and say Touch gives you so much for free that those don’t. So instead of getting into a techno flame war you may want to consider your audience and motivations for making a game.
For one, there is distribution. The only outlet for a Touch Game is a windows machine, with Touch player installed.
If you just want to learn more in general about ‘making games’ I think Touch is a fine place for it. There is so much richness of input and output that you have few limits on what you can interface with. Also I think you’d learn some very valuable lessons about what actually goes into making a game engine.
At the end of the day most of the good games, or at least the very clever parts, come down to writing piles of code and the best place for that is your favorite text editor. I know Unity has closed that gap in some respects, but I have yet to see a decent Unity game that didn’t have a bunch of code to gluing it all together.
I say make a small game in each, you’ll be richer for it. Good luck!
As part of our R&D we took our car simulator that we made for Nissan and ported it to Unity.
It ran on much lower end hardware and we didn’t have to fake the physics like with touchdesigner…in fact the workflow was much much faster in unity. If you’re making a game of course it’s a better platform, but it really falls down when it comes to making things like projection mapping tools I’ve found, not that it cant run them, they just take a lot longer to build.
I would never wish the pain we went through building collision detection etc in touch on anyone.
I don’t have expertise in this, but maybe it’s possible to compile a demo of an existing physics project to a dll for touch to use in a CPlusPlus DAT. I think you’d have to make changes to the source code to consider what DATs Touch will provide it (none is an option), and what the CPlusPlus DAT will output (maybe a DAT that can later be used in instancing). The Bullet engine seems to be well-known github.com/bulletphysics/bullet … /BasicDemo derivative.ca/wiki088/index. … sPlus_CHOP
(described here