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

Також, якщо F # є новим членом сімейства .NET, він може використовуватися безпосередньо з XNA, наприклад, який досить низько знижує поріг, на відміну від LISP, Haskell, Erlang тощо.

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

Редагувати: важко вирішити, що для цього є однозначна відповідь, тому він, ймовірно, краще підходить як вікі-повідомлення спільноти.

Зараз я працюю над грою в Haskell. Я не можу говорити про функціональне програмування взагалі, але конкретно для Haskell:

Добрий

Це дивовижні речі, завдяки яким Haskell дійсно виділявся.

• Чистота означає, що міркувати про ваш код набагато простіше. Вам не доведеться турбуватися про "поточне" значення змінної або про те, чи використання певної функції певним чином конфліктуватиме з вашим глобальним станом. Це також означає, що з паралелізмом і одночасністю працювати набагато простіше (і в багатьох випадках тривіально). Ці речі можуть бути знахідкою розробників ігор.
• Haskell дозволяє дуже легко писати на дуже високому рівні, використовуючи абстракції власного творіння. Часто простіше написати дуже загальний код, ніж спеціалізований код в Haskell, і переваги цього проявляються в меншому часі розробки та більш легкому розумінні коду. У Haskell це правдивіше, ніж у будь-якій іншій мові, про яку я знаю, що використання інтерфейсу - це як використання абсолютно нової мови (при цьому зберігаючи переваги решти екосистеми Haskell). Що більшість мов називає особливості мови, Haskell називає бібліотеку, і це не відчуває себе вимушеним. Якщо ви коли-небудь опиняєтеся, що міркуєте про свою гру в psuedocode, ви, ймовірно, можете просто написати простий інтерфейс і зробити його реальним кодом, і зазвичай цього варто зробити.
• Це може суперечити іншим відповідям, але Haskell краще справлятися з імперативним кодом, ніж будь-яка інша мова, яку я знаю. Обмеження чистоти означають, що Хаскелл має поділ між поняттями "оцінка" (зменшення виразів) та "виконання" (виконання побічних ефектів). Ви можете контролювати, коли і як виконуються побічні ефекти, з легкістю, яка не має аналогів так званим "імперативним" мовам. Незважаючи на те, що я говорив про чистоту раніше, деякі зв'язки на C все ще дуже вкрай важливі (OpenGL, я дивлюся на тебе), тому цей тонкий дрібний контроль над імперативним кодом дуже вітається. Навіть найбільш досвідчені з програмістів на С, ймовірно, оцінять це, коли вони звикають.
• GHC генерує досить швидкі бінарні файли. Вони не такі швидкі, як двійкові файли, що генеруються із звичайних компіляторів С, але знаходяться в порядку величини і набагато швидше, ніж те, що ви могли б досягти з інтерпретованою мовою. Навіть якщо ви не можете написати свою гру на інших мовах високого рівня, таких як Python, тому що це буде занадто повільно, є хороший шанс, що ви зможете це зробити в Haskell.
• Незважаючи на те, що в Haskell не так багато бібліотек, пов’язаних з іграми, як зазначено в розділі "Погано", інтерфейс іноземних функцій Haskell - це найпростіший із мене, що я коли-небудь використовував. Ви можете прив’язати до C, написавши майже виключно в Haskell.

Поганий

Це речі, які не дуже добре , але можуть бути розроблені навколо , НЕ занадто багато зусиль.

• Час і зусилля, необхідні для вивчення Haskell, можуть бути досить великими, якщо ви дуже звикли працювати з нефункціональними мовами. Мова сама по собі не дуже складна, але якщо враховувати загальні розширення мови та величезну кількість бібліотек (пам’ятайте, багато речей, які ви можете врахувати, що мовні особливості інших мов - це бібліотеки в Haskell), це виглядає набагато зловісніше. На мою думку, воно того варте, але інші можуть не погодитися.
• Деякі люди дуже сильно скаржаться на лінь. Якщо ви знаєте, чим займаєтесь, ви не будете спричиняти витоків простору, які важко відстежити (я не створив протікання простору вже пару років), але у початківців із цим набагато більше проблем. Було б нерозумно мене збивати цих людей і стверджувати, що це не проблема, але я запевняю, що це проблема, яка легко вирішується досвідом.
• У Haskell не так багато чудових бібліотек для створення ігор, і не багато Haskellers пише в ній ігри, тому важко знайти ресурси та допомогу з цього приводу.

