A close friend of mine went on a job interview recently, for a local game development company. I'm not going to name names here, but let's just say that they're a sorta-large Game Development boutique in Vancouver.
Needless to say, he didn't get the job, but that's a tale for another day. However, I personally believe that one of the reasons he didn't get the job was because of his lack of familiarity with a scripting language that they are using in-house called Lua. This concerns me, since I'm teaching students how to be game programmers and it's a topic that I haven't focused enough on in the past. We cover Unreal Script as part of a course on using an existing engine. But we haven't actually looked at taking a scripting engine and incorporating it into tools or an engine. So, armed with website in hand, I decided to break down this little barrier. The result is described in this document.
Actually, I'm not sure just how long this document is going to be. I may decide to break it into several smaller pieces, or just write one, long rant that goes from start to finish. Anyway, I'll decide this a little later on, when I've actually gotten my notes into a more intelligent and coherent format.
Why's and whatnots
First and foremost, why use a scripting language? Simply put, most of the game logic can be scripted for functionality, rather than coding it as part of the engine. As an example, think about loading or initializing a level. When the level is first loaded, maybe you want a cut scene to play. Or maybe you want to show some game credits. With a scripting system, you could get individual game entities to do specific tasks. Also, think in terms of AI. Non-Player Characters need to know what to do. Coding each NPC by hand, in the game engine could be a daunting task. When you wanted to change a behavior of an NPC, you would have to re-compile your system. With a scripting system, you could interactively change the behavior and save that state out.
I've touched on this issue a little bit in the last paragraph, but I'll discuss it a bit further here. The question is, why not just write the entire game logic in C/C++? Simply put, from a programmer's perspective, we have to start concerning ourselves with the game code, as well as the engine and tools and … well, you get the idea. We can now, with a simple scripting language start exposing that functionality to the level designers. They can start poking and prodding and optimizing gameplay. Here's a ferinstance:
That rather long winded example may be a bit exaggerated, but I hope it brings the point across. What we're trying to do with this model is move to a more data driven workflow. So, essentially what we're trying to go for is the following:
I'll go and make a prediction here. Within 5 years, a level designer will have to do more than just build pretty levels. They'll have to be able to script how the level plays. Several forward thinking game companies have already taken this approach. Also, you see this kind of integration in editors like UnrealEd and the Aurora toolset by Bioware.
Enough insights and rants
Hopefully at this point I've got everyone sold on the rationale as to why you would want to incorporate a scripting component into your game. So, the next question is: how the heck do you do it?
What I'm going to be using for my scripting component is an embeddable scripting engine called Lua. I'll be the first to admit that I'm not master of Lua, but it is a relatively simple language, so it doesn't take long to get a grip on. Some of the later examples I'll be going over are pretty straightforward. You can get information on Lua itself at www.lua.org. Also, at the end of this document, I'm going to include some additional reference material. There are a fair number of other scripting languages out there, like Small, Simkin, Python and Perl. However Lua's a nice, clean language. As well, it has one really nice advantage.
Lua is Open Source. This is good because (a) you get the source to the language, if you want to dig in that deep and (b) it's free. You can use it in commercial apps without having to cough up coin for it. As independent games development go, free == good.
So, who's currently using Lua? Is Lua some simple garage based language that is only being used by the poor? Well, not quite. Lua's been around for a while, and it's been used by more than a couple of relatively important bodies:
OK, enough with the Who's who of lua developers. You can see all the bodies using lua at the lua website.
Let's start off really simple. The first thing that we need to build, just to show off how to use lua, is a simple interpreter. What this will involve is:
Hey, I thought you said enough rants?
Yeah, I did, didn't I? So, let's get to it. Again, you can get all the lua source code by going to www.lua.org and surfing the site. I'd also like to take a second and note that there is a new version of Lua on the horizon, 5.0. I'm not going to be discussing this version in this article. I will examine it at a later date, but for now, we'll be using 4.0.1.
The first thing that we are going to want to do is build a library of all the lua functionality. This way, we don't have to include the source every time we build a project. This isn't hard, and it's nothing but grunt work. So I've done this, and included it as part of this article. I've built a static library for this example. Yes, I could have built it into a DLL, but for a scripting system, a static library is going to be a little faster. Not lots, mind you, but a little faster.
Building an interpreter is actually pretty easy, now that we have the library built. I'm going to generate a simple Win32 console application that takes input from the console (typed in) and uses lua to interpret it.