¿Cuál es la tecnología que permite programar dentro de un juego?

27

Hay algunos juegos que permiten al jugador escribir / crear guiones en el juego, por ejemplo: ingenieros espaciales o Psi .

Quiero usar algo similar a cualquiera de los dos, pero he tenido dificultades para encontrar información, así que mi pregunta es:

¿Existe una rama de programación que cubra la capacidad de un software una vez compilado para ejecutar un nuevo código creado por el usuario?

Por rama de programación me refiero a algo como PTG (Generación de terreno procesal).

Para evitar una pregunta u opinión demasiado amplia , permítanme decir claramente que no estoy buscando guías o lugares para aprender, quiero el nombre o la definición (si existe) de la tecnología involucrada.

scripting terminology

— Westside Tony
fuente

22

Bueno, probablemente "¿Intérpretes de escritura"?

— MatthewRock

2

Respondí una pregunta similar recientemente , discutiendo " Máquina virtual " como el término para el sistema que ejecuta el código de usuario, y también haciendo referencia al artículo de Patrones de programación de juegos en el Patrón de código de bytes como un medio para implementar esto más rápido que un intérprete convencional.

— DMGregory

3

Generalmente se llama "scripting". Encontrarás una gran cantidad de materiales sobre cómo implementar scripts en un juego, así como una gran cantidad (variadamente) de código abierto de muestra y código real. En un ámbito más amplio, está todo el campo de la programación del compilador (que incluye lexing, análisis, compilación, vinculación, interpretación ...). En el ámbito más amplio (no necesariamente útil), esto implica prácticamente cualquier interacción del usuario que tenga su aplicación: un motor de secuencias de comandos es realmente una forma mucho más compleja de seleccionar de un menú.

— Luaan

2

Un programa de Python puede alojar scripts de Python. Eso se llama metaprogramación. La mayoría de los idiomas interpretados tienen eso.

— user6245072

1

AFAIK en Space Engineers, el código está compilado en código C # en un entorno de espacio aislado (el juego se convirtió en código abierto, por lo que puede verificar cómo funciona en línea: github.com/KeenSoftwareHouse/SpaceEngineers ). Básicamente, el juego se entrega con un compilador de C # y el código solo permite el acceso a las funciones API del juego, por lo que el alcance del programa se limita solo a usted. Y si estás jugando multijugador, entonces el código solo se ejecuta en tu máquina (otros jugadores / el servidor solo ven las consecuencias del juego)

— Florian Castellane

42

Las secuencias de comandos escritas en lenguajes de secuencias de comandos / incrustados / interpretados como "Lua", "Lisp" o "AngelScript" ( más aquí ) se pueden actualizar durante el juego [*] y luego se interpretan (= ejecutan) sobre la marcha.

Puede vincular elementos de esos scripts a su codificación compilada nativa (C ++, etc.) para que los scripts puedan ejecutar la lógica desde su aplicación. P.ej. un comando específico que el usuario puede poner en el script, como resultado mueve al personaje del juego a una distancia dada en el mundo del juego.

Algunas preguntas vinculadas relevantes:

[*] ya sea por el usuario como parte del juego o también por desarrolladores para una iteración / prueba rápida sin reiniciar la aplicación

— Philip Allgaier
fuente

14

Tendría cuidado al llamar a algo "lenguaje interpretado". En el mejor de los casos, es un término muy discutible.

— wondra

1

Computercraft (mod de Minecraft) usa LUA como lenguaje de programación para programar tareas dentro del juego.

— Tikeb

20

Realmente no entiendo el alboroto. Lisp puede ser interpretado y compilado. No estamos aquí para discutir cómo clasificar los idiomas y si interpretedes una buena clasificación; le estamos diciendo a OP que no es consciente de este hecho que el lenguaje no necesita ser compilado, pero puede ser interpretado, y damos algunos idiomas como ejemplo. ¿Se interpreta Lisp? Sí. ¿Está compilado? También si! Pero eso está fuera del alcance. La respuesta puede ser inexacta con la redacción, pero está bien para ese propósito; empuja a OP en la dirección correcta, y eso es lo que cuenta. Aquí, toma mi +1.

— MatthewRock

1

Bueno, incluso si un lenguaje es solo de compilación, ¿qué te impide incorporar un IDE, compilador y tiempo de ejecución en tu juego? Excepto el presupuesto, eso es.

— Ordous

3

