Comments 7
Есть и на Форт (Forth) похожие проекты. :)
Проект от JohnEarnest — Mako
Демо игры проекта запускаемые в браузере Mako.JS
Mako on Github
P.S. Тоже похожий проект из затронутой темы статьи jeforth.3we
…
Проект от JohnEarnest — Mako
Mako (VM) — это портативная виртуальная игровая консоль на основе стека. Mako проект был разработан таким образом, чтобы его было легко переносить и внедрять: даже включая дополнительные функции, эталонная реализация занимает всего несколько страниц Java. Все игры и демки, написанные для Mako Теперь можно попробовать прямо в браузере благодаря Mako.JS .
Демо игры проекта запускаемые в браузере Mako.JS
Mako on Github
P.S. Тоже похожий проект из затронутой темы статьи jeforth.3we
…
Отличный выбор языка. Лисп легко разбирать и выполнять. У меня было несколько проектов с лиспом в качестве макро-языка для реализации расчетов по загружаемым извне программам. Правда, после первого проекта я перешел на Scheme, там многое проще и понятнее и спецификация R5RS на тот момент была всего на 50 страниц. Свои наработки я так и не опубликовал, но подумываю об этом.
Например, код на языке с garbage collection и на языке с явным управлением памятью было бы сложно объединить в одном проекте.
И без развернутой аргументации?
Существуют десятки лет успешные движки с подобным объединением.
И сложности объединения в одном проекте разных языков — крайне незначимая (даже можно сказать незаметная) сложность на фоне прочей сложности, что нужно преодолеть при создании игры…
Rust идеально подходит для разработки движка игры: из языков, ориентированных на производительность скомпилированного кода, в нём максимум выразительных средств – enum-ы с полями; pattern matching с деструктуризацией; макросы, генерирующие произвольный код во время компиляции; и т.п. С другой стороны, для описания игровой механики Rust подходит плохо: задержки на перекомпиляцию усложняет подход «подправить и тут же проверить, что получилось»;
По описанным критериям вперед выходит вовсе не Rust, а C++ и C#.
Понятно что автору интересно написать свой язык.
Но аргументация «почему он нужен» — не проработана.
Лучше бы этой аргументации вообще не было.
На этом примере хорошо видно, насколько код на JavaScript перегружен разнообразной пунктуацией и служебными словами, без которых можно обойтись.
Вот уж в первый раз встречаю обвинение любого языка в перегруженности пунктуацией со стороны лиспа :)
Никто вам не мешает указывать собственные рейнджи в виде [25, "i"] и раскрывать их потом как вам нравится, но как по мне вместо
(set-walls (10 40) (i 20) (i 60))лучше написать
wall({ x: [10, 40], y: 20 })
wall({ x: [10, 40], y: 60 })или что-то подобное, более читабельное чем набор чисел.
Никто вам не мешает указывать собственные рейнджи в виде [25, "i"] и раскрывать их потом как вам нравитсяРаскрытие
[25, "i"] в JS наверняка будет объёмнее, чем макрос set-walls в GameLisp.Это же не внешний API, которым будут пользоваться десять лет, а локальный макрос, позволяющий вчетверо сократить процедуру инициализации уровня, и не нужный больше нигде.
лучше написать wall({ x: [10, 40], y: 20 })Стены в Nibbles бывают диагональными
(set-walls (6 47) (i i)), пунктирными (set-walls (4 49 2) (i 40)) и т.д.
Не могу пройти мимо:
Любая достаточно сложная программа на Си или Фортране содержит заново написанную, неспецифицированную, глючную и медленную реализацию половины языка Common Lisp
Статья: Почему конкатенативное программирование имеет значение
P.S. В рассмотрении с функциональной позиции. :)
P.S. В рассмотрении с функциональной позиции. :)
Sign up to leave a comment.
Обзор GameLisp: нового языка для написания игр на Rust