Thread: [GD-General] Scripting Systems
Brought to you by:
vexxed72
Menu
▾
▴
gamedevlists-general
|
From: Dan T. <da...@ar...> - 2004-01-20 22:50:26
|
I've looked around and implemented a few systems, but I thought I'd get everyone's opinion on how scripting should be incorporated into a game. Note that I'm *not* talking about what language to use, or what the scripting should be used for, nessesarily. Also note that the archives search on sourceforge is the worst search engine ever known to mankind. If this has been covered already, I apologize. The best way I've seen so far is every game object has a script running behind it that is essentially in an infinite loop. It spins on a check for messages call into the engine. Then when it gets a message it does stuff. e.g. Move Forward Was Pressed This Frame message. Then the controlling script does some trig, comes up with an appropriate force, and calls into the physics engine to add the force for the object. Also, these scripts run in a user level thread, where the script manager throttles the script timeslice based on current game performance, and the scripts call a Yeild() function when there are no messages to process. (btw, the scripts are effectively preemtive because we altered the lua execution engine to stop the stack for a given thread when a certain instruction count is hit. That way we get many threads, with throttling , and no synchronization issues to speak of. We also get the ability to limit all scripts to a certain % of frame time.) The primary downside is with a lot of game objects out there, you run into some pretty serious dividing of the time you have. Under release mode, we were getting about 200k lua instructions/second executed in the time given to the script manager. You get 100 objects in the game, and you are down to 1k instructions, with isn't a whole lot. This is mediated by the fact that scripts call a Yeild when they aren't doing anything (so you get 2 instructions, though both are C calls). This method is vs. just running a script and creating the stack when the message comes in. This seemed far too expensive, as you could be creating script stacks all over the place, and it also runs into the problem where the game locks because the scripts are being run in the same thread. These are just the ways I've come up with, and I'd really appreciate some ideas shot at me on how people think it should be done. Thanks! Dan |
|
From: Brian H. <ho...@py...> - 2004-01-21 03:13:42
|
> a game. Note that I'm *not* talking about what language to use Ah, but I will -- anyone using Ruby successfully? It doesn't seem to be particularly well documented for embedding, but it has a host of language features that I dig, and Lua and I have a love/hate relationship at times. Brian |
|
From: Alen L. <ale...@cr...> - 2004-01-21 11:22:10
|
Don't know much about Ruby, but I'd like to hear what you have to say against Lua. :) Just to make my standpoint clear - I like using Lua for build scripts and some stuff like that, but not for game scripting. I believe that it is not well suited for in-game use, due to "by-name" lookups in interpreter and due to use of garbage collector. Now I'd like to know if you have some more arguments in this direction. Alen ----- Original Message ----- From: "Brian Hook" <ho...@py...> To: <gam...@li...> Sent: Wednesday, January 21, 2004 03:13 Subject: Re: [GD-General] Scripting Systems > a game. Note that I'm *not* talking about what language to use Ah, but I will -- anyone using Ruby successfully? It doesn't seem to be particularly well documented for embedding, but it has a host of language features that I dig, and Lua and I have a love/hate relationship at times. 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 |
|
From: Brian H. <ho...@py...> - 2004-01-21 15:18:55
|
On Wed, 21 Jan 2004 12:24:31 -0000, Alen Ladavac wrote: > Don't know much about Ruby Ruby is cool. Ruby is intensely slow. Ruby is not very easy to embed (at least, the documentation is very sparse, and the stuff I've seen isn't particularly encouraging). Ruby -> C/C++ is much easier than C/C++ -> Ruby. > but I'd like to hear what you have to say against Lua. I hate people that bitch about syntax, but hey, I'm not particularly fond of Lua's syntax. It's just not very readable IMO because there's been so much syntactic sugar. That's a subjective thing. Lack of integers really irks me, but I'm getting over that complaint since the main place I wanted integers were bit masks, and I'm finally accepting that a property-per-bit isn't as devastating a problem as I'd like to think. Lua is fast. It's small. It's trivial to embed. But it doesn't have near the amount of features of Ruby with respect to high level expressiveness, but this may be why it's 10x faster on some of the GLCS benchmarks =3D) The GC issue is going to be addressed in 5.1 hopefully, which should ship before I'm done with my current project. Brian |
|
From: Alen L. <ale...@cr...> - 2004-01-22 07:20:06
|
>I hate people that bitch about syntax, but hey, I'm not particularly
>fond of Lua's syntax. It's just not very readable IMO because there's
>been so much syntactic sugar. That's a subjective thing.
Seconded. Though it's not syntactic sugar that bothers me most. I'd prefer
to have // comments and {} blocks. I mean, we all use C on daily basis, why
make things complicated? Lua syntax makes C syntax hiliting editors look
stupid.
> Lua is fast. It's small. It's trivial to embed.
Yup, it is very slick and nice. Though I didn't find ability to store state
(for save games), what can be quite a brick.
> The GC issue is going to be addressed in 5.1 hopefully, which should
>ship before I'm done with my current project.
Do you think that GC is main speed problem? How about name lookups? Does
that show on your profile?
Alen
|
|
From: Eero P. <epa...@ko...> - 2004-01-22 07:45:55
|
Alen Ladavac wrote: > > >>Lua is fast. It's small. It's trivial to embed. > > > > Do you think that GC is main speed problem? How about name lookups? Does > that show on your profile? > For me GC has not been the main problem speed wise, and I do trigger GC each frame, so that I can minimize "real time" problems with it. Profilers show the Lua name lookup as a spike in the curves, this might be partially because the VC++ generated code seems to just hit some kind of cache line/branch prediction limitation at least on Athlon, when compiling the Lua hashing function. I suspect that I see the name lookup, not so much as plain variable lookup, but because it is used when fetching array elements by name. Local variables them self AFAIK do not need the name lookup. The main CPU consumption spike still exists in the Lua virtual machine, executing the "byte code" interpreter seems to be quite unlucky exercise for the branch prediction logic in the CPU, and mispredicted branches hurt a lot on P4/Athlon. Eero |
|
From: Alen L. <ale...@cr...> - 2004-01-22 11:02:36
|
From: "Eero Pajarre" <epa...@ko...> > For me GC has not been the main problem speed wise, and I do trigger > GC each frame, so that I can minimize "real time" problems with it. Interesting idea. It really must smooth the performance. Though I would expect it to be slooow. It certainly does trash the cache big time, doesn't it? > Profilers show the Lua name lookup as a spike in the curves, this might That's same thing that I heard before, and one of main reasons why we didn't choose Lua for in-game scripting. I just couldn't find anyone who could reaffirm that. > Local variables them self AFAIK do not need the name > lookup. That is good. However, any member variable/function access would do a name lookup, right? > The main CPU consumption spike still exists in the Lua virtual machine, > executing the "byte code" interpreter seems to be quite unlucky exercise > for the branch prediction logic in the CPU, and mispredicted branches > hurt a lot on P4/Athlon. Out of curiosity, does the interpreter have a function table for instructions? If yes, then I don't see how so much misprediction could happen. :/ Alen |
|
From: Eero P. <epa...@ko...> - 2004-01-22 11:46:41
|
Alen Ladavac wrote: > From: "Eero Pajarre" <epa...@ko...> > >>For me GC has not been the main problem speed wise, and I do trigger >>GC each frame, so that I can minimize "real time" problems with it. > > > Interesting idea. It really must smooth the performance. Though I would > expect it to be slooow. It certainly does trash the cache big time, doesn't > it? > It might be just me not noticing it, but as I said it has not been a problem yet. I certainly have been "garbage aware" in my code, so I don't produce that much of it. Also my data structures at lua side are not that huge. The main objects are on C++ side and just referred from the Lua side, although I typically still have also a Lua table for each main object. > >>Profilers show the Lua name lookup as a spike in the curves, this might > > That's same thing that I heard before, and one of main reasons why we didn't > choose Lua for in-game scripting. I just couldn't find anyone who could > reaffirm that. > > >>Local variables them self AFAIK do not need the name >>lookup. > > That is good. However, any member variable/function access would do a name > lookup, right? > Yes, although the access is based on hashed arrays etc, and is quick. > > Out of curiosity, does the interpreter have a function table for > instructions? If yes, then I don't see how so much misprediction could > happen. :/ > The main loop is actually switch based, but I think that even with function table the main switching point would predict rather badly. Also there is some unpacking of parameters in the virtual machine, which also doesn't branch predict too well. Eero |
|
From: Brian H. <ho...@py...> - 2004-01-28 22:07:19
|
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()
=09local c =3D { client_name =3D "Default" }
=09return c
end
c =3D client.create()
c.name =3D "Brian Hook" -- oops!
or
-- oops, forgot the 'then'!
if c.client_name =3D=3D "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
|
|
From: Brett B. <res...@ga...> - 2004-01-29 00:36:07
|
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
|
|
From: Brian H. <ho...@py...> - 2004-01-29 05:11:12
|
> 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.
Right, but it doesn't know that.
> 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)
Run-time is the only way to do it. Lua is a dynamically typed
language, and since it doesn't even comprehend the idea of user
defined types, "type checking" is kind of a no-op.
What we'd need is a preprocessor that uses a convention where any
uninitialized element accessed out of a table constructor or
declaration is definitely bad.
v =3D { x =3D 0, y =3D 0, z =3D 0 }
v.zz =3D 3 --<< BZZZT!
> 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.
That's either crafty or gross, I'm not sure yet. =3D)
> 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.
That's exactly what we're doing as well.
> 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.
Yep.
Sounds like we're in the same boat but without a solution =3D|
Brian
|
|
From: Brett B. <res...@ga...> - 2004-01-31 02:26:36
|
> Run-time is the only way to do it. Lua is a dynamically typed=20
> language, and since it doesn't even comprehend the idea of user=20
> defined types, "type checking" is kind of a no-op. =20
>=20
> What we'd need is a preprocessor that uses a convention where any=20
> uninitialized element accessed out of a table constructor or=20
> declaration is definitely bad.
>=20
> v =3D { x =3D 0, y =3D 0, z =3D 0 }
> v.zz =3D 3 --<< BZZZT!
>
Idea 1
A hack to be sure, but I could trap the __index error and do some sort =
of "spell checker" against known elements, starting with the locals and =
working my way upward. If it finds a recommended match (within some sort =
of error metric) it changes it and keeps going. If I have a debugger it =
could pop-up with the suggestion and allow me to accept or choose =
another symbol and optionally modify the source for me to correct the =
problem. Without a debugger it could output a log that looks like =
preprocessor logs showing the error, line number, etc. As long as there =
is an option to enable/disable the feature, it would probably fix like =
90% of the errors.
Idea 2
Based upon the concept of automated unit testing, I could load the =
function to compile, generate a unit test for each function, compile and =
load both of them, and run the unit test against it. Failures could do =
something like Idea 1 above and when fixed is written to disk (as an =
obj). This gives you a Lint-like system and since we compile each =
function as an object, incremental build will keep the performance =
acceptable. Plus it has the ability to interactively fix problems.
Anybody tried this? This sounds pretty workable to me.
Brett
|
|
From: gekido <mi...@ge...> - 2004-01-29 17:27:08
|
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 > > |
|
From: David B. <d.j...@wa...> - 2004-01-30 20:48:42
|
> 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 > Maybe I am missing something here, but arnt other people recording logs of there user input(or some other critical message path within there simulation). This is very useful in all kinds of similar situations. If these are time stamped, upon discovering a bug and fixing the script cant you have the engine replay the input(which should be fast if you are running the simulation on its own, without graphics etc) to a safe point a few seconds before the problem, pause, upload the changes and continue playing until you find another bug... David |
|
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 |
|
From: Garett B. <gt...@st...> - 2004-01-31 02:01:36
|
Design folks, Ok, sorry to distract you all, but I just don't get it. After reading about Brian's problems with his scripts (and additionally having considered the problem at length without actually implementing any scripting system myself [except for my pitiful attempt at *writing* a scripting system for Deer Hunter 3, which we won't go into here for fear of grave embarrassment to myself]) it seems to me that "scripting" is being used to solve problems that could just as easily be solved by real code. Please enlighten my heathen mind: Why not simply compile your "scripts" into C/C++ .DLLs? These are the arguments I can vaguely recall for scripting, but I just don't think they hold up: 1. You don't have to compile scripts. I mean, ok, yeah, you gotta spend a few seconds on compiling some C/C++ into a .DLL (holy mother of poo!), but that serves a handy purpose: the compiler checks a variety of error and warning conditions that give you immediate feedback before you even try the script. And if it is so difficult to arrange a test case for the script's performance, are you really saving any time by not using a compiled language? 2. Scripting code is easier for designers to write. Um, really? Is Lua any easier to write than C? Ok, it's more verbose, but verbose just means more symbols to remember and use correctly. At work I'm stuck using Visual Basic, and while it is pretty handy for our problem domain (RAD w/ database and native GUI), it also really confuses some of my C++ instincts (and vice-versa). 3. The security of a sandbox. Ok, you've got me there, if your primary goal in scripting is to allow your fanbase to create new content without exposing other users to a variety of security scenarios, then I suppose you've found your holy grail. At the cost of 15x performance of course. I seem to recall the user community (PlanetQuake et al.) doing a pretty good job of filtering through the security of mods, in fact, I don't recall any news of blaster or welchia worms arising from Q2 mods, but you know, whatever keeps your paranoid heart skipping happily along, go for it. Even if it is a huge pain in the ass. All that aside, I do believe there are some C-syntax scripting languages out there these days (http://csl.sourceforge.net/csl.html). In the realm of other ideas, Battlefield 1942 uses a "scripting" language that is really more along the lines of a gameplay balancing dataset. You can code up new vehicles in plain text by combining engines and meshes and various attributes in new and interesting ways, but you can't really change the core gameplay mechanic. I'm just not significantly compelled to go beyond dynamic library-based extendability for the time being. However, I am significantly compelled to find out why the higher minds of my time think otherwise. Please excuse my dear Aunt Sally. Regards, Garett Bass gt...@st... |
|
From: Brian H. <ho...@py...> - 2004-01-31 02:41:53
|
> Please enlighten my heathen mind: Why not simply compile your > "scripts" into C/C++ .DLLs? The sheer number of them can be daunting. In a lot of cases you're talking about several hundred if not several thousand scripts if you want to be able to dynamically load/reload chunks of code. I actually posed the same question not too long ago (look for the thread "DLLs as game objects"). But other considerations: - scripts now requires real programming, whereas a language like Lua or Python is (in theory) a bit friendlier when doing basic scripting like behaviour, triggers, etc. - security problems since you can't sandbox C++ particularly well > Um, really? Is Lua any easier to write than C? Yes, since there aren't any pointers. Remove memory management, and probably 50% of newbie C mistakes are gone. Get rid of arcane syntax like the whole & vs. * thing, and you get rid of another good chunk. Get rid of "stack" vs "heap" and hey, more problems go away. > 3. The security of a sandbox. > > > Ok, you've got me there, if your primary goal in scripting is to > allow your fanbase to create new content without exposing other > users to a variety of security scenarios, then I suppose you've > found your holy grail. That's a pretty major one, IMO. Not just that, but sandboxing protects your own designers from inadvertently trashing something if they're trying to make an edit on a live world (e.g. in an MMOG). > All that aside, I do believe there are some C-syntax scripting > ideas, Battlefield 1942 uses a "scripting" language that is really > more along the lines of a gameplay balancing dataset. Well, there's the whole data-driven vs. procedural argument, but I don't think we have time to get into THAT one again here... > I'm just not significantly compelled to go beyond dynamic library- > based extendability for the time being. I felt the same way, but for the particular problem domain I'm working in, I specifically need reloadable code, sandboxing and ease of use. Brian |
|
From: Kent Q. <ken...@co...> - 2004-02-04 02:42:43
|
There are a couple of major benefits that haven't yet been mentioned:
* You can open source your scripting code without open sourcing the whole
app. If you believe in the value of the mod community this can be big.
* Vastly shorter (nonexistent?) build times for changes at the scripting level.
* You're forced to think about the API you want to expose to scripting.
Yes, discipline in coding helps, but having the enforced discipline is useful.
Kent
----
Kent Quirk
CTO, CogniToy
|
|
From: Jorrit T. <Jor...@uz...> - 2004-02-02 12:09:08
|
Garett Bass wrote: >Design folks, > > Ok, sorry to distract you all, but I just don't get it. After reading >about Brian's problems with his scripts (and additionally having considered >the problem at length without actually implementing any scripting system >myself [except for my pitiful attempt at *writing* a scripting system for >Deer Hunter 3, which we won't go into here for fear of grave embarrassment >to myself]) it seems to me that "scripting" is being used to solve problems >that could just as easily be solved by real code. > > Please enlighten my heathen mind: Why not simply compile your "scripts" >into C/C++ .DLLs? These are the arguments I can vaguely recall for >scripting, but I just don't think they hold up: > > One other reason for not doing this is portability. The projects that I'm involved with are multi-platform. These games have to work on Windows and Linux and possibly also MacOS/X. Having to distribute two or three versions of your dll's is a hurdle. If you can keep the main portion of your game in C++ and then the game logic itself in a portable scripting language then you have some maintenance advantages. Still another reason is for sending over scripts dynamically over the internet. This may be relevant for some types of games. Doing this with C++ compiled code is very hard to do and sending C++ code requires the client to have a C++ compiler which is also a big burden. Greetings, |
|
From: <e_a...@ya...> - 2004-01-30 23:49:55
|
Hi, I'm quite surprised nobody pronouce the name of python yet. So here I go : I found Python to be a good scripting language. From what I've been told, the language is cleaner than Lua (I've never used Lua ). There are a lot of tools/site/support anywhere on the web. It supports coroutine, have a lot of useful lib (Zip for instance ). It can be used for other tasks (automated build, HTTP stuff, ... ). Last but not least, the HAP debugger is a remote debugger/IDE. There can be some perf issue on this gen consoles, thought I think some people manage to port it and use it (there are some GC and PS2 Python project on the web), and with the new console gen that is to come, there will be no reason not to use it... Hope it helps Emmanuel --- Brett Bibby <res...@ga...> a écrit : > 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 > Yahoo! Mail: votre e-mail personnel et gratuit qui vous suit partout ! Créez votre adresse à http://mail.yahoo.fr |
|
From: tweety <mi...@sy...> - 2004-01-31 07:10:01
|
Has anyone tried using the dotNet framework for doing scripting? As I'm
currently writing a game in c# (small, hobby-like game :D), it seems
natural. It's also quite fast and there is a pretty good debugger for it
(VS.NET). You could also use it with COM interop from C, who knows, maybe
it's fast enough...
----------------------------------
Peace and love,
Tweety
mi...@sy... - twe...@us...
YahooID: tweety_04_01
-----Original Message-----
From: gam...@li...
[mailto:gam...@li...] On Behalf Of Brett
Bibby
Sent: January 28, 2004 6:46 PM
To: gam...@li...
Subject: Re: [GD-General] Scripting Systems
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
|
|
From: Alen L. <ale...@cr...> - 2004-01-29 10:58:34
|
>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"... IMHO, I'd say that dynamic typing is a bug, not a feature, at least in gamedev. It is cool to use a very flexible language for small stuff like scripting parts of level. But if you need to write menus or real entity AI, I'd stick with something that can be statically checked. I believe someone mentioned Ch already somewhere here. Though it might not be portable enough for your needs. Perhaps even using lcc with your own interpreted bytecodes would help. Hey, it's a proven method ;). Just my 1kB, Alen |
|
From: Brian H. <ho...@py...> - 2004-01-30 19:46:19
|
> in gamedev. It is cool to use a very flexible language for small > stuff like scripting parts of level. But you'll have the same problems. Language syntax errors, e.g. forgetting a "do" or "end", can be caught using the luac compiler, but semantic syntax bugs, e.g. "nname" instead of "name", won't be caught. So if you script just triggers or just scripted sequences, you can still have a problem with errors. Sure, the problem is minimized, but it still exists. Brian |
|
From: gekido <mi...@ge...> - 2004-01-30 19:50:35
|
alot of our beginning designers also have problems with case sensitivity with our script language, again something that could be called a 'bug'. similar situation, we've had to just browbeat the windows users into acknowledging that there are differences between 'Name' and 'name' in the rest of the computing world ;} cheers mike w www.gekidodesigns.com Brian Hook wrote: >>in gamedev. It is cool to use a very flexible language for small >>stuff like scripting parts of level. > > > But you'll have the same problems. Language syntax errors, e.g. > forgetting a "do" or "end", can be caught using the luac compiler, but > semantic syntax bugs, e.g. "nname" instead of "name", won't be caught. > > So if you script just triggers or just scripted sequences, you can > still have a problem with errors. Sure, the problem is minimized, but > it still exists. > > 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 > > |
|
From: Thatcher U. <tu...@tu...> - 2004-01-30 20:24:09
|
On Jan 29, 2004 at 12:18 -0500, Brian Hook wrote: > > in gamedev. It is cool to use a very flexible language for small > > stuff like scripting parts of level. > > But you'll have the same problems. Language syntax errors, e.g. > forgetting a "do" or "end", can be caught using the luac compiler, but > semantic syntax bugs, e.g. "nname" instead of "name", won't be caught. > > So if you script just triggers or just scripted sequences, you can > still have a problem with errors. Sure, the problem is minimized, but > it still exists. Yes indeed. The JavaScript 2.0 spec apparently adds optional static type checking. I think JavaScript has somewhat more practical syntax and class semantics, compared to Lua, as well. I've never tried to embed a JavaScript interpreter though. -- Thatcher Ulrich http://tulrich.com |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X