@DanielJour Si bien estoy de acuerdo en que, en teoría, un lenguaje puede ser distinto de su implementación (compilado a código de máquina vs compilado a bytecode para un vm), todavía es una suposición útil que ahorra tiempo que C se compila a menos que se especifique lo contrario (y se puede imaginar el aspecto que obtendría si preguntara "espera, compiló C o interpretó C?" cada vez). Para el propósito del OP, necesita mirar los idiomas que apoyan la interpretación; si también pueden compilarse o no, no es un problema porque no es así como lo usaría.

— Blackhawk

12

El lenguaje incorporado es el término técnico apropiado. En la práctica, los lenguajes que se usan dentro de otras aplicaciones (como los juegos) a menudo se denominan scripts o incluso lenguajes interpretados , aunque no necesariamente deben interpretarse o usarse para automatizar tareas rutinarias. Buscar en Google "lenguajes de scripting para juegos" probablemente arrojaría resultados más útiles que buscar "lenguajes incrustados".

— interphx
fuente

11

Está buscando una manera de cambiar el código en algunas acciones. Esto es precisamente lo que están haciendo los intérpretes .

Echa un vistazo a Python. ¡Lo ejecutas y bam! Usted aterriza en REPL ( R ead E val P rint L oop).

Define una función "hola" que imprime "Hola, mundo". ¡Y ahí lo tienes!

Tenga en cuenta que no compiló nada; el intérprete hizo algo de magia para crear funciones sobre la marcha (durante el tiempo de ejecución) y ahora puede llamarlo.

Lo mismo se aplica a los juegos. En lugar de tener un REPL, tienes un juego con el módulo REPL. El juego probablemente inicia REPL y luego ejecuta todo lo demás en este REPL, por lo que tiene acceso a los datos y puede modificarlos activamente.

Si está trabajando con lenguajes enormes como C ++, tienden a ser menos dinámicos y probablemente compilados. Quieres algo más fácil. Puede crear su propio lenguaje o usar algunos existentes (como CoffeScript, Squirrel, Lua, Scheme, ...)

A menudo se denominan lenguajes de secuencias de comandos , ya que los utiliza para escribir secuencias de comandos que se basan en el motor del juego desarrollado en otro lenguaje (por ejemplo, C ++).

— MatthewRock
fuente

2

Si el lenguaje de programación en el juego solo fue diseñado para el propósito del juego, entonces es un lenguaje específico de dominio .

La ventaja (y desventaja) de los idiomas específicos del dominio es que el idioma en sí mismo puede limitar lo que el usuario puede hacer (es decir, no puede conectarse a Internet). Podría diseñar un lenguaje que haga que las tareas típicas del juego sean más fáciles que en un lenguaje de propósito general. La desventaja es que el usuario tiene que aprender un nuevo idioma.

Simplemente ejecutar código de usuario no higienizado en un lenguaje de propósito general (como python o perl) desde su juego, podría permitirle al usuario meterse con cosas con las que no debería meterse. Pero depende de tu juego. Si no le importa que los usuarios hagan cosas como abrir nuevas ventanas desde su juego o lo que quieran, puede usar un lenguaje de propósito general y exponer enlaces a ciertas características de su mundo de juego.

— TheEspinosa
fuente

1

Hay dos ejemplos que puedo pensar en la parte superior de mi cabeza. Ambos parecen hacer exactamente lo que estás pidiendo.

El primero son los chillidos. https://screeps.com/ Puede leer mucho sobre cómo logra este objetivo en http://support.screeps.com/hc/en-us/articles/205960931-Server-side-architecture-overview

El segundo es ComputerCraft http://www.computercraft.info/ No detallan tanto cómo funciona, pero se puede ver un poco en su wiki http://www.computercraft.info/wiki/Main_Page

En esencia, el juego principal ejecuta un intérprete en un hilo separado, luego permite que ese hilo manipule el mundo del juego a través de llamadas API.

En ambos ejemplos, si bien el idioma es casi ilimitado (solo algunas llamadas bloqueadas por razones de seguridad) las manipulaciones de API pueden limitar las manipulaciones.

Por lo general, se requiere muy poco trabajo para comenzar algo como esto. Necesitas

un administrador de hilos que protege el ciclo de tu juego (no permite que un hilo bloquee el ciclo o consuma muchos recursos). Ambos ejemplos usan un limitador basado en el tiempo.
Un intérprete para ejecutar un lenguaje. LUA es bastante común en estos días.
Un conjunto de llamadas API que modifican el mundo del juego. Qué divertido es un lenguaje de programación si no puedes hacer nada con él.
Una implementación de gestión de recursos. En otras palabras, una forma de almacenar archivos de código y hacer referencia a ellos en el juego.

