TGEPython and Self-contained Python App
by Richard Bottoms · in Torque Game Engine · 10/02/2004 (12:47 am) · 37 replies
I've solved my game's networking problem by adding TGEPython to my code. I can now connect to my backend server and do all sorts of neat stuff using JBoss on the backend.
I'd like to ship my game with Python self contained and not depend on the end user to install Python
Given this setup for demo purposes:
/sp_example1
torqueDemo.exe
python23.dll
/starter.quest
/tgepython
/tgetypes
__init__.py
What other files from Python besides python23.dll do I need to add to this tree so import statements like this:
import sys, urllib
will work?
Any Python heads out there?
Thanks,
r.b.
I'd like to ship my game with Python self contained and not depend on the end user to install Python
Given this setup for demo purposes:
/sp_example1
torqueDemo.exe
python23.dll
/starter.quest
/tgepython
/tgetypes
__init__.py
What other files from Python besides python23.dll do I need to add to this tree so import statements like this:
import sys, urllib
will work?
Any Python heads out there?
Thanks,
r.b.
#2
sys.path.append('path/to/my/modules/')
And I think that the sys module is one of the built-in ones.
As you can see in the /libs directory, the urllib itself imports
import string
import socket
import os
import time
and sys
So you need to track down the corresponding DLLs.
Another way to acchieve this would be to use the freeze utility:
check http://www.python.org/doc/faq/windows.html
This will collect the dependencies of libs and dlls for you.
10/02/2004 (2:24 am)
Or you can do this in your program via sys.path.append('path/to/my/modules/')
And I think that the sys module is one of the built-in ones.
As you can see in the /libs directory, the urllib itself imports
import string
import socket
import os
import time
and sys
So you need to track down the corresponding DLLs.
Another way to acchieve this would be to use the freeze utility:
check http://www.python.org/doc/faq/windows.html
This will collect the dependencies of libs and dlls for you.
#3
from distutils.core import setup
import py2exe
import glob
setup(name="test",
scripts=[".py"],
data_files=[]
)
So from your post, can I assume that TGEPython is working well for you? Did you mix it with normal TGE script or is it all python?
10/02/2004 (11:17 am)
Along the lines of 'freeze' is also 'py2exe'. After installing 'py2exe' you create a simple 'setup.py' file and then run 'python setup.py py2exe' and it will churn. When done it iwll leave an exe and all required dlls that it can detect in the same dir ready for packaging. A minimalistic setup.py would be"from distutils.core import setup
import py2exe
import glob
setup(name="test",
scripts=[".py"],
data_files=[]
)
So from your post, can I assume that TGEPython is working well for you? Did you mix it with normal TGE script or is it all python?
#4
from distutils.core import setup
import py2exe
import glob
setup(name="test",
scripts=["test.py"],
data_files=[]
)
10/02/2004 (11:18 am)
Er, that should be"from distutils.core import setup
import py2exe
import glob
setup(name="test",
scripts=["test.py"],
data_files=[]
)
#5
Many games that use Python embedded simply make a mini-distrib that rides along side the game files... I would recommend this method over py2exe...
-Josh Ritter
Prairie Games
10/02/2004 (12:01 pm)
Py2exe works well under Windows... I did have some funkiness with it and the wxPython 2.4 series... native controls wouldn't work so it fell back to the self drawn... I haven't tried it with wxPython 2.5Many games that use Python embedded simply make a mini-distrib that rides along side the game files... I would recommend this method over py2exe...
-Josh Ritter
Prairie Games
#6
Works for me. Anyone have directions on how to do that?
I want the end user to just install the game and go. I can write Python scripts, but I don't know much about how to install it or put support files in the proper place. I want to bypass TGE networking in favor of my own backend.
10/02/2004 (1:18 pm)
>Many games that use Python embedded simply make a mini-distrib that rides along side >the game files... I would recommend this method over py2exe... Works for me. Anyone have directions on how to do that?
I want the end user to just install the game and go. I can write Python scripts, but I don't know much about how to install it or put support files in the proper place. I want to bypass TGE networking in favor of my own backend.
#7
10/02/2004 (6:02 pm)
Bypass Torque networking? That ideas seems strange. Sure, add back end database stuff, but don't bypass the networking. Add your stuff on top. There is no better networking in the gaming world than what you have in Torque.
#8
In the world of Python networking, Twisted recently changed from the LGPL to the MIT license... For working on distributed applications and/or writing for web standards, it's totally kick ass... We use it extensively...
-Josh
10/03/2004 (7:16 am)
I can't imagine you mean to bypass Torque's networking entirely...In the world of Python networking, Twisted recently changed from the LGPL to the MIT license... For working on distributed applications and/or writing for web standards, it's totally kick ass... We use it extensively...
-Josh
#9
True. I am back working on game creation using TGE after 18 months of monitoring GG's progress. I think I three years this company will be huge with products the at challenge Unreal on the engine front and NXN's Alienbrain for game creation management.
Jeff adressed this well a few days ago, some programmers are reverse engineer types others are those who head to the book stores for 800 page references that unravel the technology they are trying to use. I am in the latter category.
Right now my need is to get a prototype for my vision up and running in time for the next GDC in 2005. I have plenty of phonebook sized references for Perl, J2EE, and Python. 'Networking with TGE' doesn't exist yet.
10/03/2004 (7:43 am)
>I can't imagine you mean to bypass Torque's networking entirely...True. I am back working on game creation using TGE after 18 months of monitoring GG's progress. I think I three years this company will be huge with products the at challenge Unreal on the engine front and NXN's Alienbrain for game creation management.
Jeff adressed this well a few days ago, some programmers are reverse engineer types others are those who head to the book stores for 800 page references that unravel the technology they are trying to use. I am in the latter category.
Right now my need is to get a prototype for my vision up and running in time for the next GDC in 2005. I have plenty of phonebook sized references for Perl, J2EE, and Python. 'Networking with TGE' doesn't exist yet.
#10
'3D Game Programming All in One' by Finney was worth every penny, and I'm a guy that prefers to dig through things rather than drop $40 on a book.
If you don't mind, how much of your game was scripted in Python? Did you mix implementation in Torque script and python? I'm almost at a point where I'd love to reuse some python code, but since I'm very new to Torque thought it would be best to stick with Torque script so there's no need to translate examples.
Python: The TGE of scripting languages.
10/03/2004 (8:33 am)
Richard,'3D Game Programming All in One' by Finney was worth every penny, and I'm a guy that prefers to dig through things rather than drop $40 on a book.
If you don't mind, how much of your game was scripted in Python? Did you mix implementation in Torque script and python? I'm almost at a point where I'd love to reuse some python code, but since I'm very new to Torque thought it would be best to stick with Torque script so there's no need to translate examples.
Python: The TGE of scripting languages.
#11
Although TNL has some feature changes over Torque networking, much of the extensive documentation on that site will help you out.
10/03/2004 (9:16 am)
Look at www.opentnl.orgAlthough TNL has some feature changes over Torque networking, much of the extensive documentation on that site will help you out.
#12
The client is mostly Torque script like most any TGE game. Calls to the back end are Python.
The back end itself is JBoss J2EE and Perl with MySQL as the database.
10/03/2004 (9:50 am)
>If you don't mind, how much of your game was scripted in Python?The client is mostly Torque script like most any TGE game. Calls to the back end are Python.
The back end itself is JBoss J2EE and Perl with MySQL as the database.
#13
10/03/2004 (10:16 am)
Thanks. Sounds like it is easy to mix TGEPython and Torque Script then. I like that very much.
#14
Beware that gSOAP uses std:: stuff, that collides with the TGE memory manager. Try to build it as a Windows CE client, as the code generated for that doesnt use std
10/03/2004 (10:28 am)
Richard - if you are using J2EE build using XDoclet, you should try to look at exposing your bean methods as JBoss.net methods - and then using gSOAP or Axis integrated into the TGE exe. Thats the approach I've been using and it works.Beware that gSOAP uses std:: stuff, that collides with the TGE memory manager. Try to build it as a Windows CE client, as the code generated for that doesnt use std
#15
TGEPython was written to extend and not replace TorqueScript... It was also written so that there are zero, that's ZERO, changes necessary to Torque's C++ code...
By changing some of the C++ sources for the TorqueScript interpreter, you can expose additional functionality to TGEPython... and/or, it's trivial to compile Torque as a standard python module (a dll on windows) and use swig to expose engine functionality...
I did some neat things like create a multi-view editor prototype with wxPython by doing just this...
-Josh Ritter
Prairie Games
10/03/2004 (10:56 am)
It's really a matter of what and how you want to use TGEPython for... TGEPython was written to extend and not replace TorqueScript... It was also written so that there are zero, that's ZERO, changes necessary to Torque's C++ code...
By changing some of the C++ sources for the TorqueScript interpreter, you can expose additional functionality to TGEPython... and/or, it's trivial to compile Torque as a standard python module (a dll on windows) and use swig to expose engine functionality...
I did some neat things like create a multi-view editor prototype with wxPython by doing just this...
-Josh Ritter
Prairie Games
#16
The backend doesn't run TGE at all at the moment.
Just JBoss/Apache/MySQL/Perl
10/03/2004 (12:12 pm)
>Beware that gSOAP uses std:: stuff, that collides with the TGE memory manager. The backend doesn't run TGE at all at the moment.
Just JBoss/Apache/MySQL/Perl
#17
/* BEGIN RANT //
I just want to say that, in my not-so-humble opinion, Python is a natural choice for game scripting, especially over writing and learning a custom scripting language.
I have had to agonize over the engine decision with my team because of lack of GG-supported python. We all work in an industry where Python is the de-facto language for artists, and hate to put time into learning something else. Especially since we can use it no-where else!
My hunch is that much more people would choose torque for their projects if it used a standard, robust, feature-rich language like Python.
Imagine if torque users could use all the python books out there instead of learning yet another language by digging through web pages. (Thanks to Ken for his nice book, though.) Now THAT would mean hitting the ground running! :) Lists, Dictionaries, etc. etc. etc.....
// END RANT */
Is anyone in the same boat? Are you using TGEPython? Looked into pyTorque?
Josh-
Did you finally decide that TGEpython or pyTorque was the better approach?
-Jason
10/16/2004 (11:39 pm)
Before I rant, I want to thank everyone at GG for their amazing work. Really. I'm amazed and humbled by the amount of work you guys have done./* BEGIN RANT //
I just want to say that, in my not-so-humble opinion, Python is a natural choice for game scripting, especially over writing and learning a custom scripting language.
I have had to agonize over the engine decision with my team because of lack of GG-supported python. We all work in an industry where Python is the de-facto language for artists, and hate to put time into learning something else. Especially since we can use it no-where else!
My hunch is that much more people would choose torque for their projects if it used a standard, robust, feature-rich language like Python.
Imagine if torque users could use all the python books out there instead of learning yet another language by digging through web pages. (Thanks to Ken for his nice book, though.) Now THAT would mean hitting the ground running! :) Lists, Dictionaries, etc. etc. etc.....
// END RANT */
Is anyone in the same boat? Are you using TGEPython? Looked into pyTorque?
Josh-
Did you finally decide that TGEpython or pyTorque was the better approach?
-Jason
#18
I agree that Python is an excellent choice for game scripting. So much so in fact that I'm writing my own implementation of Python which is designed specifically for use with Torque. This is a lightweight implementation of Python with some language extensions specifically aimed at supporting Torque features.
Why do this when TGEpython and pyTorque already exist? These systems just embed the original Python implementation into Torque. The result is in my opinion rather cumbersome. Aside from integration issues, it's very heavyweight.
When my version of Python is complete I'll be making it available to whoever's interested. It's also not encumbered with any licensing so it'll be possible to include it in the Torque distribution if Garage Games wants to.
10/18/2004 (3:17 am)
Hi Jason,I agree that Python is an excellent choice for game scripting. So much so in fact that I'm writing my own implementation of Python which is designed specifically for use with Torque. This is a lightweight implementation of Python with some language extensions specifically aimed at supporting Torque features.
Why do this when TGEpython and pyTorque already exist? These systems just embed the original Python implementation into Torque. The result is in my opinion rather cumbersome. Aside from integration issues, it's very heavyweight.
When my version of Python is complete I'll be making it available to whoever's interested. It's also not encumbered with any licensing so it'll be possible to include it in the Torque distribution if Garage Games wants to.
#19
As TGE moves forward, it will be easier and easier for users to make a choice of scripting languages. GG will not officially support those languages, but they will be available.
Meanwhile, we feel that it is important to have our own game oriented scripting language tightly coupled to our specific domain (for example, look for TS to be more network aware in the future). Many people like Python, and while I don't want to start a religious war, most programmers here at GG are not huge fans of the language.
-Jeff Tunnell GG
10/18/2004 (12:37 pm)
We would welcome a community backed implementation of Python that allows access to TGE as long as it respects our EULA. In fact, we are willing to help with SVN, publicity, and engineering support to the proper team. As to TorqueScript, it stays. If you know C++, TS is not hard to learn. It is important to the future of Torque. Who knows, maybe someday TS will be an open standard that we release to the public.As TGE moves forward, it will be easier and easier for users to make a choice of scripting languages. GG will not officially support those languages, but they will be available.
Meanwhile, we feel that it is important to have our own game oriented scripting language tightly coupled to our specific domain (for example, look for TS to be more network aware in the future). Many people like Python, and while I don't want to start a religious war, most programmers here at GG are not huge fans of the language.
-Jeff Tunnell GG
#20
My implementation of python allows TorqueScript to be mixed with python on a file by file basis. It's tightly integrated - torque functions can be transparently called from python and vice versa. Globals are shared, etc.. Basically the idea is to make no impact on people who want to keep using TorqueScript but allow people who like python to add python code wherever they want to without it being awkward.
One of the strengths of TorqueScript is its language support for game programming specific features - such as datablocks for instance. My version of python has language features very similar to these TorqueScript features so people familiar with TorqueScript will be able to use these exact same concepts in python.
It's perfectly understandable that GG wouldn't want to support a "foreign" language. It's a significant extra support load for a feature they themselves probably have little interest in. Still, I think it says a lot that this issue comes up pretty frequently. Let me just say that I'm a big fan of the Torque Engine, I think GG have done a great job and I think that TorqueScript is quite functional for its purpose. If it was down to me I'd probably just use TorqueScript.
Why then am I bothering to implement a whole new language in Torque? My game is a huge project so I need to attract a bunch of other people to code on it (I should get a commission from GG :). When I asked friends if they'd like to get involved in my game project quite a lot were interested. What I found was when they asked what language was involved I'd tell them about TorqueScript and then I just got a lot of blank looks and often a sudden decline in interest. I figured that if I wanted to maximise the hacker appeal of my game I had to make a mainstream language available for people to work in. Besides, I like implementing languages. It was a toss up between Java and Python. In the end I chose Python because I prefer the language design.
I don't think my story about people's reaction to a language they've never heard of before is an unusual one. I suspect that when people are looking at Torque's feature list with a view to buying it the lack of support for a mainstream scripting language is a significant drawback. This is all IMHO of course, but I believe this stuff strongly enough to devote a few months of my spare hours to making it a reality.
10/18/2004 (4:01 pm)
I totally agree that TorqueScript should stay. All other issues aside, there are so many great resources already written in TorqueScript that you'd be crazy to leave it behind.My implementation of python allows TorqueScript to be mixed with python on a file by file basis. It's tightly integrated - torque functions can be transparently called from python and vice versa. Globals are shared, etc.. Basically the idea is to make no impact on people who want to keep using TorqueScript but allow people who like python to add python code wherever they want to without it being awkward.
One of the strengths of TorqueScript is its language support for game programming specific features - such as datablocks for instance. My version of python has language features very similar to these TorqueScript features so people familiar with TorqueScript will be able to use these exact same concepts in python.
It's perfectly understandable that GG wouldn't want to support a "foreign" language. It's a significant extra support load for a feature they themselves probably have little interest in. Still, I think it says a lot that this issue comes up pretty frequently. Let me just say that I'm a big fan of the Torque Engine, I think GG have done a great job and I think that TorqueScript is quite functional for its purpose. If it was down to me I'd probably just use TorqueScript.
Why then am I bothering to implement a whole new language in Torque? My game is a huge project so I need to attract a bunch of other people to code on it (I should get a commission from GG :). When I asked friends if they'd like to get involved in my game project quite a lot were interested. What I found was when they asked what language was involved I'd tell them about TorqueScript and then I just got a lot of blank looks and often a sudden decline in interest. I figured that if I wanted to maximise the hacker appeal of my game I had to make a mainstream language available for people to work in. Besides, I like implementing languages. It was a toss up between Java and Python. In the end I chose Python because I prefer the language design.
I don't think my story about people's reaction to a language they've never heard of before is an unusual one. I suspect that when people are looking at Torque's feature list with a view to buying it the lack of support for a mainstream scripting language is a significant drawback. This is all IMHO of course, but I believe this stuff strongly enough to devote a few months of my spare hours to making it a reality.
Associate James Urquhart
I recall that some modules are built into the python dll; Others you will have to add on a directory in your PYTHONPATH (an environment variable).
I think you can set up the PYTHONPATH within the python api (e.g. in Blender, scripts in the scripts directory can be imported with "import"), though i am uncertain.
I would suggest making another directory, e.g. "modules" - and put your extra modules there.