RE: [GD-General] Scripting Systems
Brought to you by:
vexxed72
Menu
▾
▴
RE: [GD-General] Scripting Systems
|
From: tweety <mi...@sy...> - 2004-01-31 01:02:55
|
Why don't you just save the game before the encounter and, when needed, load it back up? ---------------------------------- Peace and love, Tweety mi...@sy... - twe...@us... YahooID: tweety_04_01 -----Original Message----- From: gam...@li... [mailto:gam...@li...] On Behalf Of gekido Sent: January 28, 2004 8:02 PM To: gam...@li... 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" <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 >>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 >>Gam...@li... >>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 > Gam...@li... > 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 Gam...@li... https://lists.sourceforge.net/lists/listinfo/gamedevlists-general Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=557 |
