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 |