sponsors gamedev.net search:

Introduction 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: Let's imagine that the Joey, our hapless game programmer, writes all the game engine, tools and game logic. Yes, Joey is a pretty busy boy, but let's assume that he's up to the Herculean task. We also have Brandon, the game designer. Brandon's a pretty smart guy and has a very clever idea for the game. So, Joey, our coder, goes away and implements all the game logic using tools he's developed based on Brandon's initial design. All is well in the game shop. The first milestone rolls up and both Joey and Brandon sit in a boardroom and go over the progress. Brandon notices a couple of issues in gameplay that don't quite work. So Joey goes back to the code, makes the changed and re-compiles. This process is going to take a day, at the very least, unless it's a trivial change. Also, depending on the internal process, you may have to wait a full day for the engine/game code to be re-compiled. Many shops have a nightly build process that happens, and the latest demo stream is built from that. So, we can be looking at a 24 hour period before Brandon gets to see the change that he requested. Now, let's imagine that our protagonist, Joey, decided that it would be in his best interest to implement the game logic using a scripting system. This may take a little longer in the beginning, but he feels that it's going to be worth it in the long run. So, he exposes from his game engine a fair bit of functionality to the game scripting system. He also writes all the game logic in said scripting system. So when he goes into the meeting with Brandon, and the designer notices something that he's not quite happy with, Joey opens up a console, makes a couple of changes to the script, and re-runs the game to see the new behavior. The changes can be implemented immediately and displayed immediately, rather than waiting for a re-compile. Additionally, if Joey was particularly bright, the scripting system could be a tool available to the level designers when they build the level. That way, with a little re-education, the designers could set events in the game, like triggers, doors, in-game events to happen without programmer intervention. 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: Means a coder is concerned in writing engine/tool code, rather than game logic. Means time taken away from writing game engine/tools. Designers like to be able to 'twiddle' with things. Scripting allows them easy access to this functionality. It also allows them more flexibility to try things out in the level that they normally would have to get a coder involved with. You don't have to re-compile if you want to change functionality in the game. Simply modify the script. You want to break the tie between engine code and game code. They should be two separate pieces. That way, it's easy to use the engine for multiple games (hopefully). 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: - Lucasarts  * Grim Fandango  * Escape from Monkey Island - Bioware  * Neverwinter Nights  * MDK2 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: Getting the lua interpreter code. Setting up your dev environment. Building an interpreter from scratch. 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. Page 2

Contents   Page 1   Page 2   Page 3   Page 4   Page 5   Page 6   Source code   Printable version   Discuss this article