TGEPython and Self-contained Python App

#21 @Jason: If I was using Torque and it wasn't disrespectful to the TGE license, I would compile Torque as a standard Python module...

PyTorque had a very cool distutils, that I spent a serious amount of time on, to do just this... PyTorque also drilled into Torque's C++ code, and used SWIG, to expose further functionality to Python...

PyTorque was quite heavy weight... TGEPython, which requires zero changes to Torque's C++ code and is 10k of source is very lightweight...

It was my belief that a LOT of people could have been introduced to Torque via this Python module... though, you would have to control the binary in this case... which you really don't need to do with the Torque demo... I don't really know... not my territory....

-Josh Ritter
Prairie Games

#22 I can see GGs POV regard TorqueScript. But by no stretch of the imagination is it easy for artists to grasp.

Quote:
If you know C++, TS is not hard to learn.

And that nearly explains it right there. Its as if Torque wasn't even designed with artists in mind.

#23 @ Randall: At some point, you need the functionality to actually make a game. We never, ever said it was easy. But, to say we never had artists in mind is absolutely wrong too. What about the GUI editors, the terrain editor, the support for industry standard 3D editors, etc?

Any language that has enough functionality to actually make a game will be just that... a language. That automatically means programmers will have a much better time with the language than artists. If artists could do it all then we wouldn't need programmers. That will never happen.

#24 I like to think I have a pretty good handle on game production, technology, programming languages, etc...

Torque is a great choice for creating a game... this includes the (expanding) art pipeline... and TorqueScript...

In fact, a big part of working with Torque is TorqueScript... and I believe TorqueScript can work for artists... it's not the language or the syntax... it's the complexity of the underlying system that script must interface with... so, YOU should be writing game SPECIFICS for YOUR game... make these have a SIMPLE interface thru TORQUESCRIPT...

Any Python support for Torque, that doesn't use the TorqueScript interface to the C++ code, has a very long road ahead of it... I believe Python can be used with Torque... and actually did quite a bit of work with the two... this work always included SOME TorqueScript...

It's unfortunate that this is always such a controversial topic.

-Josh Ritter
Prairie Games

#25 Thanks Josh.

#26 @Josh: Yeah I totally agree. I think that right now TorqueScript has enough strengths that it's really a no brainer. TorqueScript is pretty darn good at what it does!

My thoughts about python in Torque are all about offering more options to the Torque community - about making a great system even better. I can see you've had the same thoughts given your work on PyTorque and TGEPython.

I don't think it needs to be such a big controversy either. For me it's a simple story of wanting to add more advantages to a great system.

@Jeff: I agree - I can't see that python would be any easier for artists than TorqueScript either. Besides, I don't want artists taking my job so as far as I'm concerned it's just as well that programming is hard :)

Thanks for your earlier comments. It helps to understand GG's position on these kinds of additions.

#27

Quote:
If artists could do it all then we wouldn't need programmers. That will never happen.

This is true, but it doesn't have to be. Before I go any further, lemme just say that I think Torque rocks.

The problem isn't entirely the script, its the way internal functions are exposed in script. As far as I can tell, scriptors are forced to deal with Quaternions... unless there is another method that I am unaware of. Yet, the engine code itself uses VectorF for rotations- so in that respect, dealing with the C++ is FAR easier than scripting a rotation.

In order to expose the basic functions a scriptor needs, a C++ coder is required on the team. This doesn't make it "easy" to make prototypes, and certainly not easy for an artist or scriptor to create a mockup in order to generate team-building interest. I see so many people here that have good ideas, but they can't necessarily execute them because they can't do C++.

The bare-minimum functions exposed to script need to include simple movement (move an object REGARDLESS what it is between point A and point B). Similar functions are needed to rotate that object, in Point3F degrees (not radians). Other functions should include a LookAt function similar to what the bot uses for aiming/looking, except make it available to any and all objects.

The internal workings of the engine seem to be more object oriented than the scripting. Within c++, I can use:

VectorF myAngles;
myAngles.x = 0;
myAngles.y = 30;
myAngles.z = 90;
setRotation(myAngles);

Maybe I am mistaken, but TorqueScript doesn't accept anything that intuitive. I am probably wrong though, and if I am, SOMEONE PLEASE CORRECT ME, because I don't want to be scripting things the hard way.

So I applaud any efforts to implement other scripting languages. I don't think that detracts from the power of Torque, I think that shows Torques versatile STRENGTH. Regardless which scripting language is plugged in, new and useful functions will have to be coded in C++ because Torque doesn't expose that basic functionality.

Quote:
What about the GUI editors, the terrain editor, the support for industry standard 3D editors, etc?

I *think* the tools have to be compiled don't they (except the map editor)? That requires a coder or at least someone competent enough to compile the tools. And the editors that are built into the engine... well the engine still needs to be compiled.

Anyway, this topic shouldn't be confrontational nor controversial. I'd hate for people to see it that way. And just because some people would prefer to use Python, or Java or whatever else, doesn't mean that they necessarily think TorqueScript is bad. But the way I see it, forcing us to use TorqueScript would be like forcing the game to be compiled On Windows, for Windows with no other options.

