What have been your biggest challenges so far?
by Matthew Langley · in Torque Game Builder · 04/14/2005 (10:52 am) · 117 replies
NOTE: This is meant to be a Indie Game Developer support type thread... vent your time limitations, tough day job, that darn code algorithm that comes out funky, etc etc... Not a T2D/GG bashing thread... just a forewarning that if you don't have something either to discuss friendly and supportive, or constructively, then just don't post it.
Well since the forums have been awkwardly quiet this morning figured I'd throw up a discussion thread asking the question
What have been your biggest challenges so far?
*dramatic pause*
(EDIT: for those that are having problems starting with T2D and torquescript, make sure you check through all of the documentation listed in the Documentation Overview.html)
lol ok, so just out of curiosity what have been everyones challenges... note this can be anything from working with T2D, learning T2D, working with the editors... trying to get a game concept written out, game design, documentation... debugging... etc etc... not specific on T2D but your whole game development process...
for me it has been getting started on some of the major systems... I finally did a good high level list of what I need to develop and actually getting started on a brand new system is overwhelming at first...
like inventory, AI, Pathfinding, Classes, Levels, Quests, etc etc etc...
it goes on... so its hard to keep focuses on one step at a time...
As a team its been hard trying to coordinate our work to ensure the best progress... as well as motivation... at this point the motivation burns out easily when we all go home and really need to clamp down and work...
Well since the forums have been awkwardly quiet this morning figured I'd throw up a discussion thread asking the question
What have been your biggest challenges so far?
*dramatic pause*
(EDIT: for those that are having problems starting with T2D and torquescript, make sure you check through all of the documentation listed in the Documentation Overview.html)
lol ok, so just out of curiosity what have been everyones challenges... note this can be anything from working with T2D, learning T2D, working with the editors... trying to get a game concept written out, game design, documentation... debugging... etc etc... not specific on T2D but your whole game development process...
for me it has been getting started on some of the major systems... I finally did a good high level list of what I need to develop and actually getting started on a brand new system is overwhelming at first...
like inventory, AI, Pathfinding, Classes, Levels, Quests, etc etc etc...
it goes on... so its hard to keep focuses on one step at a time...
As a team its been hard trying to coordinate our work to ensure the best progress... as well as motivation... at this point the motivation burns out easily when we all go home and really need to clamp down and work...
About the author
I Manage Tool Development for Torque at InstantAction
#82
Since the Python binding isn't mature enough for production code, I'm forced to use TorqueScript. It doesn't scale well. Brian, your resource goes a long way to helping, but TorqueScript just isn't meant for complex code. It's meant for simple, localized code inside events.
Jeremy & Tomas: hurry up and save me!! ;)
05/03/2005 (9:07 pm)
My biggest stumbling block is TorqueScript itself.Since the Python binding isn't mature enough for production code, I'm forced to use TorqueScript. It doesn't scale well. Brian, your resource goes a long way to helping, but TorqueScript just isn't meant for complex code. It's meant for simple, localized code inside events.
Jeremy & Tomas: hurry up and save me!! ;)
#83
I have written 13,000 lines of code in Torque script using my OO techniques, and it's still extremely organized and easily navigable (though without all those nice 'go to definition / reference' and 'class wizard' IDE features). I could see my script code base expanding to 100,000 lines of code without much of a problem. The one thing I DO need is the ability to trace my script code, though there are already some okay resources to do that and I hear that there are some even better script tracing solutions coming down the line ;)
Of course, you have to constantly make sure your code is logically and consistantly organized. The OO stuff goes a LONG way to helping this, but it won't do it all for you. More importantly, you have to be sure you're using the OO features properly and logically, which can be an massively immense challenge in itself (think years of practice).
For example, some of the things you must absolutely avoid is using globals that aren't absolutely necessary (or built into the engine or common code). Also, you should NEVER give names to your objects to access them globally like so -
SomeClass::create(Player);
Player.swingSword();
Globalizing objects like this, while a feature, is a sure way to turn your finely organized OO code into a big ball of mud.
Instead, you should store the reference returned from the create function in a local variable or another object's member.
This is true with GUIs as well. Unfortunately, the GUI editor relies on this global naming technique. But there are ways around it. For example, say you used the GUI editor to make a GUI object named PlayerWindow. Create and reference the objecct like this -
exec("./playerWindow.gui"); // this will create the object named PlayerWindow
%playerGui = PlayerWindow;
PlayerWindow.setName(""); // this will make the created object globally inaccessible
and when you're done with the object, delete it like so -
%playerGui.delete();
In other words, where Torque tries to make you use globals, fight it. It is a fight that I always win with relative ease (though it can take a bit of trickery). And also use good OO techniques - program to an interface, not an implementation. Encapsulate everything you can. Prefer containment over inheritance. Know your design patterns without overusing them. Refactor, refactor, refactor!
I really feel that with the OO extensions that Torque Script is a full, totally robust and wonderful language. Of course, that's just me - I might be biased for more reasons than one :)
05/04/2005 (2:17 pm)
Heh, Jason, I have to partially disagree :)I have written 13,000 lines of code in Torque script using my OO techniques, and it's still extremely organized and easily navigable (though without all those nice 'go to definition / reference' and 'class wizard' IDE features). I could see my script code base expanding to 100,000 lines of code without much of a problem. The one thing I DO need is the ability to trace my script code, though there are already some okay resources to do that and I hear that there are some even better script tracing solutions coming down the line ;)
Of course, you have to constantly make sure your code is logically and consistantly organized. The OO stuff goes a LONG way to helping this, but it won't do it all for you. More importantly, you have to be sure you're using the OO features properly and logically, which can be an massively immense challenge in itself (think years of practice).
For example, some of the things you must absolutely avoid is using globals that aren't absolutely necessary (or built into the engine or common code). Also, you should NEVER give names to your objects to access them globally like so -
SomeClass::create(Player);
Player.swingSword();
Globalizing objects like this, while a feature, is a sure way to turn your finely organized OO code into a big ball of mud.
Instead, you should store the reference returned from the create function in a local variable or another object's member.
This is true with GUIs as well. Unfortunately, the GUI editor relies on this global naming technique. But there are ways around it. For example, say you used the GUI editor to make a GUI object named PlayerWindow. Create and reference the objecct like this -
exec("./playerWindow.gui"); // this will create the object named PlayerWindow
%playerGui = PlayerWindow;
PlayerWindow.setName(""); // this will make the created object globally inaccessible
and when you're done with the object, delete it like so -
%playerGui.delete();
In other words, where Torque tries to make you use globals, fight it. It is a fight that I always win with relative ease (though it can take a bit of trickery). And also use good OO techniques - program to an interface, not an implementation. Encapsulate everything you can. Prefer containment over inheritance. Know your design patterns without overusing them. Refactor, refactor, refactor!
I really feel that with the OO extensions that Torque Script is a full, totally robust and wonderful language. Of course, that's just me - I might be biased for more reasons than one :)
#84
I guess I was spoiled when I found Python. :) I much prefer it to TorqueScript or C++.
05/04/2005 (5:24 pm)
Quote:Globalizing objects like this, while a feature, is a sure way to turn your finely organized OO code into a big ball of mud.I'm no stranger to OOP, as I've got 8+ years experience with C++ and more with programming in general. I wrap my objects in ScriptObjects to encapsulate and modularize things. My game is even totally plugin driven. I can drop in new objects or remove them from a directory, and it's all detected at runtime. None of the objects are hard-coded into the logic. But I still find it unwieldy and unpleasant to program with TorqueScript, not to mention I don't like the C-style syntax or the prefixed variable names etc etc.
Instead, you should store the reference returned from the create function in a local variable or another object's member.
I guess I was spoiled when I found Python. :) I much prefer it to TorqueScript or C++.
#85
As an example I have reference objects that are named and used that way globally. Their data members never change and, hey, from what I can tell they should be datablocks, but I just couldn't get that to work. And it forced me into a (to me) clumsy declaration: I have all objects of that class declared in columnar format so it is easy to read and compare.
All objects are also tracked in global vectors to allow iteration over them, but I find it handier to pass "heavy missile" as a parameter than keep track of what index value in the global vector a heavy missile is. Makes my code easier to write and debug.
Right now my biggest challenge is getting time. Last night, for example, was spending time with the family. I'm not looking for sympathy, however, as in this case family time meant playing Champions of Norrath with my wife -- which she is already pressing to do again tonight ;^)
@Jason: Python is okay, but I prefer C, C++ and Perl. It does force writing cleaner code than Perl which is specifically why one of my co-workers hates it (something about languages that put meaning into white space ;^)
05/04/2005 (5:27 pm)
@Bryan: Hmm... I (somewhat) disagree with you on the global naming. Of course, maybe I'm not using pure OO design ;^)As an example I have reference objects that are named and used that way globally. Their data members never change and, hey, from what I can tell they should be datablocks, but I just couldn't get that to work. And it forced me into a (to me) clumsy declaration: I have all objects of that class declared in columnar format so it is easy to read and compare.
All objects are also tracked in global vectors to allow iteration over them, but I find it handier to pass "heavy missile" as a parameter than keep track of what index value in the global vector a heavy missile is. Makes my code easier to write and debug.
Right now my biggest challenge is getting time. Last night, for example, was spending time with the family. I'm not looking for sympathy, however, as in this case family time meant playing Champions of Norrath with my wife -- which she is already pressing to do again tonight ;^)
@Jason: Python is okay, but I prefer C, C++ and Perl. It does force writing cleaner code than Perl which is specifically why one of my co-workers hates it (something about languages that put meaning into white space ;^)
#86
WhiteSpace
Hehehe!
05/04/2005 (5:40 pm)
Quote:something about languages that put meaning into white space ;^)
WhiteSpace
Hehehe!
#88
Well, there's lots of ways to access objects easily without significant program redesign or making them global. For example, say you wanted to keep a reference to all the PlayerObjects you created in the game to iterate over them for some reason. You could build a PlayerObjectRef singleton and have the PlayerObject class add each created PlayerObject to that singleton's PlayerObject set. Since the PlayerObjectRef is a singleton, it, as well as its contents, are globally accessible without resorting to globals.
Theres also public static members that classes can contain. In concept, they are not strictly global, but in implementation in Torque script they are. For example -
$PlayerObject::count could be considered a public static PlayerObject member. It could, say, keep track of the number of all PlayerObjects created. Of course, since it's public it can be changed legally by some other object, so you'd really want to privatize it and make an accessor static method like this -
$PlayerObject::_count = 0;
// number
function PlayerObject::getCount()
{ return $PlayerObject::_count;}
So, as you can see, I would recommend using using globals technically, but not conceptually.
There's also the concept of namespaces that I consider valid. This is a smattering of data in a namespace which doesn't implement any class functionality. Consider this -
// namespace FredBob
$FredBob::color[0] = "red";
$FredBob::color[1] = "blue";
$FredBob::color[2] = "green";
// end namespace FredBob
This is perfectly valid, and in my opinion, does not conceptually equate to a global.
When it comes to doing stuff like this -
Player.swingSword();
or
$Player.jump();
I just can't see why you would want do it that way other than (IMO) arbitrary expidiancy. These are the things that always hurt me in the long run - it wasn't until my entire program was one unmanagable ball of mud till I realized the harm in using globals out of line with recommended OO design.
But on the other hand, if you only do it once in a great while when you run into a nigh unsolvable design problem, the harm is minimized - especially when you're programming from a high level like in script most T2D games.
So what's the point of this? Simple code organization. In other words, avoiding code that cannot easily be followed. Bad designs often lead to worse designs down the road - compounding your design problems indefinitely. Sooner or later, one can end up with most objects knowing about most other object just by letting just a handful of design problems get out of hand. This is the point where your program becomes the big ball of mud - this is where your program's growth simple hits a brick wall (rather painfully too).
Another thing I do, since I always program to an interface (albeit often with a default implementation), I code as though Torque Script was a typesafe language.
For example, if I am receiving an object from a parameter that uses comments to specify the parameter type (I always specify parameter types with comments when I cannot use the variable name to imply the type), I never access any methods / members not specified in the class's interface (the pseudo-class declaration). If I need to see if the object in question is of a type lower than the one specified by the parameter's comment (or name), then I use a custom 'cast' function that comes with the next version of OOInT2DScript. But even using this function is not recommended except where T2D loses type info (like in the onCollision parameter, etc...). Proper OO design almost always allows the type to be known and expected. This is yet another major boon to program organization - but completely optional in Torque script.
continued...
05/04/2005 (9:32 pm)
@Jason - I didn't mean to imply that you were not knowing of OO concepts, I'm just kinda prattling off to all the newbie OO programmers who happen to be lurking out there ;)Well, there's lots of ways to access objects easily without significant program redesign or making them global. For example, say you wanted to keep a reference to all the PlayerObjects you created in the game to iterate over them for some reason. You could build a PlayerObjectRef singleton and have the PlayerObject class add each created PlayerObject to that singleton's PlayerObject set. Since the PlayerObjectRef is a singleton, it, as well as its contents, are globally accessible without resorting to globals.
Theres also public static members that classes can contain. In concept, they are not strictly global, but in implementation in Torque script they are. For example -
$PlayerObject::count could be considered a public static PlayerObject member. It could, say, keep track of the number of all PlayerObjects created. Of course, since it's public it can be changed legally by some other object, so you'd really want to privatize it and make an accessor static method like this -
$PlayerObject::_count = 0;
// number
function PlayerObject::getCount()
{ return $PlayerObject::_count;}
So, as you can see, I would recommend using using globals technically, but not conceptually.
There's also the concept of namespaces that I consider valid. This is a smattering of data in a namespace which doesn't implement any class functionality. Consider this -
// namespace FredBob
$FredBob::color[0] = "red";
$FredBob::color[1] = "blue";
$FredBob::color[2] = "green";
// end namespace FredBob
This is perfectly valid, and in my opinion, does not conceptually equate to a global.
When it comes to doing stuff like this -
Player.swingSword();
or
$Player.jump();
I just can't see why you would want do it that way other than (IMO) arbitrary expidiancy. These are the things that always hurt me in the long run - it wasn't until my entire program was one unmanagable ball of mud till I realized the harm in using globals out of line with recommended OO design.
But on the other hand, if you only do it once in a great while when you run into a nigh unsolvable design problem, the harm is minimized - especially when you're programming from a high level like in script most T2D games.
So what's the point of this? Simple code organization. In other words, avoiding code that cannot easily be followed. Bad designs often lead to worse designs down the road - compounding your design problems indefinitely. Sooner or later, one can end up with most objects knowing about most other object just by letting just a handful of design problems get out of hand. This is the point where your program becomes the big ball of mud - this is where your program's growth simple hits a brick wall (rather painfully too).
Another thing I do, since I always program to an interface (albeit often with a default implementation), I code as though Torque Script was a typesafe language.
For example, if I am receiving an object from a parameter that uses comments to specify the parameter type (I always specify parameter types with comments when I cannot use the variable name to imply the type), I never access any methods / members not specified in the class's interface (the pseudo-class declaration). If I need to see if the object in question is of a type lower than the one specified by the parameter's comment (or name), then I use a custom 'cast' function that comes with the next version of OOInT2DScript. But even using this function is not recommended except where T2D loses type info (like in the onCollision parameter, etc...). Proper OO design almost always allows the type to be known and expected. This is yet another major boon to program organization - but completely optional in Torque script.
continued...
#89
Torque script is such a flexible language you could end up with a big ball of mode in just a couple thousand lines of code if you do not rigidly stick to a consistant and proven conceptual design discipline. Torque is so flexible that it allows you to blow your foot off in more ways than C++ could dream of. (Of course, there is a major upside to that flexbility which has made my life 100 times easier at times than C++ would... but thats beside the point).
So it's like a paradox - so easy to use, so easy to blow your foot off with. I think the whole 'with great power comes great responsbility' totally applies to using Torque script. I just can't see how anyone could get real far without using some major design and programming discipline therein.
*Final disclaimer
But there is no one ultimate way to code. There's my way which works for me, and many, many other ways which I have never even tried and therefore can't speak for. So if it works for you, and it holds up well in the long run, then hey, you must be doing it right :)
05/04/2005 (10:01 pm)
...continuedTorque script is such a flexible language you could end up with a big ball of mode in just a couple thousand lines of code if you do not rigidly stick to a consistant and proven conceptual design discipline. Torque is so flexible that it allows you to blow your foot off in more ways than C++ could dream of. (Of course, there is a major upside to that flexbility which has made my life 100 times easier at times than C++ would... but thats beside the point).
So it's like a paradox - so easy to use, so easy to blow your foot off with. I think the whole 'with great power comes great responsbility' totally applies to using Torque script. I just can't see how anyone could get real far without using some major design and programming discipline therein.
*Final disclaimer
But there is no one ultimate way to code. There's my way which works for me, and many, many other ways which I have never even tried and therefore can't speak for. So if it works for you, and it holds up well in the long run, then hey, you must be doing it right :)
#90
My basic methodology is to wrap everything in ScriptObjects and delegate/forward function calls to the composed objects. Ie:
I still plan to use Python for subsequent games, but I'm also pleased with the results of my efforts so far using TS. It's a flexible language, indeed, but it lacks the elegance, convenience, and power that Python has from the start. We won't go there, though, as I'm not interested in convincing anyone that what I like is best for anyone except me. :)
Gosh it's really late.
05/05/2005 (12:13 am)
@Bryan: Sorry if I sounded defensive. I just wanted to qualify the statements I was making about TS so it was clear I wasn't talking out my *** without any research. Which, btw, is something I see a lot when language criticism is bandied about. I'm on my second game using TS and T2D, so I have written a large amount of code with it.My basic methodology is to wrap everything in ScriptObjects and delegate/forward function calls to the composed objects. Ie:
function gameLogic()
{
%myCharacter = new ScriptObject( type1 );
%myCharacter.anim1 = myAnim1Datablock2D;
%myCharacter.sprite = new fxAnimatedSprite2D() { etc };
%myCharacter.function();
}
function type1::function( %this )
{
%this.sprite.playAnimation( %this.anim1 );
// do more stuff with %this instance specific to this type of character
}Then toss the instances into SimSets and you have a decent method of keeping things organized. I actually have another layer of indirection since I have a "meta-description" of the type which gets default values for each instance when it's created.I still plan to use Python for subsequent games, but I'm also pleased with the results of my efforts so far using TS. It's a flexible language, indeed, but it lacks the elegance, convenience, and power that Python has from the start. We won't go there, though, as I'm not interested in convincing anyone that what I like is best for anyone except me. :)
Gosh it's really late.
#91
05/05/2005 (1:31 am)
I am pretty curious about Python. I'll do a quick wikipedia :)
#92
What an interesting language! I might have to give it a go one day :)
05/05/2005 (1:59 am)
Hmm... cool dynamic OO features... but no member privacy? Catching syntax errors??? :OWhat an interesting language! I might have to give it a go one day :)
#93
lol I was almost tempted to stick up for TS on that post (when I saw Bryan's post I figured his would be a good defense though)... I scripted a 40 page Torque Database and surprisingly it works quite efficiently. Though I do know what you mean, TS does lack some "features" it could have... you should read through some of Ben Garney's old plans, he mentioned all the improvements going into TS in TGE 1.4
05/05/2005 (8:07 am)
@Jason: Well put... I can respect people who say their peace and respect other's perspective of it :)lol I was almost tempted to stick up for TS on that post (when I saw Bryan's post I figured his would be a good defense though)... I scripted a 40 page Torque Database and surprisingly it works quite efficiently. Though I do know what you mean, TS does lack some "features" it could have... you should read through some of Ben Garney's old plans, he mentioned all the improvements going into TS in TGE 1.4
#94
And I now dread the C-type "for" loops after the simplicity of Python's.
Like I said, I'm not trying to push it on anyone. TS was made for Torque, so it's obviously able to get the job done well (I've done some pretty cool things with it), and a lot of people like the C syntax, but I find it cumbersome after working with Python.
The other big challenge so far is the tile editor. :) I've just started working with tile maps, so I'm learning some new things and finding some new challenges there.
@Bryan: You can actually have private members, but it's not as necessary as it may at first seem. If you prefix a function or variable with two underscores it's considered private by the interpreter, although in Python you can get access to anything if you really want to. I spent quite a while trying to figure out where my well-known C++ idioms were in Python, until I learned that they don't apply and it's actually quite liberating not having them around yet still allows full OO design. I really had to shift my thinking to "get" Python and see its power.
05/05/2005 (10:11 am)
I'm only using this comparison as one instance, not saying everyone should use Python, but, there's one thing that Python does which TS could use, for example, and that's if you haven't assigned to a variable, the compiler should complain. Python also uses typeless, dynamic variables like TS, but in TS you can do this:%myData = 33; if ( %myDara == 33 ) doSomething();TS will create two variables: myData and myDara, and you'll never know there's a bug there but your code will misbehave. In Python the compiler would raise an error that myDara does not exist because you never assigned a value to it.
And I now dread the C-type "for" loops after the simplicity of Python's.
for myVar in someListOfStuff: doSomething( myVar )That will doSomething() with each myVar in someListOfStuff. You don't mess with counters or anything. It will iterate over all the elements for you, and you just get on with the code (you can also iterate by a "step" value if you want to go by 2, 3, 4, n elments at a time). There's a ton of stuff like this that has spoiled me forever. :) I was pretty fed up with C++, anyway, but now I really dread it.
Like I said, I'm not trying to push it on anyone. TS was made for Torque, so it's obviously able to get the job done well (I've done some pretty cool things with it), and a lot of people like the C syntax, but I find it cumbersome after working with Python.
The other big challenge so far is the tile editor. :) I've just started working with tile maps, so I'm learning some new things and finding some new challenges there.
@Bryan: You can actually have private members, but it's not as necessary as it may at first seem. If you prefix a function or variable with two underscores it's considered private by the interpreter, although in Python you can get access to anything if you really want to. I spent quite a while trying to figure out where my well-known C++ idioms were in Python, until I learned that they don't apply and it's actually quite liberating not having them around yet still allows full OO design. I really had to shift my thinking to "get" Python and see its power.
#95
Yeah, the issue with it not complaining about a variable actually is a feature in a lot of languages. The looseness of scripting in that area is liked by some and other used to more strict languages its disliked... I think Ben mentioned TorqueScript might give you the option to do either, to forward declare variables or to do them on the fly
php and actionscript are other languages that allow you to declare variables on the fly, there is merrit for that since it can save time.
hmm, Python for loops look interesting, I definately want to delve into that after hearing some very good compliments to the language from Josh Ritter and Jay Barnson (he did a RPG in a week on it)
though I have gotten used tot he C style for loops, lol I don't mind them so much since I use them in php, C++, and TS, so doing something different might be "too" convenient when I have to switch back to another language
05/05/2005 (10:35 am)
Well Josh Ritter is a huge advocate of Python and hes done an MMO in Torque based off of a Python system thats integrated with Torque... so I definately would give Python plenty of credit.Yeah, the issue with it not complaining about a variable actually is a feature in a lot of languages. The looseness of scripting in that area is liked by some and other used to more strict languages its disliked... I think Ben mentioned TorqueScript might give you the option to do either, to forward declare variables or to do them on the fly
php and actionscript are other languages that allow you to declare variables on the fly, there is merrit for that since it can save time.
hmm, Python for loops look interesting, I definately want to delve into that after hearing some very good compliments to the language from Josh Ritter and Jay Barnson (he did a RPG in a week on it)
though I have gotten used tot he C style for loops, lol I don't mind them so much since I use them in php, C++, and TS, so doing something different might be "too" convenient when I have to switch back to another language
#96
$Con::warnUndefinedVariables = true;
This will shoot out a gray console warning when an undefined variable is used (which works just like your example).
Very handy!
05/05/2005 (11:30 am)
You can have Torque script point out the usage of undefined variables by affixing this line of code to the begining of your main.cs script -$Con::warnUndefinedVariables = true;
This will shoot out a gray console warning when an undefined variable is used (which works just like your example).
Very handy!
#97
@Bryan: Whoa! I'll definitely use that, thanks a ton.
05/05/2005 (3:04 pm)
@Matthew: You don't have to forward declare variables in Python, but you do have to assign to them to make them "valid". So you still get the "looseness" like TS et al.@Bryan: Whoa! I'll definitely use that, thanks a ton.
#98
thx for pointing that out Bryan, I've forgotten that probably 10+ times lol...
I didn't follow up on the plan Ben posted asking for ideas on including new features in TorqueScript.. though he might've gone with the option to choose strict and loose... which would be pretty usefull
05/05/2005 (3:59 pm)
Ahh very cool..thx for pointing that out Bryan, I've forgotten that probably 10+ times lol...
I didn't follow up on the plan Ben posted asking for ideas on including new features in TorqueScript.. though he might've gone with the option to choose strict and loose... which would be pretty usefull
#99
I think I went through the same process as Jason.. After I did just one project in Python, learned the language and toyed around with ZODB (an object oriented dbase / persistent objects - gotta love'm) any other language became unelegant and cumbersome. Right now it almost feels depressing doing something in another language. Not in the least because Python is usually written in 1/3 of the code (reduces bugs too) that other languages need and it is very readable - even after years... Both help you doing more and coding less. And that's essentially what I want (T2D fits in here). Nonetheless, toying with T2D is exciting :)
Im off googling for Torque+Python :)
05/05/2005 (4:38 pm)
Python... *loving sigh*I think I went through the same process as Jason.. After I did just one project in Python, learned the language and toyed around with ZODB (an object oriented dbase / persistent objects - gotta love'm) any other language became unelegant and cumbersome. Right now it almost feels depressing doing something in another language. Not in the least because Python is usually written in 1/3 of the code (reduces bugs too) that other languages need and it is very readable - even after years... Both help you doing more and coding less. And that's essentially what I want (T2D fits in here). Nonetheless, toying with T2D is exciting :)
Im off googling for Torque+Python :)
#100
05/05/2005 (11:08 pm)
@Edo: Jeremy Noetzelman and Tomas Dahle are working on Python for T2D (and TAP in general). It's not ready for prime time yet, but it's close.
Torque Owner Jeremy Alessi