FANDOM


Action Code Script (ACS) es el lenguaje de programación que se creó para Hexen y que fue ampliado en gran medida por ZDoom. Se trata de un guión (script) de código de bytes con el objetivo principal de manipular estructuras dentro del nivel como alturas de sector, texturas y Poliobjetos. ACS permite a los diseñadores de niveles desarrollar eventos durante el juego, por lo que la creación de entornos interactivos, incluso en el arcaico motor de Doom, puede hacerse en forma infinitamente más abierta.

Los monstruos, y cualesquiera otros actores para el caso, pueden ser insertados, eliminados, controlados, tienen muchas de sus propiedades alteradas e incluso pueden perseguir "objetivos" a través de una forma limitada de IA. El uso de ACS abre muchas posibilidades para el diseño de los niveles, sobre todo si la persona que lo usa es talentosa, paciente e imaginativa.

Aspectos técnicos

Dado que ACS se basa en un código de bytes, el idioma de origen no está necesariamente definido. En la práctica, la mayoría del código está escrito para el compilador ACS de Raven Software, ACC.

El lenguaje ACS es sintácticamente similar a C / C++ (es incluso comentable1 , como se muestra en el ejemplo de más abajo) y permite la mayoría de las declaraciones de flujo de control habituales (if, do, while, for, until). ACC admite algunos comandos básicos del preprocesador C, específicamente #define y #include, pero no se analizan en un pase separado y tienen algunas limitaciones.

Una secuencia de comandos, que se compone en un editor de texto de algún tipo, contiene comandos, declaraciones de variables y llamadas posiblemente incluso a otras secuencias de comandos (como las subrutinas en un lenguaje de programación). Los elementos de nivel superior para reconocer son scripts y sus tipos de secuencias de comandos, que son los eventos que desencadenan la secuencia de comandos contenidas en un script determinado.

Variables

ACC reconoce dos tipos de variables: int y str. A los efectos de Hexen, estos dos tipos son intercambiables ya que una cadena es simplemente un puntero a un índice de la tabla de cadenas. Las variables se pueden definir en uno de los tres ámbitos existentes: mundo, mapa y local.

  • Las variables de mundo mantienen su valor para todos los mapas en un mismo centro.
  • Las variables de mapa son específicas del mapa.
  • Las variables locales son específicas para un script en el mapa.

Las reglas normales de alcance C se aplican a las variables locales. Todas las variables se inicializan a cero de manera predeterminada y las variables de mundo / mapa no se pueden inicializar a ninguna otra cosa sin la ayuda de un script.

Scripts

El código en ACS está organizado en scripts. Estos pueden verse más o menos como hilos de ejecución, por lo que su orden de ejecución debe considerarse indefinido. Los scripts se identifican por un número arbitrario del 1 al 999. Cualquiera que sea el número elegido, Hexen solo puede cargar 64 secuencias de comandos en el mapa activo.

Un script puede llevar hasta tres argumentos o tener una condición de ejecución especial: OPEN, RESPAWN, DEATH o ENTER. OPEN indica que la secuencia de comandos se debe ejecutar durante la inicialización del mapa, RESPAWN es ejecutado por el jugador cuando reaparece en el modo multijugador, DEATH es ejecutada por el jugador cuando muere y ENTER es ejecutado por el jugador la primera vez que ingresa al juego.

Una secuencia de comandos se inicia escribiendo algo como lo siguiente:

// This is a comment
int AvailableToAllScripts;

SCRIPT 1 OPEN {
    if (AvailableToAllScripts == 101){
        restart;
    }
}

ACS no admite matrices o funciones personalizadas. Un bucle infinito hará que el juego se cuelgue, ya que la máquina virtual ACS nunca devuelve el control al juego. Algunos source ports implementan un límite de ejecución de instrucción para notificar al desarrollador cuándo sucede esto sin detener el juego.

Acciones especiales ACS

ACS_Execute