#28 You could just replace Torque Script with Python in your last post Randall, and it still would be true : you would need a C++ coder to expose functions to the script "layer", etc.
As for Python being intuitive ? It's syntax has a few idiosyncracies of its own, like any other programming language.
Non argument.
As for controversy : I think it has partly to do with the fact that you could embed TGE in Python, like what Joshua pulled off with PyTorque, and that the result wouldn't be publicly distributable because that would consist a breach of the TGE EULA.
It also has to do with how people go all fanatic about their languages, tools, platforms of choice :)
That said, use Python, Lua, Small, or even Java, if you feel like it, to script in TGE, although unless you're ready to spend a lot of hours working on your scripting solution, you'll end up with a mixed environment of TScript and whatever your choice is.
Just don't go saying Python (insert any other scripting language, including TScript ;)) is the ultimate panacea and that everyone should use it, 'cause you think it's the best : as long as there is programming involved, the average non programmer will have trouble with it, period.
The solution to that particular problem is to learn programming basics, not throw more languages at people (although I'm partial to Lua ;))

This is without getting into the inertia inherent to any project/community : tgePython was publically available for over a year, with some vocal proponents too (including yours truly, but not for the language : for the Blender users ;)), and certainly hasn't seen a widespread public adoption, although it had no problem with TGE's EULA, being embedded in TGE, unlike PyTorque.
What am I trying to say ? Well, trying to convince people that they should adopt what you think is better is a waste of valuable dev time :)
Especially when there is a perfectly workable solution already in place...

Keep on Torquin' !!!

#29 Not wanting to create any more "controversy" guys but wanting to correct a misconception... A couple of people now have said that the problem with python is that you need a C++ coder to access Torque functions. As I mentioned earlier my version of python doesn't require any special work for it to access Torque functions. It's totally integrated with Torque - you can call a Torque console function just as if it was a python function and you can access a Torque global just as it it was a python global. That's the whole point of doing this implemention really - otherwise I'd just use TGEPython myself. I wanted to create a version of python which had all of the advantages of TorqueScript. It's totally integrated. There's nothing you can do in TorqueScript that you can't do in my python implementation. Ok, got that off my chest now :)

#30

Quote:Well, trying to convince people that they should adopt what you think is better is a waste of valuable dev time :)

Halle-freakin-lujah!!!

I have wasted a lot of time and effort trying to convince people of things, great and small... The reality is that you can:

A) Get hung up all smeared in technological feces
B) Get on with a game

Fortunately, our situation has forced me to concentrate on option B

Go Indie!

-Josh Ritter
Prairie Games

#31 Zik... I think the issue at hand was that to expose more core engine , aka C++ code, to TorqueScript... or to Python would require the same work. Now if your python implementation is integrated more compleatly into the engine itself and can directly access and modify the core engine without having to have functions exposed to it.... where is your security? How do you prevent the client from being able to modify things they have no business touching?

#32 Harold, yeah that makes more sense. I hope to offer the same Torque integration features as TorqueScript has - except in python of course. I'm certainly not interested in opening up a security can of worms. Thanks for your comment.

#33 I'm partial to Lua myself. And that scripting language is used in hundreds of released titles, including Grim Fandango, Baldurs Gate, Escape from Monkey Island, Soul Ride, Impossible Creatures, Far Cry, Pain Killer, Fairly Odd Parents, and Minions of Mirth (Created by our local GG buddy, J. Ritter).

For any given Scripting language, I am sure others can come up with similar lists (Python is massively popular for nearly everything under the sun).

Now as far as needing a C++ coder- yes, one is needed regardless which scripting language is used. First of all, you need the coder to plug your fav script into the game. Second, Torque contains a lot of less than useful and un-intuitive functions... so the Coder is needed to create new and useful functions, not simply expose the existing ones.

I think Josh Ritter was on the right track with PyTorque. It makes much more sense to use Torque as library for its raw calculations (mesh, texture, etc) and networking capabilities, with most the game logic running from the scripting engine (expensive, process heavy functions would be sent to Torque to be resolved).

Furthermore, within that concept, nearly any scripting language could be used as long as it can make calls into Torque.

Torque right out of the box currently does not make the best use of Scripting. It seems to be mostly used for Gui input and configuration for entities (which are called Images in Torque, I think). A tiny bit of logic is seen in AIbots, but I think this could be taken much further to have an entire game scripted. I know its possible, I've done it before with other engines.

#34 (sorry for the bump -- was looking for the python/torque resources actually)

Lisp is not popular at all.

But learning Lisp took over a huge chunk of my time a year ago -- God, I ate it up. Then did nothing practical with it for a year.

I think that using Lisp with Torque would be a fine way to continue my "zero-productivity" mantra for Lisp hacking.

After all -- although some like Python, some like Ruby, some like C++, some like Java or .NET, and some like BF (heh), one thing we can all agree on is:

LISP, created in 1958, is still the most powerful and flexible language out there.

/me sidesteps the wall of flame, whistling "Seventy-Six Trombones".

#35 I had it and used it quite a while back but I lost the package somewhere in switching machines and now the links to download it no longer work. If someone does have it I would love to get it again

#36 Agreed, actually -- I had it as well, and in January I had 2 goddamned hard drives in a row go bad on me. (This is the ONLY time I've felt that RAID might be a good idea).

#37 Anyone have TGEPython available?