Re: [GD-General] Scripting

[mike w. <mi...@ub...>]

> 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