Editing QuakeC (section)

== Limitations and subsequent solutions ==
The [[syntax]] of QuakeC is based on that of the [[C (programming language)|C 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

:<code>SomeFunction (ftos (num1), ftos (num2));</code>

will fail because the second call to <code>ftos</code> (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++ and [[compiler|compiled]] into the executable, which is faster. However, this makes it harder for the community to create [[Mod (computer gaming)|mods]] and it makes the process of [[porting]] the game to another platform (such as [[Linux]]) more costly.

Despite its advantages, the choice of implementing game logic using a custom scripting language and [[Interpreter (computing)|interpreter]] was dropped from the next generation [[Quake II engine]] in favor of compiled [[C (programming language)|C]] code due to the overall inflexibility of QuakeC, the increasingly complex game logic, the performance to be gained by packaging game logic into a native [[dynamic link library]], and the advantage of leveraging an already established programming language's community, tools, educational materials, and documentation.<ref>{{cite web |last=Carmack |first=John |author-link=John Carmack |title=Here is a technical issue to be discussed, Pg.18 |url=http://fabiensanglard.net/fd_proxy/doom3/pdfs/johnc-plan_1997.pdf#page=19 |date=13 March 1997 |work=[[.plan]] |publisher=[[id Software]] |access-date=5 November 2018}}</ref>

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 complicated [[Integrated development environment|programming environment]]. The eventual solution, implemented by the [[Quake III engine]], was to combine the advantages of original QuakeC with the advantages of compiling C to native code. [[LCC (compiler)|LCC]] was extended to compile standard C into bytecode, which could be interpreted by a [[virtual 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.<ref>{{cite web |last=Carmack |first=John |author-link=John Carmack |title=Jul 24, 1999, Pg.54 |url=http://fabiensanglard.net/fd_proxy/doom3/pdfs/johnc-plan_1999.pdf#page=54 |date=24 July 1999 |work=[[.plan]] |publisher=[[id Software]] |access-date=5 November 2018}}</ref>