RE: Scripting Systems

Why don't you just save the game before the encounter and, when needed, load
it back up?

----------------------------------
Peace and love,
Tweety
[email protected] - [email protected]
YahooID: tweety_04_01

 

-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of
gekido
Sent: January 28, 2004 8:02 PM
To: [email protected]
Subject: Re: [GD-General] Scripting Systems

the developers of simkin (the language that we have embedded) have created a
command-line debugger for this type of thing, but i haven't been able to
afford the license he wants yet for us to integrate this into our
development environment.

with that said, i definitely agree that these types of issues with our game
engine, although implementing a custom script editor has helped simplify
things.

i've recently created a custom build of SCITE (www.scintilla.org), which if
you haven't checked it out is probably the slickest editor i've ever used
(and open source).

it took me all of an hour to create an entire api for our engine (with all
the game functions, parameters etc) and we now have autocomplete for
functions (among many other things), which helps eliminate some of the
semantic issues that arise from custom scripting...

i believe it has lua support straight out of the box as well.

regarding debugging, i've never really considered implementing an http
server for debugging, but now that you say it, it sounds like an interesting
idea...

the half-life engine has their 'console' and 'rconsole' access tools for
this kind of thing, implementing a 'remote console' would help for some
debugging, but for the most part, we simply output information to the
on-screen console and use that for debugging...

regarding the 'getting into the game', i agree that this is a pain as well,
having to play 5 minutes through a level to test one feature is a major
pain...i haven't figured out a solution for that one yet ;}

cheers
mike w
www.realityfactory.ca



Brett Bibby wrote:

> 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 -----
> From: "Brian Hook" <[email protected]>
> To: <[email protected]>
> 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 
>>honest to God code), with Nick Trout as my personal coach to see me 
>>through the (one step better than horrible) documentation.
>>
>>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.
>>
>>My most common programming errors are simply mechanical:
>>
>>1.  Accidentally typing object:method() instead of object.method() or 
>>vice versa
>>
>>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()
>>
>>3.  Typographical/memorization errors:
>>
>>function object.foo( x, y, z )
>>....
>>end
>>
>>o.foo( y, x, z ) -- oops!
>>
>>or:
>>
>>function client.create()
>>local c = { client_name = "Default" }
>>return c
>>end
>>
>>c = client.create()
>>c.name = "Brian Hook" -- oops!
>>
>>or
>>
>>-- oops, forgot the 'then'!
>>if c.client_name == "Brian Hook"
>>   c:doSomething()
>>end
>>
>>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"...
>>
>>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.).  
>>
>>Brian
>>
>>
>>
>>
>>-------------------------------------------------------
>>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_idU7
> 
> 
> 
> -------------------------------------------------------
> 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_idU7
> 
> 


-------------------------------------------------------
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



-------------------------------------------------------
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