RE: [GD-General] Re: Scripting

[Awen L. <ali...@ed...>]

On our current grame, we are NOT using scripts (and when i read Evan Bell
post, i believe we're doing the same kind of... anyway :)).
I am really upset with that decision, (i suspect some
nonsense-but-historical reasons) but it's not a thing you shake at this
point of the project. Ok.
Let's assume we're an average team, with average design and technical
skills:
An average scripting engine introduces generally some high concepts like:
MoveTo(X,Y) PlayAnimation('A'), actorW.IsHearing(actorZ). And remember we
are not using such. So:
1) Our non scripted engine requires a programmer to code an actor. Yes.
2) The simplest functionnality-calls of an actor, requires 3 code lines (a
programmer is NOT disturbed by that: 3 or 10 code line is *EASY* to handle).
3) The actor process is supervised by the programmer (logical), so
aggregating resources, ensuring that all will work, is really really
PAINFUL. But our programmers ignores the pain. Programmers have brain
connections to slalom between difficulties (it's somewhat faster than
resolving them)
4) Bad, obscure, trickery is so ALLOWED in an actor behavior code (C++) 'Ok,
easy boy, C++ is my wisdom'

Results:
	Modifying an actor behavior is a LONG process because of reasons 1 to 4
(theorem: many little resolvable-on-the-fly troubles equal long processes).
You can't just 'modify an actor'; you'll need a meeting with:
	- a game designer (*)
	- a project lead  (*)
	- a lead code (*)
	- the programmer
(*) think salary.
Meetings equal meeting reports, equal report availabilities by mail mail to
the team, WHICH IS LONGER TO WRITE THAN THE REQUIRED BEHAVIOR SCRIPT.

Programming is usually a slow process (see HalfLife's PostMortem), and
nobody will scratch its head regarding the time it takes to code a behavior.
It'll become the standard.
But from a planning point of view, it's a real 'wanna-be' overkill.
But from a game point of view, i suspect that the lack of fun in creating an
actor is causing heavy damages to the final product.

So you must really really think about it before throwing one of the other
solution. Please (yes i beg !).

Awen






-----Message d'origine-----
De : gam...@li...
[mailto:gam...@li...]De la part de
brian hook
Envoyé : dimanche 8 décembre 2002 08:56
À : gam...@li...
Objet : Re: [GD-General] Re: Scripting


> It is more like "glue"....The designers use the scripting language
> functions just like public interfaces to game objects.

Does this mean then that you're only using it to provide coding-like
functionality to the designers without requiring them to actually write
code or harass programmers?

> SetPlatformDestination( 'BigFloatingRock', GetMarkerPos
>( 'CenterMarker01' ), 1.0 );

Right, this kind of gets back to the example me and Thatcher were
using -- instead of a "function call" interface, a data description
interface could probably do the same thing without actually requiring
there to be language constructs:

PlatformXYZ =
{
   type = 'platform',
   destination = 'BigFloatingRock',
   pos = 'CenterMarker01',
   value = 1.0
}

> The main problem we have is the designers request the ability to do
> more and more complicated tasks with the scripting language, but do
> not enjoy the requisite increase in script complexity.

Two issues here.  The first is exactly one of the concerns I have with
generalized scripting -- there is a tendency for the entire engine to
become part of the scripting language as designers ask for more and
more stuff.  The second is that you often get a lot of exposed
facilities that are never taken advantage of and, conversely, a lot of
simple features end up getting (ab)used in interesting ways to get
specific types of output.  For example, in Quake3 there were "regen"
fields that were created when one of the designers realized you could
assign a negative value to a pain field.

> To avoid creating Yet Another Crappy Parser I used flex & bison to do
> the hard work of creating the script compiler.

Eewww.  I'm leaning towards just using Lua as my syntax for, er,
everything, and letting it handle the heavy lifting.

-Hook


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