Warning: This post is focused on programming concepts.
Speed and ease of use have always been at odds with each-other in the computing world. In the days of the Apple II, most people started writing games in BASIC, until they needed more speed, then they switched to something faster. BASIC is an interpreted language and runs slower, but something like C is a compiled language and runs much faster even with equivalent code. That brings us to video games, which are really just specialized computer programs themselves. Why would someone use an interpreted language or a compiled one? Let’s explore that question.
Firstly, it’s important to really understand the difference between compiled code and interpreted code. Compiled code must be converted into a format the computer and understand, binary. This process is called “compiling”, and is done by a special program called a “compiler.” However, interpreted code is run through an “interpreter”, line-by-line. That’s really all there is to it. Compiled code (like C++) is harder to debug, however, and doesn’t offer the instant gratification of interpreted code (like PHP). As stated before, compiled code is much faster, as the compiler allocates memory and other such processes at compile time. The computer running the program does not have to do this on-the-fly like an interpreted language.
One of the most popular uses of an interpreted language in gaming is as a scripting language. Often times a game engine will allow in-game scripting to be done in a separate language outside of the source code of the engine itself. One major reason to do this is multiplatform compatibility. Instead of rewriting all the game play programming, you just re-write the script interpreter. Take for instance the SCUMM engine, used by many LucasArts adventure games. Not only was this engine ported to many different platforms, but a reverse-engineered open source version was later developed which supports even more platforms. However, sometimes multiplatform isn’t really a concern, but a scripting language has other benefits. The original Crash Bandicoot had a scripting language called GOOL (game object-oriented lisp). Based on lisp, this language made the transition from 60Hz NTSC (used in the U.S.) gameplay to 50Hz PAL (used in Europe) gameplay more simple. Moving to 50Hz throws off the timing of a game and many 50Hz releases run more slowly than their 60Hz counterparts, however Crash ran smoothly on both, since it was a simple matter of re-adjusting the back-end code of the game and not the gameplay code at all.
However, everything else in the game engine is usually written with compiled code. The interpreter itself is written in compiled code, but a game engine is many parts. Rendering, input, memory management, resource loading, all these are speed intensive tasks that often require a lot of CPU cycles. If your rendering code was interpreted, it could take up to 5 times as long to render a frame. A game that would run at 60 frames per second would then run at around 12 frames per second, which is not very good. Games are very speed-focused, as a gamer usually wants a very smooth experience while playing. Action games are especially reliant on speed, but you have more leeway with things like role playing games.
More Info:
About Compilers and Interpreters
The SCUMM Diary: Stories behind one of the greatest game engines ever made
Making Crash Bandicoot - GOOL