Thread: Re: [GD-General] Re: Scripting
Brought to you by:
vexxed72
Menu
▾
▴
gamedevlists-general
|
From: brian h. <bri...@py...> - 2002-12-08 07:56:02
|
> 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
|
|
From: Awen L. <ali...@ed...> - 2002-12-09 10:43:40
|
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
|
|
From: Colin F. <cp...@ea...> - 2002-12-09 13:40:39
|
2002 December 9th
Monday
>>> 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.
Maybe the horror scenario you are describing is mostly
a problem with how your project is managed, and not so
much about how scripting is better than compiled code
for some aspects of the game.
As far as consulting the game designer when you modify
an actor's actions, how could this be avoided?
If your organization designated a person to design the
game, then any effort to avoid consulting the game
designer when making changes to the game experience
is sabotage. In fact, unless there is an explicit
agreement within the team that people have freedom
to "enhance" or elaborate on game elements specified
by the game designer, then changes should only come
about by initiative of the game designer. I think
your team might need to explicitly discuss and decide
the degree to which each individual developer can
make creative decisions about the game without
consulting the game designer.
The project lead is not the game designer.
If the project lead needs to be consulted about
game design decisions, this is a serious problem.
Sure, the game designer may require legal advice
or general content advice from the project lead,
but if the project lead, or publisher, or
marketing, or the president of your game company
is telling an artist or game designer to
change dialog or the plot of the game, then
you damage the fidelity of the game design
and you have the big meetings so that everyone
can do the game designer's job.
Is it draconian to have a game designer
designing the game? No! That's his or her job!
If a programmer on the team happens to also have
game design talent, then he or she can propose
changes to the designated game designer.
Presumably, one hires a game designer based on
a record or promise of good final game designs,
and even if the game designer refuses to listen
to outside input (which I doubt would ever happen),
this is irrelevant; the past performance of a
game designer validates his or her methods.
If a programmer feels like his or her game
design ideas are falling on deaf ears too often,
then maybe the programmer should consider seeking
a game design position. If one feels very
passionate about design aspects of the game,
and the game designer refuses to listen or change
the design, then either the designer really does
know better about what will make the best final product,
or the company made a mistake when it hired the
game designer. Requiring the game designer to
give team members some freedom to improvise is
not the solution.
I really don't see why the lead programmer is
involved at all in the scenario you describe.
The lead programmer breaks up the coding
requirements in to small coding tasks,
schedules the tasks in a timeline, and assigns
tasks to programmers according to their
skills and expertise. The lead programmer
should explicitly define programming standards
for the team -- and make announcements about
general programming issues as the project
evolves (like "patch your compiler to 4.0",
or "avoid using the function foobar()").
So, the lead programmer gives the task
"implement cut-scene scripting" to a programmer,
perhaps referring to specific items in the
game design document. There should be no
need to consult the lead programmer for
any aspect of this programming task.
If consultations are necessary, then either
the lead programmer failed to define general
programming standards at the outset of the
project, or the junior programmer doesn't
have sufficient qualifications.
Arguments about scripting allowing cheaper labor
to perform tasks are not convincing. The task
will be completed in a shorter time, and with
fewer errors, when it is performed by a person
with greater skill at the task. When you give
a task to a junior programmer or to an artist with
no programming skill, the only possible benefit
is that you might free up a person who has unique
skills or expertise necessary to complete other
tasks. If you have too much C++ "script" programming
for your programming team, hire a new programmer
to do C++ "script" programming -- and there's
no reason why this programmer shouldn't have
tons of experience and demand a high salary.
The idea of somehow turning programming in to
a kind of non-programming is pure illusion!
Scripting is programming! If you dumb it down,
you're just dumbing it down and limiting
the potential, which is fine, but should be
recognized for what it is.
To summarize, I think your woes are caused by a
lack of clear division of responsibilities in your
company, and a lack of policies to make communication
efficient. Team members need roles and authority,
and meetings should be easy to initiate, only involve
relevant people, and should stay focused and end
when the matter has been decided. With defined
authority, a person will automatically know when
there is a matter that requires a meeting -- or
a quick e-mail, phone call, or shouting across
the room!
I'm not bashing scripting (no pun intended), but
if a "dumb worker drone" working with blissful,
cheap efficiency on a script runs in to a problem,
like needing a feature that cannot be expressed
in the scripting language, then this will lead
to MORE trouble than the programmer working in
native C++ who runs in to the same problem.
I'll end this by agreeing with you at some level:
scripting has its benefits. If you have a subsystem
in a game that is fun to modify, and has relatively
simple operations with simple execution control,
then scripting is cool. I like the idea of scripting
menu stuff, character ("actor") actions, and some
high-level actions taken by game objects. I think
frequent need for simple modifications, or your
desire to open up the game to end-users, are strong
justifications for supporting some kind of scripting
(e.g., Javascript, small C) or parsing (e.g., XML).
Hee, hee! I was going to say that I was an opinionated
jerk for writing all of this nonsense, but then I worried
that somehow this would be a form of passive-aggression
or projection -- like saying that everyone out there
with an opinion was a jerk...Or was it that the
Apollo moon landings never occurred? I don't know. I took
Psychology 101 about 10 years ago, and the only thing
I remember about that class was all of the sexy,
mysterious, complicated, analytical young ladies
who were the teaching assistants. Okay, that and
something about bells ringing and dogs drooling.
Oh, and left-handed mothers flashing images of ink
splotches resembling food pellets through electrodes
attached only to the right hemisphere of a cat's
brain in a jar filled with hallucinogenic drugs...
Wait, did that really happen?
-- Colin
cp...@ea...
www.colinfahey.com
|
|
From: Awen L. <ali...@ed...> - 2002-12-09 15:36:10
|
The real horror is this:
Colin, you're just right about that crap: you know it, i know it, and maybe
the 2 or 3 of us at the studio, probing mailing lists, are now scratching
their heads after reading you ('damn, if he was right...').
But it happens: i were just writing about side-effects of such a decision
along time (no way ! no script ! programmers are the best !): it's only
another illustration of some 'chaos theory'... (busted you, butterfly !).
Living in a perfect world with perfect people is a quite different
discussion, i would like to have... sigh... just 59 other people to convince
:-P
Awen
PS: Colin is right telling that this way of (not) scripting is dumb. So are
bad implementations (the human part of it) of scripting engine...
Hold on Brian, don't despair, maybe try again !?
|
|
From: Javier A. <ja...@py...> - 2002-12-09 11:56:40
|
brian hook <bri...@py...> wrote: >> SetPlatformDestination( 'BigFloatingRock', GetMarkerPos >> ( 'CenterMarker01' ), 1.0 ); For what is worth, in Praetorians we rolled our own scripting language, and it has been a great productivity tool for our designers. The language is designed around the use we wanted for it, doesn't contain loops, functions or high-level types (arrays, structs). Scripts are pretty much a series of calls to engine-published functions, with condition checking and variable assignments here and there. It Just Works. One of our designers was hired about a year ago. He had never touched a computer. He has had no trouble writing scripts, and has been able to tailor the flow of his missions without much problems. Whenever he needed some kind of higher-level functionality he would request the programmers to add it, but the task of the script was to sequence and parameterize the mission flow. Javier Arevalo Pyro Studios |
Thanks for helping keep SourceForge clean.
X