Re: [GD-General] Scripting Systems

[Brett B. <res...@ga...>]

You know Brian, you got me all excited when I read your note because it =
started off like you POSH note so I thought you had a nifty solution to =
all of this :)

I sympathize as I am also currently implementing Lua. I similar problems =
as you and we are trying to figure out how to fix them or find another =
scripting language as well.

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)

2. Debugging is a pain, although we have designed a solution. We are =
implementing a small, simple http protocol and hooking a script debugger =
to it. The game communicates to the debugger via http so we can debug =
PS2, GCN and PC scripts. You can even point a web browser at the IP and =
get a list of vars and their values and change them via a form (slow but =
just in case host debugging not available).  But building the debugger =
under Lua isn't nearly as nice as it could be. What are other scripting =
language debuggers like?

3. Incremental builds. We have converted our scripts to game objects =
(not to be confused with OO object programming). Each function is =
therefore unique and can be compiled and re-uploaded to the VM =
on-the-fly and so you can effectively pause the game in the debugger and =
replace a value, table or funciton anytime. This can make for some =
interesting bugs in it's own right, but without it you end up having to =
play the game for minutes just to get back to a place where you want to =
test something. Sometimes you can't even recreate the exact situation =
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?

Brett

----- Original Message -----=20
From: "Brian Hook" <ho...@py...>
To: <gam...@li...>
Sent: Thursday, January 29, 2004 6:07 AM
Subject: Re: [GD-General] Scripting Systems


> So I finally am getting around to using Lua "in anger" (i.e. in real=20
> honest to God code), with Nick Trout as my personal coach to see me=20
> through the (one step better than horrible) documentation.
>=20
> And what I've learned so far is that scripting, while cool in theory,=20
> is really a pain in the ass in a lot of practical ways, most of it=20
> having to do with type checking and basic things of that ilk.
>=20
> My most common programming errors are simply mechanical:
>=20
> 1.  Accidentally typing object:method() instead of object.method() or=20
> vice versa
>=20
> 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()
>=20
> 3.  Typographical/memorization errors:
>=20
> function object.foo( x, y, z )
> ....
> end
>=20
> o.foo( y, x, z ) -- oops!
>=20
> or:
>=20
> function client.create()
> local c =3D { client_name =3D "Default" }
> return c
> end
>=20
> c =3D client.create()
> c.name =3D "Brian Hook" -- oops!
>=20
> or
>=20
> -- oops, forgot the 'then'!
> if c.client_name =3D=3D "Brian Hook"
>    c:doSomething()
> end
>=20
> Finding these (often trivial) problems requires me to load and run my=20
> scripts, and in some cases I have to get into pretty entrenched areas=20
> 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=20
> condition to occur, then having things barf/not work because you typed =

> "nname" instead of "name"...
>=20
> This is all embedded as well, so using a development environment=20
> 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=20
> can't exactly make independent unit tests that run with the command=20
> line interpreter.
>=20
> Do other languages handle this any better?  JavaScript suffers from=20
> the same problems since it is also prototype-based (a la SELF et.=20
> al.). =20
>=20
> Brian
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> 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
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_idU7