Plan for Jay Barnson
by Jay Barnson · 03/30/2005 (7:52 pm) · 14 comments
Python Rawks
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?
Python vs. TorqueScript... this could be interesting
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?
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?
Python vs. TorqueScript... this could be interesting
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?
About the author
Jay has been a mainstream and indie game developer for a... uh, long time. His professional start came in 1994 developing titles for the then-unknown and upcoming Sony Playstation. He runs Rampant Games and blogs at Tales of the Rampant Coyote.
#2
Just for grins --- here's my little 2D Python / SDL project after just shy of 30 hours:
I doubt it's gonna look a whole lot better when I hit 40 hours, but it's amazing how quickly some things have been coming along.
03/31/2005 (12:23 am)
I haven't mucked with LUA much, but I have to agree about Python. It's becoming too well used for general-purpose applications now to be considered a scripting language.Just for grins --- here's my little 2D Python / SDL project after just shy of 30 hours:
I doubt it's gonna look a whole lot better when I hit 40 hours, but it's amazing how quickly some things have been coming along. 
#3
03/31/2005 (12:27 am)
Did you have to use free tools for this?
#4
03/31/2005 (2:15 am)
I just hate the syntax.. the rest doesnt really matter.
#5
Yeah, that was part of the challenge. So it's all free-license stuff. I'm not even using any of my own homemade tools, since the challenge was to start completely from scratch. My main tool is GiMP, plus some free-for-commercial-use textures off the Internet. If I actually had some reasonable artistic ability, I could overcome that --- GiMP is a pretty good tool.
If I had more time (and skill), I'd do more with Blender --- building models and then using a high-quality render for the texture.
I'm going to end up using Lego-creatures and photographing them with a digital camera for content if I'm not careful.
@Phil:
I mostly just hate the indentation rules (though I guess it forces readable style). But I'm also not fond of the use of the "%" symbol for local variables in TorqueScript... enh. You get used to anything after you use it for a while. One day I'll quit forgetting to add the "%" in TS.
@Josh:
cBanana.pyd? Do we even WANT to know?
Just out of curiosity, what's Genesis.exe?
03/31/2005 (7:01 am)
@Jeremy: Yeah, that was part of the challenge. So it's all free-license stuff. I'm not even using any of my own homemade tools, since the challenge was to start completely from scratch. My main tool is GiMP, plus some free-for-commercial-use textures off the Internet. If I actually had some reasonable artistic ability, I could overcome that --- GiMP is a pretty good tool.
If I had more time (and skill), I'd do more with Blender --- building models and then using a high-quality render for the texture.
I'm going to end up using Lego-creatures and photographing them with a digital camera for content if I'm not careful.
@Phil:
I mostly just hate the indentation rules (though I guess it forces readable style). But I'm also not fond of the use of the "%" symbol for local variables in TorqueScript... enh. You get used to anything after you use it for a while. One day I'll quit forgetting to add the "%" in TS.
@Josh:
cBanana.pyd? Do we even WANT to know?
Just out of curiosity, what's Genesis.exe?
#6
/imm recompile
This recompiles the database (in less than 3 seconds, good and fast), and attaches the new data to your live monsters, items, spells, quests, etc. So, if you are play testing and fighting a monster that's too easy... you can give him a couple levels, a special attack, add some to his "Presence" stat without leaving the game. This is mucho important for writing quests with actions and requirements. You can add and TEST them on the fly. Muahahaha :)
On the indentation:
One of my FAVORITE aspects is the indentation. After 18 months with Python you still don't like this? Some people just can't be saved ;)
-Josh
03/31/2005 (7:07 am)
cBanana is a C extension for Twisted... Genesis.exe is the database compiler, for mod-makers. You can also regenerate the database, while playing the game, by executing the Immortal command:/imm recompile
This recompiles the database (in less than 3 seconds, good and fast), and attaches the new data to your live monsters, items, spells, quests, etc. So, if you are play testing and fighting a monster that's too easy... you can give him a couple levels, a special attack, add some to his "Presence" stat without leaving the game. This is mucho important for writing quests with actions and requirements. You can add and TEST them on the fly. Muahahaha :)
On the indentation:
One of my FAVORITE aspects is the indentation. After 18 months with Python you still don't like this? Some people just can't be saved ;)
-Josh
#7
03/31/2005 (7:09 am)
SLICK!
#8
There have been a couple times where I exclaimed, "Oh shit! Python's going to be too slow!!! Oh no!!!" ... in one instance, I wrote a single C extension function that saved the day. In the other, I modified the logic as it was doing a bunch of unneccesary processing. In both instances, by using the profiler module, I was able to quickly pinpoint the bottlenecks.
... and yes, Python's container classes (especially the associative array dictionaries), generator "coroutines", inheritance, libraries with standard installation packages, etc all come in handy! Of course it's not the only language and not every project NEEDS Python... that would be zealotry.
-Josh
03/31/2005 (7:18 am)
Torque is a major (and important) component of our game. There are other components. One of Python's strengths is in gluing components together. There is no way we could be where we are at with the game using only C++. The debugging cycle(s) alone would kill us. There have been a couple times where I exclaimed, "Oh shit! Python's going to be too slow!!! Oh no!!!" ... in one instance, I wrote a single C extension function that saved the day. In the other, I modified the logic as it was doing a bunch of unneccesary processing. In both instances, by using the profiler module, I was able to quickly pinpoint the bottlenecks.
... and yes, Python's container classes (especially the associative array dictionaries), generator "coroutines", inheritance, libraries with standard installation packages, etc all come in handy! Of course it's not the only language and not every project NEEDS Python... that would be zealotry.
-Josh
#9
Re: Scripting languages ...
Python seems ok if you're using it in place of something like C++. However, when you start looking at scripting languages to extend an existing app (e.g. torque), it's really not suited for it. The preferred way to extend python is to write an extension module for python, not embed it in another app. There's a few reasons for that that I forget now, but there's a blow by blow comparison on both methods on the python site somewhere. As far as Python's syntax goes, the only reason for the indentation thing is it's the author's preferred style of indenting, and he wanted to force everyone else to use it with Python by making it part of the syntax.
Lua, on the other hand, was designed exclusively for embedding in other apps, and as such doesnt have as big a library of useful stuff. In fact, out of the box, it only supports things the standard C library supports. However, Lua is a very very fast and powerful language that is easily extended to do pretty much whatever you want with minimum of effort. Although it may not support the more complex structures that other languages do, they are easy to implement with Lua's tables. It's lack of library can be a bit of a problem if you wanted to use it in place of C++, but when extending an existing codebase you'd already have most of that code and it would "just" be a matter of exposing it to Lua.
TorqueScript was designed to let you do what you need to do for Torque to do its stuff. It's really good at what it does, at the expense of perhaps being less useful for general programming. Yeh, it doesnt have all the complex types that python does, and its not as flexible as Lua, but it doesnt need to be. It gets the job done quickly and well, and that's all that matters.
I guess my point is that it doesnt matter what you use, as long as it's the right tool for the job.
T.
03/31/2005 (8:44 am)
Jay, great work on the GIW :)Re: Scripting languages ...
Python seems ok if you're using it in place of something like C++. However, when you start looking at scripting languages to extend an existing app (e.g. torque), it's really not suited for it. The preferred way to extend python is to write an extension module for python, not embed it in another app. There's a few reasons for that that I forget now, but there's a blow by blow comparison on both methods on the python site somewhere. As far as Python's syntax goes, the only reason for the indentation thing is it's the author's preferred style of indenting, and he wanted to force everyone else to use it with Python by making it part of the syntax.
Lua, on the other hand, was designed exclusively for embedding in other apps, and as such doesnt have as big a library of useful stuff. In fact, out of the box, it only supports things the standard C library supports. However, Lua is a very very fast and powerful language that is easily extended to do pretty much whatever you want with minimum of effort. Although it may not support the more complex structures that other languages do, they are easy to implement with Lua's tables. It's lack of library can be a bit of a problem if you wanted to use it in place of C++, but when extending an existing codebase you'd already have most of that code and it would "just" be a matter of exposing it to Lua.
TorqueScript was designed to let you do what you need to do for Torque to do its stuff. It's really good at what it does, at the expense of perhaps being less useful for general programming. Yeh, it doesnt have all the complex types that python does, and its not as flexible as Lua, but it doesnt need to be. It gets the job done quickly and well, and that's all that matters.
I guess my point is that it doesnt matter what you use, as long as it's the right tool for the job.
T.
#10
I am from the extension school, although up until a few weeks ago I was using Python embedded in Torque. When it came to getting the thing mobile, with Py2Exe, quickly throwing together the pytorque extension module made the most sense. Again, this is just switching to a dynamic libary compile with exposed init, tick, and shutdown functions. Nothing crazy.
Lua is a great choice for an embedded language... and if you don't need all the whiz-bang, probably a better choice than Python as an extension language. I'm more interested in an application language.
TorqueScript as a small configuration/logic language is great and I am glad it exists. We use the console system extensively and have many hooks into the TorqueScript interpreter.
-Josh
03/31/2005 (9:21 am)
Extending Vs. Embedding PythonI am from the extension school, although up until a few weeks ago I was using Python embedded in Torque. When it came to getting the thing mobile, with Py2Exe, quickly throwing together the pytorque extension module made the most sense. Again, this is just switching to a dynamic libary compile with exposed init, tick, and shutdown functions. Nothing crazy.
Lua is a great choice for an embedded language... and if you don't need all the whiz-bang, probably a better choice than Python as an extension language. I'm more interested in an application language.
TorqueScript as a small configuration/logic language is great and I am glad it exists. We use the console system extensively and have many hooks into the TorqueScript interpreter.
-Josh
#11
But yeah, having high-level functionality already written for you is nice. But isnt that kind of what middleware is all about? :)
Lua has also got some of the higher level stuff that you CAN use with it. But its tiny footprint was a BIG plus on the PS2 etc.
Wonder if python's footprint would be acceptable in a PS2 scenario?
03/31/2005 (3:11 pm)
I still dont like pythons indentation.. that puts me off it from the get-go.But yeah, having high-level functionality already written for you is nice. But isnt that kind of what middleware is all about? :)
Lua has also got some of the higher level stuff that you CAN use with it. But its tiny footprint was a BIG plus on the PS2 etc.
Wonder if python's footprint would be acceptable in a PS2 scenario?
#12
03/31/2005 (9:21 pm)
I think Python's footprint is around 4 - 5 megs unzipped, last time I checked. But it's been a while... I could be wrong.
#13
04/01/2005 (9:20 pm)
Phil, take a look at http://www.asbahr.com/python.html .... has a downloadable version of python for the PS2 ... it's 2.1, so rather old, but shows you that it can be done. 
#14
04/28/2005 (5:20 pm)
You could also try stackless python, www.stackless.com 
Torque Owner Prairie Games
Prairie Games, Inc.
Minions of Mirth has over 1.2 megs of Python sources. If you aren't familiar with Python, that's a whole lot of Python source. I've written less than 2k of TorqueScript sources.
The entire GUI is Python driven (Python -> C++ via TGEPython), the persistent world and RDBMS use Python, the networking using the Twisted Framework, etc. Python is absolutely vital to our development, in fact I even compile Torque as a standard Python module (don't worry anyone, it's really just compiling Torque as a dynamic library with a few exposes functions for startup, ticking, and shutdown). We use Python distribution/packaging to create the binary version. Python, Python, Python.
I really don't care if anyone else uses Python. I do, it kicks ass, and I am quite happy.... and a great thing about Torque is it's excellent console system. You could just as easily insert Lua or other strong programming language. Lua and Python especially have transcended being "scripting" languages.
-Josh
PS: Here's a funky looking Torque engine game if ever I saw one :)