feyd wrote:I can verify that many (real) games use scripting languages to define a lot of behaviors rather than actual code. Unreal engine projects will usually use UnrealScript, which is based on ECMAScript, for example.
Been there, done that, wrote the manual (literally).
Yes, scripting is a great way to separate engine code from game code and allow for quick modifications without recompile (or even, if one is wise enough, without restarting the executable). The key point is that this is done for the benefit of the
developers, not for the sake of modders (bar a few games that did this on purpose, to invite modders). Or, it comes free with the 3rd party engine you're using.
But gamers would not care for it. They don't need a fancy script language, they need to enjoy the game.
Modders would not care for it either, not unless the game becomes hugely popular.
Modders would also suck at modding, because they generally don't have the resources, talent or experience to make an enjoyable mod.
In the end of the day you are left with only a handful of successfull mods
ever made.
(Rant off, I know that was not exactly
Weirdan's point) So yes, modern games use scripting. What does this have to do with web-based games? (Okay, we may say the same of web-based games, PHP *is* a scripting language after all

) But do these two unrelated facts justify what Hory is trying to write on his grave, security-wise?
I don't think it pays to go through all the hassle to support modding for a web-based game.
I don't think gamers would appreciate it if the game allows user-level scripting either.
And I definitely don't think eval() is the way to do that, but we've already established that
-----
@
Kieran Huggins: closures? How would you use closures to provide a safe sandbox? You rather need a mechanism to limit the language's native API to a rich-yet-secure subset. This is trivial in some languages, and quite bordersome in others.