Чи є якийсь ігровий движок, що використовує функціональну мову програмування? [зачинено]

Чи є якийсь ігровий механізм, що використовує функціональну мову програмування, схожу на Scheme, Common Lisp, Clojure або JavaScript?

Я спробував Unity3D, але їх "JavaScript" насправді не JavaScript, сильно набраний і не функціонує.

Є LambdaCube, який написаний Haskell (це не зовсім ігровий движок, але більше схожий на графічний движок).

Ви завжди можете використовувати f # або iron python (так, я знаю, python не функціонує) або будь-яку іншу. Неофіційну мову з XNA на платформі .net.

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

редагувати: Ще один механізм, написаний на Lisp: http://code.google.com/p/blackthorn-engine/

У мене немає відповіді на запитання, як написано, але я вважаю, що ви, можливо, намагаєтесь запитати "чому немає більш функціональних ігрових двигунів", а не шукати конкретний. Якщо це правильно, слід перефразувати питання. Якщо ні ... ігноруйте мене. :)

Чисто функціональний підхід не підходить для ігор. Ігри (і графіка, і фізика, і AI) і в основному все про зміни стану. Правильним функціональним підходом до цих проблем було б обчислити цілий новий стан один раз за цикл, який матиме дуже суворе покарання у порівнянні з кодуванням, безпосередньо безпосередньо від того, як працює фактичне обладнання.

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

Це не означає, що функціональному програмуванню не місце десь в іграх. Я використовую дуже функціональний стиль кодування (де це доречно) в C #, Unity JavaScript і навіть C ++ 11. Деякі дуже специфічні проблеми найкраще або, принаймні, найлегше вирішити з функціональним стилем, і більшість популярних сьогодні мов підтримують таку форму програмування, хоча і в більш громіздкій формі, ніж "справжні" функціональні мови. Зазвичай ці проблеми, що вирішуються функціональними підходами, не знаходяться ні в основному коді двигуна, ні в коді, який працює в самій грі. Функціональне кодування може бути дуже корисним для інструментів та обробки даних в режимі офлайн (наприклад, моделі випічки та інші активи). Також можна сперечатися, що програмування графічного процесора нечітко функціональне в написанні алгоритмів,

Звичайно, все ж найкраще уникати функціональних підходів за межами дуже конкретних обставин, оскільки ви хочете, щоб ці офлайн-інструменти були максимально швидкими. Функціональні мови перевершують паралелізм, що добре для деяких проблем, але абстрагування апаратних засобів, як правило, призводить до дуже неефективних однопоточних характеристик. (Такі мови, як LISP, добре спрацьовують тут, оскільки вони не є чистими функціональними, а насправді загальний LISP є багатопарадигмою.) Абсолютна найгірша річ для ігрового двигуна або пов'язаного з ним інструментарію - це бути вузьким місцем для ітерації вмісту. Фантастичний двигун з безліччю функцій, який вимагає художників або дизайнерів рівних годин, щоб зробити те, що можна було зробити за 5 хвилин (або в ідеалі, майже миттєво), просто призведе до ігор низької якості або скасування через збільшення бюджету.

Компанія Naugthy Dog використовувала List у своїх ігрових двигунах, і вона отримала назву Lis-Assembly Assembly Lisp.

Деякі відомості можна знайти тут: http://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp

Деякі зразки коду: http://web.archive.org/web/20070127022728/http://lists.midnightryder.com/pipermail/sweng-gamedev-midnightryder.com/2005-August/003804.html

Він не доступний для загального користування.