Re: [GD-General] Re: Scripting
Brought to you by:
vexxed72
|
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
|