¿Hay algún motor de juego que use un lenguaje de programación funcional? [cerrado]

10

¿Existe algún motor de juego que use un lenguaje de programación funcional similar a Scheme, Common Lisp, Clojure o JavaScript?

He probado Unity3D pero su "JavaScript" no es en realidad JavaScript, está fuertemente tipado y no es funcional.

functional

— MaiaVictor
fuente

2

Estoy usando ThreeJS, pero, aunque está lleno de genialidad, es la falta de una comunidad activa y la documentación es un problema grave.

— MaiaVictor

55

¿Por qué querrías programar en un lenguaje de programación funcional? ¿Cuál es el problema al que te enfrentas? Por favor sé más específico. Tal como está, esta pregunta es demasiado general para producir una respuesta correcta y es propenso a generar una lista de respuestas (todas igualmente "correctas") como esta: - ¿Qué tal Clojure combinado con cualquier motor de juego Java? - ¿Qué tal adoptar un estilo de programación funcional en un lenguaje que no es funcional per se? (Lea Programación funcional en C ++ por Carmack.) - etc.

— Eric

2

El Javascript de Unity3D es tan funcional como el Javascript normal , solo necesita usar tipos C # 4.0, algo como:var add : Func<int, int, int> = ...

— fableal

2

Consulte las preguntas frecuentes sobre las preguntas "Qué tecnología utilizar". Esta pregunta, como muestran las respuestas, solo está generando una lista. No es constructivo ya que no hay una única respuesta correcta (aparte de "Sí, la hay"). Este no es el lugar para compilar listas.

— MichaelHouse

2

Esta es una especie de problema de "herramienta adecuada para el trabajo correcto". La programación funcional se centra principalmente en minimizar y eliminar, siempre que sea posible, el estado mutable. Eso puede funcionar bien para ciertas clases de aplicaciones, pero es completamente antitético a la forma en que funciona cualquier juego.

— Mason Wheeler

7

Hay LambdaCube que está escrito en Haskell (no es exactamente un motor de juego, sino más bien un motor de gráficos).

— tumdum
fuente

2

Esto también podría ser de su interés (comentario general de Tim Sweeney de Epic)

— tumdum

Enlace interesante, hay un ppt aquí

— bobobobo

2

Siempre puede usar f # o iron python (sí, lo sé, python no es funcional) o cualquier otro lenguaje .netified con XNA en la plataforma .net.

http://fsharpgamedev.codeplex.com/ http://www.ironpython.info/index.php/XNA_Example_with_a_Bouncing_Sprite

editar: Un motor más, escrito en Lisp: http://code.google.com/p/blackthorn-engine/

— Grzegorz Sławecki
fuente

2

No tengo una respuesta a la pregunta tal como está escrita, pero creo que posiblemente estés tratando de preguntarte "por qué no hay motores de juego más funcionales" en lugar de buscar uno específico para usar. Si eso es correcto, debe reformular la pregunta. Si no ... ignórame. :)

Un enfoque funcional puro no es una buena opción para los juegos. Juegos (y gráficos, física e IA) y básicamente todo sobre cambios de estado. El enfoque funcional correcto para estos problemas sería calcular un estado completamente nuevo una vez por bucle, lo que tendrá una penalización de rendimiento muy severa en comparación con la codificación más directa de cómo funciona el hardware real.

Es por esa razón que no ves ningún motor de juego de estilo funcional en producción. Es simplemente el paradigma de programación incorrecto para la mayoría de los problemas que un motor de juego debe resolver. Es el paradigma de programación incorrecto para la mayoría de los problemas que también deben resolverse en scripting de nivel superior y código de lógica de juego. Si bien es casi seguro que sea posible hacer un motor de juego funcional, sería lento, difícil y engorroso de usar, y no tendría otro propósito real que ser una demostración / juguete ordenado para presumir.

Eso no quiere decir que la programación funcional no tenga un lugar en algún lugar de los juegos. Utilizo un estilo de codificación muy funcional (cuando corresponda) en C #, Unity JavaScript e incluso C ++ 11. Algunos problemas muy específicos son mejores o al menos más fáciles de resolver con un estilo funcional, y la mayoría de los lenguajes populares actuales admiten esa forma de programación, aunque de una manera más engorrosa que los lenguajes funcionales "reales". Por lo general, estos problemas resueltos con enfoques funcionales no están en el código del motor central, ni en el código que se ejecuta en el juego en sí. La codificación funcional puede ser bastante beneficiosa para las herramientas y el procesamiento de datos fuera de línea (modelos de horneado y otros activos, por ejemplo). También es discutible que la programación de GPU sea vagamente funcional en cómo se escriben los algoritmos,

Por supuesto, puede ser mejor evitar enfoques funcionales fuera de circunstancias muy específicas, ya que desea que estas herramientas fuera de línea sean lo más rápidas posible. Los lenguajes funcionales se destacan en el paralelismo, lo cual es bueno para algunos problemas, pero las abstracciones del hardware tienden a conducir a un rendimiento de un solo hilo muy ineficiente. (Los lenguajes como LISP funcionan bien aquí porque no son puramente funcionales, y de hecho Common LISP es multi-paradigma). Lo peor para un motor de juego o un kit de herramientas relacionado es ser un cuello de botella para la iteración de contenido. Un motor elegante con muchas características que lleva a los artistas o diseñadores de niveles horas para hacer lo que se podría hacer en 5 minutos (o idealmente, casi al instante) solo conducirá a juegos de baja calidad o cancelación debido a la escalada del presupuesto.

— Sean Middleditch
fuente

1

Ver: Clean Game Library (Clean) y Nikki and the Robots (Haskell).

— Andres F.

1

Esta respuesta es principalmente incorrecta y parece estar basada en una comprensión muy pobre de los lenguajes funcionales reales.

— CA McCann

1

¿Tienes algún contrapunto real?

— Sean Middleditch

44

... ¿Cuánta experiencia tiene en el envío de juegos de calidad industrial en lenguajes funcionales? Si tienes experiencia, compártela. Haga declaraciones con explicaciones y justificaciones, no apelaciones a la experiencia o autoridad, o acusaciones personales. La probabilidad de este tipo de discusión indignada y disputas personales es exactamente por qué esta pregunta se cerró.

— Sean Middleditch

44

Estás poniendo palabras en mi boca. No estoy indicando mi nivel de experiencia porque su opinión sobre mi experiencia es totalmente irrelevante para el tema. No afirme que no tiene tiempo para declarar hechos mientras tiene tiempo para atacar niveles de habilidades personales. Probablemente tenga correcciones reales, pero necesita indicarlas. "Ese tipo está equivocado", no es una respuesta valiosa para nadie. Solo puedo afirmar que estás equivocado, y luego tenemos un ciclo interminable y sin sentido de disputas. Por favor diga por qué una respuesta es incorrecta.

— Sean Middleditch

0

La compañía Naugthy Dog usó List en sus motores de juego y se llamaba Game Oriented Assembly Lisp.

Puede encontrar información aquí: http://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp

Algunos ejemplos de código: http://web.archive.org/web/20070127022728/http://lists.midnightryder.com/pipermail/sweng-gamedev-midnightryder.com/2005-August/003804.html

No está disponible para uso público.

— bcsanches
fuente

Si nos fijamos en la descripción de Wikipedia, rápidamente se hace evidente que GOAL no era un lenguaje funcional, a pesar de la ascendencia LISP.

— Mason Wheeler