¿Con qué lenguaje funcional es más adecuado para crear juegos? [cerrado]


19

He tenido un ojo en los lenguajes de programación funcionales por un tiempo, pero dudo en entrar en ellos. Pero creo que es hora de que al menos empiece a mirar en esa dirección para asegurarme de que estoy listo para cualquier cosa.

He visto hablar de Haskell, F #, Scala, etc. Pero no tengo idea de las diferencias entre los idiomas y sus comunidades, ni me importa particularmente; excepto en el contexto del desarrollo del juego.

Entonces, desde el punto de vista del desarrollo de juegos, ¿ qué lenguaje de programación funcional tiene las características más adecuadas para la programación de juegos? Por ejemplo, ¿hay bibliotecas / motores / marcos de desarrollo de juegos funcionales o motores gráficos para lenguajes funcionales? ¿Existe algún lenguaje que maneje mejor ciertas estructuras de datos que se usan comúnmente en el desarrollo de juegos?

En pocas palabras: ¿qué lenguaje de programación funcional es mejor para la programación funcional de juegos y por qué?

Creo / espero que esta pregunta declare un mejor lenguaje claro, por lo tanto, no la he marcado CW a pesar de su tendencia subjetiva.


2
"¿Qué quieres decir con juegos en 2D o juegos en 3D?" "¿Eh? No lo sé - aieeee "
Cyclops

@ Cyclops uh, ¿qué? No entiendo ...
Ricket

@Ricket, en parte fue una solicitud para aclarar de qué tipo de juego estás hablando, 2D o 3D (y tal vez en tiempo real o por turnos). En parte fue una broma de Monty-Python que oscureció la primera parte. Wups :) Y creo que es útil especificar el tipo de juego, a menos que haya un solo lenguaje funcional que sea perfecto para todo , entonces diferentes idiomas pueden ser mejores en diferentes cosas.
Cyclops

No creo que 2D o 3D afecten la elección de un idioma, excepto por la variedad de motores / bibliotecas disponibles para un idioma. Personalmente estoy interesado en 2D y 3D, así que no estaba pensando en uno u otro al escribir esta pregunta. Pero, en general, los juegos en 2D y 3D comparten una gran cantidad de sistemas y estructuras de datos comunes (por ejemplo, audio, entrada, IA, estructura del programa, bucle de juego) y hay muchos juegos en 3D que podrían transferirse a 2D o viceversa. Y sí, no he visto a Monty Python, por eso no lo entendí en absoluto. :)
Ricket

1
No creo que haya una respuesta definitiva sobre el mejor idioma.
Wei Hu

Respuestas:


12

F # es parte de la familia Microsofts .net tiene acceso a XNA, que es una base fantástica para crear juegos. Un poco de google aparece algunos tutoriales, videos y artículos. Los excelentes documentos de XNA también deberían ayudar.

Ha habido algo de movimiento en los juegos para Haskell también, mira aquí . Probablemente usarás enlaces openGL.

Dado que Scala juega en tierra Java, se integra con todos los motores / enlaces Java disponibles, vea esta publicación SO .

Creo que todo se reduce a preferencias, aunque solo he jugado con Haskell, imagino que cada lenguaje funcional tiene su propia idiosincrasia. Puede valer la pena preparar un pequeño juego de prueba en cada uno y ver cuál te parece mejor.

Como dije, solo tengo una experiencia mínima de Haskell, así que no puedo comentar sobre lo mejor, pero estos recursos deberían ayudarlo a comenzar con suerte.


2
Entre los problemas con las JVM y la inmadurez de la implementación del compilador, he encontrado que el rendimiento de Scala es inaceptable cuando se usa un estilo funcional, aunque el lenguaje en sí mismo lo admite bien. Termina siendo tan rápido como, por ejemplo, Python o Ruby, no F # u OCaml. (La velocidad de Scala es competitiva para más estilos de OO / procedimientos.)

De hecho, obtuve un proyecto F # ejecutando XNA (que es una ventana XNA vacía con azul aciano, solo que el código era F # y no C #.
RCIX

8

Yo diría Lisp.

Se ha utilizado en juegos como lenguaje de script, al menos en Naughty Dog (o eso creo), y es un lenguaje muy maduro.