Потворний

Це речі, які потребують значних зусиль для подолання.

• Якщо ви пишете гру, що займає ресурси, сміттєзбірник GHC може вас кусати досить сильно. Це покоління загального покоління, тому щоразу час від часу ви можете скидати кілька кадрів. Для деяких ігор це нормально, але для інших це головна проблема. Я та деякі інші розробники ігор, які використовують Haskell, хотіли б бачити в режимі реального часу GC, реалізований для GHC, але, наскільки мені відомо, до цього не витрачаються зусилля. Наразі я не переживаю над тим, щоб працювати над цим (і ще не бачив жодного скинутого кадру з нього), але принаймні одна інша команда вдалася вкласти основний цикл візуалізації в C.

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

Космічні витоки виникають періодично, і, хоча вони створювали певні проблеми, в загальній схемі це було невелика кількість (наприклад, порівняно з пошуком тупиків у подібних розмірах Java-проектах), і коли вони були виправлені , вони залишалися нерухомими.

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

Haskell зробив нелегку роботу легкою, і всі труднощі, про які я вже згадував, були крихітними порівняно з великою кількістю складного коду, який ми створили, який є чистим, ремонтопридатним і майже непорушним. Паралелізм буде проблемою розвитку ігор дуже скоро, і ми вкрай готові з цим боротися. Дещо з того, що я сказав, може не стосуватися малих проектів, тому що ми в цьому тривалий час, тому початкові витрати, такі як криві навчання, підтримка бібліотеки тощо, є набагато меншими проблемами.

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

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