Una vez que los scripts han sido compilados y guardados en los lumps BEHAVIOR de los niveles, el diseñador de mapas usa la acción especial ACS_Execute (# 80) para implementar los contenidos. La acción se puede insertar en cualquier tipo de linedef, por ejemplo un interruptor o una línea que se puede cruzar. Hexen también permite matar monstruos y recolectar objetos para activar acciones especiales, por lo que también se pueden configurar para ejecutar scripts.

El especial de ACS incluye información numérica, como la identificación del script y el mapa del script que se pretende ejecutar. Si la secuencia de comandos de destino pertenece a un nivel diferente de donde se desencadenó, el sistema comienza a ejecutar la secuencia de comandos tan pronto como el jugador se transporte a ese mapa.

Parámetros de acción #80
Número de script
Número de mapa
Argumento 1
Argumento 2
Argumento 3

ACS_LockedExecute

La acción ACS_LockedExecute (# 83) permite al diseñador bloquear la función de desencadenarse. En consecuencia, el jugador debe tener en su podeer una de las once llaves antes de poder iniciar el script. Los mapas de stock en Hexen utilizan esto únicamente para las activaciones con la barra espaciadora, pero los cruces de líneas, los baches y los impactos de proyectiles también son compatibles con la acción especial. Si bien algunos de estos métodos parecen tener poco que ver con el uso de llaves, las características permiten al mapeador crear rompecabezas imaginativos alrededor de los objetos, especialmente si las llaves se reemplazan con otros artefactos.

Parámetros de acción #83
Número de script
Número de mapa
Argumento 1
Argumento 2
Número de llave
ID# de la llave
1 Llave de acero
2 Llave de la cueva
3 Llave del hacha
4 Llave de fuego
5 Llave de esmeralda
6 Llave del calabozo
7 Llave de plata
8 Llave oxidada
9 Llave del cuerno
10 Llave del pantano
11 Llave del castillo

UsePuzzleItem

La acción UsePuzzleItem (# 129) es similar a la acción anterior, ya que evita que un script se active antes de que el jugador posea el objeto correcto entre los diecisiete Artefactos puzzle existentes en el juego.

Parámetros de acción #129
Número de artefacto
Número de script
Argumento 1
Argumento 2
Argumento 3
ID# del artefacto puzzle
0 Cráneo de Yorick 9 Máscara de llamas
1 Corazón de D'Sparil 10 Espada del sello
2 Planeta rubí 11 Reliquia sagrada
3 Planeta esmeralda 1 (#9005*) 12 Sigilo del Mago
4 Planeta esmeralda 2 (#9009*) 13 Engranaje de acero
5 Planeta zafiro 1 (#9006*) 14 Engranaje de bronce
6 Planeta zafiro 2 (#9010*) 15 Clock Gear (Ring of steel)
7 Daemon Codex 16    Clock Gear (Ring of bronze)
8    Liber Oscura

* Los números del tipo de cosa se presentan para su identificación.

Argumentos

Las acciones especiales de ACS contienen una característica que le permite al mapeador diseñar módulos de scripts. En otras palabras, si muchos efectos de juego en un nivel comparten una secuencia idéntica de comandos, el diseñador de mapas no tiene que crear scripts separados para cada uno de ellos.

En lugar de establecer números de etiqueta únicos u otros valores para varios scripts, el asignador puede insertar los datos numéricos de los comandos en el propio ACS_Execute. Por lo tanto, puede establecer diferentes sectores de destino, velocidades, alturas u otros para eventos distintos, mientras se basan en un solo guión.

Las figuras se almacenan en parámetros llamados argumentos. ACS_Execute proporciona soporte para tres valores únicos, mientras que la versión bloqueada de la acción especial puede contener dos de ellos. A continuación se muestra una secuencia de comandos de ejemplo y una vista aérea del mapa donde se realiza la secuencia de comandos.

SCRIPT 2 (int arg0, int arg1) 
// The definitions tell the script to use argument data 
// from the linedef it was triggered
{
  Door_Open(arg0,16);
  tagwait(arg0);
  changefloor(arg1,"F_014");
  Floor_RaiseByValue(arg1,8,48);
}
HXN Ejemplo ACS

"MAP01" de un PWAD

En la instancia, los argumentos de la secuencia de comandos se usan para habilitar números de etiquetas variables. Con ellos, el asignador puede hacer que ocurra una sola secuencia en varios sectores objetivo.

Cuando se inicia el script, se abre una puerta con una velocidad de 16. La ejecución de acciones se suspende hasta que la puerta alcanza su altura de destino (tagwait).

Una vez que la puerta está completamente abierta, se establece que la textura de un piso cambie en otro sector y el sector todavía tiene que subir 48 unidades de mapa con una velocidad de ocho.

Estos dos comandos simulan un puente que se eleva desde el líquido, un efecto que es bastante común en los mundos de los juegos del motor de Doom.

Los círculos rojos en la imagen de la derecha representan los números de etiqueta de los sectores. Los sectores marcados con los números 1 al 3 han sido editados para comportarse como puertas, mientras que los sectores con las etiquetas 4 al 6 se han preparado para funcionar como puentes. Se accede a las tres secciones presionando una linedef delante de la puerta. Para realizar el contenido del script anterior, los desencadenantes se configuran de la siguiente manera:

Parámetro Izquierda Centro Derecha
Número de script 2 2 2
Número de mapa 1 1 1
Argumento 1 1 2 3
Argumento 2 4 5 6
Argumento 3 0 0 0

Una vez que el jugador presiona las linedefs, sus números de argumento reemplazan los espacios arg0 y arg1 (Argumento 1 y 2 respectivamente) de la secuencia de comandos. Como resultado, se pueden activar tres puertas y puentes diferentes en momentos separados y en cualquier orden deseado mediante el uso de un solo script. Sin embargo, es notable que cualquier función que cause una pausa (void delay, tagwait, polywait, scriptwait) en una secuencia de comandos del módulo impide que otros miembros de la línea la reinicien antes de que la pausa definida haya expirado. En el ejemplo, la función tagwait tiene el efecto secundario de bloquear los disparadores en otras linedefs hasta que la puerta activa haya detenido su movimiento. Si tal comportamiento parece ser adverso para la jugabilidad, el mapeador puede evitarlo, ya sea diseñando la secuencia sin funciones de retardo o creando un script separado para cada caso.

Algunos mapas originales en Hexen, como Hub 1: Winnowing Hall, tienen grandes vitrales. La ruptura de ellos es uno de los efectos que utiliza argumentos de script. Como el efecto permanece constante, los niveles generalmente tienen solo un script que controla el evento de ruptura. Los scripts especiales se han establecido en cada pared para ser activados por un impacto. Los argumentos almacenan información como la etiqueta del piso que se debe bajar para eliminar la característica de bloqueo de la pared. Otra información importante es el número de mapa que se usa para generar fragmentos de vidrio al romperse.

ACS Extendido

En ZDoom se origina un formato de código de bytes extendido conocido como ACSe (al formato ACS de Hexen a veces se lo llama ACS0 basado en el fourCC en el encabezado) y extiende el ACS de varias maneras.

Algunas llaves adiciones incluyen soporte para scripts con nombre, inicialización estática de variables de mapa, funciones personalizadas, matrices, alcance global y bibliotecas. El alcance global funciona de manera similar al alcance de mundo, pero se aplica a todos los mapas en una sesión de juego, no solo a aquellos del centro actual. Normalmente, estos se usan en combinación con bibliotecas ACS que permiten que los módulos compilados de ACS se reutilicen entre mapas. El código de bytes subyacente utiliza el mismo conjunto de instrucciones, aunque está expandido, por lo que no se necesita una VM independiente para admitir ambos tipos de código de bytes.

Desde entonces, se ha implementado el soporte para ACS extendido en Eternity Engine.

Véase también

Notas al pie

1.   comentable: capaz de ser marcado con un comentario.

Fuente

  • Este artículo incorpora texto del artículo ACS del proyecto de documentación ZDoom de contenido abierto.
El contenido de la comunidad está disponible bajo CC-BY-SA a menos que se indique lo contrario.