«а почему нет совместимости с моим мад-клиентом пятнадцатилетней давности?»

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

Сдаюсь. Только до сих пор не понял, зачем надо сохранять полное состояние вм. Как я понимаю, сейвится состояние комнат, объектов, игроков. Файты тоже сейвятся ?
Состояние игрового мира: объекты, мобы, комнаты.
Это все нативные объекты и они и так уже сохранялись между ребутами еще до Фени.
Как на счет состояния потоков, глобальных/локальных переменных и тд?
Даже если отбросить многопотоковость (без которой, кстати, очень сложно было бы построить нормальный диалог с персонажем) и полное состояние виртуальной машины, только на то чтоб сохранить все мобы и предметы с помощью какого-нибудь pickle уйдет значительно больше времени чем четверть секунды. А делать это итеративно не получится если нет возможности получить список измененных с прошлой итерации объектов. Когда-то давным-давно предметы записывались «тупо» на диск. В итоге можно было ксерокопировать шмотки тупо подняв их с пола, тупо набрав save и тупо крашнув мир одним из тысячи доступных на тот момент способов. Ну, или сделать все то же самое прямо перед плановым ребутом. В общем, тупо пробовали до нас. Тупо не работает.
А когда это происходит у вас?
Я в ветке про Дримленд уже описывал в общих чертах.
Просто размазывать сохранение на большое количество игровых тиков.
Без специальной поддержки языка это не так уж и просто по описанной выше причине. Даже если писать в базу с транзакциями, надо знать когда можно завершить транзакцию так, чтоб, например, при передаче денег от одного персонажа другому деньги не исчезли бесследно и не появились из ниоткуда в случае внезапного краща, или отключения света.
Самый простой вариант — использование pickle или shelve.
Варианты по сложнее и по интереснее, например, ZODB или Prevayler (для питона он тоже есть).
Вроде, это все библиотеки для сохранения отдельных объектов языка на диск/в базу данных.
Я говорю про сохранение состояния всей виртуальной машины целиком, включая выполняемый код, глобальные + локальные переменные, потоки, стек, и тд. Теоретически интерпретатор можно остановить в любой момент выдернув сервер из розетки и продолжить с того же места 10 лет спустя. При этом с точки зрения выполняемых скриптов ничего не произойдет. Мне известно только об одном очень специфическом клоне jvm который позволяет делать нечто подобное, но дальше тезисов этот проект вроде так и не сдвинулся — слишком узкая область применения.
вы переписали на феню большинство логики мада,

Пока далеко не большинство. В Дриме где-то 250к строк кода на с++ и всего 25к строк кода на Фене.
например, создание персонажа
В Дриме с момента выбора кодировке персонаж сразу в мире. У него стандартное имя Stranger и ему недоступны почти все команды. В остальном это полноценный персонаж.
Вся процедура создания персонажа сводится к общению с мобом. Феня для таких задач и создавалась.
К примеру, вам нужно добавить автоматическое склонение имен
Руффина прикрутила автоматическое склонение имен при создании персонажа где-то месяц назад. Может рассказать сколько это заняло у нее времени.
Нативные классы и вызовы у вас пишутся на Си и подгружается в виде модулей?
Да. Не только нативные классы — почти весь код перегружается налету. Начиная с работы с сокетами и заканчивая игровой логикой. Так было в Дриме задолго до Фени. Нельзя поменять без ребута только несколько системных библиотек.
клиент может просто отрубать начальный диапазон символов.

1) Некрасиво будет смотреться, если брать текущую версию дримлэнда
2) Всякие ASCII-рисунки будут отображаться криво
3) Латиница все же иногда нужна в маде (например, в общении).
Для новых игроков это может и не нужно, а из старожилов (включая меня) достаточное кол-во людей до сих пор использует англ команды.

Тогда может быть какой-нибудь режим сделать ?
тут имелось в виду расширение API

Так если вся игровая логика написана на скриптовом языке, API не нужно расширять.
Что именно?

Состояние игрового мира: объекты, мобы, комнаты.
Кто должен контролировать запись?

Игровой движок
когда это должно происходить

А когда это происходит у вас? Понятно, что писать на диск не получится так же быстро, как в БД, но это не критично. Просто размазывать сохранение на большое количество игровых тиков.
Можно подробней, потому что у меня есть подозрение что мы говорим о совершенно разных вещах.
Самый простой вариант — использование pickle или shelve.
Варианты по сложнее и по интереснее, например, ZODB или Prevayler (для питона он тоже есть).
Феня хороша для описания поведения комнат, предметов, мобов, написания квестов, простых активных/пассивных умений/заклинаний и, пожалуй, все.

Я с этим и не спорю, но как мне показалось, вы переписали на феню большинство логики мада, например, создание персонажа. К примеру, вам нужно добавить автоматическое склонение имен. В nodejs я просто добавил библиотеку и написал пару строк кода. У вас же это все займет несколько больше времени.
можно без всяких ребутов

Нативные классы и вызовы у вас пишутся на Си и подгружается в виде модулей?
Для новых игроков это может и не нужно, а из старожилов (включая меня) достаточное кол-во людей до сих пор использует англ команды.

