QuakeC es un lenguaje compilado desarrollado en 1996 por John Carmack de id Software para programar partes del videojuego Quake . Mediante QuakeC, un programador puede personalizar Quake en gran medida añadiendo armas, modificando la lógica y la física del juego, y programando escenarios complejos. Se puede utilizar para controlar muchos aspectos del juego, como partes de la IA, activadores o cambios de nivel. El motor de Quake fue el único motor de juego que utilizó QuakeC. Los motores posteriores utilizaron módulos de juego DLL para la personalización, escritos en C y C++ a partir de id Tech 4 .
Descripción general
El código fuente de QuakeC, la lógica del juego original Quake de id Software, se publicó en 1996 y se utilizó como base para modificaciones como Capture the Flag y otras. [ 1 ] El código fuente de QuakeC se compila mediante una herramienta llamada qcc en un código de bytes almacenado en un archivo llamado progs.dat . Los programadores de modificaciones de Quake podían publicar su código de bytes progs.dat sin revelar su código fuente . La mayoría de los mods de Quake se publicaron de esta manera.
QuakeC se conoce como interpretado porque, mientras Quake se ejecuta, interpreta continuamente el archivo progs.dat. [ 2 ]
Limitaciones y soluciones subsiguientes
La sintaxis de QuakeC se basa en la del lenguaje de programación C , lo que explica su nombre, pero no admite la implementación de nuevos tipos, estructuras, matrices ni ningún tipo de referencia que no sea el tipo "entidad" (que siempre es una referencia). QuakeC también sufre del hecho de que muchas funciones integradas (funciones prototipadas en el código de QuakeC pero definidas en realidad dentro del motor del juego y escritas en C) devuelven cadenas en un búfer de cadena temporal, que solo puede contener una cadena a la vez. En otras palabras, una construcción como
SomeFunction (ftos (num1), ftos (num2));
Fallará porque la segunda llamada a ftos(que convierte un valor de punto flotante a una cadena) sobrescribe la cadena devuelta por la primera llamada antes de que SomeFunction pueda hacer algo con ella. QuakeC no contiene ninguna función de manejo de cadenas ni de archivos, ya que el juego original simplemente no las necesitaba.
La mayoría de los videojuegos de la época tenían su lógica de juego escrita en C/C++ puro y compilada en un ejecutable, lo que resultaba más rápido. Sin embargo, esto dificultaba la creación de mods por parte de la comunidad y encarecía el proceso de portar el juego a otra plataforma (como Linux ).
A pesar de sus ventajas, la opción de implementar la lógica del juego utilizando un lenguaje de scripting e intérprete personalizados se descartó del motor Quake II de próxima generación en favor del código C compilado debido a la inflexibilidad general de QuakeC, la lógica del juego cada vez más compleja, el rendimiento que se obtendría al empaquetar la lógica del juego en una biblioteca de enlace dinámico nativa y la ventaja de aprovechar la comunidad, las herramientas, los materiales educativos y la documentación de un lenguaje de programación ya establecido. [ 3 ]
La distribución de código nativo generó nuevas preocupaciones de seguridad y portabilidad. El bytecode de QuakeC ofrecía pocas oportunidades para manipulaciones, mientras que el código nativo tenía acceso a toda la máquina. El bytecode de QuakeC también funcionaba en cualquier máquina que pudiera ejecutar Quake. La compilación a código nativo añadió una barrera de entrada adicional para los desarrolladores de mods novatos, ya que se les pedía que configuraran un entorno de programación más complejo . La solución final, implementada por el motor de Quake III , fue combinar las ventajas del QuakeC original con las ventajas de compilar C a código nativo. LCC se extendió para compilar C estándar a bytecode, que podía ser interpretado por una máquina virtual de manera similar a QuakeC. Esto abordó los problemas de seguridad, portabilidad y cadena de herramientas, pero se perdió la ventaja de rendimiento del código nativo. Esto se solucionó compilando aún más el bytecode a código nativo en tiempo de ejecución en máquinas compatibles. [ 4 ]
Compiladores modificados y extensiones de lenguaje
Armin Rigo publicó un descompilador y un recompilador (llamados respectivamente DEACCy REACC). Estos programas se crearon mediante ingeniería inversa y probablemente se publicaron antes del lanzamiento de qcc. [ 5 ]
En 1996, id Software publicó el código fuente de qccsu compilador de QuakeC, junto con el código original de QuakeC. Pronto surgieron versiones modificadas, entre ellas FrikQCCfastqcc , de Jonathan Roy y Ryan "FrikaC" Smith . Estas versiones añadieron funcionalidades, optimizaciones y mejoras en la velocidad de compilación.
En 1999, cuando id Software publicó el código del motor de Quake bajo la Licencia Pública General de GNU (GPL), se examinó el funcionamiento del intérprete de bytecode y se lanzaron nuevos compiladores de QuakeC, como el de JP Grossman qccxy una nueva versión de FrikQCC. Estos compiladores aprovecharon las nuevas funcionalidades descubiertas de forma retrocompatible, de modo que el bytecode pudiera seguir interpretándose correctamente con motores de Quake sin modificar. Entre las nuevas funcionalidades se incluyen matrices, punteros, enteros, bucles for y manipulación de cadenas.
Ahora que el código fuente del motor Quake podía modificarse, se añadieron nuevas funciones integradas a QuakeC. Las características que los programadores de QuakeC llevaban tiempo deseando finalmente se hicieron realidad: QuakeC ahora contaba con funciones para el manejo de archivos y cadenas, búferes de cadena ampliados, más funciones matemáticas, etc. Sin embargo, los programadores que aprovecharon estos cambios perdieron la compatibilidad con versiones anteriores del motor Quake sin modificar.
Xonotic desde la versión 0.7 utiliza el compilador gmqcc . [ 6 ]
QuakeC del lado del cliente
Algunos motores Quake mejorados (en particular DarkPlaces y FTEQW) admiten una extensión del QuakeC estándar (ahora comúnmente conocida como QuakeC del lado del servidor) que permite la programación del motor Quake solo en el lado del cliente , también abreviada como CSQC (QuakeC del lado del cliente). Esto es especialmente útil para interfaces gráficas de usuario (GUI), HUD y cualquier efecto visual complejo que no necesite simularse en el servidor y transmitirse a través de la red. [ 7 ]
Véase también
Referencias
- ↑ Lasse Lehtinen (25 de julio de 1996). "Lanzamiento de QuakeC" . Historia de Quake y QuakeWorld . Archivado del original el 16 de julio de 2011. Consultado el 14 de enero de 2011 .
- ↑ Andrew Wu. "Conceptos básicos de Quake C" . Consultado el 6 de abril de 2013 .
- ↑ Carmack, John (13 de marzo de 1997). "Aquí hay un problema técnico que debe discutirse, pág. 18" (PDF) . .plan . id Software . Recuperado el 5 de noviembre de 2018 .
- ↑ Carmack, John (24 de julio de 1999). "24 de julio de 1999, pág. 54" (PDF) . .plan . id Software . Recuperado el 5 de noviembre de 2018 .
- ↑ "Entrevista con Armin Rigo - 12 de febrero de 1997" . 30 de abril de 1997. Archivado del original el 30 de abril de 1997.
- ↑ "Lanzamiento de Xonotic 0.7" .
- ↑ "QuakeC del lado del cliente" . QuakeWiki . 30 de septiembre de 2012. Consultado el 16 de noviembre de 2016 .
Enlaces externos
- Repositorio de GitHub de id que contiene el código fuente en C de qcc (compilador de QuakeC).
- Repositorio de GitHub de id que contiene el código fuente de QuakeC para la lógica del juego QuakeWorld.
- Especificaciones no oficiales de QuakeC
- Gran colección de mods de control de calidad, incluyendo su código fuente.
- Inside3d: una buena colección de tutoriales de control de calidad aquí.
- InsideQC: Nuevo sitio web que heredará el legado de Inside3D tras su cierre.
- Lenguajes de programación específicos de dominio
- desarrollo de videojuegos
- Terremoto (serie)
- Lenguajes de scripting
- Id Tech
- Lenguajes de programación de tipado estático