Wednesday, March 30, 2005
Python vs TorqueScript - Cage Match Anyone?
the Game-In-A-Week project continues. And I'm getting nervous, because I'm nearing the 30-hour mark and the gameplay isn't in there yet. But I'm still trucking along, documenting as I go.
One thing I've realized during this project is HOW MUCH PYTHON RULES. Last night I was doing some very tricky, ugly code on this game (all in Python), and I thought, "Man, this is almost taking as much time as it would take for me to do it in C++." Then I realized that this surprised me BECAUSE I'd been going along so incredibly quickly up until this point - 2x to 4x the speed of development in C++. And I've only got about 18 months of Python experience, as opposed to about 15 years in C / C++.
I've been making an assumption that Python might not be appropriate for a larger project. Out at Symantec we did have a pretty large testing framework built on Python. I heard that Eve Online was done largely in Python. And I saw that Josh Ritter was able to port his whole game "Minions of Mirth" from a custom, Quake-2 based engine over to Torque in just a few weeks due to the fact that most of the game is written in Python. So maybe my assumption is incorrect?
I've got a major project in mind for development in Torque in the near future (I've got a smaller Torque project currently under construction that's temporarily on the shelf while I work on "Hackenslash!"). I've been a little intimidated by the scope of the thing. Now that I've seen the power of Python, I've started considering how much easier it would be if I wrote the core game in Python, binding it to Torque via TGEPython or something a little more direct.
I'm trying to look at the pros and cons of Python vs TorqueScript. At the core, the two languages offer a lot of very similar, time-saving features for development - they are both object-oriented, with typeless variables and no real need to worry about memory management. TorqueScript is built into Torque, which means you get some obvious improvements in run-time optimization and the fact that you don't need to create some kind of Python distro to go with your game. I've got a greater familiarity with Python, but my comfort level with TorqueScript is going up steadily too. Python has a greater range of support via libraries and community code. It's definitely a richer language, but that doesn't matter if you aren't using all those extra features. One of the big things I'm really taking advantage of right now is Python's support of dictionaries, lists, and other sequence types --- I haven't explored whether or not TorqueScript supports similar functionality (or if it can be emulated / constructed pretty easily).
Anybody with experience in both care to chime in?
Labels: programming
- posted by The Rampant Coyote @ 7:01 PM (Permalink)
Comments:
Links to this post:
<< Home
I'll add my voice to the choir: Python is fantastic both for rapid prototyping and for large projects.
The first time I used the language in a real-world project was for an electronic journal for the ACM. We had to parse and manipulate generous heaps of data and spit out a polished product to be shipped on CD. Python was brilliant. I've since used it for a Windows port of one of our Palm OS games. It was a joy to write.
I'd kill for a feature-complete 3D engine with solid Py bindings. Can one be had for love or money?
The first time I used the language in a real-world project was for an electronic journal for the ACM. We had to parse and manipulate generous heaps of data and spit out a polished product to be shipped on CD. Python was brilliant. I've since used it for a Windows port of one of our Palm OS games. It was a joy to write.
I'd kill for a feature-complete 3D engine with solid Py bindings. Can one be had for love or money?
# posted by 
: March 31, 2005 12:32 AM
: March 31, 2005 12:32 AM
He just mentioned one, Torque with the TGEPy bindings I guess. I've never heard of the bindings, but I suppose they must be good or Coyote wouldn't recommend them.
That much said, I too love Python, but I'm going to go with Lua I think for a couple of reasons.
1) Lua is much, much smaller in runtime requirements.
2) Lua is at least as fast as Python, if not faster.
3) Lua has full garbage collection, whereas Python uses reference counting. True, it doesn't make much difference until you have cyclic references, and how often does that happen? I just don't want to be the one having to track that kind of bug down.
4) Lua has as good C++ bindings as Python
5) Lua has coroutines, which means that microthreads, useful for AI, are easy. Python doesn't have anything like this, though Stackless Python has microthreads, but it's not directly interfaceable to C++ as CPython is.
6) Lua has the same high level constructs that Python does, that is lists, vectors, and dictionaries.
There, that's my blurb. Python certainly isn't the wrong way to go, but I think Lua offers more to a game developer. That's my $0.02.
That much said, I too love Python, but I'm going to go with Lua I think for a couple of reasons.
1) Lua is much, much smaller in runtime requirements.
2) Lua is at least as fast as Python, if not faster.
3) Lua has full garbage collection, whereas Python uses reference counting. True, it doesn't make much difference until you have cyclic references, and how often does that happen? I just don't want to be the one having to track that kind of bug down.
4) Lua has as good C++ bindings as Python
5) Lua has coroutines, which means that microthreads, useful for AI, are easy. Python doesn't have anything like this, though Stackless Python has microthreads, but it's not directly interfaceable to C++ as CPython is.
6) Lua has the same high level constructs that Python does, that is lists, vectors, and dictionaries.
There, that's my blurb. Python certainly isn't the wrong way to go, but I think Lua offers more to a game developer. That's my $0.02.
Well, I haven't tried TGEPython, so I don't know how "solid" those bindings are. But Prairie Games is using it (plus a bit of customization) as the interface into Torque, which I'm very interested in.
Also, I *think* there are Python bindings for Irrlicht... maybe Ogre3D by now, too.
And if not - Python is actually pretty dang easy to integrate into C++ code, so it's not too hard to create your own bindings. Python was used with the Half-Life 2 engine for Vampire the Masquerade: Bloodlines, which was released last Christmas. The "Freedom Force" games are also largely Python-driven.
Also, I *think* there are Python bindings for Irrlicht... maybe Ogre3D by now, too.
And if not - Python is actually pretty dang easy to integrate into C++ code, so it's not too hard to create your own bindings. Python was used with the Half-Life 2 engine for Vampire the Masquerade: Bloodlines, which was released last Christmas. The "Freedom Force" games are also largely Python-driven.
I experimented with LUA briefly when it was still a pretty new thing. I'm sure it's more mature now.
Dictionaries and Lists are a big deal with the code I'm currently working on - two things that seem to be missing from TorqueScript. It's been amazing how easy it is to associate objects with each other so easily - I've got items and monsters being responsible for creating pop-up menus for the player, and the menus easily calling their objects with commands back to them. Yes, it's all stuff that can be done in C++ (or C for that matter), but it's been so trivial to implement.
Dictionaries and Lists are a big deal with the code I'm currently working on - two things that seem to be missing from TorqueScript. It's been amazing how easy it is to associate objects with each other so easily - I've got items and monsters being responsible for creating pop-up menus for the player, and the menus easily calling their objects with commands back to them. Yes, it's all stuff that can be done in C++ (or C for that matter), but it's been so trivial to implement.
He just mentioned one, Torque with the TGEPy bindings I guess.
You're right! I didn't parse TGEPython as being a Torque Python binding.
You're right! I didn't parse TGEPython as being a Torque Python binding.
# posted by : April 01, 2005 9:41 PM
: April 01, 2005 9:41 PM
I know I'm about one year late, but I'd like to correct what Bilbo says : Python does have a garbage collector. In fact, it mixes garbage collection with reference counting, getting the best of both worlds.
Non-container types are reference counted, therefore being predictively collected, without risking cyclic references (because they are non-container types).
Container types are garbage collected. See http://www.python.org/doc/lib/module-gc.html
Post a Comment
Non-container types are reference counted, therefore being predictively collected, without risking cyclic references (because they are non-container types).
Container types are garbage collected. See http://www.python.org/doc/lib/module-gc.html
Links to this post:
<< Home
