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
fuente
Respuestas:
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:
¿Qué lenguaje de script debería elegir para mi juego?
¿Qué buscas en un lenguaje de script?
¿Cómo se agrega un lenguaje de script a un juego?
[*] 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
fuente
interpreted
es 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.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".
fuente
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 ++).
fuente
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.
fuente
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
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.
fuente
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.
fuente