¿Es viable implementar su propio lenguaje de script?

Estoy codificando un juego beat 'em up en C ++ y ha llegado el momento de implementar secuencias de comandos para eventos, desencadenantes, escenas de corte, etc. He leído en Internet y obtuve bastante información. Mi solución de primera elección sería implementar mi propio lenguaje de script como el de Cave Story . He visto esto sugerido, pero la mayoría de la gente sugiere lua, pero eso no parece ajustarse a mi tipo de programación.

¿Has creado tu propio lenguaje de script? ¿Por qué elegiste rodar el tuyo en lugar de usar uno existente? ¿Qué recursos consultó durante el desarrollo?

No. Al menos, probablemente no.

Este es un caso muy frecuente de reinventar la rueda en el desarrollo del juego, un error que todavía es bastante popular.

Si haces esta pregunta, es muy probable que te influya lo que otros hacen, así que mira lo que Epic Games acaba de hacer con Unreal Engine:

• UE3 tenía un elemento UnrealScript personalizado, extraño, no optimizado y difícil de depurar,
• Si el rumor es cierto, su soporte se está eliminando en UE4 , a favor de las DLL de C ++ recargables en caliente.

¿Crees que puedes hacerlo mejor que Epic?

La creación de lenguajes de programación pertenece a los creadores de lenguajes de programación , no a los ingenieros de juegos.

Se necesitan años y años para que un lenguaje se vuelva completamente maduro, y su conjunto de herramientas que lo acompaña (compilador, enlazador, intérprete, depurador ...) se puede usar. Hoy en día tienes muchas soluciones disponibles a mano, así que no hay absolutamente ninguna razón real para comenzar algo nuevo desde cero, al menos no si el objetivo es simplemente hacer un juego. Período.

Para responder a sus preguntas secundarias, no, por estas mismas razones, nunca he implementado mi propio lenguaje de secuencias de comandos. Pero he sufrido mucho con algunos a medio hornear. Debido a que se crearon con una característica muy limitada en mente, siempre tuvieron estas pequeñas peculiaridades que te vuelven loco. A menudo, pasarás muchísimo tiempo intentando evitar las limitaciones del idioma en lugar de solo crear tu juego.

Si la razón por la que desea crear un lenguaje es porque está destinado a ser utilizado por personas que no conocen muy bien la programación, o si cree que lo necesita porque quiere algo muy específico de dominio, déjeme decirle que estos también malas razones Puede escribir una API de muy alto nivel con funciones que do_what_they_say_and_say_what_they_do(), y un código repetitivo muy simple que expone su uso básico. Sus usuarios no tan técnicos estarán encantados de aprender un poco de programación, y usted estará encantado de no estar limitado por algún lenguaje mal implementado.

Entonces, como esto puede sonar un poco brusco o incluso duro, diré que hay un caso en el que podría tener sentido: si quieres aprender cómo se hace un lenguaje de secuencias de comandos. Pero por favor, por favor, si lo haces: no obligues a otros a usarlo.

Editar

Acabo de echar un vistazo a la lista de comandos de Cave Story que has vinculado. Ay:

<ECJx:y      [EC?] Jump           @ Jump to event Y if any npc with ID X is present

No quiero mostrar falta de respeto al desarrollador detrás de Cave Story, pero este es un ejemplo perfecto de una simple lista de comandos que muta en un lenguaje de script personalizado incontrolable. Esto podría seguir siendo útil para un desarrollador único o un equipo muy pequeño, pero en esta etapa le aconsejo que cambie a un lenguaje Turing completo y bien probado (por ejemplo, Lua), donde podría hacer:

if (npc.id == x) then
    jump_to_event(y)
end

Esto facilitará mucho las cosas cuando, por ejemplo, necesite una condición más compleja:

if (npc.id == x) or (npc.type == "enemy") then
    jump_to_event(y)
end

