Являются ли функциональные языки программирования подходящими для графического программирования?

Ответ 1

Вы можете использовать функциональные языки для программирования графики и игр так же, как на любом другом языке.

Это только простая игра, но я написал Ironclad: Steam Legions в Clojure как упражнение в функциональном программировании для разработки игр.

Вот некоторые уроки, которые я изучил/общие замечания по использованию Clojure для игрового программирования:

• Вы должны быть осторожны с производительностью, поскольку игры могут быть очень требовательными, а функциональные языки накладывают некоторые накладные расходы. Clojure, безусловно, "достаточно хорош" для большинства игр, но вам нужно знать трюки, чтобы оптимизировать ваш код. Например, функциональные языки могут получить немного GC-heavy, производя много временных объектов. Вам необходимо изучить уловки, чтобы избежать этого (например, используя сокращение таким образом, чтобы избежать создания новых объектов последовательности или использования примитивной арифметики)

• Mutability полезен в играх. Например, если вы делаете что-либо с физикой или плавной анимацией, у вас часто бывает много объектов с постоянно меняющимися местами. Вы можете имитировать это с помощью функциональных/неизменных структур данных, но если вы заботитесь о производительности, это не очень хорошая идея. Поэтому стоит выяснить, как получить изменяемые данные на вашем функциональном языке, даже если он не является идиоматическим (например, в Clojure, вы, вероятно, захотите использовать массивы Java)

• Непрерывные постоянные структуры данных действительно оказываются очень полезными и в играх. В Ironclad все игровое состояние хранилось в единой неизменной структуре данных. Это позволило использовать некоторые интересные трюки, например, эффективно снимать состояние игры/мгновенные отмены/бегать назад во времени.

• Clojure отличный для игровых скриптов. Динамическая природа в сочетании с компиляцией во время выполнения и возможностью определять произвольные DSL с помощью макросов - это массовая победа. На самом деле, даже если бы я писал игру на языке OOP, например Java, я бы серьезно подумал об использовании Clojure (или другого Lisp) для сценариев.

• Clojure отличный для интерактивного развития. Я часто обнаруживал, что я запускаю игру в одном окне, взламывая текущий код в REPL. Это забавно изменить структуры данных игры и сразу увидеть эффекты! Это удивительное видео также дает вам представление о том, что возможно с развитием Clojure.

• В Clojure по крайней мере вы часто захотите использовать библиотеки Java для графики, например. Swing для 2D или LWJGL для 3D. В некоторых случаях обертки для них уже существуют, однако я нашел достаточно простым использовать их непосредственно из Clojure. В конце концов, Java interop так же прост, как (.methodName object arg1 arg2)

В заключение я считаю, что функциональные языки являются отличным выбором для разработки игр, за исключением очень интенсивных игр, где вы, вероятно, будете лучше работать с C/С++, чтобы иметь более прямой контроль над оборудованием.

Ответ 2

Это хорошая серия на тему: (4 части) Чисто функциональные ретрограммы. Вы можете использовать этот подход в Clojure и использовать базовые библиотеки Java-игр для управления графикой.

Ответ 3

Наверное, никто не заботится об этом теперь пятилетнем вопросе, возможно, даже не об этом. Но, как старый парень с графикой в ​​стиле Lisp, мне хотелось взвесить. Название упоминает "графическое программирование", тогда вопрос задает вопрос о библиотеках для разработки игр. Стоит отметить, что графическое программирование включает в себя множество тем, не связанных с игровым программированием. (Таким образом, например, визуализация данных в Clojure будет примером "языков функционального программирования, подходящих для графического программирования", но не для игрового программирования.) Существует также различие между функциональными языками (например, Lisp, где все функция, но возможны побочные эффекты) и языки, которые являются чисто функциональными только с неизменными типами данных (например, Haskell или Clojure).

Конечно, существуют графические системы на основе Lisp, написанные в стиле "multi-paradigm", то есть не чисто функциональные/неизменяемые. Например, я работал в Symbolics в начале 1980-х годов, когда мы создали одну из первых систем создания цифрового контента (например, Maya или AutoCAD) полностью в Lisp. Моя диссертация 1978 года была посвящена Lisp основанной на доменах-langauge процедурной анимации под названием ASAS. Мы использовали это в triple-I (Information International Inc.), чтобы сделать очень раннюю работу CGI для специальных эффектов в художественных фильмах, включая TRON 1982 года. (Это описано в этом SIGGRAPH paper. Наконец, игровая студия Naughty Dog запрограммировала игровой логики нескольких названий (серия Crash Bandicoot, Jak и Daxter?) с вдохновленным Scheme языком, называемым Game Oriented Assembly Lisp (GOAL).

Говоря о более современных усилиях и более строго функциональных/неизменяемых языках: "LambdaCube 3D - это чисто функциональный язык, подходящий для Haskell, для программирования графического процессора (графического процессора)".

В докладе Джона Кармакса в Quakecon 2013 он подробно рассказал (около 30 минут) о своих интересах и экспериментах с чисто функциональными языками для разработки игр. Его взгляд, кажется, заключается в том, что есть очевидные преимущества для использования функционального программирования, но есть некоторые проблемы, и что он недостаточно далеко продвинулся по этому пути, чтобы иметь сильное мнение. Он рассказывает об экспериментах с Haskell и Lisp. Эта тема находится между 1:17: 00-1: 49: 00 в этом видео.