• Крива навчання FP: FP вимагає повного переходу мислення з ітеративного програмування. Навчитися мислити з точки зору карт і складок, а не циклів, вимагає розумових тренувань, якщо ти до цього не звик.
• Крива навчання Маті: Хаскелл є і блаженним, і проклятим математичною витонченістю своїх дизайнерів, тому що після того, як ти засвоїш основи ПП, ти застрягнеш з монадами, морфізмами, стрілами та цілою низкою інших міркувань, які, хоча і не є жорсткими самі по собі дуже абстрактні.
• Монади: цим щенятам не особливо важко загорнути свій розум, особливо якщо ви приймаєте твердження Еріка Реймонда, що вони є "хак, щоб перетворити функціональну композицію в спосіб змусити послідовне функціонування викликів". На жаль (хоча це стає кращим, оскільки Хаскелл набирає популярність), багато пояснень монад або націлюють шлях над головою більшості програмістів ("вони моноїди в категорії ендофайнерів!"), Або зовсім не корисну аналогію (наприклад, , Жахливий точний приклад Брента Йоргей, " монади схожі на бурріто ! Ви думаєте, що він жартує? Щоб ніхто ніколи не міг придумати таку гнучку аналогію в підручнику? Подумайте ще раз .)
• Екосистема: Якщо вам вдалося вийти за межі всіх інших ударів на дорозі, ви будете щокуючи і щосили суперечити практичній повсякденній реальності роботи з все ще значною мірою експериментальною мовою. Бог допоможе вам, коли ви потрапите сюди. Ось де я почав серйозно приєднуватися до Scala, або F #, чи іншої мови, де є хоча б певна гарантія сумісності з іншими бібліотеками. Колись я отримав Haskell для з'єднання та завантаження бібліотек OpenGL у Windows. Це змусило мене відчувати себе досить добре. Потім прив'язки OpenGL були перевипущені та зламали все, що я зробив. Ось таке життя в Хаскелл-Ланд. Чесно кажучи, це може бути біль. Хочете обгортку для двигуна Bullet? Це в Hackage - в Abandonwareз листопада минулого року. Вам подобається Ogre3d? Злом пов'язаний лише з підмножиною бібліотеки . Підсумок полягає в тому, що якщо ви будете дотримуватися мови на шляху переробки, ви витратите набагато більше часу, працюючи на основній сантехніці, ніж ви б, якби ви тільки стежили за стадом і затрималися з C ++.

Зворотний бік цього полягає в тому, що все швидко поліпшується. І це дійсно все залежить від того, що ви хочете від досвіду. Ви хочете створити гру та розмістити її на своєму веб-сайті, щоб шукати слави та багатства? Дотримуйтесь C ++ або Python. Але якщо ви хочете дізнатися щось нове, що вимагатиме від вас інновацій своїх процесів, спробуйте функціональну мову. Досить мати багато терпіння до себе, поки ви навчаєтесь.

У Antti Salonen є цікавий блог, в якому детально описується його справа про програмування ігор Haskell. Варто прочитати.

Правка (через рік): Тепер, коли я більше вивчав Державну монаду, я розумію, що це не особливо вдале рішення для держави, яка має намір зберігатися поза певною функцією. Справжні рішення щодо безгромадянства знаходимо в Haskell в IOVar, ST, MVar (для безпеки потоку) або через щось на зразок Yampa, яке використовує стрілки та FRP для управління внутрішнім станом, який, тим не менш, прихований від розробника. (Цей список знаходиться в порядку складності, хоча перші три не є особливо складними, коли ви розумієте монади.)

Об'єктивний Камл!

Використання функціональних мов може бути величезною перевагою у більшості типів розробки програмного забезпечення, головним чином, оскільки вони значно скорочують час розробки. Я бачу великий потенціал для написання серверного сервера в гру або AI та логічні шари на клієнті, функціональною мовою. І як всім відомо, LISP використовували для сценаріїв NPC.

Якби я спробував написати фронт-гру гри на функціональній мові, я б неодмінно пішов на « Objective Caml» , що є гібридною мовою. Це нащадок ML, який дозволяє змішувати ітеративний та функціональний стилі, має об'єктивну систему із стаціонарними об'єктами. (Caml - мова, на якій моделюється F #.)

Зв'язки OpenGL, здається, працюють бездоганно, і люди вже давно роблять ігри в OCaml. Мова може бути складена і є потенційно дуже швидкою (вона, як відомо, давно перемогла C у деяких тестах, не так, як зараз справи).

Також є тонни бібліотек. Все - від інформатики до прив'язки до бібліотек усіх видів.

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

Що стосується переваг, перегляньте Бібліотеку чистої гри (http://cleangl.sourceforge.net/) та перевірте гру платформерів. Як тільки ви обернетеся навколо синтаксису (я рекомендую вам спробувати), ви побачите повну витонченість конструкцій та те, наскільки близько джерело відображає поняття, які вони виражають. Як додатковий бонус, абстракція стану та необхідність явного переходу стану робить ваш код набагато більш дружнім для багатоядерних.

З іншого боку, вона потребує значного зміни парадигми. Багато з того, що ви звикли робити, не думаючи про це, раптом більше не існує, і ви будете спантеличувати, як це вирішити, просто тому, що ви думаєте за неправильними зразками.

З моєї точки зору, найбільші проблеми будуть:

• Безгромадянство функціональних мов: Ідея в іграх полягає в тому, що кожен суб'єкт має стан і цей стан змінюється від кадру до кадру. Існує механіка, яка імітує таку поведінку в деяких мовах (наприклад, функції з "!" В plt-схемі), але це відчуває себе неприродно.
• Порядок виконання : В іграх деякі кодові частини залежать від інших частин коду, які слід закінчити перед виконанням. Функціональні мови зазвичай не дають жодних гарантій щодо порядку виконання аргументів функції. Існують способи наслідування такої поведінки (наприклад, (begin...у схемі "plt").

Не соромтеся розширити цей список (і, можливо, додати деякі позитивні моменти ^^).

Ви можете написати свій код на C / C ++ і використовувати вбудовану мову, наприклад, Embedded Common Lisp для сценарію. Хоча отримати їх для компіляції на іншій платформі може бути складно. Ви можете подивитися на Lisp In Small Pieces, щоб навчитися писати власну мову сценаріїв. Це справді не так складно, якщо у вас є час.

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

Я не навчився F #, хоча так може бути набагато простіше працювати.

позитивним вважатиметься ефективність і портативність, а негатив - керування складністю , сьогодні гра серйозно складна і потребує інструментів або мови програмування, які можуть краще керувати складністю, таких як об'єктно-орієнтована методологія або загальне програмування, яке важко реалізувати у функціональному програмуванні мова.