Тут идея появилась, а почему бы в клиент не добавить опцию отображать или нет англоязычные вставки. Идея в том, что в Юникоде коды разные у латиницы и кириллицы, клиент может просто отрубать начальный диапазон символов. Если конечно нагрузки слишком большой не возникнет на ресурсы компьютера.
Тот момент, как я понимаю — это начало 2000-х? На данный момент я точно уверен, что такое можно провернуть с питоном, и скорее всего можно было провернуть с ним это 18 лет назад.
Можно подробней, потому что у меня есть подозрение что мы говорим о совершенно разных вещах.
Для сохранения состояния между ребутами можно было тупо писать на диск
Что именно? Кто должен контролировать запись? И главное — когда это должно происходить?
У языка нет поддержки коммьюнити, у языка малый функционал. Нет поддержки большинства популярных структур хранения данных, нет новомодных фишек, нет дополнительный библиотек. Из этого вытекает еще один минус — увеличение трудоемкости в некоторых случаях
Эти аргументы применимы практически к любому DSL. Однако вся суть DSL заключается именно в том, чтоб снизить трудоемкость в узком диапазоне задач. Да, на Фене сложно написать операционную систему, или, например, навигационную систему для баллистических ракет. Но с этими задачами вполне справляется С++. Феня хороша для описания поведения комнат, предметов, мобов, написания квестов, простых активных/пассивных умений/заклинаний и, пожалуй, все. Однако это уже больше половины кода некоторых мадов. Если для перечисленных задач не хватает какой-то структуры данных, или библиотеки — можно без всяких ребутов за пару минут добавить пару нативных классов/вызов с необходимой функциональностью и продолжить строгать скрипты. Подсказка по существующему API встроена в сам язык (сперто из питона).
Синтаксис языка не такой уж и экзотический. Кто угодно с опытом работы на яваскрипте сможет без проблем читать существующие скрипты. Еще через пару часов экспериментов прямо в мире, вполне сможет написать и отладить что-то вроде этого: dreamland.rocks/fenia/fire.html
> должна быть возможность расширять функциональность языка без ребутов.
Нет, тут имелось в виду расширение API, т.е. добавление доступа ко все большему количествау игровых структур и их полей и методов.

> Зачем эти англоязычные вставки в маде для команд?
Для новых игроков это может и не нужно, а из старожилов (включая меня) достаточное кол-во людей до сих пор использует англ команды.

Про цвета повреждений запишу себе, спасибо за идею.
Godot использует собственный скриптовый язык — GDScript

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

Который, опять же, практически никто не использует.
Circle'ах используют DGScript

Только для триггеров. Если бы fenya использовался только для триггеров, в принципе было бы не так плохо.
Я это веду все к тому, что вероятность привлечения новых кодеров на этом языке для мада близится к нулю.
Круто!
Поделюсь своим мнением. Вообще есть два пути. Первый, подгонять движок под существующий язык программирования. Второй, подгонять язык программирования под существующий язык. Какой путь оптимальнее зависит от многих факторов. И очень часто разработчики идут по втрому пути.
Например, Godot использует собственный скриптовый язык — GDScript, так как решили, что существующие скриптовые языки по требуемым параметрам не подходят для движка. В Unity используют собственный диалект Javascript и т.д. Да и в Circle'ах используют DGScript, больше нигде не используемый. В общем, не вижу в Фене ничего странного.
Очень даже неплохо, только бы побольше действий для такого контекстного меню. Желательно, чтобы вообще все, кроме разговоров, можно было делать мышкой.
В помощь «одноруким» muder.ru/blog/244.html
Ну вот, собственно muder.ru/blog/244.html
Ответил в блоге:
P2w стали нормальным явлением, т.е. нормой индустрии. Я согласен с вашей оценкой с точки зрения нравственного аспекта данной проблемы, но реальность уже изменилась, проще всего под нее подстроиться и просто напросто не пытаться «выиграть» в pay2win — если нет стремления 'win', то и 'pay' безразличен. Просто играть в свое удовольствие без вложений или с минимальными (на чашку кофе разработчикам). Именно это я имел в виду в своем прошлом видео.
Не согласен с мнением, что p2w-игры это нормально. Я считаю, что p2w допустимо лишь в однопользовательских играх или играх без pvp. Но если в игре есть pvp, то делать ее p2w это подло. Создатели игры сталкивают игроков кошельками и побеждает тот, у кого он толще. Я отношусь к играм как к виду искусства и думаю, что пользоваться в них таким приемом — бесчестно.

По поводу голосового интерфейса. Так на Западе он только только появляется, а мы как всегда безуспешно пытаемся пытаемся догнать его. Через несколько лет все это появится и у нас. Тут еще дело тормозится тем, что английский — это аналитический язык, а русский — синтетический, то есть английский проще запрограммировать, да и вообще он проще русского.
Я пару лет назад присматривался к CMU Sphinx: сами команды вполне можно забить в jsgf (местный формат грамматики), аргументы (названия предметов и мест, а также имена) — тоже. Наибольшая сложность — непосредственно с прямой речью, но ее можно «скармливать» гуглу или яндексу.

Но — нужен специальный клиент, чтоб со Сфинксом работать.