Tricks of the Windows Game Programming Gurus:Making Silicon Think with Artificial Intelligence

All ITKnowledge Source Code Search Tips Advanced Search |

| Tricks of the Windows Game Programming Gurus by Andre LaMothe Sams, Macmillan Computer Publishing ISBN: 0672313618 Pub Date: 09/27/99

Search this book:

Previous | Table of Contents | Next

#### Designing the Scripting Language

The design of the scripting language is based on the functionality that you want to give it. Here are some questions that you might ask yourself:

  • Will the scripting language be used for AI only, or will it be used for the entire game?
  • Will the scripting language be compiled or interpreted?
  • Will the scripting language be ultra-high-level, with an almost English-like syntax, or will it be a lower-level programming-like language with functions, variables, conditional logic, and so on?
  • Will all the gameplay be designed using the scripting language? That is, will the programmers do any hard-code game design, or will the entire game run with scripts?
  • What level of complexity and power do you want to give the scripters/game designers? Will they have access to system and engine variables?
  • What’s the level of the game designers who will use the scripting language? Are they HTML coders, entry-level programmers, or professional software engineers?

These are the kinds of questions that you should think about before you start designing the language. Once you’ve answered these and any other questions, it’s time to implement the language and really design the entire game.

This is a very important phase. If your game is going to be completely controlled by a scripting language, you’d better make it really open-ended, robust, extensible, and powerful. For example, the language should be able to model an airplane that flies by every now and then, as well as a monster that attacks you!

In any case, remember that the idea of a scripting language is to create a high-level interface to the engine so that low-level C/C++ code doesn’t need to be programmed to control the objects in the game. Instead, an interpreted or compiled pseudo-English language can be used to describe actions in the game. This is shown in Figure 12.28.

Figure 12.28 The relationship between the engine and scripting language.

For example, here’s a script for an imaginary scripting language to control a street light:

    OBJECT: "Street Light", SL

    VARIABLES:

        TIMER green_timer; // used to track time

    // called when object of this type is created

    ONCREATE()

    BEGIN

    // set animation to green

    SL.ANIM = "GREEN"

    END

    // this is the main script

    BEGINMAIN

    // is anything near the streetlight

    IF EVENT("near","Street Light&")) AND

       TIMER_STATE(green_timer) EQUAL OFF THEN

       BEGIN

       SL.ANIM = "RED"

       START_TIMER(green_timer,10)

       ENDIF

    // has the timer expired yet

    IF EVENT(green_timer,10) THEN

       BEGIN

       SL.ANIM = "GREEN"

       ENDIF

    ENDMAIN

I just threw this together right now, so it may have some holes in it, but the point is that it’s very high-level. There are a million little details about setting animations, checking proximity, and so forth, but with this language anyone can make a traffic light program.

The code starts up and sets the light to green with `ONCREATE()`, and then it tests if anything is close by with the `EVENT()` test and turns the light red. After the light has been red for awhile, it turns back. The language looks a little like C, Basic, and Pascal all mixed together—yup!

This is the kind of language you need to design and implement to control a game—something that is neutral and knows how to operate on any object. For example, when you say `BLOWUP(“whatever”)`, the language processor better know how to make that work for any object in the game. Even though the call to blow up a blue monster might be `TermBMs3()`, and the call to blow up a wall might be `PolyFractWallOneSide()`, you just want to say `BLOWUP(“BLUE”)` and `BLOWUP(“wall”)`. Get the point?

You’re probably wondering how to implement one of these scripting languages. It’s not easy. You have to decide whether you want an interpreted or compiled language—is the language going to compile into straight code, be interpreted by an interpreter in the game engine, or something in between? Then you have to write the language, a parser, a code generator, and a P-code interpreter, or make the code generator create straight PentiumX machine code or maybe translate to C/C++. These are all compiler design issues and you’re on your own here, but you’ve already written a couple of baby interpreters.

Some tools to help you are LEX and YACC, which stand for Lexical Analyzer and Yet Another Compiler Compiler. These are language parsing and definition tools to help you implement the recursive decent parser and complex state machines needed for a compiler or interpreter. If you still have my book Sams Teach Yourself Game Programming in 21 Days in the attic, there I show how to do a little language parsing. It may save you a trip to the store or the Internet.

I have a trick that you can use to get started without needing to write a full-blown language compiler/interpreter. Hold onto your hat!

Previous | Table of Contents | Next

Copyright © Macmillan Computer Publishing, Inc.

Products | Contact Us | About Us | Privacy | Ad Info | Home
Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights reserved. Reproduction in whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Read EarthWeb's privacy statement.