c++ - que - lenguajes de programacion
El papel de los lenguajes de scripting en la programación de juegos (12)
Como de costumbre, creo que la respuesta es "depende".
No hay manera. Halo 3 o Call of Duty 4 podrían haberse basado principalmente en secuencias de comandos. Los títulos AAA mejor calificados deben, por definición, empujar el sobre de cualquier plataforma que toquen. Esto simplemente no se puede hacer con secuencias de comandos.
Los juegos casuales, sin embargo, son una historia diferente. Los grandes juegos como Unity tienen muchos scripts integrados.
También hay un mercado para mods. Un motor de juego sólido con un buen entorno de scripting puede ser una plataforma para retoques, derivaciones y, en algunos casos, juegos totalmente nuevos. Counter Strike es mi ejemplo favorito personal. Creo que estás limitado en este caso a los juegos de tipo FPS run-and-gun.
Entonces, hay un lugar para escribir guiones en los juegos, pero probablemente se mantendrá en el juego pequeño / casual y en el espacio del modificador.
Así que me he encontrado con un debate en el trabajo sobre cuál es el papel apropiado de un lenguaje de scripting en el desarrollo del juego. Por lo que puedo decir, hay dos escuelas de pensamiento sobre esto:
1) El lenguaje de scripting es poderoso y completo. Grandes porciones del código del juego están escritas en el lenguaje y el código solo se mueve a C ++ cuando el rendimiento dicta que es necesario. Esto es generalmente algo así como Lua o Unrealscript.
2) Este lenguaje de scripting es extremadamente limitado. Casi todos los códigos de juegos están en C ++ y el idioma solo está ahí para exponer la funcionalidad subyacente a los diseñadores.
Mi frustración proviene de ver el enfoque número dos frecuentemente abusado, con sistemas grandes implementados en un lenguaje que no tiene las características que hacen que ese código sea mantenible.
Así que comencé apoyando el enfoque número uno, pero después de hablar con algunos diseñadores, me di cuenta de que muchos de ellos prefieren el número dos, y en su mayoría son programadores que prefieren uno.
Así que todavía me pregunto qué enfoque es mejor. ¿Acabo de ver un código incorrecto y culpando a la herramienta en lugar de al programador, o realmente necesitamos una herramienta más compleja?
Como se ha dicho antes; utilice scripts para la lógica del juego y C ++ para la funcionalidad del juego. Un ejemplo sería escribir un modo de juego, pero usar C ++ para renderizar.
Creo que el equilibrio que desea es algo en este sentido: desea la lógica del juego en el guión, pero la funcionalidad del juego en el código.
Una gran ventaja del script es que puede configurar esperas fácilmente. Por ejemplo:
enemigo = GetObjectFromScene ("enemigo01"); en 5 segundos {enemigo.TrowGrenadeAt (jugador); }
Solo un ejemplo artificial. Ese tipo de lógica sería molesto de configurar en C ++. El script puede hacer que sea más fácil expresar este tipo de lógica, pero desearía que la funcionalidad real (las funciones que llama) esté en C ++.
Y el script no tiene que ser lento. Hay juegos con muchos guiones que se ejecutan a 60 fps en las consolas, pero requiere un buen diseño y encontrar el equilibrio adecuado entre las opciones 1 y 2 anteriores.
El ciclo compile-link-run-test para el código compilado de C ++ cuando se trata de algo tan complejo como un videojuego es muy, muy lento. El uso de un motor de scripting le permite realizar grandes cambios funcionales en el juego sin tener que compilar el programa. Este es un ahorro de tiempo masivo y masivo. Como dices, las cosas que necesitan optimización se pueden mover a C ++ según sea necesario.
Los motores AAA son altamente impulsados por secuencias de comandos. Torque, usado para Tribes II (¡y muchos otros juegos!) Está escrito, Unreal tiene Unrealscript y más. El scripting no es solo para mods, es clave para un desarrollo eficiente.
La comunidad de desarrollo de juegos ya usa el scripting como una forma muy común de construir interfaces de usuario y ajustar las respuestas de AI. Puedes encontrar mucha información en sitios como Gamasutra. Lo interesante es que los lenguajes estándar están comenzando a reemplazar a los intérpretes personalizados.
Dos de los mejores ejemplos de secuencias de comandos en juegos de AAA que vienen a la mente son World of Warcraft (usa Lua) y EvE Online (usa Python). EvE también utiliza scripts en el servidor: tienen una inversión significativa en Stackless Python.
Actualización: El rendimiento esencialmente no será un problema debido a las multinúcleas. Incluso las máquinas de gama baja terminarán con más núcleos que la pantalla y las actualizaciones del modelo. También podría gastar uno de esos núcleos ejecutando una solución de scripting para la interfaz de usuario.
Realmente no puedo ver el argumento de que grandes cantidades de código con guiones va a ser superior a grandes cantidades de C ++. Uno podría hacer el contra argumento. He visto proyectos grandes y terribles escritos en lenguajes de scripting que comenzaron con la mentalidad de scripting: hacer las cosas de manera rápida y sucia. Desafortunadamente, esto no se escala bien. Realmente no hay forma de hacer un argumento de calidad de código basado únicamente en el lenguaje de programación. La gente puede escribir montones de código de mantenimiento en cualquier idioma, compilado o guionado.
De todos modos, es realmente imposible saber la línea entre su "enfoque 1" y "enfoque 2" sin saber dónde están los cuellos de botella de rendimiento y qué es lo que sus usuarios van a querer más "guión".
Yo sugeriría un "enfoque 3" que es hacerlo todo o en parte en C ++ y exponer un SDK limpio en C ++. Esto tendría la ventaja de obligarlo a escribir su código como si fuera una interfaz de usuario que alguien fuera de su organización debe usar. Es de esperar que sea más fácil de mantener Y tenga el efecto secundario adicional de implementar su interfaz de scripting para usted. Toda su interfaz de scripting debería hacer ahora es reenviar a su SDK. ¡Viola!
Con este enfoque evitas tener que trazar una línea entre el dominio de lo que está "guionado" vs lo que está en C ++. Usted y sus usuarios tienen la opción de agregar funcionalidad en C ++ con el SDK o usar un lenguaje de scripting.
Uno de los mejores ejemplos de scripting en acción es Civilization IV. Utiliza Boost Python. Como resultado, es terriblemente lento. Un claro contrapunto a la afirmación de que "el código se mueve a C ++ cuando el rendimiento dicta que es necesario".
La forma correcta es diseñar una arquitectura desde el principio, y decidir qué problemas son computacionalmente difíciles y cuáles complejos para especificar desde el principio. Gráficos, física, identificación de caminos, retroalimentación instantánea en la entrada, texto a voz, todo claramente computacionalmente difícil. Las decisiones tipo AI "amistosa u hostil", "defender o atacar", "gastar o guardar" son complejas de especificar por adelantado.
La conclusión es que quieres exponer a los actores capaces, pero desalmados, a tu código de scripting. El código de scripting describe lo que los actores deberían hacer, pero el código de C ++ se ocupa del cómo .
Con respecto al ciclo de compilación-enlace, es importante tener una arquitectura modular adecuada. Cuando trabaje en la lógica de pathfinding, nunca debería tener que compilar código de gráficos. Además, herramientas como Incredibuild pueden ayudar a acelerar los tiempos de compilación. Las empresas de juegos grandes probablemente ya tengan una granja de renderizado, que se puede duplicar bastante bien como una granja de compilación.
Si dividimos un juego en dos partes: el motor y el juego real (diseño).
Un motor de juego de primera clase sólido probablemente está escrito en C / C ++ y algunas personas incluso optimizan aún más con el código ensamblador. Puede hacer muchas cosas realmente rápidas para gráficos y física con instrucciones específicas de la CPU. No hay forma de obtener rendimiento cuando se renderizan paisajes grandes o múltiples objetos complejos solo desde un lenguaje de scripting.
Cuando se trata del juego en sí, hay muchos aspectos que se pueden hacer en lenguajes de programación lentos pero de mayor nivel. La inteligencia artificial y otra lógica del juego se pueden escribir en el guión con éxito. Puede acelerar el desarrollo y se abre para modding y expansiones de la comunidad de una manera simple.
Así que comencé apoyando el enfoque número uno, pero después de hablar con algunos diseñadores, me di cuenta de que muchos de ellos prefieren el número dos, y en su mayoría son programadores que prefieren uno.
Esto debería tener un sentido obvio: si el lenguaje de scripting es "potente y con todas las funciones", los diseñadores tendrán que crear los sistemas, ya que esta oportunidad está disponible para ellos. Por otro lado, si el lenguaje de scripting solo expone pequeños detalles del juego codificado, entonces los programadores tienen que crear esos sistemas, ya que los diseñadores no pueden. No estoy diciendo que cada lado es flojo, pero obviamente ambos tienen habilidades individuales que el proyecto requiere que se centren (ya que nadie más puede hacerlo de manera efectiva), lo que significa que siempre hay un interés en hacer que otra persona haga una tarea determinada si posible.
Y como consecuencia de esto, el rol adecuado dependerá de cómo se diseñen los recursos humanos en su empresa, junto con los requisitos de rendimiento de su juego. Una vez que tenga una idea de cuántas personas necesitarán algún tipo de secuencia de comandos, sabrá qué parte del juego lo requerirá y, por lo tanto, puede decidir qué tan amplia o estrecha debe ser la interfaz. Esto contribuye a lo que sería el "dominio" del idioma, como lo menciona onebyone.livejournal.com arriba.
(Por lo poco que vale, soy un desarrollador de juegos profesional y también el moderador del foro de Scripting Languages en Gamedev.net.)
Creo que el póster aquí es correcto para favorecer el método n. ° 1. Es un método más limpio y ofrecerá mejores resultados a largo plazo a pesar de las quejas de los diseñadores. Al final, el código determinará una buena programación de juego desde mediocre (malo).
Decir que los juegos se deben hacer solo con C ++ (o afirmar que los títulos de AAA se hacen así) es simplemente ignorante. La mayoría de los juegos hoy en día tienen secuencias de comandos de una u otra forma, ya sea un lenguaje de scripting propietario (UnrealScript), lenguaje genérico (Lua, python, C #, Java, etc.) o basado en datos (xml, formato binario patentado, etc.). Simplemente investigue y descubrirá que la mayoría de los motores emplean scripts de una forma u otra.
Creo que la cuestión de si tener 1) lenguaje de scripting potente y completo frente a 2) lenguaje de scripting extremadamente limitado es abordar el problema desde el lado equivocado. El entorno de scripting (basado en lenguaje o datos) debe diseñarse de modo que sea el mejor soporte para el proceso de creación del juego. La expresividad del sistema es crucial aquí: los diseñadores y scripters deberían ser capaces de resolver fácilmente los problemas que tienen sin demasiados dolores de cabeza mientras que no deberían estar expuestos a un sistema demasiado complejo que les resulte difícil comprender y aprender. A menudo, los programadores (incluido yo mismo) tienden a diseñar sistemas haciendo suposiciones sobre cómo se utilizarán y tratando de garantizar que todas las características entre la tierra y el cielo puedan implementarse, lo que da como resultado sistemas complejos. Al verse abrumados por esta complejidad, los diseñadores terminan usando lo mínimo para hacer el trabajo.
Por ejemplo, en nuestro juego ( Rochard ) diseñamos un sistema de inteligencia de datos completamente expandible y con secuencias de comandos, pero los diseñadores de niveles terminaron usando solo los patrones de IA de stock porque no tenían tiempo ni esfuerzo para utilizar el sistema de inteligencia artificial al máximo grado. Así que, al final, acabo de crear una buena interfaz de usuario para elegir fácilmente esos patrones de IA de stock.
Yo diría que no hay una bala de plata en este asunto.
Creo que los diseñadores necesitan ver un lenguaje adecuado para ellos. Eso no es negociable: tienen que dedicar su tiempo al diseño, no a la programación.
Si las secuencias de comandos permiten un rápido desarrollo de código de juego digno de un producto, los programadores también deberían hacerlo. Pero tiene que ser productivo: hacer todo dos veces no ahorra tiempo. Por lo tanto, debe mantener las secuencias de comandos en su lugar. Si un desarrollador puede guiar el sistema de inventario en una semana, o escribirlo en C ++ en un mes, entonces usted quiere un guion completo, solo para darle más tiempo para optimizar las partes que posiblemente alcancen los límites de rendimiento. Entonces no es el inventario, ni la tabla de puntaje alto, ni el sistema de mapeo de teclas, ni la lógica de juego de alto nivel, como lo que se supone que hacen los personajes. Todo eso puede ser escrito si eso le ahorra tiempo para gastar en acelerar los gráficos y la física: los programadores deben ser capaces de resolver exactamente cuáles son los cuellos de botella, y los programadores pueden hacer una predicción razonable de lo que ganó. t ser
Los diseñadores probablemente no deberían saber o preocuparse si los programadores están usando el lenguaje de scripting para implementar el código del juego. No deberían tener una opinión sobre si (1) es bueno o malo. Entonces, incluso si los programadores están en lo cierto al querer (1), ¿por qué esto molesta a los diseñadores? ¿Cómo han notado que el lenguaje de scripting tiene todas las funciones, si lo único que necesitan es un número bastante pequeño de recetas estándar? Algo ha ido mal, pero no creo que Lua sea un lenguaje demasiado bueno.
Una posibilidad es que el uso del mismo lenguaje de scripting para ambos se convierta en un obstáculo para trazar una línea definida entre las interfaces utilizadas por los diseñadores y las interfaces internas del código del juego. Eso, como dije en la parte superior, no es negociable. Incluso si usan el mismo lenguaje de scripting, los programadores aún tienen que proporcionar a los diseñadores la funcionalidad que necesitan para hacer su trabajo. El hecho de que los diseñadores usen Lua para codificar las estrategias de inteligencia artificial y los árboles de conversación, y Lua es un lenguaje con todas las funciones capaz de escribir un motor de física, no significa que se espera que sus diseñadores escriban su propio motor de física. O usa más del 10% de las capacidades de Lua.
Probablemente puedas hacer ambos (1) y (2), mente. No hay ninguna razón por la que no se pueda dar a los programadores Lua, y a los diseñadores, un DSL en miniatura con pocas funciones que se "compila" en Lua con un guión Lua.