¿En qué casos son mejores los lenguajes de script que otros?
Todas las respuestas son apreciadas, proporcione una descripción y describa en qué casos se destaca el idioma.
(Recuerde, un idioma por respuesta)
¿En qué casos son mejores los lenguajes de script que otros?
Todas las respuestas son apreciadas, proporcione una descripción y describa en qué casos se destaca el idioma.
(Recuerde, un idioma por respuesta)
Respuestas:
Lua es ampliamente utilizado en la industria del juego . Desde juegos independientes ( Aquaria ) hasta títulos AAA (Civilization).
¿La razón principal? Diría que es fácil de aprender y fácil de incorporar a tus juegos. Pero lo mismo podría decirse de Python, estoy seguro. Las secuencias de comandos, en general, no son difíciles. Creo que la verdadera razón por la que deberías ir con Lua es porque está comprobado, lo que resulta en muchos más recursos para que aprendas ... Si tienes ganas de experimentar con algo fuera de lo normal, entonces comenzaría a jugar con otro idioma.
La ardilla tiene una historia interesante. Fue construido después de que un arquitecto del juego tuvo problemas con la recolección de basura impredecible de Lua, y loco todo es nulo, incluso si no existe .
Squirrel es el lenguaje sripting utilizado en Left 4 Dead 2 . La API es muy parecida a lua (al autor de Squirrel le encanta el diseño de Lua ).
Entonces Squirrel es un lenguaje increíble, ya que es un poco Lua de segunda generación. Tomó las buenas ideas y eliminó las molestas excentricidades.
Lo mismo de Lua:
Nuevo en Squirrel:
La principal desventaja de Squirrel es que no es Lua. Lua es mucho más ampliamente utilizado. Pero si eso no es un problema, Squirrel es una victoria fácil. Sin embargo, a menudo la popularidad del lenguaje es una característica útil en sí misma, por lo que la decisión no es tan clara.
V8 Javascript de google.
PRO:
Bastante fácil de usar
Mejorando constantemente
Potente y flexible.
Otros Como muchos mencionaron, JavaScript es una herramienta de programación común. Agregarlo a mis juegos ha abierto muchas más personas que se sienten capaces que otros idiomas. También admite una gran cantidad de conversión y conversión para ahorrar trabajo para el programador, también lo hace realmente fácil de usar, funciona bien con STL.
Posibles CON:
La documentación puede ser confusa. Realmente no es la mejor.
Ejemplos A menudo, una red de rarezas. Al carecer de una simplicidad sólida, se presenta como un nivel mucho más alto de lo que es.
Plantillas A veces, estas son odiadas o evitadas.
Tamaño de la base de código del SDK El tamaño del código generado puede considerarse hinchado.
Eso depende del juego y su plataforma objetivo.
Un juego que ejecuta 100 personajes que no son jugadores (juegos RTS) tiene diferentes necesidades que un juego que ejecuta solo 2 (Street Fighter). Un juego que se ejecuta en una PC tiene diferentes necesidades que un juego que se ejecuta en una consola.
Lua es popular
GameMonkey es utilizado por varios equipos. Es más rápido que Lua y mejor en subprocesos.
Python se ha usado en varios juegos.
JavaScript es una opción posible ya que puede descargar motores de JavaScript. Hay más programadores de JavaScript que cualquier otro tipo de programador.
También hay idiomas especializados.
SCUMM se ha utilizado en varios juegos de aventuras y es particularmente adecuado para esos juegos.
En aras de la integridad, otra opción es mono-script , que le permite utilizar la implementación de Novell del marco .NET para scripts. Es lo que usa Unity . Aquí hay otra página sobre incrustar mono en su aplicación.
El marco Mono es más rápido que la mayoría (¿quizás todos?) De lenguajes de secuencias de comandos porque no se interpreta y porque hay una capa entre el compilador y el conjunto de instrucciones, le permite programar en una variedad de lenguajes, incluidos C # y dialectos de Python, Lua y Javascript.
Sin embargo, no estoy seguro de si es gratis en todas las plataformas.
Personalmente, encontré que AngelScript (ver el enlace a continuación) es mucho más fácil de vincular a C ++ que Lua cuando estaba eligiendo un lenguaje de script para mi propio proyecto. (De hecho, escribí una pequeña biblioteca de envoltorios para que sea aún más fácil de usar, a costa de cierta flexibilidad).
http://www.angelcode.com/angelscript/
Dicho esto, sospecho que Lua tiene algunas ventajas que lo hacen atractivo para los desarrolladores de juegos comerciales:
(a) Es más maduro y extendido que AngelScript
(b) Su sintaxis es más fácil para los no programadores (AngelScript es muy parecido a C ++)
(c) Tiene una huella más pequeña que AngelScript (al menos por lo que recuerdo)
Sin embargo, si solo está escribiendo un proyecto de pasatiempo, diría que al menos vale la pena echar un vistazo a AngelScript.
Debes elegir un lenguaje de secuencias de comandos que tenga enlaces estables y bien compatibles con el lenguaje de desarrollo principal de tu juego. Si está escribiendo su juego en C o C ++, entonces hay enlaces bastante sólidos disponibles para Python y Lua. Si está escribiendo su juego para la plataforma .NET (usando C # u otro lenguaje), le recomiendo usar IronPython o IronRuby. Ambas son implementaciones completas de lenguaje que aprovechan el Dynamic Language Runtime (DLR) de Microsoft, que proporciona un excelente rendimiento y una integración muy estrecha con .NET Framework. La interoperabilidad entre C # y IronPython / IronRuby es bastante fluida en estos días, especialmente con la introducción del enlace dinámico del sitio de llamadas en C # 4.0.
Bueno, engaño específicamente.
Con guile puedes tener tu propio DSL (lenguaje específico de dominio) solo para tu juego. Una vez que te acostumbras a los paréntesis y la notación de prefijos, el esquema es un paraíso para trabajar.
Si vas a usar la astucia en un juego serio, esperaría un par de meses hasta la versión 2.0, ya que eso incluirá, IIRC, un intérprete Ecmascript, así como el esquema actual. También puede esperar ver grandes mejoras de velocidad.
Esto depende de lo que realmente necesita. Como señala David, Lua es muy popular, aunque un desarrollador de juegos me señaló que no estaba completamente seguro de por qué. Creo que su ligereza es una razón común, pero en este punto, esperaría que mucha gente use Lua porque se ha convertido en el estándar de facto. Parece mejor para una modificación muy ligera.
Para un enfoque más completo, diría que Python es la elección correcta. Civ IV lo usó con un efecto decente.
Elegir un lenguaje de secuencias de comandos en lugar de otro depende de sus requisitos específicos.
Algunas de las opciones que tiene para elegir podrían ser:
Velocidad del intérprete: si la característica de la secuencia de comandos es utilizada únicamente por los desarrolladores, es decir, la secuencia de comandos del comportamiento estático, entonces la velocidad y una API ampliable pueden ser el aspecto más importante. Tuve algunas buenas experiencias con LUA allí.
Fácil de aprender, accesibilidad: para un diseñador de contenido / nivel puede ser difícil aprender lenguajes de secuencias de comandos más complejos (depende del fondo) para generar un comportamiento dinámico. En ese caso, el uso de lenguajes fáciles de aprender (es decir, de uso común) y bien documentados podría ser más apropiado aquí. JavaScript o Python podría ser una buena solución aquí.
Integración de flujo de trabajo: si tiene una canalización de producción específica con herramientas ya existentes, podría ser una mala idea usar un lenguaje que parezca funcionar mejor para un caso dado si las otras herramientas están trabajando con una completamente diferente. Esto es especialmente válido si tiene varios programadores trabajando en las diferentes herramientas. En ese caso, podría ser más eficiente utilizar el lenguaje "no muy adecuado".
Si está trabajando en un título para Windows y escribiendo código administrado que se ejecuta sobre Common Language Runtime (CLR), digamos, por ejemplo, en C #, le sugiero que eche un vistazo a la integración de (Iron) Python como lenguaje de secuencias de comandos.
En mi experiencia, Python es muy fácil de enseñar a los no programadores / diseñadores. Es aún más fácil de aprender para los desarrolladores, ya que esencialmente se lee como pseudocódigo. Ser tipeado dinámicamente es solo uno de los aspectos que ayudan a que las personas con poca o ninguna experiencia previa en codificación se pongan en marcha rápidamente con el lenguaje.
Además de que el lenguaje es fácil de aprender y poderoso, el CLR y los equipos de idiomas de Microsoft (Anders Hejlsberg, Eric Lippert, Mads Torgersen, Jim Hugunin et al.) Han hecho un gran trabajo al exponer las características del compilador y el tiempo de ejecución a través del nuevo Dynamic Language Runtime (DLR) en .NET 4, lo que hace que la interoperabilidad entre el código de tipo estático y el código de tipo dinámico sea mucho más sencillo. Por lo que he visto y probado hasta ahora, el código repetitivo se reduce al mínimo. Mantendrá su base de código limpia y mantenible.
Puedes utilizar esto para mantener muy baja la fricción entre las partes de tu juego y el motor. Tener ambos ejecutados dentro de la misma máquina virtual también hará posible que el tiempo de ejecución optimice más su código durante la ejecución.
La respuesta depende mucho de su entorno. Actualmente estoy trabajando con Unity, así que uso un lenguaje basado en mono (en mi caso C #, pero Javascript y Boo también son opciones). La respuesta depende completamente de tus circunstancias específicas.
Si tiene un equipo existente que utilizará el lenguaje de secuencias de comandos o un diseñador principal (nivel) que utilizará las secuencias de comandos, elija el idioma que elija. Pasarán su tiempo con él, por lo que deben ser atendidos.
[grano de sal] Si no tienes a nadie o plan a largo plazo, entonces hazlo tú mismo . Sí, escribir un compilador y / o un intérprete para un lenguaje de secuencias de comandos puede llevar una semana o dos, pero a la larga la flexibilidad pagará muchas veces. Simplemente no te vayas por el mal camino y reinvente el cerebro. [/grano de sal]