Thread: Re: [GD-General] Scripting Systems (Page 2)
Brought to you by:
vexxed72
Menu
▾
▴
gamedevlists-general
|
From: Brian H. <ho...@py...> - 2004-01-30 20:50:18
|
> 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. JavaScript gets a bit of a bad rap, mostly because it's associated with, say, mouse rollovers. There was a discussion about this on the vworld-tech mailing list, and basically one of the big things, IMO, that's holding back mass adoption of SpiderMonkey is that people just have no idea if it's fast or not. As much as the GLCS is a pile of poo, it's all a lot of people have to go on when it comes to real world performance measurement. When I saw Ruby routinely being outperformed by a factor of 5 to 10 or more, I knew that it probably wasn't going to be practical for my use. Since the NJS implementation scored poorly, that was the only datapoint I had to go by for SpiderMonkey even though it's an unrelated codebase. I was taken to task for this assumption (rightfully so), but at the same time that's effectively asking me to try out every language and see for myself if it's going to be effective or not, and I don't have that kind of time. There are probably 20 or so small languages that are interesting in some fashion or another (Small, IO, etc.) but which I don't have the time to really sit down and exhaustively give a "fair" assessment. So I put the onus on the implementors if they want people to adopt their stuff. And in situations like that, I pretty much fall back to Lua =3D) Brian |
|
From: Thatcher U. <tu...@tu...> - 2004-02-01 04:06:20
|
On Jan 30, 2004 at 03:50 -0500, Brian Hook wrote: > > Since the NJS implementation scored poorly, that was the only > datapoint I had to go by for SpiderMonkey even though it's an > unrelated codebase. I was taken to task for this assumption > (rightfully so), but at the same time that's effectively asking me to > try out every language and see for myself if it's going to be > effective or not, and I don't have that kind of time. There are > probably 20 or so small languages that are interesting in some fashion > or another (Small, IO, etc.) but which I don't have the time to really > sit down and exhaustively give a "fair" assessment. > > So I put the onus on the implementors if they want people to adopt > their stuff. Yeah, agreed, you have to be pragmatic. Another way to look at this is that community/social/marketing attributes of programming languages are very important -- in many respects more important than technical aspects. -- Thatcher Ulrich http://tulrich.com |
|
From: Brian H. <ho...@py...> - 2004-02-01 04:30:21
|
> Yeah, agreed, you have to be pragmatic. Another way to look at > this is that community/social/marketing attributes of programming > languages are very important -- in many respects more important > than technical aspects. I rant about just that (along with other stuff) on my Web page here: http://www.bookofhook.com/Article/GameDevelopment/TipsforOpenSourceDev elope.html In a nutshell, if you're open sourcing something, then in theory it's because you think other people should use your stuff. So put out the effort to evangelize/educate, and if you don't, don't cry because your project isn't as popular as the others that "aren't as good". Brian |
|
From: <cas...@ya...> - 2004-01-30 22:52:11
|
Brian Hook wrote: > Do other languages handle this any better? JavaScript suffers from > the same problems since it is also prototype-based (a la SELF et. > al.). For this kind of problems I would suggest to use test units, to catch the errors without having to play the game. With a scripting language test units are easy to write and you can implement a simple testsuite application to run them all automatically. I would also look at python, I think they may have similar problems. Here is an interview of the Guido van Rossum about strong and weak typing, that might be of interest: http://artima.com/intv/strongweak.html Also, as you said, python has the benefit of many good IDEs that help you write correct code. I think lua does not have a good IDE, but I haven't looked for it either. Hope that helps. -- Ignacio Castaño cas...@ya... |
|
From: gekido <mi...@ge...> - 2004-01-30 23:07:55
|
> Also, as you said, python has the benefit of many good IDEs that help > you write correct code. I think lua does not have a good IDE, but I > haven't looked for it either. www.scintilla.org - built in lua syntax highlighting, api etc very slick, open-source, and very easy to create your own API for function auto-complete etc cheers mike w www.gekidodesigns.com |
|
From: <cas...@ya...> - 2004-01-31 01:45:37
|
gekido wrote: > www.scintilla.org - built in lua syntax highlighting, api etc > > very slick, open-source, and very easy to create your own API for > function auto-complete etc scite is an excelent editor. However, it doesn't provide all the features that a good IDE would provide, for example, an integrated parser that analizes your code and provides dynamic autocompletion. In lua that would be quite hard, because it doesn't have class declarations. In fact, it doesn't have classes, only tables, and they aren't declared either, so it would be quite hard to provide autocompletion. I think that it would be possible to provide autocompletion, writting an integrated editor in your game (it's really easy if you use scite) and write the code while the game is running. If the object is global, it's easy to inspect it, but if it's local, it becomes much harder... -- Ignacio Castaño cas...@ya... |
|
From: Jorrit T. <Jor...@uz...> - 2004-01-21 07:26:36
|
Dan Thompson wrote: >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. > > I'm the project manager of CEL (Crystal Entity Layer) which is a game entity layer sitting on top of Crystal Space (see http://cel.sf.net for more info). In CEL we support scripting in various languages (currently C++, Python, and XML are being used but other languages are possible). The idea is that every entity gets a script associated with it (which we call a 'behaviour' in CEL). Every entity also gets a number of property classes which correspond to what that entity can do. For example, if you want to have a 'chest' entity in an adventure game you could have an entity with the following property classes: - pcmesh: for the actual 3D representation of the chest - pcinventory: representing the contents of the chest (containing other entities) - pcgravity: if you want the chest to react to gravity and fall down - pcmeshselect: so a user can select the mesh with his/her mouse - ... Property classes can be created dynamically and thus you can make entities by adding the appropriate functionality to it. Property classes communicate to the script or behaviour by sending messages. For example, the pcinventory property class will send the message 'pcinventory_addchild' when something is added to the inventory. The pcmeshselect property class will send the message 'pcmeshsel_down' if the mouse down button is pressed on the mesh. How the message is translated to the scripting language is up to the plugin that handles the particular scripting language. For example, in python the script is a python class and every message corresponds directly to a method in that class. So if the property class sends 'pcinventory_addchild' then that method will be called in the python script. I have found this system to be very flexible. Greetings, |
|
From: Alen L. <ale...@cr...> - 2004-01-21 11:22:10
|
----- Original Message ----- From: "Dan Thompson" <da...@ar...> > 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. AFAIK, one usual method is to make sure that all "yields" are always on the bottom of the stack so you don't need to keep and store stack for each script. This of course rules out real preemptiveness. But... how do you handle that anyway? Don't you ever get problems with one script being interrupted in the middle of modifying some object and another one accessing that same object in a half-valid state? And having scripts running on a different thread? Do you use some synchronizations when accessing other subsystems from scripts? Alen |
|
From: Dan T. <da...@ar...> - 2004-01-21 21:08:04
|
All engine calls are atomic, so after each call we try to guarantee the validity of an object. Of course, there could be situations where this is not possible, so perhaps the premtive isn't good. However, I couldn't think of any other way to prevent scripts from being able to eat all the processor. The only break we get is since its user level threading, we control exeactly when the preemption occurs. Do people often just make one script stack, and have multiple files running in it? Or one stack per script? -Dan ----- Original Message ----- From: "Alen Ladavac" <ale...@cr...> To: <gam...@li...> Sent: Wednesday, January 21, 2004 4:21 AM Subject: [email] Re: [GD-General] Scripting Systems > > ----- Original Message ----- > From: "Dan Thompson" <da...@ar...> > > 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. > > AFAIK, one usual method is to make sure that all "yields" are always on the > bottom of the stack so you don't need to keep and store stack for each > script. This of course rules out real preemptiveness. But... how do you > handle that anyway? Don't you ever get problems with one script being > interrupted in the middle of modifying some object and another one accessing > that same object in a half-valid state? And having scripts running on a > different thread? Do you use some synchronizations when accessing other > subsystems from scripts? > > Alen > > > > ------------------------------------------------------- > 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: Alen L. <ale...@cr...> - 2004-01-22 07:37:33
|
Well, running it on one stack worked ok for us during last several years, and lot of other people use that. However, I cannot claim which technique is most often. I believe that most people do cooperative instead of preemptive for scripts, and general multithreading is avoided like a plague, unless really necessary (loading in the background, etc.). Just my 0.02$. Alen ----- Original Message ----- From: "Dan Thompson" <da...@ar...> To: <gam...@li...> Sent: Wednesday, January 21, 2004 20:01 Subject: Re: [email] Re: [GD-General] Scripting Systems > All engine calls are atomic, so after each call we try to guarantee the > validity of an object. > > Of course, there could be situations where this is not possible, so perhaps > the premtive isn't good. However, I couldn't think of any other way to > prevent scripts from being able to eat all the processor. > > The only break we get is since its user level threading, we control exeactly > when the preemption occurs. > > Do people often just make one script stack, and have multiple files running > in it? Or one stack per script? > > -Dan > > ----- Original Message ----- > From: "Alen Ladavac" <ale...@cr...> > To: <gam...@li...> > Sent: Wednesday, January 21, 2004 4:21 AM > Subject: [email] Re: [GD-General] Scripting Systems > > > > > > ----- Original Message ----- > > From: "Dan Thompson" <da...@ar...> > > > 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. > > > > AFAIK, one usual method is to make sure that all "yields" are always on > the > > bottom of the stack so you don't need to keep and store stack for each > > script. This of course rules out real preemptiveness. But... how do you > > handle that anyway? Don't you ever get problems with one script being > > interrupted in the middle of modifying some object and another one > accessing > > that same object in a half-valid state? And having scripts running on a > > different thread? Do you use some synchronizations when accessing other > > subsystems from scripts? > > > > Alen > > > > > > > > ------------------------------------------------------- > > 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 > > > > > > ------------------------------------------------------- > 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 > |
×
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