¿Por qué usamos scripts en el desarrollo?

67

En mi proyecto actual, los scripts de Lua son llamados por las funciones de C ++ en el lado del servidor. Después de eso, los scripts vuelven a llamar a las funciones de C ++ que todavía están en esa solución. ¿Por qué deberíamos hacer tales cosas y no llamar a la función C ++ directamente? ¿En qué situaciones se necesitan los guiones?

scripting Josh
fuente

Respuestas:

73

Los scripts generalmente se compilan en tiempo de ejecución , mientras que el idioma del host se compilará en tiempo de compilación. Esto significa que no necesitamos volver a compilar si el script cambia. Volver a compilar un juego completo puede llevar de minutos a horas, lo que implica un gran éxito de productividad.

Por lo general, el código crítico o el código de fondo no se incluirán en la secuencia de comandos. Este código debe ejecutarse rápidamente y, a menudo, la administración de la memoria es crucial.
En los juegos, la lógica y la configuración del juego suelen estar contenidas en archivos de script. Estos scripts pueden ser actualizados fácilmente por no programadores (como el diseñador) para modificar el juego. Los lenguajes de script son fáciles y actúan de manera indulgente para ese propósito.

A menudo, un lenguaje de script también se usa para hacer scripts en tiempo real . Esto es útil para ajustar algunos elementos de juego o incluso para depurar. Muchos juegos proporcionan una consola para este propósito (principalmente interno).

Es muy posible que crees un juego usando un motor de juego existente, solo mediante secuencias de comandos. La capa del motor del juego se desacopla por completo de la capa lógica del juego . Los motores modernos generalmente se pueden usar para crear juegos FPS o RTS fácilmente como este, pero no es posible para ningún género. Un MMO probablemente requeriría otro tipo de motor.

Entonces, el resultado final es el desacoplamiento. Los beneficios enumerados anteriormente a menudo superan el trabajo adicional para crear o integrar un lenguaje de secuencias de comandos.

Nef
fuente
77
+1 por decir que los scripts son generalmente más fáciles de actualizar por los no programadores. Los diseñadores no siempre son programadores, y no tienen que serlo.
Roble
19
Siento que me estoy repitiendo en cada pregunta sobre las secuencias de comandos: si su flujo de trabajo requiere que los no programadores programen (lo que incluye las secuencias de comandos), lo morderá por el culo más tarde. Los diseñadores no siempre son programadores, pero tan pronto como escriben scripts no triviales (por ejemplo, tan pronto como intentan definir una función o usan un bucle) fingen ser uno. Si no tienen entrenamiento en programación, eso terminará en lágrimas y tiempo perdido para todos.
55
Joe: eso no invalida el argumento, solo significa que tienes que decidir dónde desacoplar las "cosas de programación" de las "cosas de diseño" y la línea divisoria será diferente según la experiencia técnica de tus diseñadores (o falta del mismo).
Ian Schreiber
3
Estoy bastante seguro de que cualquier diseñador que se respete a sí mismo está bien enseñado en al menos un idioma. Para aclarar un poco las cosas, me gustaría matizar el término "no programador" como alguien cuya profesión no es la de un ingeniero de software. Lamento usar el término, gracias a Joe veo que es ambiguo. Creo que hay una amplia gama de programadores, desde los que escriben XML simple hasta el ensamblaje hardcore o el procesamiento matemático de señales pesadas. Espero que esto resuelva el problema de dualidad "no programador".
Nef
8
No escuché a nadie sugerir que los diseñadores deberían escribir scripts complejos y de misión crítica para la producción. Sin embargo, los diseñadores con una comprensión modesta de la programación aún podrían modificar algunos scripts experimentalmente (y luego entregarlos a los programadores reales). Ciertamente podrían escribir scripts ad hoc simples desde una consola en tiempo de ejecución para facilitar sus propias pruebas. Me imagino que los diseñadores podrían aprovechar las secuencias de comandos básicas para crear prototipos de nuevos diseños de pantalla (incluso si no son más que maquetas interactivas y semifuncionales). Se debe escribir un montón de código que no sea de producción.
Mike Strobel el
38

Hiciste la pregunta equivocada. La verdadera pregunta, creo, es ¿por qué soportamos lenguajes "sin script" como C, C ++, Java, etc. Y la respuesta es una razón: rendimiento. (Y tal vez la inercia, pero esa inercia está ahí debido al rendimiento, y cualquiera que pueda escribir bien C / C ++ / Java puede escribir al menos Ruby / Python / Lua / JavaScript aceptable).

Usamos lenguajes de "scripting" (lo que realmente significa, muy alto nivel, recolección de basura y, por lo general, alguna forma de escritura más flexible y compilación dinámica) porque generalmente son lenguajes más fáciles para cualquier persona, incluidos los programadores, para escribir código. Hay menos cosas estúpidas como recordar liberar después de malloc o asegurarse de que su código sea seguro para excepciones, o recordar hacer que todos sus destructores sean virtuales. Si nuestras computadoras fueran infinitamente rápidas, estaríamos usando lenguajes de "script" para todo.


fuente
44
Me gusta este argumento de manera mucho mejor que "lo que los diseñadores pueden programar." Es una muy mala idea descartar el valor del desarrollo rápido y poder experimentar con los cambios sin recompilar todo.
ojrac
10

Los lenguajes de secuencias de comandos para la lógica del juego son un muy buen ejemplo del patrón de arquitectura de software Alternate Hard and Soft Layers . Hay una buena discusión en ese sitio (y otros, estoy seguro) sobre los beneficios de hacerlo.

Tétrada
fuente
8
  1. Cada nueva clase lua tiene dos líneas. Cada nueva clase de C ++ es dolor.
  2. No te quejes de los tipos cuando todo lo que quieres es mezclar valores.
  3. Recolección de basura.
  4. El código de script está muy bien aislado en máquinas virtuales, lejos de todos esos desagradables segfaults errantes y desbordamientos de matriz.
zaratustra
fuente
5

Los cambios de script son fáciles de implementar. Por ejemplo, puede mantener los scripts en una base de datos, lo que significa que, en lugar de una redistribución binaria completa y un posible reinicio del servicio, simplemente emite una sola instrucción UPDATE de SQL, posiblemente seguida de una señal a su servicio en ejecución para recargar el script.

Además, los lenguajes de script a menudo son simples de entender y fáciles de programar, por lo que no necesita los desarrolladores 'hardcore' (los que se ocupan de la gestión de memoria / punteros y optimizaciones de nivel de CPU) para la mayoría del código (si es un juego de rol grande, los scripts para IA, hechizos, efectos de objetos y el mundo en sí son a menudo más grandes que el código del motor). Los lenguajes de script permiten un mayor enfoque en el 'qué' en lugar del 'cómo' debido a la recolección de basura (en el caso de Lua) y un mayor nivel de abstracción.

Michael Stum
fuente
4

Un escenario en el que los scripts son útiles es cuando queremos que nuestro motor sea extensible por complementos / complementos. Estas extensiones son creadas en muchos casos por personas no profesionales (como jugadores avanzados y entusiastas). Los guiones son más seguros y fáciles para este propósito. Al usar scripts, no necesitan usar compiladores, y no necesitan estar al tanto de los punteros ...

Un gran ejemplo de esto es el juego World of Warcraft. Tiene miles de complementos creados por la comunidad. Estos complementos se escriben utilizando LUA + XML.

Dani
fuente