Re: Scripting Systems

As a fan of Lua (can't say that I'm an expert, but I've used it a bit),
I felt the need to comment.

> So I finally am getting around to using Lua "in anger" (i.e. in real 
> honest to God code), with Nick Trout as my personal coach to see me 
> through the (one step better than horrible) documentation.

I don't see what's so wrong with Lua's documentation. It has all the
info about the language, up to the next step - how to actually use it.
And I must admit, there are plenty of ways one can use Lua (just as with
C++). I suppose the recently published book by Roberto Ierusalimschy
(one of the creators of the language) talks about that.
So, I've never missed anything in the Lua manual, except a "Tips &
tricks" section. That can be found partially in the Lua technical notes
and on the lua-users.org site.

> And what I've learned so far is that scripting, while cool in theory, 
> is really a pain in the ass in a lot of practical ways, most of it 
> having to do with type checking and basic things of that ilk.

True. However, the real power of Lua lies in its ability to create
mechanisms. You actually *can* add all sorts of type checks or property
access restrictions, if you want. Yes, that's a bit of additional work,
and can slow down execution, but you can disable it in final builds. I
know Lua could use a standard library with a set of pre-defined
mechanisms... hopefully this will happen one day, esp. with the new
LuaCheia project.

> 1.  Accidentally typing object:method() instead of object.method() or 
> vice versa

You could catch this with a type check system.

> 2.  Forgetting that table.foo() isn't called ON the table but WITH the 
> table, i.e. it's table.insert( t, ... ) not t:insert( t )/t.insert()

This goes away after a bit of practice, and getting used to 'think in
Lua': if you could write t:insert(...) for any table, this would mean
that you have a global propery "insert" inside all tables, which doesn't
make much sense.

> 3.  Typographical/memorization errors:
> 
> function object.foo( x, y, z )
> ....
> end
> 
> o.foo( y, x, z ) -- oops!

If x and y are of the same type, you wouldn't be able to catch this in
any language.

> or:
> 
> function client.create()
> =09local c =3D { client_name =3D "Default" }
> =09return c
> end
> 
> c =3D client.create()
> c.name =3D "Brian Hook" -- oops!

A class + type check system here would help too.

> or
> 
> -- oops, forgot the 'then'!
> if c.client_name =3D=3D "Brian Hook"
>    c:doSomething()
> end

Syntactic errors are easily found by using loadstring/loadfile (I'm
talking about Lua 5.0).

> Finding these (often trivial) problems requires me to load and run my 
> scripts, and in some cases I have to get into pretty entrenched areas 
> of my code (e.g. AI that responds to being attacked, etc.).  It really 
> sucks to load up a game, spend 5 minutes getting a particular 
> condition to occur, then having things barf/not work because you typed 
> "nname" instead of "name"...

Yes, that's a problem. Although you can call scripts with xpcall and use
debug.debug() or your own function as an error handler, I suppose it
would be hard to replace the faulting function from inside the handler.
But it's probably not impossible to implement an 'edit and continue'
feature, in a future Lua version, or even now.

> This is all embedded as well, so using a development environment 
> doesn't seem feasible (but I haven't looked into them enough to say).  
> Also, because of the reliance on calls back into my main kernel, I 
> can't exactly make independent unit tests that run with the command 
> line interpreter.
> Do other languages handle this any better?  JavaScript suffers from 
> the same problems since it is also prototype-based (a la SELF et. 
> al.).  

I don't see how you can use an IDE for embedded scripts, with any
language, unless you build it yourself inside your game editor or the
game itself. The same for unit tests.

> 1. We need some sort of Lint for Lua. This is hard to implement because =
> you can dynamically create table members. It's advertised as a feature =
> but when I type "nname" instead of "name" it's an error not a new =
> member. How do other languages get around this? I'm guessing they don't =
> either, but isn't there a better way to handle this? (I know I can trap =
> the __index method but I'm talking about finding errors before runtime)

This is a good idea.

> easily. This is only a partial solution, but I have heard others say Lua =
> is especially difficult to save the game state. How do other languages =
> used in games save thier game states?

Especially difficult?? It's definitely quite easy to save a Lua table
into a .lua file...

Currently I'm using Lua to create some tools, almost as a standalone
language for rapid development, and I run into these problems as well
(mostly type checking). I think it's possible to find solutions to
them, using the mechanisms the language provides.

BTW, Lua 5.0 is definitely an improvement over previous versions, though
I suppose it's not easy to switch from 3.2 or 4 to 5, if you already
have a working Lua connection and lots of scripts... But switching
should be considered when beginning a new project.

I don't know any other scripting language that has these problems
solved, I guess only the language you write yourself can solve them...
And of the 3rd party languages Lua does the most things right.

You should ask questions like these on the Lua mailing list, I think the
people there are generally very helpful. At least the language authors
will consider these issues for future releases... It seems they are
paying special attention to the usage of Lua in games.

Ivan






-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Gamedevlists-general mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_id=557