Каковы проблемы и преимущества написания игр с функциональным языком?

Хотя я знаю, что функциональные языки не являются наиболее часто используемыми для написания игры, существует много преимуществ, связанных с ними, которые кажутся им интересными в любом контексте программирования. Особенно легкость распараллеливания, о которой я думаю, может быть очень полезной, поскольку фокус движется в сторону все большего числа процессоров.

Кроме того, поскольку F # как новый член семейства .NET, он может использоваться непосредственно с XNA, например, который немного снижает порог, в отличие от перехода с LISP, Haskell, Erlang и т. д.

Если у кого-то есть опыт написания игр с функциональным кодом, то, что оказалось положительными и отрицательными? Для чего это было нужно, а что нет?

Изменить: найти трудно решить, что для этого есть один хороший ответ, поэтому он, вероятно, лучше подходит для публикации в сообществе wiki.

80 голосов | спросил 3 revs
McMuttons
1 Jam1000000amThu, 01 Jan 1970 03:00:00 +030070 1970, 03:00:00

10 ответов


56

В настоящее время я работаю над игрой в Haskell. Я вообще не могу говорить о функциональном программировании, но специально для Haskell:

Хорошее

Это потрясающие вещи, которые делают Haskell действительно выделяющимся.

  • Чистота означает, что рассуждение о вашем коде намного проще. Вам не нужно беспокоиться о «текущем» значении переменной, или каким-то образом использование данной функции будет конфликтовать с вашим глобальным состоянием. Это также означает, что параллелизм и параллелизм намного легче работать (и во многих случаях тривиальными). Эти вещи могут стать находчивой для разработчиков игр.
  • Haskell позволяет очень легко писать на очень высоком уровне, используя абстракции собственного творения. Часто проще писать очень общий код, чем специализированный код в Haskell, и преимущества этого проявляются в меньшем времени разработки и более легком понимании кода. Это более верно в Haskell, чем на любом другом языке, который я знаю о том, что использование интерфейса похоже на использование совершенно нового языка (при сохранении преимуществ остальной экосистемы Haskell). То, что большинство языков называют языковыми функциями, Haskell называет библиотекой, и это не кажется вынужденным. Если вы когда-нибудь узнаете о своей игре в psuedocode, вы, вероятно, можете просто написать простой интерфейс и сделать его настоящим кодом, и обычно это стоит того, чтобы это сделать.
  • Это может противоречить другим ответам, но Haskell лучше справляется с императивным кодом, чем любой другой язык, который я знаю. Ограничения чистоты означают, что у Haskell есть разделение между понятиями «оценка» (сокращение выражений) и «выполнение» (выполнение побочных эффектов). Вы можете контролировать, когда и как выполняются побочные эффекты, с легкостью, не имеющей аналогов на так называемых «императивных» языках. Несмотря на то, что раньше я говорил о чистоте, некоторые привязки C по-прежнему очень необходимы (OpenGL, я смотрю на вас), поэтому этот мелкозернистый контроль над императивным кодом очень приветствуется. Даже самые опытные программисты C, вероятно, оценят его, как только они привыкнут к нему.
  • GHC генерирует довольно быстрые двоичные файлы. Они не так быстро, как двоичные файлы, генерируемые из общих компиляторов C, но находятся на порядок, и far быстрее, чем вы могли бы достичь с помощью интерпретируемого языка. Даже если вы не можете писать свою игру на других языках высокого уровня, таких как Python, потому что это будет слишком медленно, есть шанс, что вы можете сделать это в Haskell.
  • Несмотря на то, что в Haskell не так много библиотек, связанных с игрой, как указано в разделе «Плохо» ниже, интерфейс внешней функции Haskell является самым простым, что я когда-либо использовал. Вы можете привязываться к C, написав почти исключительно в Haskell.

Плохой

