Re: [GD-General] Scripting

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

absolutely.

we've (somewhat/maybe/hopefully) managed to isolate the scripting side of
things with the workflow in our engine by providing the 'entities' as i
described below for the 'artists' on the team - even artists can hopefully
understand placing lights, effects, etc as entities in the world, most 3d
programs have similar concepts for placing lights & behaviors...

this way the scripts are something that the artist simply needs to 'attach'
to the entity as opposed to code from scratch.  the 'non-programming
designer-type' might never even need to see the scripts, they just know that
adding a pawn to their level & attaching the 'badguy1.s' script, they get
the desired result after recompiling their level (which if the designer is
only compiling the entities only takes seconds usually).

many of the core scripts start out being written by the 'programmer-types'
on the team - they are usually testing new features/functions that have been
implemented, as well as providing 'examples' for the rest of the designers
to modify or use as a starting point for their own custom implementations.

the beauty of it is that creating or modifying scripts doesn't actually need
the attention of a 'C++' programmer, anyone that has done basic programming
can modify or extend the 'base' scripts that the programmers have provided.
this saves us from having programmers create the cinematics scripts or
in-game NPC scripts - in other words doing jobs that should be left to the
designers & artists.

someone asked if anyone has created a main engine core that doesn't need to
be modified or recompiled and is fully scripted for all gameplay code - this
is basically what we have done.

i think this is a decision that should be made for several reasons, one of
which is details in the 'Big Orange Book' (game architecture & design) about
how each department of your project team should be responsible to the other
almost as they would external clients.

meaning that the programmers provide documentation for their releases,
provide reasonable examples & samples of how to implement the various
features.  in turn the designers provide detailed 'use cases' that help the
programmers implement the various features.  cycle ad nauseum.

instead of being teams that 'work against each other' as programmers &
artists seem to naturally, you create defined boundaries & expectations for
your work.  the programmers work should not be affected by the designers,
and vice versa, yet allowing for concrete lines of communication...

(who said that everything ends up being about management? ;)

cheers,

mike w
www.uber-geek.ca


----- Original Message -----
From: "Jamie Fowlston" <ja...@qu...>
To: <gam...@li...>
Sent: Tuesday, December 10, 2002 5:30 AM
Subject: RE: [GD-General] Scripting


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