Это все нативные объекты и они и так уже сохранялись между ребутами еще до Фени.
Как на счет состояния потоков, глобальных/локальных переменных и тд?
Даже если отбросить многопотоковость (без которой, кстати, очень сложно было бы построить нормальный диалог с персонажем) и полное состояние виртуальной машины, только на то чтоб сохранить все мобы и предметы с помощью какого-нибудь pickle уйдет значительно больше времени чем четверть секунды. А делать это итеративно не получится если нет возможности получить список измененных с прошлой итерации объектов. Когда-то давным-давно предметы записывались «тупо» на диск. В итоге можно было ксерокопировать шмотки тупо подняв их с пола, тупо набрав save и тупо крашнув мир одним из тысячи доступных на тот момент способов. Ну, или сделать все то же самое прямо перед плановым ребутом. В общем, тупо пробовали до нас. Тупо не работает.
А когда это происходит у вас?
Я в ветке про Дримленд уже описывал в общих чертах.
Просто размазывать сохранение на большое количество игровых тиков.
Без специальной поддержки языка это не так уж и просто по описанной выше причине. Даже если писать в базу с транзакциями, надо знать когда можно завершить транзакцию так, чтоб, например, при передаче денег от одного персонажа другому деньги не исчезли бесследно и не появились из ниоткуда в случае внезапного краща, или отключения света.
Самый простой вариант — использование pickle или shelve.
Варианты по сложнее и по интереснее, например, ZODB или Prevayler (для питона он тоже есть).
Вроде, это все библиотеки для сохранения отдельных объектов языка на диск/в базу данных.
Я говорю про сохранение состояния всей виртуальной машины целиком, включая выполняемый код, глобальные + локальные переменные, потоки, стек, и тд. Теоретически интерпретатор можно остановить в любой момент выдернув сервер из розетки и продолжить с того же места 10 лет спустя. При этом с точки зрения выполняемых скриптов ничего не произойдет. Мне известно только об одном очень специфическом клоне jvm который позволяет делать нечто подобное, но дальше тезисов этот проект вроде так и не сдвинулся — слишком узкая область применения.
вы переписали на феню большинство логики мада,
Пока далеко не большинство. В Дриме где-то 250к строк кода на с++ и всего 25к строк кода на Фене.
например, создание персонажа
В Дриме с момента выбора кодировке персонаж сразу в мире. У него стандартное имя Stranger и ему недоступны почти все команды. В остальном это полноценный персонаж.
Вся процедура создания персонажа сводится к общению с мобом. Феня для таких задач и создавалась.
К примеру, вам нужно добавить автоматическое склонение имен
Руффина прикрутила автоматическое склонение имен при создании персонажа где-то месяц назад. Может рассказать сколько это заняло у нее времени.
Нативные классы и вызовы у вас пишутся на Си и подгружается в виде модулей?
Да. Не только нативные классы — почти весь код перегружается налету. Начиная с работы с сокетами и заканчивая игровой логикой. Так было в Дриме задолго до Фени. Нельзя поменять без ребута только несколько системных библиотек.
Тот момент, как я понимаю — это начало 2000-х? На данный момент я точно уверен, что такое можно провернуть с питоном, и скорее всего можно было провернуть с ним это 18 лет назад.
Можно подробней, потому что у меня есть подозрение что мы говорим о совершенно разных вещах.
Для сохранения состояния между ребутами можно было тупо писать на диск
Что именно? Кто должен контролировать запись? И главное — когда это должно происходить?
У языка нет поддержки коммьюнити, у языка малый функционал. Нет поддержки большинства популярных структур хранения данных, нет новомодных фишек, нет дополнительный библиотек. Из этого вытекает еще один минус — увеличение трудоемкости в некоторых случаях
Эти аргументы применимы практически к любому DSL. Однако вся суть DSL заключается именно в том, чтоб снизить трудоемкость в узком диапазоне задач. Да, на Фене сложно написать операционную систему, или, например, навигационную систему для баллистических ракет. Но с этими задачами вполне справляется С++. Феня хороша для описания поведения комнат, предметов, мобов, написания квестов, простых активных/пассивных умений/заклинаний и, пожалуй, все. Однако это уже больше половины кода некоторых мадов. Если для перечисленных задач не хватает какой-то структуры данных, или библиотеки — можно без всяких ребутов за пару минут добавить пару нативных классов/вызов с необходимой функциональностью и продолжить строгать скрипты. Подсказка по существующему API встроена в сам язык (сперто из питона).
Синтаксис языка не такой уж и экзотический. Кто угодно с опытом работы на яваскрипте сможет без проблем читать существующие скрипты. Еще через пару часов экспериментов прямо в мире, вполне сможет написать и отладить что-то вроде этого: dreamland.rocks/fenia/fire.html
1. Да, но зачем они нужны, если от них можно отказаться?
2. В общих чертах это работает так: все скриптовые объекты сохраняются в Berkeley DB. Происходит это постепенно в конце каждого такта и ограничено по времени так, чтоб каждый такт по прежнему был равен 0.25 секунды. Все изменения сохраняются в контексте долгоиграющей транзакции. Когда нечего сохранять, состояние базы на диске полностью соответствует состоянию виртуальной машины и текущая транзакция завершается. Berkeley DB гарантирует что даже при аварийном отключении питания при повторном открытии базы ее состояние будет соответствовать одному из последних коммитов. Не важно какому именно. Т.е. всегда есть шанс, что какие-то изменения не сохранятся, однако есть гарантия, что состояние виртуальной машины (да и мира в целом) будет согласованным (consistent). Например, если ты бросил предмет в комнате, то после выключения/включения питания предмет окажется или на полу, или в инвентаре, но никак не «и там, и там», или «ни там, ни там». Статистика показывает что полное сохранение состояния занимает 3 мс. 10 лет назад, на старом железе сохранение 100,000 долгоживущих объектов было размазано на десяток тактов. Разумеется, если бы в мире тогда был скрипт, который бы это делал каждый такт, транзакция бы никогда не завершилась.
Пруль там выше процитировал мой комментарий, который частично отвечает на этот вопрос. В общих чертах:
— скриптовая виртуальная машина должна сохранять свое состояние между ребутами (включая внезапное выдергивание сервера из розетки),
— должна быть возможность расширять функциональность языка без ребутов.
На тот момент я не знал ни одного языка в котором можно было бы это сделать.
Как на счет состояния потоков, глобальных/локальных переменных и тд?
Даже если отбросить многопотоковость (без которой, кстати, очень сложно было бы построить нормальный диалог с персонажем) и полное состояние виртуальной машины, только на то чтоб сохранить все мобы и предметы с помощью какого-нибудь pickle уйдет значительно больше времени чем четверть секунды. А делать это итеративно не получится если нет возможности получить список измененных с прошлой итерации объектов. Когда-то давным-давно предметы записывались «тупо» на диск. В итоге можно было ксерокопировать шмотки тупо подняв их с пола, тупо набрав save и тупо крашнув мир одним из тысячи доступных на тот момент способов. Ну, или сделать все то же самое прямо перед плановым ребутом. В общем, тупо пробовали до нас. Тупо не работает.
Я в ветке про Дримленд уже описывал в общих чертах.
Без специальной поддержки языка это не так уж и просто по описанной выше причине. Даже если писать в базу с транзакциями, надо знать когда можно завершить транзакцию так, чтоб, например, при передаче денег от одного персонажа другому деньги не исчезли бесследно и не появились из ниоткуда в случае внезапного краща, или отключения света.
Я говорю про сохранение состояния всей виртуальной машины целиком, включая выполняемый код, глобальные + локальные переменные, потоки, стек, и тд. Теоретически интерпретатор можно остановить в любой момент выдернув сервер из розетки и продолжить с того же места 10 лет спустя. При этом с точки зрения выполняемых скриптов ничего не произойдет. Мне известно только об одном очень специфическом клоне jvm который позволяет делать нечто подобное, но дальше тезисов этот проект вроде так и не сдвинулся — слишком узкая область применения.
Пока далеко не большинство. В Дриме где-то 250к строк кода на с++ и всего 25к строк кода на Фене.
В Дриме с момента выбора кодировке персонаж сразу в мире. У него стандартное имя Stranger и ему недоступны почти все команды. В остальном это полноценный персонаж.
Вся процедура создания персонажа сводится к общению с мобом. Феня для таких задач и создавалась.
Руффина прикрутила автоматическое склонение имен при создании персонажа где-то месяц назад. Может рассказать сколько это заняло у нее времени.
Да. Не только нативные классы — почти весь код перегружается налету. Начиная с работы с сокетами и заканчивая игровой логикой. Так было в Дриме задолго до Фени. Нельзя поменять без ребута только несколько системных библиотек.
Что именно? Кто должен контролировать запись? И главное — когда это должно происходить?
Эти аргументы применимы практически к любому DSL. Однако вся суть DSL заключается именно в том, чтоб снизить трудоемкость в узком диапазоне задач. Да, на Фене сложно написать операционную систему, или, например, навигационную систему для баллистических ракет. Но с этими задачами вполне справляется С++. Феня хороша для описания поведения комнат, предметов, мобов, написания квестов, простых активных/пассивных умений/заклинаний и, пожалуй, все. Однако это уже больше половины кода некоторых мадов. Если для перечисленных задач не хватает какой-то структуры данных, или библиотеки — можно без всяких ребутов за пару минут добавить пару нативных классов/вызов с необходимой функциональностью и продолжить строгать скрипты. Подсказка по существующему API встроена в сам язык (сперто из питона).
Синтаксис языка не такой уж и экзотический. Кто угодно с опытом работы на яваскрипте сможет без проблем читать существующие скрипты. Еще через пару часов экспериментов прямо в мире, вполне сможет написать и отладить что-то вроде этого: dreamland.rocks/fenia/fire.html
2. В общих чертах это работает так: все скриптовые объекты сохраняются в Berkeley DB. Происходит это постепенно в конце каждого такта и ограничено по времени так, чтоб каждый такт по прежнему был равен 0.25 секунды. Все изменения сохраняются в контексте долгоиграющей транзакции. Когда нечего сохранять, состояние базы на диске полностью соответствует состоянию виртуальной машины и текущая транзакция завершается. Berkeley DB гарантирует что даже при аварийном отключении питания при повторном открытии базы ее состояние будет соответствовать одному из последних коммитов. Не важно какому именно. Т.е. всегда есть шанс, что какие-то изменения не сохранятся, однако есть гарантия, что состояние виртуальной машины (да и мира в целом) будет согласованным (consistent). Например, если ты бросил предмет в комнате, то после выключения/включения питания предмет окажется или на полу, или в инвентаре, но никак не «и там, и там», или «ни там, ни там». Статистика показывает что полное сохранение состояния занимает 3 мс. 10 лет назад, на старом железе сохранение 100,000 долгоживущих объектов было размазано на десяток тактов. Разумеется, если бы в мире тогда был скрипт, который бы это делал каждый такт, транзакция бы никогда не завершилась.
— скриптовая виртуальная машина должна сохранять свое состояние между ребутами (включая внезапное выдергивание сервера из розетки),
— должна быть возможность расширять функциональность языка без ребутов.
На тот момент я не знал ни одного языка в котором можно было бы это сделать.