¿Qué lenguaje de script debería elegir para mi juego? [cerrado]

53

¿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)

Linus Sjögren
fuente

Respuestas:

39

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.

David McGraw
fuente
8
Lua es muy popular porque proporciona características de "metalenguaje". Puede implementar estructuras orientadas a objetos, o funciones procesales puras, etc. Tiene una interfaz C muy simple y le da al desarrollador del motor mucha flexibilidad en el lenguaje mismo.
Karantza
3
No estoy convencido de que Python sea una buena elección. Los enlaces de C para Python están mucho más orientados a extender Python con C, luego incrustar Python en C.
SpoonMeiser
55
Por lo que he escuchado, Ĺua también tiene un buen rendimiento en tiempo de ejecución en comparación con otros lenguajes de script como Python. (y tiene soporte completo para cierres, una característica realmente ingeniosa si me preguntas ...)
thbusch
2
En realidad, Civilization IV usa python ...
Emiliano
2
@happy_emi De hecho, mientras Civ V usa Lua
Tobias Kienzler
23

Ardilla

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:

  • corutinas
  • tablas y metatablas
  • tipo dinámico
  • mucho más

Nuevo en Squirrel:

  • clases
  • matrices
  • expresiones regulares en lugar de la sintaxis de coincidencia de Lua.
  • Lenguaje de estilo C / C ++ / Java / C # en lugar del estilo Pascal / Delphi.
  • mucho más

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.

código_deft
fuente
9

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.

FuzzYspo0N
fuente
Una desventaja para mí fue el tamaño. Si está creando un juego simple / casual, entonces el motor v8 es bastante grande e incluso puede ser mucho más grande que todo el juego.
Zack The Human
Es cierto, pero como un archivo .lib independiente, ¿es eso una gran preocupación? Simplemente se coloca al lado de su SDL, o su lua. Si te refieres al tamaño del código generado, bueno, no he probado qué tan grande es, pero eso no es un mal punto.
subrayó el
Me refería al tamaño del código generado. Supongo que no es TAN grande teniendo en cuenta el tamaño de la mayoría de los juegos de hoy.
Zack The Human
1
Probado, shell.cc predeterminado con los últimos relojes SVN en 1.441 MB bit.ly/9DNn8J . Si bien esto parece bastante pesado, la mayoría de las bibliotecas necesitan hacer cualquier otra cosa (redes, gráficos) se sumarán a eso de manera tan dramática. Un proyecto paralelo mío con v8, phoenixGL, ENet, racimos de impulso y mucho más código dentro de la solución (como compresión, encriptación, bibliotecas gui, awesomium) con 2.5 MB en Visual Studio 2008 - Y comprimido en un " liberar "construir pesos en 861 KB. Para mí, eso no es tan malo. En ciertas plataformas, podría ver que es problemático, aunque no para la mayoría :)
subrayó el
1
He usado V8 varias veces antes en mis proyectos. IMO Javascript es el lenguaje más ideal para usar para las secuencias de comandos de juegos. La naturaleza basada en eventos y los objetos basados ​​en prototipos hacen que todo sea tan fácil. :)
Stephen Belanger
7

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.

gman
fuente
Javascript es una muy buena idea. Me pregunto por qué no parece haber tenido tracción en este espacio. ¿Algunas ideas?
cflewis
JavaScript tiene tracción. La unidad lo usa. Lo mismo ocurre con Wolfire Games para su motor.
AA Grapsas
Dos motores realmente no hacen tracción. Supongo que la razón es solo un desarrollo reciente es que no ha habido muchos buenos intérpretes de JavaScript antes de Mono y V8. SpiderMonkey no es exactamente algo que miras y dices "Sí, ¡quiero que mi juego sea tan rápido, delgado y estable!"
4

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.

Sander van Rossen
fuente
44
Tenga en cuenta que si está haciendo el desarrollo de la consola, el código JITing está aparentemente fuera de discusión porque no puede marcar las páginas de datos como ejecutables. El IL tiene que ser precompilado en la plataforma de destino.
Jeff
3
El problema JIT también se aplica a iOS. También Mono tiene restricciones de licencia. Necesita una licencia comercial si desea usarla en un entorno donde el usuario final no puede / no puede actualizar el tiempo de ejecución de Mono.
Sam
4

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.

Stuart Golodetz
fuente
2

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.

Mike Strobel
fuente
2

Esquema

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.

Joe D
fuente
1

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.

cflewis
fuente
0

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".

Blackbone
fuente
0

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.

codeurgeon
fuente
0

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.

usuario266
fuente
-2

ActionScript es un lenguaje de tipo híbrido dinámico / estático utilizado para crear juegos Flash, que se puede distribuir ampliamente en la web. Está bastante bien soportado con bibliotecas como Flixel, FlashPunk y Box2d.

Iain
fuente
-2

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]

Andreas
fuente
Escribiría un intérprete o compilador jit en haskell para algo como lisp / esquema o bash o python o lua o erlang (cualquier cosa sin sus libs estándar) en uno o dos días. No sugeriría escribir un intérprete en C ++ o Java, siempre y cuando no sea para interpretar sth lisp like. Pero esa no era la pregunta, de todos modos.
comonad
Creo que la pregunta estaba más orientada a los pros y los contras de los lenguajes de script, no a cómo decidir cuál usar. Todavía útil, supongo.
Michael Coleman