December 11, 2004
Scripting and false dichotomy
I read this article about scripting languages for games and I thought there was some useful content and some not so useful. Specifically, I found the the comparison of Lua, Ruby and Python quite interesting. But I don't think the author's experience of some of the other languages, or understanding of their problem domain, is insufficient to include them in the comparison.
When discussing the topic of higher-level languages for games with colleagues, an attitude I commonly come across, and one which is implied by this article, goes something like, "if it's not C++ then it must be a scripting language". I think this is wrong for a number of reasons and it is a barrier to objectively considering which languages are valuable for use in games development.
First of all, what exactly is scripting and what is a scripting language? I would argue that scripting is what you do when you write scripts. A script is a simple program that automates a process, often gluing together a sequence of steps that might be individually carried out by hand.
Many people would describe Python, Ruby, Lua, Rexx and JavaScript as scripting languages. I think that is a good description. The inventors of these languages would, I think, be happy with the description because, when designing these languages, they considered scripting as one of the major applications. This doesn't mean that these languages can only be used for scripting or that scripts cannot be written in other languages.
Whole games can be written in Python. Although I don't think we're about to see a console FPS written exclusively in Python for some time! And if you wanted to write scripts in C, you could do it, but it is hardly the ideal language.
When a technical designer uses a language to customize the behavior of game objects, that could accurately be described as scripting. And a scripting language, like Python, is a good language for them to use. But by restricting ourselves to that application, we are missing opportunities both in terms of what we use higher languages for and which higher-level languages we use.
Also, "if it's not C++ then it must be a scripting language" is a false dichotomy. If Java is not C++, does that make it a scripting language? How about SQL? Java is a statically typed object oriented language with more in common to C++ than a scripting language. SQL is a database query language and too domain specific to be a scripting language.
So when a games programmer thinks about using a language other than C or C++, they often automatically think about a single application: customizing the behaviour of game objects. Also, such a programmer will tend to evaluate the suitability of a higher-level language in those terms. No surprise then that C#, Lisp and all the other languages got such a bad "review" in the aforementioned article.
For no particular reason, lets take C# as an example. The author of the article is right in a sense that C# would make a bad scripting language. It would not be a good language for a technical designer to use to customize the behavior of game objects. A language like Python would be a better choice. It is easier to learn, has faster turnaround time, etc, etc.
But that does not mean C# is inappropriate for use in games. It means that C# would be best used to solve different problems. In terms of syntax and semantics, C# is a lot like C++. At the risk of oversimplifying, C# trades off some performance for safer, cleaner and more expressive semantics than C++. It is also typically compiled using a JIT compiler rather than a stand-alone compiler but that is really just an implementation detail. Someone could write an stand-alone C# to native code compiler if they wanted to.
So my point is that a question like, "what is the best scripting language to use in my game?", is dangerous because it is a loaded question. A better question would be "given these game problems, what are the most appropriate languages to use?". There is no single correct answer. It depends on the game, platform(s), availability and quality of tools, ability of the chosen languages to inter-operate, experience of other programmers on the project and all kinds of other factors.
When discussing the topic of higher-level languages for games with colleagues, an attitude I commonly come across, and one which is implied by this article, goes something like, "if it's not C++ then it must be a scripting language". I think this is wrong for a number of reasons and it is a barrier to objectively considering which languages are valuable for use in games development.
First of all, what exactly is scripting and what is a scripting language? I would argue that scripting is what you do when you write scripts. A script is a simple program that automates a process, often gluing together a sequence of steps that might be individually carried out by hand.
Many people would describe Python, Ruby, Lua, Rexx and JavaScript as scripting languages. I think that is a good description. The inventors of these languages would, I think, be happy with the description because, when designing these languages, they considered scripting as one of the major applications. This doesn't mean that these languages can only be used for scripting or that scripts cannot be written in other languages.
Whole games can be written in Python. Although I don't think we're about to see a console FPS written exclusively in Python for some time! And if you wanted to write scripts in C, you could do it, but it is hardly the ideal language.
When a technical designer uses a language to customize the behavior of game objects, that could accurately be described as scripting. And a scripting language, like Python, is a good language for them to use. But by restricting ourselves to that application, we are missing opportunities both in terms of what we use higher languages for and which higher-level languages we use.
Also, "if it's not C++ then it must be a scripting language" is a false dichotomy. If Java is not C++, does that make it a scripting language? How about SQL? Java is a statically typed object oriented language with more in common to C++ than a scripting language. SQL is a database query language and too domain specific to be a scripting language.
So when a games programmer thinks about using a language other than C or C++, they often automatically think about a single application: customizing the behaviour of game objects. Also, such a programmer will tend to evaluate the suitability of a higher-level language in those terms. No surprise then that C#, Lisp and all the other languages got such a bad "review" in the aforementioned article.
For no particular reason, lets take C# as an example. The author of the article is right in a sense that C# would make a bad scripting language. It would not be a good language for a technical designer to use to customize the behavior of game objects. A language like Python would be a better choice. It is easier to learn, has faster turnaround time, etc, etc.
But that does not mean C# is inappropriate for use in games. It means that C# would be best used to solve different problems. In terms of syntax and semantics, C# is a lot like C++. At the risk of oversimplifying, C# trades off some performance for safer, cleaner and more expressive semantics than C++. It is also typically compiled using a JIT compiler rather than a stand-alone compiler but that is really just an implementation detail. Someone could write an stand-alone C# to native code compiler if they wanted to.
So my point is that a question like, "what is the best scripting language to use in my game?", is dangerous because it is a loaded question. A better question would be "given these game problems, what are the most appropriate languages to use?". There is no single correct answer. It depends on the game, platform(s), availability and quality of tools, ability of the chosen languages to inter-operate, experience of other programmers on the project and all kinds of other factors.
# posted by Alastair Patrick : 2:24 PM
