QuakeC

QuakeC es un lenguaje compilado desarrollado en 1996 por John Carmack de id Software para programar partes del videojuego Quake. Con QuakeC, un programador puede personalizar Quake en gran medida agregando armas, cambiando la lógica y la física del juego y programando escenarios complejos. Se puede usar para controlar muchos aspectos del juego en sí, como partes de la IA, disparadores o cambios en el nivel. El motor Quake fue el único motor de juego que usó QuakeC. Los siguientes motores utilizaron módulos de juego DLL para la personalización escritos en C y C++ desde id Tech 4 en adelante.

Resumen

La fuente de QuakeC para la lógica de juego original de id Software Quake se publicó en 1996 y se usó como base para modificaciones como capturar la bandera y otras. El código fuente de QuakeC se compila usando una herramienta llamada qcc en un código de bytes guardado en un archivo llamado progs.dat. Los programadores de las modificaciones de Quake podrían entonces publicar su código de bytes progs.dat sin revelar su código fuente. La mayoría de las modificaciones de Quake se publicaron de esta manera.

QuakeC permitió que el motor de Quake dominara la dirección del género de disparos en primera persona. Gracias a la idea de Carmack de extender la vida de los videojuegos agregando capacidad de expansión ilimitada (la capacidad de extensión ya desempeñó un papel importante en Doom), ha surgido una enorme comunidad de Internet de jugadores y programadores por igual y muchos multijugadores modernos los juegos son extensibles de alguna forma.

QuakeC se conoce como interpretado porque mientras se ejecuta Quake, continuamente interpreta el archivo progs.dat.

Limitaciones y soluciones posteriores

La sintaxis de QuakeC se basa en la del lenguaje de programación C, explicando su nombre, pero no admite la implementación de nuevos tipos, estructuras, arreglos o cualquier tipo de referencia que no sea la "entidad&#. 34; tipo (que siempre es una referencia). QuakeC también sufre por el hecho de que muchas funciones integradas (funciones prototipadas en el código de QuakeC pero definidas en el motor del juego y escritas en C) devuelven cadenas en un búfer de cadena temporal, que solo puede contener una cadena en un momento dado. 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 en 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 o funciones de manejo de archivos, que simplemente no eran necesarias en el juego original.

La lógica del juego de la mayoría de los videojuegos de la época estaba escrita en C/C++ simple y compilada en el ejecutable, que es más rápido. Sin embargo, esto hace que sea más difícil para la comunidad crear mods y hace que el proceso de migrar el juego a otra plataforma (como Linux) sea más costoso.

A pesar de sus ventajas, la opción de implementar la lógica del juego usando un lenguaje de script personalizado y un intérprete se eliminó 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, la rendimiento que se obtiene al empaquetar la lógica del juego en una biblioteca de enlaces dinámicos nativos, y la ventaja de aprovechar la comunidad, las herramientas, los materiales educativos y la documentación de un lenguaje de programación ya establecido.

La distribución de código nativo generaba nuevos problemas de seguridad y portabilidad. El bytecode de QuakeC brindaba pocas oportunidades para hacer travesuras, mientras que el código nativo tenía acceso a toda la máquina. El bytecode de QuakeC también funcionó en cualquier máquina que pudiera ejecutar Quake. La compilación con código nativo agregó una barrera de entrada adicional para los desarrolladores de mods novatos, porque se les pedía que configuraran un entorno de programación más complicado. La solución final, implementada por el motor Quake III, fue combinar las ventajas del QuakeC original con las ventajas de compilar C en código nativo. El compilador lcc C se amplió para compilar C estándar en código de bytes, que podrí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 perdió la ventaja de rendimiento del código nativo. Eso se resolvió compilando aún más el código de bytes en código nativo en tiempo de ejecución en máquinas compatibles.

Compiladores modificados y extensiones de lenguaje

Armin Rigo lanzó un descompilador y un recompilador (llamados DEACC y REACC respectivamente). Estos programas se crearon mediante el proceso de ingeniería inversa y probablemente se publicaron antes del lanzamiento de qcc.

id Software lanzó el código fuente de qcc, su compilador de QuakeC, junto con el código original de QuakeC en 1996. Pronto surgieron versiones modificadas, incluido fastqcc y Ryan "FrikaC" FrikQCC de Smith. Estos agregaron funcionalidad, optimizaciones y aumentos de velocidad de compilación.

En 1999, cuando id Software lanzó el código del motor de Quake bajo la Licencia Pública General GNU (GPL), se examinó el funcionamiento del intérprete de bytecode y se lanzaron nuevos compiladores de QuakeC, como J.P. Grossman's qccx y una nueva versión de FrikQCC. Estos compiladores aprovecharon las características recién descubiertas de una manera compatible con versiones anteriores para que el código de bytes aún pudiera ser interpretado correctamente por los motores de Quake sin modificar. Las nuevas funciones incluyen matrices, punteros, enteros, bucles for y manipulación de cadenas.

Con el código fuente del motor Quake que ahora se puede cambiar, se agregaron más funciones a QuakeC en forma de nuevas funciones integradas. Las funciones anheladas durante mucho tiempo por los codificadores de QuakeC finalmente se hicieron realidad, ya que QuakeC ahora tenía funciones de manejo de archivos y cadenas, búferes de cadenas ampliados, más funciones matemáticas, etc. Sin embargo, los programadores que aprovecharon estos cambios perdieron la compatibilidad con el motor Quake sin modificar.

Xonotic desde la versión 0.7 usa el compilador gmqcc.

QuakeC del lado del cliente

Algunos motores de Quake mejorados (en particular, Darkplaces y FTEQW) son compatibles con una extensión de QuakeC normal (ahora comúnmente conocida como QuakeC del lado del servidor) que permite la creación de secuencias de comandos solo del lado del cliente del Terremoto. Esto es especialmente útil para GUI, HUD y cualquier efecto visual pesado que no necesite simularse en el servidor y transferirse a través de la red.