No hay una sola rama de programación que maneje todas estas preocupaciones. Pero necesitará una base sólida en subprocesos múltiples y un conocimiento general de cómo funciona un intérprete.

— coteyr
fuente

0

El ejecutable compilado debe contener un analizador que pueda leer el código externo del programa . No es necesario que el código del programa se parezca a C, Python o xyz; puede ser cualquier tipo de información descriptiva que sea adecuada para el propósito en cuestión. Por ejemplo sueco o morse.

El código del programa externo debe tener una sintaxis , de modo que el analizador lo entienda mientras lo lee carácter por carácter. La sintaxis puede describir (y el código puede contener) identificadores, valores numéricos, operadores, etc .

El analizador es fijo (compilado) pero funciona en código externo flexible.

El ejecutable compilado debe tener una API interna para su funcionalidad relevante. para que el analizador pueda realizar acciones. Lo más probable es que también haya acceso (bidireccional) a los datos internos del ejecutable, o el analizador debe proporcionar algún tipo de almacenamiento de datos y limpieza.

El analizador puede leer el código del programa externo al inicio del ejecutable , o puede leer (partes de) ad hoc , o puede volver a leerlo por cada cuadro (sería ineficiente), o incluso el código puede escribirse a mano y publicado en el analizador cuando se prepara (como: "mover la unidad X hacia adelante 5 pasos" [enter]).

Esencialmente, el código externo no es fijo ; puede cambiar cualquier año, día o minuto, pero aún así el ejecutable no necesita ser compilado nuevamente. Solo cambia el comportamiento resultante, alojado por el ejecutable.

El texto que está leyendo en este momento es (más o menos, incluso si fue hablado) interpretado porque lo "ejecuta" en su cerebro mientras lo lee, sin saber lo que dice la siguiente oración (o incluso si es posible, cambia a escondidas correctamente) ahora). A diferencia de Stack Overflow (pre) compilando toda la historia en bytecode en sus cerebros, que luego la ejecuta, y ofc entonces ya no podría cambiar más.

El fenómeno en curso es la interpretación. La creación de secuencias de comandos es solo el acto de crear una deSCRIPCIÓN o escritura . Toda la codificación de la computadora es scripting de imo: describimos lo que queremos que suceda. La palabra "scripting" tiene un significado algo inclinado, pero así está bien. Sabemos lo que queremos decir.

No hay absolutamente nada extraordinario con los idiomas interpretados, y de ninguna manera es un término discutible . Existen una multitud de ellos, y algunos de los más antiguos se interpretan como opuestos a compilados. En un lenguaje interpretado, por ejemplo, se podría escribir a mano:

calcetín = Socket.New (AddressFamily.InterNetwork, SocketType.Stream ProtocolType.Tcp) [ENTRAR]

... y luego toma un descanso de café de 30 ... no, 45 minutos :-). Al regresar, existe "calcetín" y está listo para su uso posterior escribiendo más a mano o dejando que la automatización del intérprete continúe con él.

— Ventormenta
fuente

Existe una idea errónea de que un lenguaje interpretado debe ser lento. No es verdad. Dependiendo de los diversos factores que hacen que esta discusión sea demasiado amplia para los comentarios, el lenguaje interpretado puede ser una magnitud o menos lento, tan rápido o incluso para algunas operaciones más rápido que el lenguaje de control que se considera rápido (generalmente C). El ejemplo con socket probablemente funcionaría más o menos como en C, por lo que el ejemplo es engañoso. También puede redefinir funciones compiladas en tiempo de ejecución en algunos idiomas, y la interpretación no significa simplemente "ir una instrucción a la vez".

— MatthewRock

Claro, un lenguaje interpretado también puede funcionar más rápido, después de todo, es el código de bytes que se ejecuta, y la ejecución puede optimizarse mucho mejor, dependiendo de la automatización del intérprete. Además, algunos intérpretes pueden compilar, desde el código, partes del código en bytecode (y ejecutar), ad hoc. El ejemplo es solo un ejemplo de la libertad, "¿Ir una instrucción a la vez"? Bueno, eso es una simplificación excesiva, quizás agregue "mientras el código futuro es flexible".

— Ventormenta

Piense en "guión" más como un guión de película: todavía necesita actores, y estos se definen directamente en términos de biología y sociología, no en ciencias del teatro (aunque al final se basan en biología y sociología), porque estos idiomas son más adecuado para ese propósito pero no para el otro :)

— rackandboneman