La ventaja de Lisp está en la deserialización, que es una parte importante de lo que llamamos gestión de activos. La deserialización del lisp es trivial, el código y los datos son uno. Esto facilita tener un formato de archivo para activos y comportamientos. No es como uno en json / xml / yaml / bin y un archivo F # para AI. Puede guardar todo como expresiones s, lo que simplificará mucho la canalización de activos.


TBH lo recomendaría contra esto. Los lenguajes de script no son solo para que los use el desarrollador; los modders querrán modificar el juego, y no hay nada que los asuste más rápido que (() ()))) () ((()). Además, incluso en lo que respecta a los lenguajes funcionales, Lisp es esotérico.
RCIX

77
Si asustar a los modders es algo que te preocupa, buscar un lenguaje funcional probablemente no sea el movimiento correcto.
Paul Wicks

3
@RCIX & @Joe - Necro potencia ACTIVATE. De todos modos, Scheme se usa como lenguaje de enseñanza. SICP es algo así como la mitad de un título de CS en un libro y es utilizado por un montón de escuelas (incluido MIT hasta hace poco), y HTDP es una introducción menos dura.
Jesse Millikan

1
@RCIX y Joe de hecho. lisp & esquema son los idiomas introductorios en muchas universidades.
Oberhamsi

1
Lisp no es algo que quieras usar. Naughty Dog tenía UN solo programador Lisp y cuando renunció, hicieron la transición de todos sus motores a C ++. No tengo idea de por qué un motor obsoleto de una compañía se arrastra como un ejemplo brillante todo el tiempo =)
Patrick Hughes

8

Después de adquirir algo de experiencia práctica con él, votaría por Clojure, que ya ha escrito un pequeño juego en él, y planea hacer más.

Razones:

  • Productividad : Clojure es un lenguaje dinámico. Tiene excelentes características para el desarrollo interactivo de estilo REPL, por ejemplo, puede usar REPL para consultar o alterar el estado dentro de una instancia de aplicación de juego en ejecución. El código en Clojure también es a menudo ridículamente conciso. Supongo que soy 3-5 veces más productivo en Clojure que en Java o C #.
  • Impuro : si bien aprecio la belleza y la elegancia de los lenguajes funcionales puros como Haskell, la programación de juegos es una búsqueda desordenada donde gana el pragmatismo. Quiero poder poner efectos secundarios en mis funciones cuando los necesito, y Clojure lo permite. Dicho esto, el estilo idiomático de Clojure debe ser puramente funcional la mayor parte del tiempo .
  • Metaprogramación : la herencia Lisp de Clojure como lenguaje homoicónico lo hace ideal para la metaprogramación / generación de código. Es fácil "extender el lenguaje" para hacer sus propios DSL o eliminar bioplaca. Podrías usar Clojure fácilmente como su propio lenguaje de programación de juegos, y la compilación de código dinámico significa que tus secuencias de comandos se ejecutarán tan rápido como tu motor de juego principal.
  • Acceso a bibliotecas Java . Puede utilizar todas las bibliotecas de sonido / gráficos / AI / redes de Java, lo cual es una gran ventaja frente a la mayoría de los otros lenguajes funcionales (donde tendrá que escribirlos desde cero o desarrollar un montón de código de interfaz complicado). Esto puede ser un salvavidas.
  • Multiplataforma : esto se puede ejecutar de forma gratuita en la JVM, pero es una buena ventaja.
  • Rendimiento : para un lenguaje funcional dinámico, Clojure es lo más rápido posible. Siempre se compila JIT, nunca se interpreta. Con la optimización inteligente, puede igualar la velocidad del código Java puro de bajo nivel en Clojure. Por ejemplo, puede usar matrices primitivas de Java o proporcionar sugerencias de tipo para garantizar que el compilador produzca llamadas de función con tipo estático en código de rendimiento crítico.
  • Concurrencia : Clojure tiene un gran modelo para administrar el estado concurrente, respaldado por un impresionante sistema de memoria transaccional de software. Vale la pena ver este video para obtener más información sobre cómo funciona esto.

El único momento en que no consideraría Clojure sería si estuviera escribiendo un juego de vanguardia gráficamente intensivo en el que necesita un rendimiento de vanguardia (donde todavía creo que necesita C / C ++).

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.