Это нехорошие вещи, но их можно без проблем работать без слишком .

  • Время и усилия, необходимые для изучения Haskell, могут быть довольно высокими, если вы очень привыкли работать с нефункциональными языками. Сам язык не очень сложный, но когда вы учитываете общие языковые расширения и огромное количество библиотек (помните, многие вещи, которые вы могли бы учитывать в языковых функциях на других языках, являются библиотеками в Haskell), это выглядит намного более зловещим. На мой взгляд, это того стоит, но другие могут не согласиться.
  • Некоторые люди много жалуются на лень. Если вы знаете, что делаете, вы не будете вызывать утечки пространства, которые трудно отследить (я не создал космическую утечку через пару лет), но у новичков гораздо больше проблем с этим. Мне было бы глупо стрелять в этих людей и утверждать, что это не проблема, но я буду утверждать, что это проблема, которую легко решить с опытом.
  • Существует не так уж много больших библиотек для создания игр в Haskell, и не так много Haskellers пишут в нем игры, поэтому сложно найти ресурсы и помочь в этом вопросе.

Уродливый

Это вещи, которые потребуют значительных усилий для преодоления.

  • Если вы пишете ресурсоемкую игру, сборщик мусора GHC может сильно вас укусить. Это поколение GC, так что каждый раз вы можете сбросить несколько кадров. Для некоторых игр это нормально, но для других это серьезная проблема. Я и некоторые другие разработчики игр, использующие Haskell, хотели бы, чтобы в GHC была реализована GC в режиме реального времени, но, насколько мне известно, на это еще не потрачено никаких усилий. В настоящее время я не беспокоюсь о том, чтобы обойти это (и пока не видел от него никаких отброшенных кадров), но по крайней мере одна другая команда прибегнула к тому, чтобы положить их основной цикл рендеринга в C.
ответил Lenard Arquin 7 AM000000120000002431 2015, 00:01:24
18

Я потратил последний год на разработку коммерческого игрового движка в Haskell, и для нас этот опыт был в целом положительным. Наш игровой мир сложный, и Haskell упростил моделирование процесса преобразования из формата редактора в формат игрового движка. Мне не хотелось бы думать, что этот код будет выглядеть на императивном языке.

Иногда возникали утечки пространства, и, хотя они вызывали небольшие проблемы, в общей схеме это была небольшая сумма (например, по сравнению с поиском взаимоблокировок в проектах Java аналогичного размера) и один раз они были исправлены, они остались неподвижными.

Мы используем FRP, подобный Yampa, и, конечно же, с ним связана кривая обучения, но как только это закончится, опыт очень положительный. Библиотеки для нас не были проблемой - все, что нам было нужно, было доступно. Задержки сбора мусора были особой проблемой, поскольку она предназначена для встроенной платформы. Мы использовали некоторые C ++ для управления анимацией. Производительность также была проблемой, поскольку это встроенная платформа (= медленный процессор). Мы сделали несколько C, и мы также рассматриваем новые технологии Haskell, такие как ускорение. Аниматор C ++ был проектным решением на ранней стадии, а места, где код слишком медленный, - это очень маленькие области. В конечном счете, мы хотим перевести все наши C в Haskell.

Haskell справился с трудной задачей, и все трудности, о которых я только что упоминали, были крошечными по сравнению с большим количеством сложного кода, который мы выпустили, который является чистым, обслуживаемым и в значительной степени нерушимым. Параллелизм скоро будет проблемой в разработке игр, и мы очень хорошо справимся с этим. Некоторые из того, что я сказал, могут не относиться к небольшим проектам, потому что мы находимся в этом надолго, так что затраты на запуск, такие как кривые обучения, поддержка библиотек и т. Д., Гораздо меньше.

ответил Lenard Arquin 7 AM000000120000002431 2015, 00:01:24
17

Дэйв упоминает некоторые превосходные моменты, хотя я должен указать, что Хаскелл решил обе его проблемы. Безгражданство можно обойти, используя государственную монаду (EDIT: не совсем - см. Ниже для подробностей) , и последовательность может быть обработана с использованием IO monad (EDIT: или любой другой монады, для этого независимо от того, ...) .

