Re: [GD-General] Scripting

[Mickael P. <mpo...@ed...>]

Concerning console game using scripting languags, I can at least say that
"Time Commando" (PlayStation, 1996), and "Little Big Adventure"
(PlayStation, 1997) are both based on scripts.

Actually the game engine by itself is only a bunch of functionalities:
detect collision, move and animate actors, play sound and movies, display
stuff, and so on. 100% of game logic is scripted.

The reason is the variety of actors we had. Time Commando contains 10
history periods, each with around 30 custom items/actors (opponents,
weapons, traps, bonuses, ...), so it was a lot faster to code these custom
things in scripting language than directly in the engine, because even the
more complex actors never had more than 4 page of script text (not including
resource definition, but you need it in C++ anyway).

In Little Big Adventure, it allows the designers to add a lot of small stuff
here and there that makes the game world really interesting. You want some
random sound here and there, a squirel that climbs to the nearest tree when
you approach, that's simple to do. In most standard engine, you would have
to derive a SquirelClimbingTree class derivated from some other weird
hiearchy that maked perfect sense at the beggining of the development but
that ressemble to some weird artistic sculpture at the end of the project...

Another reason, is that Time Commando was coded by a grand total of 4
programers on two simultaenous versions (PC and PlayStation), so we were
happy to let the level designers "make the game" and try things.

One of the things I notice each time a "scripting vs complete engine" thread
begins, is that most people talk about lua, python, c, perl or whatever
other off the shelf language they can think about, and the eventual problems
of interfacing with the game engine, memory management, debugging, ... but
almost no one is talking about the cool thing there is in a well design
scripting language: the fact that you can easily code separate actors like
if you were in a perfectly multitasking system.

When you code some actor in a C/C++, you have explicit entry and exit points
that are used at every refresh frame.

In a nicely designed custom scripting system you do not have these. For what
it worth, your actor is living _alone_ in a forever loop (or until he dies,
get reseted, change behavior, or whatever).

Consider the following script fragment (it's the kind of things we had in
TimeCommando, except that the C++ like syntax was not here, so we had
"TestAlive(CowBoy)"):

==============
BeginActor Indian
    UseWeapon bow
    While CowBoy.isalive
        Shoot CowBoy
        Next
    EndWhile
    PlayAnim Victory
EndActor

BeginActor CowBoy
    UseWeapon gattling
    While Endian.isalive
        Shoot Indian
        Next
    EndWhile
    PlayAnim Victory
EndActor
==============

The "Next" command simply tell the interpreter to memorise the current
program counter for the current actor, and move on on the next actor.

Using this system you gain the fact that you know in which order the actors
are executing their code so you can perform complex choregraphies because
you know that this particular actor is performing this or this exactly at
this particular moment, so you can perform particularly nasty things. Never
tried to synchronise complex objects ?

In Time Commando we had to dynamicaly split/merge characters in a way it
could not be noticed by the player. I'm not talking here of kiddy things
like some actor on a moving platform, I'm talking here of a cowboy riding on
his horse (one single animated mesh containing the horse and the rider) and
then having it climbing down from the horse and going to the saloon (two
separate objects), or a tank on a battlefield where you have the turret that
turn independantly of the tank base, and the gunner on the turret that look
around independantly of the direction the turret is looking at...

In summary: it worked fine.

    Mickael Pointier