Re: I just don't get it (Was: Scripting Systems)

Hi Garett,

I somewhat agree with you. I think that the only real excuse to use a 
scripting language for all the game logic is portability, specially if 
you are targeting the mod community. However, if you design your 
language from scratch you can also add special features that ease the 
development of the scripts, for example, quakec provided a mechanism to 
specify state machines and animations, and unrealscript also has state 
machines and other nice features.

In most cases I think that a scripting languages are overrated. However, 
that doesn't mean that scripting languages shouldn't be useful for 
games, it's just that I don't see the need to code all the game logic 
using a scripting language.

You can expose events and object properties to the script, to customize 
some game situations or entity behaviours, the same way you use 
javascript to add simple dynamic content to a webpage. And you can also 
use it to define state machines, or scripted sequences, but not for all 
the game logic/ai.

I think that it would be a good idea to mimic javascript Document Object 
Model (DOM) where a set (or hierarchy) of objects is exposed to the 
script and those objects are coded natively in C++ implementing 
IDispatch or using any other kind of reflection mechanism.


-- 
Ignacio Castaño
[email protected]



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:
> 
> 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
> [email protected]



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