¿Has creado tu propio lenguaje de script y por qué elegiste rodar el tuyo en lugar de usar uno existente?

Sí, aunque tomé prestada la sintaxis de otros idiomas. En general, fue una gran experiencia de aprendizaje y en mi caso no fue tan difícil porque el lenguaje era simple.

Lo hice principalmente porque quería usar una sintaxis regular de estilo C para mis scripts, ya que todos en el equipo estaban familiarizados con ella.

También estaba interesado en aprender un poco sobre la implementación de lenguajes de programación, y dado que solo necesitaba un subconjunto muy simple de características (variables, aritmética, condicionales, bucles y llamadas a funciones o rutinas en el juego) decidí probarlo.

¿Qué recursos consultó durante el desarrollo?

Mi principal recurso fue este libro:

Logré aprender lo suficiente de este libro para implementar:

• Un lexer: que era casi trivial usando expresiones regulares, solo usando Regex.Match para identificar y dividir tokens.
• Un analizador de descenso recursivo: básicamente una función para cada regla en la gramática y algunos métodos auxiliares para mirar hacia adelante y consumir tokens. Miré la especificación gramatical de C # en busca de inspiración. La parte más difícil fue tratar con la aritmética y las precedentes de operadores de relaciones sin entrar en una recursión infinita.
• Un intérprete de AST: utilizando el patrón de diseño del visitante, atravesé el árbol generado por el analizador y ejecuté cada nodo de instrucción de forma recursiva.

Me habría detenido allí ya que casi todo lo que necesitaba ya estaba funcionando, excepto por una cosa: llamar y ceder en las corutinas de Unity3D desde el intérprete recursivo. Para resolver ese problema, tuve que deshacerme de la recurrencia, y volví una vez más al libro. Esta vez terminé agregando:

• Un compilador: otro visitante, pero en lugar de ejecutar código, genera una lista de pequeñas instrucciones atómicas de cada nodo del AST (es decir, un simple lenguaje de ensamblaje personalizado basado en pila). Las operaciones como un bucle while o una condición if se convierten en etiquetas e instrucciones tipo goto. En este punto también escribo el script compilado en el disco como un archivo binario.
• Un intérprete de código de bytes: simplemente itera sobre una lista plana de instrucciones. Sin la recursividad, ahora era fácil de integrar con las rutinas de Unity3D.

Todo el proceso tardó aproximadamente 2 semanas desde cero conocimiento, y fue muy divertido :)

PD: Al final, también quería agregar resaltado de sintaxis e inteligencia para mi lenguaje personalizado en nuestras herramientas. Scintilla fue un salvavidas en este sentido. Usé el siguiente contenedor:

http://scintillanet.codeplex.com/

He visto esto sugerido, pero la mayoría de la gente sugiere lua, pero eso no parece ajustarse a mi tipo de programación.

Bien, intentemos esto desde un ángulo diferente: ¿qué tiene Lua que no te gusta? ¿Es algo que se puede arreglar fácilmente o es algo fundamental?

Por ejemplo, utilice palabras clave como then/do/enddenotar bloque de código en lugar de buenas llaves de estilo C / C ++. Si ese es tu problema ... eso es algo que puedes solucionar. Todo lo que necesita hacer es definir su propio pequeño dialecto de Lua y escribir una herramienta de transformación simple que convierta su sintaxis de llaves en Lua real.

¿Quieres + = de alguna forma? Eso también es fácilmente algo que puede hacer en un sistema de preprocesamiento. Simplemente convierta las declaraciones del formulario expr1 += expr2en expr1 = expr1 + expr2.

De acuerdo, tendrás que encontrar una manera de detectar si un par de llaves representan una tabla o un do/endpar. Y que tendría que conectar su sistema de pre-procesamiento en Lua reemplazando dofile, loadstringy otras funciones de la biblioteca estándar de Lua. Pero todo es finalmente factible.

