lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


Check out this link
http://www-cs-students.stanford.edu/~amitp/gameprog.html

Here is my general take on this...
Every game in a nut shell can be thought of as doing two things over an over
again.

1. Deside what each object in the game has to do.
2. Simulate the objects doing it.

As such you will tend to move #1 to the scripting side and keep #2 in the
engine. #2 will usually include the following

A. Low level screen access. Script may decide (#1) which texture to use on
the model but the actual rendering of the model and whatever housekeeping is
associated with the texture and whatnot #2.
B. Pathfinding. Script may deside where the character should be hadding at
the moment (#1) while the pathfinging code driving character across the
landscape is #2.
C. Animation selection. The script will usually decide what animation
shoulde be played by the character but the playback is #2.
D. Sound selection is #1. Sound playback #2.
E. Iteration facilities for your object world will belong to #2.
F. The game world representation itself as well as the accessors #2.
G. Collision detection is #2.
F. Any simulations where you would have to traverse tons of data will mainly
use #2.
... and so on.

You will want to make those C functions the script knows about as general as
possible to avoid using your script for low level programming. For instance
if you had a character in your game that could come and take sit on a chair.
In the worst case you want to use your script something like this

---------------------------------------------
set_target(chair)
result = wait_for(route_to_target()) -- this scripting engine has to keep
executing this point until the routing is done ***
if(result == SUCCESS) then
    wait_for(play_animation_at_target("sit")) -- see ***
end

rather than

---------------------------------------------
x,y = get_pos(chair)
result = wait_for(route_to(x,y)) -- see ***
if(result == SUCCESS) then
    o = get_orientation(chair)
    face_oposite(o)
    prepare_to_switch_animations();
    wait_for(play_animation("sit")) -- see ***
else
    set_background_animation("idle")
end

"wait_for" is for illustration only of course. This *wait_for* puppy is what
one would need microthreads for. Withought microthreads one will only be
limited to the mesasge based system where you have a message pump in #2
(C[++], etc.) and message handlers in #1(LUA, etc.).

The above examples are a bit of an exageration to convey the idea of how
involved scripting can get. In the second case you will have to spend $$+
extra in development and/or lower your game's performance to *some* degree.
While in the first case you don't have as much control over the game.

So, you just keep balancing on this edge and when you reach the point of
knowing exectly where to draw that fine line between the script and the main
engine I would love to hear about it :)

AB

----- Original Message -----
From: "Brian A. Knudsen" <brian@sacred.dk>
To: "Multiple recipients of list" <lua-l@tecgraf.puc-rio.br>
Sent: Sunday, June 09, 2002 2:33 AM
Subject: lua as game script


> i tried to use lua alongside a vc++ project (a simple game), and it worked
> perfectly. But my lack knowledge in the field of game scripting leads me
to
> ask for resources regarding this .. especially if they used lua. I'm not
> sure what to keep inside the mainfile and what to pass onto lua, and also
im
> in doubt how todo this with the best design ..
>
> any hints?
>
> Brian
>