RE: [GD-General] I just don't get it (Was: Scripting Systems)
Brought to you by:
vexxed72
Menu
▾
▴
RE: [GD-General] I just don't get it (Was: Scripting Systems)
|
From: Lewin, G. <gl...@ea...> - 2004-04-21 15:49:10
|
My thoughts....=20 Sudeki has proven to me that a low level scripting language is probably a bad idea. A lot of the problems on Sudeki are due to the designers not being as technical as we would have hoped, and from what I hear from people that are on the project now, it's still causing problems. So if you are targeting a designer, you really want to give them a higher level language. I would say that python and tcl and friends are even a bit too low level, but that's a gut feeling, not something from experience. I do know that when I worked on point and click adventures all those years ago, our extremely basic scripting language proved to be somewhat more of a success, with designers and "low level" (excuse the term, not sure what the best way to say it is) programmers doing a lot of work very easily. (I can go into more details if anyone is interested) I think the point I want to make is that scripting (for game play scripting) needs to be a sandbox, with not much power, basically holding the designer's hands. Right now if I had time, I would seriously consider trying to write a nice visual scripting language, something similar to what I heard XSI had a few years back. Note, if your scripting language is targeted at the same people that are writing c++ code, then by all means, go ahead with a low level language, but you have to then justify to yourself the use of a scripting language and not just plain code. The option of (for example) using python to prototype stuff and then porting what is needed to c++ in this scenario sounds like a good idea, and seems to be what a lot of people are doing. I can't wait for the next generation of consoles myself. Actually I mainly can't wait until the PS/2 stops being the bread and butter of game developers. Maybe then python will become a much more viable option... _________________________________________ Gareth Lewin - http://www.garethlewin.com "Facts are useless. You can use facts to prove anything that's even remotely true. Facts shmacts!" -- Homer Jay Simpson. -----Original Message----- From: tweety [mailto:mi...@sy...]=20 Sent: Tuesday, April 20, 2004 9:27 PM To: gam...@li... Subject: RE: [GD-General] I just don't get it (Was: Scripting Systems) this is a real thread ressurection, so be amazed! :)) Anyway, have any of you looked at http://www.angelcode.com/angelscript/ ? It's a byte-code interpreted scripting language that mimics c++, including classes and pointers (ok, so you can't move them, but you can use operator*() on them). It's portable, too. ---------------------------------- Peace and love, Tweety mi...@sy... - twe...@us... YahooID: tweety_04_01 -----Original Message----- From: gam...@li... [mailto:gam...@li...] On Behalf Of Garett Bass Sent: February 4, 2004 8:05 AM To: gam...@li... Subject: [GD-General] I just don't get it (Was: Scripting Systems) 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... ------------------------------------------------------- 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=3D557 ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dcli= ck _______________________________________________ Gamedevlists-general mailing list Gam...@li... https://lists.sourceforge.net/lists/listinfo/gamedevlists-general Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=3D557 |
