Ok, time for a nice programming discussions amongst us programmers. 
(and gamers, or course)
Ever seen a game (or game development kits) with and without scripting? Here's a few right off the bat:
Allegro Game Development Kit (and many others) - These tend to be RPGs, with 99% of the code in scripted files.
Civ4 - It's known that this will include scripting (Python).
AoE II - This has basic AI scripting.
So, here's what I think the pros and cons are: (You'll notice that some can be both)
Pros:
1 - Customisability. With scripts, a player can develop scenarios, and enhance their game. It's possible to even create an entirely new game.
2 - Open Source. Players and developers can easily share their code out in the public domain.
3 - The game is forced to act as an engine, leaving very little features hard-coded.
4 - Minimal compilier time. The only thing that's compilied is the game engine itself.
5 - Can be as limited, or as extensive as the programmer wants. If the game is meant to be a game engine, it can allow a 3rd party programmer to create whatever they want within the capabilities of the engine.
Cons:
1 - Customisability. Suppose you're making a Role Playing Game. Why would you want 99% of your code visible to the user? Sometimes, scripting is too much information. The user could easily see some spoiler, or find all the secrets in the game, or even add a few lines to give them the best stats.
2 - Interpretor. Scripts are interpreted, which take longer than compiled code.
3 - Circular. One thing I'll probably never understand is why in the world you would use a compilier to create the game engine, only to use a 'compilier' again to actually code the game for the game engine. Seems like double-work to me, and is begging for Murphy's Law (see the above two points) to strike.
4 - Sloppy. It's just plain sloppy with all these scripting files running around. Besides, some old school programmers probably wouldn't like the whole world looking at their code (which is why they wouldn't use scripts in the first place).
5 - Security concerns. If your script allows for reading/writing of files, then it's possible to download a rouge script someone has made that could ruin your computer. Think VBScript and MS Outlook.
6 - Can be limited. Depending on the script (whether it uses Python, or an internal script), you could be limited to the features you can use. Although a good game might use addons (DLL files for graphics routines, etc.).
Personally, I don't like full blown scripts that much (then again, I'm kind of old-school). The fact that it isn't compiled means it's not going to be as fast, which nowadays isn't much of a concern. But, it really depends on the type of game it is. For games with scenarios, it's a great tool. For a RPG type game, then I wouldn't go for it, since it's eluding the purpose of the executable itself. Might as well compile that code anyway.
(and gamers, or course)Ever seen a game (or game development kits) with and without scripting? Here's a few right off the bat:
Allegro Game Development Kit (and many others) - These tend to be RPGs, with 99% of the code in scripted files.
Civ4 - It's known that this will include scripting (Python).
AoE II - This has basic AI scripting.
So, here's what I think the pros and cons are: (You'll notice that some can be both)
Pros:
1 - Customisability. With scripts, a player can develop scenarios, and enhance their game. It's possible to even create an entirely new game.
2 - Open Source. Players and developers can easily share their code out in the public domain.
3 - The game is forced to act as an engine, leaving very little features hard-coded.
4 - Minimal compilier time. The only thing that's compilied is the game engine itself.
5 - Can be as limited, or as extensive as the programmer wants. If the game is meant to be a game engine, it can allow a 3rd party programmer to create whatever they want within the capabilities of the engine.
Cons:
1 - Customisability. Suppose you're making a Role Playing Game. Why would you want 99% of your code visible to the user? Sometimes, scripting is too much information. The user could easily see some spoiler, or find all the secrets in the game, or even add a few lines to give them the best stats.
2 - Interpretor. Scripts are interpreted, which take longer than compiled code.
3 - Circular. One thing I'll probably never understand is why in the world you would use a compilier to create the game engine, only to use a 'compilier' again to actually code the game for the game engine. Seems like double-work to me, and is begging for Murphy's Law (see the above two points) to strike.
4 - Sloppy. It's just plain sloppy with all these scripting files running around. Besides, some old school programmers probably wouldn't like the whole world looking at their code (which is why they wouldn't use scripts in the first place).
5 - Security concerns. If your script allows for reading/writing of files, then it's possible to download a rouge script someone has made that could ruin your computer. Think VBScript and MS Outlook.
6 - Can be limited. Depending on the script (whether it uses Python, or an internal script), you could be limited to the features you can use. Although a good game might use addons (DLL files for graphics routines, etc.).
Personally, I don't like full blown scripts that much (then again, I'm kind of old-school). The fact that it isn't compiled means it's not going to be as fast, which nowadays isn't much of a concern. But, it really depends on the type of game it is. For games with scenarios, it's a great tool. For a RPG type game, then I wouldn't go for it, since it's eluding the purpose of the executable itself. Might as well compile that code anyway.
