Re: A few questions about scripting

Jacobo Ríos a écrit :
>
> For example, many games (like the old Maniac Mansion, etc) have their 
> own scripting language which only handles the game dialogs and events 
> ("if secret-brick moved then open door"), this is very simple for 
> designers to add or delete, and have a rapid testing approach, if you 
> add a new mission, then just let your designer to add a few lines and 
> done!..
--

I think it's one of the important points about scripting language: Does 
it look like a complete generic purpose language that allows you to do 
everything, or on the other hand is it an ultra-specialized language 
that fits the type of game you are doing, with very high-level 
constructs (play this animation, do that if I'm triggered, detect 
collision) and simple syntax (no scoping, no final semi colon, no && << 
!1:, etc...).

At Adeline Software we had ultra specialized scripting languages, Little 
Big Adventure and Time Commando share some of the concepts and have 
similar instruction set but they are very different one from another, 
and really did not look at all like C++ or Pascal :)

The end result is that animators and game designers were able to do some 
minigames, script some characters, add easter-eggs, all that very easily.

When you throw out the preconceived ideas you may have about your main 
programming language, you get a lot of freedom in what you can do in a 
script. You can design a language where you handle nicely the 
synchronization of multiple agents running in parallel, you can invent 
instructions that simplifies common actions (in the example of Jacobo, 
the "if secret brick moved'" had a special instruction, the SWIF (Switch 
If), that was particular useful for handling things like levers or 
on/off buttons: It enters the IF on the first time the condition get 
TRUE, then nothing happens while it is TRUE, it will enters the ELSE the 
first time the condition get FALSE, and nothing will happen until it 
gets TRUE again. Pretty cool for puzzles)

That's mostly why I don't like languages like LUA :)

Not that LUA is bad, just that it is a full-featured language, so by 
definition it means that:
- you get as many different scripts as you get people (too many ways to 
do the same thing)
- programmers will write scripts that non programmers will not be able 
to understand
- it's so advanced that you need a real debugger
- some people will start to metaprogram in script, using the whole 
mathlibrary-memoryallocation to write stuff that really should be 
implemented in C++ and exposed as utility functions

If instead you have a simple scripting system, you will force everybody 
to use the same basic constructs, so you maximize the chance that people 
can understand/fix/maintain other people's script. Some programmer 
should regularly take a look at how the scripts are done, and when you 
start to notice some common patterns (sequences of instructions), it 
probably means it's time to modify the system a bit, either by adding a 
new instruction that replaces this pattern, or by showing different ways 
of doing that (ie: update the documentation and inform the users).

So to summarize what I think:
- powerful script language is bad, because you only get the crap 
equivalent of slow C++, the only thing you get is the fast iteration 
time, and you can probably cheat using dynamically loaded modules to 
achieve the same purpose.
- domain-specific/taillor made language is good - if it's well designed.

/me ducks and covers

    Mike






_______________________________________________
Sweng-Gamedev mailing list
[email protected]
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com