I think the bottom line is, productivity.

On a large project that takes a long time to compile, the last thing you want to be doing is tweaking little variables here and there and waiting for it to compile just to see if that fixed some minor glitch.

Since LUA is not compiled, but rather interpreted on the fly, you can make a small change and simply relaunch the game, rather then re-compile and relaunch.

On small projects like Teapot Wars, this really doesn't make much of a difference since you can just re-compile in less then a minute, but I can imagine that would get extremely irritating on a project that took even a couple minutes to compile, let alone hours to compile.

The first several pages of the Lua chapter talk about this exact thing. 25+ years ago, the exact same question was said about C. Why would anyone choose C over Assembly Language when Assembly is so freakin' fast? What about the same discussion in the 90's regarding C++? Why would you incur the cost of using C++?

Kl1x is absolutely right about programmer efficiency but it's much further than just compile time. There's also a huge dev-time cost savings as well. It's typically faster and easier to write (or prototype) a system in a language like Lua than it is C++. Lua is higher level and you don't have to worry about a lot of the little headaches you get from a lower-level language like C++. For example, I can build a table using anything as the index key without having to deal with templates and the STL. I can have a single table with multiple types for key entries. I can add and remove variables at runtime without worrying about newing & deleting stuff. Functions are also first-class objects, so I can attach and remove functions at runtime with very little cost. Dev time is MUCH faster.

Let's take another example: the event system. The C++ event system in GCC could have been written in about 1/10 the amount of time if I did the whole thing in Lua. It's incredibly trivial in that sort of language.

Lua, Python, and other scripting languages are the next evolutionary step of software engineering. When game programmers starting turning to higher level languages like C, they still used Assembly for all the time-critical stuff. That's exactly what we're doing here; C++ handles stuff like graphics and physics while Lua handles things like gameplay events.

-Rez

One of the coolest things about scripting languages, is that with a little extra work on the C++/Lua implementation you can actually change the Lua script without restarting the game!

This means that you can swiftly tweak variable values or even script logic while your game is running - which VASTLY improves iteration time which ultimately makes your game more fun.

Also, since you only need to load certain Lua scripts attached to game actors that are actually present, you can use scripting systems like Lua to build a vast game with thousands of different actors - and do so very efficiently memory-wise.

Another example is what I am currently working on, it is a 2D Map editor for a game at school, I have a custom command line in the game that will parse lua script. What is nice about this is that I haven't coded all of the GUI yet, so to add objects, assets, load and save maps, I have exposed the functions to Lua, and I am able to simply call them from the command console.

Without this I would have to either hard code these functions or wait until the GUI was up.

Sorry to bring up an older topic, but another answer is to look at what is occurring in the industry:

Some MMOs today seem to offer LUA scripting as a way to allow custom modifications to the UI. There are entire large efforts to build custom UIs and helpful macros to aid in raids (groups of players in a dungeon) and etc.

I think some of us actually expect this in a game now.

Yeah, I know the WOW has a GUI scripting system based in Lua, and there is even a Visual Studio plugin for it.

I have been recently learning to use Unity, and I am really seeing that essentially what the GCC book is doing is making a flexible game engine such as Unity (Although not nearly as refined). Although it uses Javascript/C#/Boo it is essentially the same idea as using Lua, in the Unity Editor you can literally change the variables of a script and run it in a split second, doing this same change in pure C++ you would need to rebuild for every change, this is really cool being able to change variables and immediately see there effect that quick.

I am finding that using Unity has really opened my eyes to alot of the things Mike and Rez have been teaching in the book, and I encourage anyone who is struggling to see how all the components are working together to give Unity a try.