¿Los lenguajes de programación funcionales son adecuados para la programación de gráficos?

Question

Simplemente muy curioso sobre esto, según mi propia experiencia, toda la programación gráfica parece estar relacionada con C o C++. Como el Direct10X. ¿El lenguaje de programación funcional proporciona algún tipo de biblioteca gráfica para desarrollar videojuegos?

Answer 1

Puede utilizar lenguajes funcionales para hacer programación de gráficos/juegos como en cualquier otro idioma.

Es solo un juego simple, pero escribí Ironclad: Steam Legions en Clojure como un ejercicio de programación funcional para el desarrollo de juegos.

Estas son algunas de las lecciones que aprendí/observaciones generales sobre el uso Clojure para la programación de juegos:

• Necesita ser cuidado con el rendimiento como los juegos pueden ser muy exigente y los lenguajes funcionales imponen algunos gastos generales. Clojure es ciertamente "lo suficientemente bueno" para la mayoría de los juegos, pero necesitas conocer los trucos para mantener tu código optimizado. Por ejemplo, los lenguajes funcionales pueden obtener un poco de GC pesado produciendo una gran cantidad de objetos temporales. Tienes que aprender los trucos para evitar esto (por ejemplo, usando reducir de manera que se evite la creación de nuevos objetos de secuencia, o el aprovechamiento de artithmetic primitiva)

• Mutabilidad es útil en juegos. Por ejemplo, si estás haciendo algo con física o animación suave, a menudo tienes muchos objetos con ubicaciones que cambian constantemente. Usted puede simular esto con estructuras de datos funcionales/inmutables, pero si le importa el rendimiento no es una buena idea. Por lo tanto, vale la pena averiguar cómo obtener los datos mutables en su lenguaje funcional, incluso si no es idiomático (por ejemplo, en Clojure es probable que desee hacer uso de matrices de Java)

• inmutables estructuras de datos persistentes realidad resultan ser muy útil en los juegos también. En Ironclad, todo el estado del juego se almacenó en una única estructura de datos inmutables. Esto permitió algunos trucos geniales, como hacer una instantánea eficiente del estado del juego/undos instantáneos/correr hacia atrás en el tiempo.

• Clojure es impresionante para secuencias de comandos del juego. La naturaleza dinámica junto con la compilación en tiempo de ejecución y la capacidad de definir DSL arbitrarios con macros es una gran victoria. De hecho, incluso si estuviera escribiendo un juego en un lenguaje OOP como Java, consideraría seriamente usar Clojure (u otro Lisp) para crear scripts.

• Clojure es impresionante para el desarrollo interactivo. A menudo me encontré ejecutando el juego en una ventana mientras pirateaba el código de ejecución junto con un REPL. ¡Es divertido alterar las estructuras de datos de los juegos e inmediatamente ver los efectos! This awesome video también le da una idea de lo que es posible con el desarrollo al estilo Clojure.

• En Clojure, al menos, a menudo querrá utilizar las bibliotecas de Java para los gráficos, p. Ej. Swing para 2D o LWJGL para 3D. En algunos casos, ya existen envoltorios para ellos, sin embargo, me resultó bastante fácil usarlos directamente de Clojure.Después de todo, la interoperabilidad de Java es tan simple como (.methodName object arg1 arg2)

En conclusión, creo que los lenguajes funcionales son perfectamente buenas opciones para el desarrollo del juego, con la excepción de los juegos mismos rendimiento intensivo en el que aún pueden ser mejor con C/C++ para tener un control más directo sobre el hardware.

Answer 2

Esta es una buena serie sobre el tema: (4 partes) Purely Functional Retrogames. Podrías tomar este enfoque en Clojure y usar las bibliotecas de juegos Java subyacentes para manipular los gráficos.

Answer 3

Probablemente a nadie le importe esta pregunta ahora de cinco años, tal vez ni siquiera el asker original. Pero como un tipo antiguo de gráficos en Lisp, quería opinar. El título menciona la "programación de gráficos" y luego la pregunta sobre las bibliotecas para el desarrollo de juegos. Vale la pena señalar que la programación de gráficos incluye muchos temas no relacionados con la programación de juegos. (Entonces, por ejemplo, la visualización de datos en Clojure sería un ejemplo de "lenguajes de programación funcionales adecuados para programación de gráficos" pero no de programación de juegos). También hay una distinción entre lenguajes basados ​​en funciones (como Lisp, donde todo es una función, pero se permiten los efectos secundarios) y lenguajes que son puramente funcionales con solo tipos de datos inmutables (como Haskell o Clojure).

Sin duda ha habido sistemas de gráficos basados ​​en Lisp escritos en un estilo de "multi-paradigma", es decir, no puramente funcional/inmutable. Por ejemplo, trabajé en Symbolics a principios de la década de 1980, cuando produjimos uno de los primeros sistemas de "creación de contenido digital" (como Maya o AutoCAD) completamente en Lisp. Mi tesis de MS de 1978 fue sobre un lenguaje específico de dominio basado en Lisp para animación de procedimientos llamado ASAS. Usamos eso en triple-I (Information International Inc.) para hacer muy temprano el trabajo de CGI para efectos especiales en largometrajes, incluido el TRON de 1982. (Eso se describe en este SIGGRAPH paper.) Finalmente, el estudio de juego Naughty Dog programó la lógica del juego de varios títulos (Crash Bandicoot, Jak y Daxter series?) Con un lenguaje inspirado en Scheme llamado Game Oriented Assembly Lisp (GOAL).

hablar de los esfuerzos más modernas, y más estrictamente funcional idiomas/inmutables: “LambdaCube 3D es Haskell-como lenguaje específico de dominio puramente funcional para programar la (unidad de procesamiento gráfico) de la GPU.”

en Keynote de John Carmack en Quakecon 2013, habló ampliamente (unos 30 minutos) sobre su interés y experimentos con lenguajes puramente funcionales para el desarrollo de juegos. Su punto de vista parece ser que hay beneficios obvios para el uso de la programación funcional, pero hay algunos desafíos, y que no había ido lo suficientemente lejos en ese camino para tener una opinión firme. Habla sobre experimentar con Haskell y Lisp. Este tema es entre 1: 17: 00-1: 49: 00 en este video.