[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: RE: Ironic comment RE: cooperative multitasking
- From: "Jordan, Chuck" <CJordan@...>
- Date: Sun, 9 Jun 2002 16:32:25 -0700
> -----Original Message-----
> From: Thatcher Ulrich [mailto:firstname.lastname@example.org]
> Sent: Saturday, June 08, 2002 3:01 PM
> To: Multiple recipients of list
> Subject: Re: Ironic comment RE: cooperative multitasking
> On Jun 08, 2002 at 12:38 -0400, Sean Middleditch wrote:
> > The fact that enough game companies don't find languages
> like Lua useful
> > says that there is something Lua is missing that it
> shouldn't be. All
> > that I can really think of tho is a) *real* multi-tasking,
> and b) a more
> > newbie-friendly syntax.
> Eh, IMHO "real" multitasking in a game scripting language is more bug
> than feature. Less deterministic, and thus harder to debug than
> cooperative multitasking. Thread synchronization is difficult -- no
> point in inflicting it on scripters any more than necessary.
I agree 100%. I would tend to think that if you're writing scripts
that don't lend themselves to a cooperative multitasking (or no
multitasking) model, then you're trying to do too much in scripts.
I've yet to see any content scripting that can't be expressed with
event handler functions that take the "do something, wait for it to
finish, then do something else" model.
And as for the "newbie-friendly" syntax, I don't think this is
really a problem. Lua's biggest strength, apart from its small
footprint, is that it's so extensible. That's also it's biggest
weakness -- it presents engineers with a huge blank page. (As
Stan Lee pointed out, "With great power comes great
responsibility.") The power is that you can have lua mimic any
number of different programming models (except for pre-emptive
multitasking, maybe). The responsibility is that any order you want
in the scripts, you have to design and impose yourself.
In my experience, people -- "newbies" and experienced programmers
alike -- don't get hung up on the specifics of syntax. All they
care about is a consistent method of getting the engine to do what
they want. Apart from the period-verus-colon business, there's
just not enough syntax in lua to be "unfriendly" to anyone; the
problem is that it's not instantly obvious how to develop a system
out of one basic data type and a simple funtion-calling mechanism.
You can't just set a person down with Notepad, the lua reference
manual, and some glue functions, and expect them to be productive.
You're going to have to write some system scripts and design an
interface to your engine; the semantics of that interface are much
more important than the syntax of the base language.
I was responsible for implementing a scripting system for the
ultimately ill-fated PC version of "Obi-Wan" at LucasArts, and
this was after I'd worked as a scripter on a project that used
lua extensively, and before that as a scripter using a very high-
level, very application-specific scripting language. My goal was
to come up with something that was general-purpose enough to be
used for a variety of games, but had enough features to account
for all of the "weaknesses" of lua. (And as Thatcher mentioned,
I had a strong desire to "roll-my-own" language). In my case, the
end result had built-in thread support, type-checking, variable
declarations, classes, variables passed by reference or by value,
associative arrays, and was a complete failure. It was just too
big to be appealing to all the different types of projects going
on in the company, while at the same time too general-purpose to
be a big time-saver. In retrospect, all the time I spent
developing my own language would've been better put to
experimenting with lua and figuring out how to tailor it to the
application. I'd suggest that anyone who's hacking into the
existing lua interpreter might be better off spending that time
analyzing whether a) the changes are truly beneficial, and 2) the
same effect can't be achieved using a simpler mechanism already
supported in the base language.
So in addition to Bret's suggestions about expanding the exposure
of the language itself, I'd say that it's also necessary to expand
the exposure of what the language is truly capable of. Integrate
the examples from the FAQ into the main document -- I know that when
I first read the description of the language, it never would've
occurred to me that inheritance or type checking were even possible,
much less that they were such simple mechanisms. I'd bet that a lot
of people (myself included) passed over lua when considering a
scripting language to use, because it's just not clear how the
language can be applied to their system.