| QuakeC | |
|---|---|
| Paradigm | imperative (procedural),structured |
| Designed by | John Carmack |
| Developer | id Software |
| First appeared | 1996 |
| Typing discipline | static,strong |
| Filename extensions | .qc |
| Majorimplementations | |
| Quake C Compiler, FastQCC, FTEQCC, QCCx, GMQCC | |
| Influenced by | |
| C | |
QuakeC is acompiled language developed in 1996 byJohn Carmack ofid Software to program parts of thevideo gameQuake. Using QuakeC, a programmer is able to customizeQuake to great extents by adding weapons, changing game logic and physics, and programming complex scenarios. It can be used to control many aspects of the game itself, such as parts of the AI, triggers, or changes in the level. TheQuake engine was the onlygame engine to use QuakeC. Following engines usedDLL game modules for customization written inC, andC++ fromid Tech 4 on.
The QuakeC source to the originalid SoftwareQuake game logic was published in 1996 and used as the basis for modifications likecapture the flag and others.[1] QuakeC source code is compiled using a tool calledqcc into abytecode kept in a file calledprogs.dat. The programmers ofQuake modifications could then publish theirprogs.dat bytecode without revealing theirsource code. MostQuake mods were published this way.
QuakeC allowed theQuake engine to dominate the direction of thefirst-person shooter genre.[citation needed] Thanks to Carmack's idea of extending video game life by adding unlimited expandability (extensibility already played a big role inDoom), an enormous Internet community of gamers and programmers alike has arisen and many modern multiplayer games are extensible in some form.[citation needed]
QuakeC is known as interpreted because asQuake runs, it is continually interpreting the progs.dat file.[2]
Thesyntax of QuakeC is based on that of theC programming language, explaining its name, but it does not support the implementation of new types, structures, arrays, or any kind of referencing other than the "entity" type (which is always a reference). QuakeC also suffers from the fact that many built-in functions (functions prototyped in the QuakeC code but actually defined within the game engine and written in C) return strings in a temporary string buffer, which can only hold one string at any given time. In other words, a construct such as
SomeFunction (ftos (num1), ftos (num2));will fail because the second call toftos (which converts a floating-point value to a string) overwrites the string returned by the first call before SomeFunction can do something with it. QuakeC does not contain any string handling functions or file handling functions, which were simply not needed by the original game.
Most video games at the time had their game logic written in plain C/C++ andcompiled into the executable, which is faster. However, this makes it harder for the community to createmods and it makes the process ofporting the game to another platform (such asLinux) more costly.
Despite its advantages, the choice of implementing game logic using a custom scripting language andinterpreter was dropped from the next generationQuake II engine in favor of compiledC code due to the overall inflexibility of QuakeC, the increasingly complex game logic, the performance to be gained by packaging game logic into a nativedynamic link library, and the advantage of leveraging an already established programming language's community, tools, educational materials, and documentation.[3]
Distributing native code created new security and portability concerns. QuakeC bytecode afforded little opportunity for mischief, while native code has access to the whole machine. QuakeC bytecode also worked on any machine that could run Quake. Compiling to native code added an additional barrier to entry for novice mod developers, because they were being asked to set up a more complicatedprogramming environment. The eventual solution, implemented by theQuake III engine, was to combine the advantages of original QuakeC with the advantages of compiling C to native code.LCC was extended to compile standard C into bytecode, which could be interpreted by avirtual machine in a manner similar to QuakeC. This addressed the security, portability, and tool chain problems, but lost the performance advantage of native code. That was solved by further compiling the bytecode into native code at run time on supported machines.[4]
A decompiler and a recompiler were released byArmin Rigo (calledDEACC andREACC respectively). These programs were made through the process ofreverse engineering, and were most likely published before the release ofqcc.[5]
id Software released the source ofqcc, their QuakeC compiler, along with the original QuakeC code in 1996. Modified versions soon sprung up, including Jonathan Roy'sfastqcc and Ryan "FrikaC" Smith'sFrikQCC. These added functionality, optimizations, and compiling speed boosts.
In 1999, when id Software released the code from Quake's engine under theGNU General Public License (GPL), the workings of the bytecode interpreter were examined and new QuakeC compilers were released, such as J.P. Grossman'sqccx and a new version of FrikQCC. These compilers took advantage of newly discovered features in a backwards-compatible way so that the bytecode could still be properly interpreted by unmodified Quake engines. New features include arrays, pointers, integers, for loops and string manipulation.
With theQuake engine source code now able to be changed, further features were added to QuakeC in the form of new built-in functions. Features long yearned for by QuakeC coders finally reached realization as QuakeC now had file and string handling functions, enlarged string buffers, more math functions, and so on. However, programmers taking advantage of these changes lost backwards compatibility with the unmodified Quake engine.
Xonotic since version 0.7 uses thegmqcc compiler.[6]
Some enhancedQuake engines (notablyDarkPlaces and FTEQW)[clarification needed] have support for an extension of regular QuakeC (now commonly referred to as server-side QuakeC) that allows client-side-only scripting of theQuake engine, also abbreviated as CSQC (client-side QuakeC). This is especially useful for GUIs, HUDs[clarification needed] and any visually heavy effects that do not need to be simulated on the server and transferred over the network.[7]