Si le preocupan pequeños problemas como ese, y está demasiado casado con un estilo de programación como para cambiar la forma en que codifica (nota: generalmente es una calidad terrible para tener como programador), esta es una alternativa mucho más viable que simplemente escribiendo tu propio idioma. Esto llevaría quizás un par de semanas como máximo . Compare eso con los años que se gastarían en un lenguaje adecuado, con un rico soporte de depuración y similares.

Si sus problemas son mayores que esto (los valores globales son los predeterminados, lo que requiere que lo use en localtodas partes), algunos de estos se pueden administrar (simplemente haga que la declaración de nuevo global sea un error, mediante el uso de entornos alterados y metatablas). Si odias las funciones como objetos de primera clase, corutinas, recolección de basura u otros elementos básicos de Lua ... bueno, entonces estás en tu propia creación;)

Y si realmente quieres ser duro al respecto, puedes escribir tu propio idioma que compilas en Lua. Por lo tanto, al menos podrá aprovechar el muy bien probado tiempo de ejecución de Lua, la excepcional API de Lua y otras instalaciones básicas de Lua, todo desde su idioma! Lua. Esto llevará tiempo, pero aún no serán los años que pasarías en otra cosa.

Para complementar las otras respuestas, esta no es una opción estrictamente binaria. Dentro de un lenguaje de script existente, también puede crear su propio lenguaje específico de dominio . Las ventajas de este enfoque son:

• En realidad, no tiene que meterse con gramáticas formales, analizadores, implementadores editores personalizados, etc.
• Obtendrá la mayor parte del beneficio de implementar un lenguaje de script especializado, es decir, una abstracción adicional, específica para su juego.
• vs homebrew: los usuarios que estén familiarizados con el lenguaje de scripting de su elección podrán usar su DSL de inmediato.
• vs. lenguaje simple: los usuarios que no estén familiarizados con el lenguaje de secuencias de comandos solo necesitarán conocer el DSL para modificar su juego.

La desventaja principal es que estaría diseñando el DSL con las restricciones de su lenguaje "base".

Se podría tener sentido en función de la mecánica de su juego. Algunos juegos con una mecánica lo suficientemente simple podrían usar un lenguaje interpretado para salvarse de una codificación Lua / Python demasiado complicada, pero los ahorros de complejidad podrían no valer demasiado. Por ejemplo, uno de esos juegos de Novela Interactiva podría usar fácilmente un motor de secuencias de comandos escrito a medida.

Si su juego involucra un motor de física, varios componentes del juego y una complejidad variable de personajes y habilidades, definitivamente debería considerar buscar otros lenguajes de secuencias de comandos existentes, por lo que no está luchando para agregar las características necesarias a su personalizado, o corrigiendo errores con eso. Si bien Lua es probablemente el más rápido, hay muchos otros que pueden gustarle más por su sintaxis, y muchos de ellos se jactan de la facilidad con que se integran con C. Python, Ruby y Angelscript son algunos. (Siéntase libre de mencionar a otros en los comentarios)

Si se asegura de que dichos lenguajes solo se usen para el "control lógico" (es decir, manejar un caso de colisión específico para ciertos tipos de objetos, como el lanzallamas tocando un bloque de hielo), el rendimiento casi nunca será un problema. Por supuesto, por otro lado, si los usa para más código de rutina (haciendo un algoritmo de verificación de colisión personalizado que ejecuta cada cuadro), es más probable que lo empañe.

Yo digo, adelante. En un currículum sería una demostración extra de habilidad. Sin embargo, ten en cuenta que primero necesitas esa habilidad. No va a ser fácil, va a ser bastante difícil. También hay libros sobre el tema y tutoriales en línea, pero en última instancia, dependerá de usted y de su comprensión de cómo funciona un compilador y cómo se analiza y traduce el código.

Asegúrate de que comiences de forma simple, prueba con frecuencia y mantén tu ideal. Pero siempre recuerda, LUA está ahí para ti.