Do you prefer code or scripting?
by Andy Schatz · in Torque Game Engine · 06/16/2005 (4:49 pm) · 13 replies
Question first, argument second:
Show of hands...
If you could get rid of Torque's scripting system entirely, and have all gameplay implemented in C++ code, would you?
Scripting offers:
-Non-programmers the ability to "code" gameplay
-Arguably easier moddability for communities
-Run-time programming interface
Implementing all gameplay in code offers:
-Faster execution
-Vastly superior debugging
-Consolidated development environment
I've been involved in several large-scale commercial products where scripting was used heavily. 5-8 years ago, data-driven gameplay was hailed as the saving grace of large projects. But what I've found is that having non-programmers scripting is always a disaster, debugging is FAR harder, it forces programmers to learn two code bases rather than one, and you end up implementing much of the gameplay in code for speed purposes anyways.
The mantra is that scripting should be used appropriately and in moderation, but I've never seen that happen. Once the scripting system exists, it gets abused.
I'm sure some GG guys can evangelize the other side of this argument, but I for one would prefer almost entirely code-based gamplay implementation, perhaps separated into a second DLL the way that the original Half-life did it.
Thoughts?
Show of hands...
If you could get rid of Torque's scripting system entirely, and have all gameplay implemented in C++ code, would you?
Scripting offers:
-Non-programmers the ability to "code" gameplay
-Arguably easier moddability for communities
-Run-time programming interface
Implementing all gameplay in code offers:
-Faster execution
-Vastly superior debugging
-Consolidated development environment
I've been involved in several large-scale commercial products where scripting was used heavily. 5-8 years ago, data-driven gameplay was hailed as the saving grace of large projects. But what I've found is that having non-programmers scripting is always a disaster, debugging is FAR harder, it forces programmers to learn two code bases rather than one, and you end up implementing much of the gameplay in code for speed purposes anyways.
The mantra is that scripting should be used appropriately and in moderation, but I've never seen that happen. Once the scripting system exists, it gets abused.
I'm sure some GG guys can evangelize the other side of this argument, but I for one would prefer almost entirely code-based gamplay implementation, perhaps separated into a second DLL the way that the original Half-life did it.
Thoughts?
#2
06/16/2005 (5:03 pm)
I would say no, every Commercial game has scripting. How much time would you waiste if you had to spend it compiling all the time. The speed decrease in scripting is very minimal. Scripting is very effecient. I was going to wright up something better but I gtg eat. Oh yea and I completly agree with that scripting should be used appropriately and in moderation. Oh yea I totally agree with brandon
#3
I've also worked on large commercial products that didn't use scripting and found the workflow to be superior. (correct me if I'm wrong on this) The original Half-life implemented their gameplay in C, encapsulated inside a DLL that ran on top of the engine DLL. That seems pretty elegant to me.
@Brandon- If someone gave me a square wheel and a round wheel and told me that the square wheel was intended for dirt and the round wheel was intended for road, I would still use the round wheel for both. ;)
06/16/2005 (5:12 pm)
It doesn't take long to compile (mere seconds), and how much time do you waste when you make a syntax error in your script and you have to read through the console log or hunt through the script itself to find the error?I've also worked on large commercial products that didn't use scripting and found the workflow to be superior. (correct me if I'm wrong on this) The original Half-life implemented their gameplay in C, encapsulated inside a DLL that ran on top of the engine DLL. That seems pretty elegant to me.
@Brandon- If someone gave me a square wheel and a round wheel and told me that the square wheel was intended for dirt and the round wheel was intended for road, I would still use the round wheel for both. ;)
#4
I don't think that you should use the argument that non-coders can implement gameplay, as a reason why we have scripting languages in games engines.
Also, as for faster execution when you implement all gameplay in code. The idea when you develop software is not to be stupid, naturally you don't implement all gameplay in script. If you have, save, AI algorithms that executes heavy tree-searching algorithms, then implement them in code, and open them up to the scripting language, with engine hooks.
I don't agree with "vastly superior debugging" either. Are we talking scripting languages in general, or TorqueScript in TGE here? You have a lot of tools available to you to debug script as well as the source code of the engine, and I would say that debugging script usually is easier - not perhaps vastly easier.
06/17/2005 (1:35 am)
Quote:
Scripting offers:
-Non-programmers the ability to "code" gameplay
-Arguably easier moddability for communities
-Run-time programming interface
Implementing all gameplay in code offers:
-Faster execution
-Vastly superior debugging
-Consolidated development environment
I don't think that you should use the argument that non-coders can implement gameplay, as a reason why we have scripting languages in games engines.
Also, as for faster execution when you implement all gameplay in code. The idea when you develop software is not to be stupid, naturally you don't implement all gameplay in script. If you have, save, AI algorithms that executes heavy tree-searching algorithms, then implement them in code, and open them up to the scripting language, with engine hooks.
I don't agree with "vastly superior debugging" either. Are we talking scripting languages in general, or TorqueScript in TGE here? You have a lot of tools available to you to debug script as well as the source code of the engine, and I would say that debugging script usually is easier - not perhaps vastly easier.
#5
06/17/2005 (1:46 am)
Quote:I don't think that you should use the argument that non-coders can implement gameplay, as a reason why we have scripting languages in games engines.But that IS a reason that is often given. I don't agree with it, but it's been cited many times.
Quote:Also, as for faster execution when you implement all gameplay in code. The idea when you develop software is not to be stupid, naturally you don't implement all gameplay in script. If you have, save, AI algorithms that executes heavy tree-searching algorithms, then implement them in code, and open them up to the scripting language, with engine hooks.Agreed wholeheartedly
Quote:I don't agree with "vastly superior debugging" either. Are we talking scripting languages in general, or TorqueScript in TGE here? You have a lot of tools available to you to debug script as well as the source code of the engine, and I would say that debugging script usually is easier - not perhaps vastly easier.Really? I have experience with two major script bases, the Medal of Honor scripting language (based on QuakeIII/FAKK) and TorqueScript. Neither allows me to step through code, set breakpoints, set up watches, view the callstack or script variables upon an error, profile my code, etc. Now the situation might be different with LUA, but why would you want to use two different debugging interfaces when you can have a single, integrated one?
#6
06/17/2005 (10:34 am)
Actually, TorqueScript has a debugger that supports all those things.
#7
I think sripting is used too much in the GG community because most people either don't have a nice C++ IDE to develop with, or don't understand C++. Scripting does have it's place though. One good example that highlights this point is "mods". It has been proven time and time again that allowing end users to "mod" your game increases replay value and interest. In this area C++ does not shine, and would not be used. So, each has it's intended purpose and function, but I do agree with you scripting is used way too much for things C++ is better suited for.
B--
EDIT: Ben delivers another good point: TorqueScript is game scripting on steroids! :) The vast resource of scripting mods shows how powerful this little language can be. Just another plus for end user "mods" of your game.
06/17/2005 (10:46 am)
@Andy: I agree with you. I also prefer C++ for developing. Step line debugging/break points, quick compiles, easy acces to definition blocks, locals, etc.I think sripting is used too much in the GG community because most people either don't have a nice C++ IDE to develop with, or don't understand C++. Scripting does have it's place though. One good example that highlights this point is "mods". It has been proven time and time again that allowing end users to "mod" your game increases replay value and interest. In this area C++ does not shine, and would not be used. So, each has it's intended purpose and function, but I do agree with you scripting is used way too much for things C++ is better suited for.
B--
EDIT: Ben delivers another good point: TorqueScript is game scripting on steroids! :) The vast resource of scripting mods shows how powerful this little language can be. Just another plus for end user "mods" of your game.
#8
So you are saying that the developers of Tribes 2, ThinkTanks, Lore, Marble Blast, Orbz, dRacer, BoomBall, etc. "don't understand C++"? We all use scripting heavily.
06/17/2005 (2:52 pm)
Quote:
I think sripting is used too much in the GG community because most people either don't have a nice C++ IDE to develop with, or don't understand C++.
So you are saying that the developers of Tribes 2, ThinkTanks, Lore, Marble Blast, Orbz, dRacer, BoomBall, etc. "don't understand C++"? We all use scripting heavily.
#9
Why would I want to dismantle the engine in my Ford Explorer every time I changed the oil?
~ Yeah, it's a shaky metaphor, but you get the point.
06/17/2005 (3:00 pm)
In answer to the question - H3LL NO.Why would I want to dismantle the engine in my Ford Explorer every time I changed the oil?
~ Yeah, it's a shaky metaphor, but you get the point.
#10
Though this might true in some cases, I think in a lot of cases the opposite is true. A lot of people already know C++ and don't know TorqueScript and don't understand it... often times its when people don't understand how integrated script is into the engine and how powerful that integration is. :)
06/17/2005 (3:05 pm)
Quote: think sripting is used too much in the GG community because most people either don't have a nice C++ IDE to develop with, or don't understand C++.
Though this might true in some cases, I think in a lot of cases the opposite is true. A lot of people already know C++ and don't know TorqueScript and don't understand it... often times its when people don't understand how integrated script is into the engine and how powerful that integration is. :)
#11
I scripted a 40+ page Torque Database, since I made it of Script Objects and because its in script I can load any type of data I want into it without any hitch... integer, strings, file paths, flie names, even can pass it entire objects (really passing object ID's) that it will store and I can reference later... now all that is acheived automagically by setting up that way, I didn't have to set up anything special to get it to do so; however, if I had used C++ that would've been a very large headache to be able to do that, yes it would end up more efficient, but the time to do it would at least be quadrupled, if not more. Then if I added any addition objects to my game that I would want loaded I would have to modify the source again. With script it still works more than fast enough and it does all this naturally :)
On top of that if I ever want to add special functionality I can do so quickly, modify a little bit, run Torque test it and repeat... I can even exec the file upon modification and test the changes real time. If I want to integrate some of it into the C++ I still can and can still keep some or a lot of it on the script side so I can still modify it in seconds.
Just something to think on *shrug*
06/17/2005 (3:10 pm)
An example of how useful the script can be in a way not usually thought of.I scripted a 40+ page Torque Database, since I made it of Script Objects and because its in script I can load any type of data I want into it without any hitch... integer, strings, file paths, flie names, even can pass it entire objects (really passing object ID's) that it will store and I can reference later... now all that is acheived automagically by setting up that way, I didn't have to set up anything special to get it to do so; however, if I had used C++ that would've been a very large headache to be able to do that, yes it would end up more efficient, but the time to do it would at least be quadrupled, if not more. Then if I added any addition objects to my game that I would want loaded I would have to modify the source again. With script it still works more than fast enough and it does all this naturally :)
On top of that if I ever want to add special functionality I can do so quickly, modify a little bit, run Torque test it and repeat... I can even exec the file upon modification and test the changes real time. If I want to integrate some of it into the C++ I still can and can still keep some or a lot of it on the script side so I can still modify it in seconds.
Just something to think on *shrug*
#12
*searches*
A quick search revealed nothing obvious regarding debug tools for TorqueScript. Am I an idiot for using this engine for 6 months and not knowing about this?
@Mr. Tut- Yes, extensibility is one of the great reasons to use script. I won't deny that. But 95 percent of projects don't need to be extensible, at least in terms of new features. And no matter how similar the language is to C++, the syntax and workflow are still significantly different.
@Kirby- Ah but we're not changing the oil, we're building a CAR! /Still a bad metaphor
Oh and all you game devs that use script heavily OBVIOUSLY don't know how to use C++. Stupid programmers. ;)
06/17/2005 (3:32 pm)
@Ben- Where do I find all these wonderful toys? I'm assuming there's documentation somewhere? *searches*
A quick search revealed nothing obvious regarding debug tools for TorqueScript. Am I an idiot for using this engine for 6 months and not knowing about this?
@Mr. Tut- Yes, extensibility is one of the great reasons to use script. I won't deny that. But 95 percent of projects don't need to be extensible, at least in terms of new features. And no matter how similar the language is to C++, the syntax and workflow are still significantly different.
@Kirby- Ah but we're not changing the oil, we're building a CAR! /Still a bad metaphor
Oh and all you game devs that use script heavily OBVIOUSLY don't know how to use C++. Stupid programmers. ;)
#13
06/17/2005 (3:37 pm)
@Andy: Though I understand your point (and agree with it to an extent), I'd have to disagree with "95 percent of projects don't need to be extensible." With the restriction of being an indie I often find my team's projects need to be all the more extensible, since we are prone to getting help, contracting help, bringing in people and people leaving. 
Torque 3D Owner Brandon Maness
B--