As the title suggests this issue has been discussed endless times already, with arguments pro and con raging against each other. So at one hand I can understand that many are tired of the discussions and I apologize for dragging this out in the open once more. Yet I feel I should try one more time to bring together a comprehensive look on the topic of scripting, since the issue - dead horse or not - will stay with us as long as we play TFC.
Definition: Scripting may be defined as any form of automation of one or more commands inside the game by using the game’s own scripting language, used by the console or external configs.
By that definition basically the whole interface between player and game is scripted, since all configuration is done by the scripting language (and can be customized by it). Look at your config.cfg and you will find a script which is executed each time you start a game (in fact executed three times). The config.cfg shows a number of commands which configures game parameters (brightness, game-sound, net-parameters, etc.), hardware-settings (3D-sound, mouse- or joystick-settings, etc.) and controls (mouse- & keyboard-buttons).
For the sake of this discussion let us classify four different kinds of uses for scripting:
1) Configuration-scripts: Changing of game-settings
2) Communication-scripts: Predefined Communication-lines
3) Action scripts, this once again broke down into:
- a) Single Action
- b) Multiple Actions
Before we go into details allow me to take you on a trip into the past, as IMO scripting in TFC cannot be discussed without taking a closer look at the roots it derived from. So let me introduce you to Quake and it’s most prominent MOD, TeamFortress.
Quake was basically designed with DOS in mind. While Windows95 had been released already Quake was very much developed as a DOS-game. Many DOS applications used cfg- or ini-files to store settings, since there was no central file, like today’s registry of Win9x or NT/XP, to store 3rd party information. Also was DOS strictly a single-task-OS. You couldn’t load two programs at the same time. So any kind of setup/config-program had to be run either separately or to be integrated into the game (DOOM, for example, had a separate setup-program, while Quake integrated the setup into the game).
Quake offered a certain degree of customization for the player. He could assign arbitrary keyboard-buttons for actions or change his name or skin for deathmatch within the game. To make this possible id had to define such parameters and to change/store them on the fly. This seems quite obvious, but it wasn’t in those days. But id went one step further, heck, actually they went two steps further. They based many parameters in the game on commands which could be called separately and they created an interface to that command-area - the console - basically creating a commandline inside the game. This might seem so obvious today, as many games sport such an interface these days (and many still feature this - by now rather old-fashioned - commandline interface), but it was revolutionary back then. I don’t know if any other game used such a console before, for me Quake was the first game I saw offering one.
Suddenly it was possible to change a lot of settings without even leaving the game. You could alter key-configurations, your player-name or load a new map within the game.
Fast forward to the MODs and to TF
This command-structure and the possibility to define ’impulse’-commands to execute separately programmed actions which then could be used in the game was a very important tool for the MOD-scene to create custom MODs. With that it was possible to create new items which could be used in the respective MOD. In the case of TF there were a number of items which were developed for TF while not having a counterpart in the original Quake, like the scanner or even the grenades.
But there was a flaw in the design. Since a MOD was loaded just as a modification of Quake it had to use Quake’s interface. But the customizing-section of Quake offered no settings for new items, like using the scanner or grenades (because Quake itself didn’t had them). The commands of priming and throwing a grenade were there, but you had to assign them to a key to use them. You could do that in the console. However, Quake’s scripting language offered another neat feature: You could load external config-files from the console. And since almost every command which worked in the console could be used in configs it also meant you could load config-files from within another config-file. So instead of having to reassign the same keys every time you simply stored your personal configuration in a config-file.
The next logical step was to create different configs to use with the different classes (since each class carried different weapons and had different special abilities). And with time people created more elaborate scripts to adept the game to their needs and purposes. It also introduced the possibility to automate a sequence of commands to perform certain actions.
Another fast forward. Half-Life is created by Valve, using portions of the Q1 and Q2 engine. One thing they adopt is the scripting language and the console. Both are fully implemented, though access to the console was initially disabled (if I recall correctly there was no option to access the console without enabling it in the HL commandline, the ’console’-option in the game options was added later, I think). When TFC is released in April 1999 it makes full use of the scripting language, offering customizable configs for all classes and maps, which would be loaded automatically, plus another two user-customizable configs which would be loaded automatically when present (autoexec and mapdefault). Actually the valve.rc file is also a config-file which autoexecutes. All this excluding the config.cfg which initially was just designed as a temp-config to store your recent configuration data.
In these configs - once again - basically all commands of the scripting language could be executed and just as in TF one config-file could load other config-files. No major changes had been made to scripting when Valve ported TF to TFC.
Okay, after that history lesson let’s get back to the initial discussion.
Scripting - as defined above - is an essential and necessary feature of TFC. Basically all customization is done by scripts, the configs for maps and classes are scripts and the VGUI, introduced by TF1.5, is also a script. So the discussion if scripting in general is good or bad is actually pointless, since it is an integral part of the game. In fact the discussion is rather revolving around the question (or ethics) of the use of scripts, or more precisely which scripts, or part of scripts should be used.
At this point it makes sense to come back to the different types of scripts I distinguished above.
Configuration: Usually nobody has a problem with using scripts to change game-settings.
Communication: Same here. Communication scripts, even the most complex ones, are widely accepted, which IMO is odd. But more on that later,
Action: Well, I guess nobody would argue against single-actions, since the game is mainly based on that way of configuration. The most criticized uses for scripting, however, is the scripting of multiple actions to be performed automatically.
The line of argument of scripting-opponents is basically that such a script is enabling its user to perform a more complex kind of action(s) with pressing a single button. Depending on the respective action performed those scripts are looked at either being cheap or cheating. We will have to discuss the issue of cheating through scripts more thoroughly later.
Now the range of such multiple-actions-scripts is rather broad. By that definition a number of regular commands are already in question. Each +command/-command is already a multiple-action command (replacing that by normal means would require at least 4 commands). So the sniper’s special ability (zooming) is already a multiple action script. Same goes for priming and throwing a grenade (even if you use two separates keys, which is not the default).
So we have the problem that we either discuss integrated multiple-action scripts (created by Valve) vs. customized multiple-action scripts or ’bad’ multiple-action scripts vs. ’good’ multiple-action scripts. But frankly I tend towards a third interpretation, but I will come to that later.
Let’s look at the first: Integrated multiple-action scripts (created by Valve) vs. customized multiple-action scripts.
So basically all multiple-action-scripts not created by Valve would be bad. That goes along the line ’everything not explicitly allowed is permitted’. While this would be a legit approach one has to ask ’why’? If Valve would not want scripting at such an extent why do they enable the player to do so? Why does Valve keep such a wide range of commands accessible to the user, including such basic movement-commands? If Valve had any reservations on scripting they could have easily reduced the number of commands available. They could have limited scripting severely during the last 3 years of TFC. So there is no indication that Valve has any problems with multiple-action-scripts. In past interviews with Valve employees I never read a single negative comment on user-scripting, quite contrary there were thoughts on integrating more multiple-action scripts (Rocketjump) into the game. And I might add that I participated on the beta-test for the TF1.5 patch and never heard any negative remark on scripting during those tests.
So when one accepts that Valve has no reservations on scripting all that remains is an ethical discussion of ’good’ vs. ’bad’ scripts. Problem is of course, that this is a highly subjective discussion. Using the ’zoom’-command (fov) for any class other than the sniper is usually a very controversial topic. This isn’t even a ’multiple-action’-issue, yet is a good example for the different approach of both sides to the general discussion. The opponents argue that the sniper is the only class which has the ability to zoom in by default. So any other class using zoom would use an ability not originally intended for it. The supporters however argue that the command is implemented and accessible, so it might be used by each class. Or to put it the other way around: If Valve had intended to the sniper to be the only class to zoom why did they not modify the command in a way that it would work exclusively for the sniper (like ’disguise’ or ’build’, which only works for the spy/engy)?
Actually I can accept both sides’ arguments for an ethical discussion in general, but it makes no sense to argue that using fov would be an abuse of the scripting language.
Let’s move to a more appropriate example of this discussion: Rocketjumps.
The opponents argue that a RJ-script would enable its user to perform an action (combined of multiple single actions) with pressing a single button. They also argue that this enables the scripts user to perform an action he might not be able to perform manually.
It’s important to separate those to arguments, since they point in different directions!
The first argument is flawed, since the script does nothing which could not be done manually pretty much the same way (quite contrary there’s a common consensus that a manual RJ is superior to a scripted one). So for the game it makes no difference if the RJ was done manually or scripted since the result is (basically) the same. It makes no sense at all to criticize the method by equal result. Either one accepts RJ’s in general or not, but for the game it doesn’t matter by which means the jump was achieved.
More interesting is the notion that scripting would enable a player to perform actions beyond his manual skills. At that point we introduce a completely different subject to the discussion: The subject of technics (supposedly) replacing skill. This actually has nothing to do with an ethical discussion about scripting, it is rather a basic discussion about the game, and the perception of the game and the gamer.
That’s a good point to pick up a few loose ends.
During most discussions I was under the impression that most opponents to multiple-action(MA)-scripts have no reservations at all against complex communication scripts. At first glance that doesn’t make sense. When you insist on playing the game in the most ’purely’ way you would have to condemn comm-scripts just as much as RJ-scripts and the like. TFC initially didn’t came with any kind of communication. It wasn’t until TF1.5 that TFC featured some (basic) predefined messages. And even today not all Valve-maps are covered by those messages (e.g. Avanti, Crossover). So I could argue that a ’purist’ would have to type all messages by hand (or use simple binded messages at best), most definitely he would have to argue against the use of complex comm-scripts. But the MA-opponents don’t.
And the reason is quite simple: Comm-scripts have nothing to do with personal skill! On the most basic level of gaming they don’t affect the display of personal gaming skill. In that regard it makes sense that those people oppose scripted RJ since it blurs the (possible) skill difference between those doing them manually (which requires skill) and those using scripts (which requires no skill).
Those people want the personal skill of a player being projected on his playing as closely as possible.
IMO that’s the aforementioned third interpretation on the ’anti-script’-party of this whole scripting discussion. It is absolutely secondary if a script is legit or not, as long as it doesn’t impair the display of personal skill.
It was often referred to that those scripts would ’play the game for you’. This notion - being absolutely silly to begin with, since I have yet to see a script which would play the game for me - makes only sense in light of that. It neglects the value of tactical thinking, of group strategy or the value of communication and reduces the game to its simple roots as a deathmatch game.
IMO there’s a major misconception on games like TFC. Certain people tend to compare playing a game like TFC with being an athlete, or players in a sport like soccer or football. They construct a direct relation between their personal (in an abstract way ’physical’) abilities to their effect inside the game. This comparison is wrong!
A better comparison would be with a racing driver (or similar). Between the computer gamer and his game is a medium: the computer, just like a racing driver needs his car for a race. A racing driver is not exclusively defined by his personal attributes, but as well by the way he interacts with his car and - of course - by the car itself. A purist would have to insist that everybody drives exactly the same car, so that the personal skill reflects most accurately on the course of a race. But if you look at racing you will find that exactly that isn’t true. There are certain regulations to prevent a driver of having an unfair advantage (in other words: cheating), but in the borders of those specs each car can be modified to serve the needs of the driver. All that without regards on the skills of a driver. He will adapt his car to support and increase his skills, but his skills are not defined by the car. And those skills are very much different from those of a athlet or football player, since he has to use his skill through the medium of his car.
To make a very clumsy comparison to RJ-scripts: If a driver would decide to use an automatic instead of gears (or whatever it’s called 
there would be nothing wrong with that. It would not reflect on his skill as a driver, it would only affect certain aspects of his driving. And obviously it would not run the race for him 
Your computer is just a tool you use to play the game. Your configuration is just a tool. Scripting is also just a tool. A tool doesn’t define your skill, it’s your skill using the tool to its maximum effect.
I should not end this editorial without making a short comment on the problem of cheating. As soon as a script is performing an action which could not duplicated manually we are entering a gray area ultimately leading to cheating. In that regard using fov is not cheating since it can be done via the console anyway. On the other hand a RJ-script which actually allows you to ’look down’ at an angle that you effectively look behind you so you are propelled forward instead upwards is very questionable (to put it mildly). The ethics of single scripts can be - and should be - questioned and discussed to determine if it is cheating or not. But that has to be decided for each single incident, it doesn’t reflect on scripting in general.
If you like dead horses you can discuss this editorial here on the PF forums 
RSS 2.0