Проблемы, которые у вас будут (и которые я пытался изучить как программирование игр, так и Haskell), в большей степени соответствуют этим требованиям. (Все они специфичны для Haskell, поскольку я действительно еще не углубился ни в какие другие языки FP.)

  • Кривая обучения FP: FP требует полного смещения мышления от итеративного программирования. Научиться думать с точки зрения карт и складок, а не циклов, требует умственной тренировки, если вы к этому не привыкли.
  • Кривая обучения Mathy: Хаскелл благословлен и проклят математической изощренностью своих дизайнеров, потому что после того, как вы изучите основы FP, вы застряли с монадами, морфизмами, стрелами и целым множеством другие соображения, которые, хотя и не жесткие сами по себе, очень абстрактны.
  • Монады: эти щенки не особенно сложно обмануть, особенно если вы принимаете заявление Эрика Раймонда , что они являются «хаком, чтобы превратить композицию функции в способ принудительного упорядочения вызовов функций». К сожалению (хотя это становится все лучше, так как популярность Haskell), многие объяснения монад направляются на голову большинства программистов («они моноиды в категории эндофунтеров!») Или совершенно бесполезной аналогией (например, , Печально точный пример Брент Йорги, « монады похожи на burritos ! "Вы думаете, что он шутит? Что никто не мог придумать такую ​​тупическую аналогию в учебнике? Подумайте еще раз ).
  • Экосистема: Если вам удастся выйти за пределы всех других ударов на дороге, вы будете щеки и жульничества против практической повседневной реальности работы с еще большей экспериментальной язык. Бог поможет вам, когда вы приедете сюда. Здесь я начал серьезно шуметь для Scala, или F #, или на каком-то другом языке, где есть как минимум some гарантия совместимости с другими библиотеками. Когда-то я получил Haskell, чтобы связать и загрузить библиотеки OpenGL в Windows. Это заставило меня чувствовать себя неплохо. Затем привязки OpenGL были переизданы и сломали все, что я сделал. Это жизнь на земле Хаскелл. Честно говоря, это может быть боль. Вам нужна оболочка для механизма Bullet? Это в Hackage - как отказ от использования с ноября прошлого года. Вам нравится Ogre3d? Hackage имеет привязки к только подмножеству библиотеки . Суть в том, что если вы придерживаетесь языка с проторенного пути развития игры, вы потратите гораздо больше времени на работу над базовой сантехникой, чем если бы вы просто следовали за стадом и застряли на C ++.

Откидной стороной этого является то, что вещи быстро улучшаются. И это действительно зависит от того, что вы хотите от опыта. Вы хотите создать игру и поместить ее на свой сайт, чтобы искать славу и удачу? Stick с C ++ или Python. Но если вы хотите узнать что-то новое, что потребует от вас инноваций в ваших процессах, попробуйте функциональный язык. Просто имейте много терпения с собой, пока вы учитесь.

У Antti Salonen есть интересный блог, в котором подробно описывается его повторное дело снова с программированием игр Haskell. Это стоит прочитать.

Изменить (через год): Теперь, когда я изучил государственную монаду больше, я понимаю, что это не очень хорошее решение для государства, которое предназначено для сохранения за пределами определенной функции. Реальные решения безгражданства найдены в Haskell в IOVar, ST, MVar (для обеспечения безопасности потоков) или через что-то вроде Yampa, которое использует Arrows и FRP для управления внутренним состоянием, которое тем не менее скрыто от разработчика. (Этот список в порядке сложности, хотя первые три не особенно сложны, если вы понимаете монады.)

ответил rtperson 22 J000000Thursday10 2010, 19:15:01
5

Objective Caml!

Использование функциональных языков может быть огромным преимуществом в большинстве типов разработки программного обеспечения, главным образом потому, что они значительно сокращают время разработки. Я вижу большой потенциал для написания серверного бэкэнда в игре, или AI и логических слоев на клиенте, на функциональном языке. И, как всем известно, LISP использовался для сценариев NPC.

Если бы я попытался написать интерфейс игры на функциональном языке, я бы определенно пошел на Objective Caml , который является гибридным языком. Это потомок ML и позволяет смешивать итеративные и функциональные стили, имеет объективную систему с объектами с сохранением состояния. (Caml - это язык, на котором моделируется F #.)

Связи OpenGL кажутся безупречными, и люди долгое время делают игры в OCaml. Язык может быть скомпилирован и потенциально очень быстр (он давно победил над C в некоторых тестах давным-давно, не так, как сейчас обстоят дела).

Существует также множество библиотек. Все от компьютерных наук до привязок ко всем видам библиотек.

ответил rtperson 22 J000000Thursday10 2010, 19:15:01
4

Не совсем ответ на что-либо, но я чувствую, что обсуждение игрового программирования в функциональных языках является неполным без упоминания функционального реактивного программирования (FRP) - http://www.haskell.org/frp/ - и его наиболее распространенная реализация (я думаю?), YAMPA - http://www.haskell.org/yampa/.

ответил rtperson 22 J000000Thursday10 2010, 19:15:01
3

Что касается преимуществ, ознакомьтесь с «Чистой библиотекой игр» (http://cleangl.sourceforge.net/) и проверьте игру в платформер. После того, как вы приступите к синтаксису (я рекомендую вам попробовать), вы увидите явную элегантность конструкций и то, насколько близко источник сопоставляется с концепциями, которые они выражают. В качестве дополнительного бонуса, абстракции состояния и необходимости явно передавать состояние вокруг, ваш код гораздо более дружелюбен.

С другой стороны, для этого требуется серьезный сдвиг парадигмы. Многое из того, что вы привыкли делать, не задумываясь об этом внезапно, больше не существует, и вы будете озадачиваться, как его решить, просто потому, что вы думаете о неправильных шаблонах.

ответил rtperson 22 J000000Thursday10 2010, 19:15:01
2

С моей точки зрения, самые большие проблемы будут:

  • Безгражданство функциональных языков: идея в играх заключается в том, что каждая сущность имеет состояние, и это состояние изменяется от кадра к кадру. Есть механики для имитации этого поведения на некоторых языках (например, функции с «!» В схеме plt), но это выглядит неестественно.
  • Порядок выполнения . В играх некоторые части кода зависят от других частей кода, которые должны быть закончены перед выполнением. Функциональные языки обычно не дают никаких гарантий относительно порядка выполнения аргументов функции. Есть способы воспроизвести это поведение (например, (begin ... "в схеме plt).

Не стесняйтесь распространять этот список (и, возможно, добавить некоторые положительные точки ^^).

ответил rtperson 22 J000000Thursday10 2010, 19:15:01
1

Вы можете написать свой код на C /C ++ и использовать встроенный язык, такой как Embedded Common Lisp для ваших скриптов. Хотя получить их для компиляции на другой платформе может быть сложно. Вы можете посмотреть на Lisp In Small Pieces, чтобы узнать, как писать собственный язык сценариев. Это действительно не так сложно, если у вас есть время.

ответил rtperson 22 J000000Thursday10 2010, 19:15:01
0

Я написал простые игры в LISP, и это было весело, но не то, что я бы рекомендовал. Функциональное программирование связано с конечным результатом. Так что это очень удобно для обработки данных и принятия решений, но я обнаружил, что было трудно сделать простой чистый код, как базовый контур управления.

Я не научился F #, хотя с этим может быть намного легче работать.

ответил Jeff 15 J000000Thursday10 2010, 11:12:03
-1

положительная будет производительность и переносимость , а отрицательный будет управлять сложностью , игра сегодня очень сложна и нуждается в инструментах или языке программирования которые могут лучше управлять сложностью, например, объектно-ориентированная методология или универсальное программирование, которое сложно реализовать на языке функционального программирования.

ответил uray 15 J000000Thursday10 2010, 18:33:39

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132