RE: [GD-General] Scripting

[Jamie F. <ja...@qu...>]

i think one key point that hasn't been touched on (enough? :) yet is that
the scripting language (whether data definition, a full language, or
whatever) should be appropriate to the people who will use it.

some designers can think like a coder. some can't. similarly with artists.
if you pitch the scripting at the appropriate level, it will work great.
this is my main complaint with generic scripting systems: they've been
designed at a particular level of complexity, and that simply can't be
appropriate for every user.

jamie


-----Original Message-----
From: gam...@li...
[mailto:gam...@li...]On Behalf Of
mike wuetherick
Sent: 10 December 2002 03:55
To: gam...@li...
Subject: Re: [GD-General] Scripting


> My instinct is that a scripting language as an "extension" (vs. "as
> data") seems ill advised at times, because you kind of have
> responsibilities that are mixed and often poorly defined.  Using it as
> your primary application language means it's no longer "scripting", it's
> just the language you happen to be developing in and you're now calling
> into a separate native engine for system specific tasks.  That seems
> completely reasonable if you feel the language itself is much more
> productive than C or C++ or whatever.

good point, didn't see the difference initially.

the way things have worked generally is that they start out as simple
'entities' (which are simple structs that have custom pragmas that the
editor recognizes, providing public and private data for this particular
entity (private data is used by the game engine on runtime, public is
exposed to the level designer as the entities properties) that the designer
can drop into their levels (lights, etc) and if the complexity of the
feature becomes too unwieldy to edit via entities (as adding many of a
similar entity can become), then that functionality is moved into scripting.

for example, the players in-game actions are currently read in via an ini
file - there are basic 'set' actions that the player can do, essentially a
reference to an animation & that's about it.  this is being updated to
provide links to scripts (or functions within one) that will allow for more
complicated actions (all custom-created by the designer without needing to
recompile the engine) such as special moves, animated camera motions during
specific in-game actions (pull off a special finishing move & trigger a
flyby camera sequence), etc...

of course, certain features are scriptable by default as well, and anything
simpler is left as entities.  the combinations seems to work well & provides
an extremely good range of possiblities for the designer.

cheers,

mike w
www.uber-geek.ca



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Gamedevlists-general mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_id=557