DreamLand MUD жив!
dreamland.rocks 9000
https://dreamland.rocks
http://forum.mudconnector.su/viewtopic.php?f=6&t=1934
Два замечания от Пруля
1. Ох уж эти новые доменные зоны
2. У них симпатичный веб-клиент на сайте
3. Сейчас внесу их в свою статистику
https://dreamland.rocks
http://forum.mudconnector.su/viewtopic.php?f=6&t=1934
Два замечания от Пруля
1. Ох уж эти новые доменные зоны
2. У них симпатичный веб-клиент на сайте
3. Сейчас внесу их в свою статистику
24 комментария
— видимо старый движок основательно переписан.
— интересно это переделанные старые mobprogs'ы или свой какой-то придумали.
А так сделано вроде солидно, надеюсь авторы мада не забьют на него через месяц.
вот ответ на вопрос про скриптовый язык от его создателя, Филдса (Filths).
— Скриптовый язык полностью свой. У Дрима есть важная историческая особенность — полностью сохранять состояние между ребутами.
Если ты бросишь в комнате предмет, он там будет лежать годами. Уже даже десятилетиями.
В связи с этим, к языку было то же самое требование: сохранять стабильное состояние виртуальной машины даже если сервер в любой момент выдернут из розетки.
На тот момент я не нашел ни одного существующего скриптового языка, виртуальную машину которого было бы легко и итеративно сохранить на диск.
Синтаксис языка — какая-то дикая помесь яваскрипта, луа и пхп. Он не перегружен, в том смысле что описание грамматики влезает на две страницы текста.
Из-за перманентного состояния виртуальной машины и из-за того что функции — обычные объекты, скрипты можно легко писать и тестить прямо из мира.
Вот однострочный пример: pastebin.com/Rhs3r0V4
И все. Этот скрипт будет висеть на мобе всегда. Пока его не убьют, или не присвоят его onGreet новое значение. Аналогично можно присвоить поведение прототипу моба. Тогда все мобы типа от рождения и до смерти будут себя так вести.
Вот более сложный пример: dreamland.rocks/fenia/nanny.html Это скрипт ответственный за вход в мир и создание персонажа.
— От себя добавлю, что сейчас я постепенно добавляю информацию на сайт: появилась база вещей, пути к зонам, следующие на очереди — хелпы и информация для строителей (примеры использования языка и встроенного редактора зон). Мир активно ищет новых игроков, кодеров и билдеров.
А как там с миром дела обстоят? Отталкивает частичная англоязычность, когда среди русского текста встречаются вставки английского. Это сильно по атмосфере мира бьет, по крайней мере для меня. Зоны там стандартные ромовские переведенные или еще и свои есть?
Планируется ли движок и скриптовый язык в open-source переводить?
Своих зон около 30 штук, остальные ромовскиие, анатолийские и т.д.
Движок состоит из ядра и кучи плагинов. Абсолютно все выкладывать в open-source не планирую, т.к. там очень специфические именно для этого мира вещи. Планирую выложить в общий доступ ядро (включая скриптовый язык) и минимальный набор плагинов (например, отвечающих за сетевое подключение, загрузку зон, перемещение, общение и тд). Уже был успешный эксперимент интеграции ядра и языка с другим мудом, Грани Мира. Когда Груумш и я его снова подняли в 2015м, в нем уже был прикручен новый скриптовый язык и многое перегружалось на лету. Насколько я помню, титанических усилий на интеграцию не понадобилось.
Игроки не появятся пока не появится интересный геймплей, а для этого нужны какие-то свои уникальные фишки. Из ромовских мадов, только аладон более или менее популярен, в остальные играют полторы калеки. Возможно для привлечения игроков придется многое менять и очень сильно.
Насколько я знаю, fenia это полностью свой язык, придуманный и написанный ими, немного напоминающий lua.
Лично я, хоть и высококлассный программист, делать свои сложные языки побаиваюсь, это не такая уж и простая задача. Для другого своего проекта я сделал усеченный интерпретатор языка forth (и гордо назвал его proolskript), но тот, кто знает основы языков, тот скажет, forth программируется не просто, а очень просто, в этом и его сила и слабость. И у меня была мысль вставить forth в свой мад для некоторой автоматизации. Например, в моем маде уже есть команда создать новую комнату в определенном направлении,
например
build n
Добавив фортовские операторы можно было бы одной строкой сделать, например, ход на 10 клеток на север вот так
10; for; build n; n; endfor
Здесь 10 раз повторяется то, что между словами for и endfor (а повторяется создать комнату на севере и перейти на север). Синтаксис форта обратный, поэтому параметр идет первым, перед оператором. Выглядит конечно коряво, но программируется легко
Ну, или сожрать 10 раз хлеб
10; for; есть хлеб; endfor
(а если запрограммировать немного по другому, те же конструкции не будут нуждать в точках с запятой, но это уже частности)
Если есть какие-то вопросы по формату, отвечу.
Практически всё переведено на XML, кроме двух вещей:
* часть профайла игрока где хранится инвентарь и дом.животное
* так называемые дропы — информация о том, в какой комнате сейчас находятся какие предметы и мобы (для сохранения состояния между ребутами)
Сериализация из/в XML не требует дополнительных усилий со стороны программера — если поля класса помечены специальными «аттрибутами» (по сути — define-ми), генерацией дополнительного кода для сериализации всех полей занимается meta-object compiler, это просто еще один этап в сборке исходников.
— скриптовая виртуальная машина должна сохранять свое состояние между ребутами (включая внезапное выдергивание сервера из розетки),
— должна быть возможность расширять функциональность языка без ребутов.
На тот момент я не знал ни одного языка в котором можно было бы это сделать.
Но раз уж начал спрашивать, то продолжу это грязное дело. Я конечно не специалист, но вроде бы для этих целей используют https://en.wikipedia.org/wiki/Pike_(programming_language) и https://en.wikipedia.org/wiki/AngelScript. Могли бы они подойти подойти для ваших целей? Или Феня все-равно лучше?
1. Чо вы все так не любите ребуты? Вот, World of Warcraft перезагружается каждую неделю по графику и все довольны — и игроки и админы
2. А как вообще сохранять состояние машины так, чтобы оно не терялось даже при выдергивании сервера из розетки. Непрерывно писать на диск? Это тоже чревато сбоем файловой системы. И все равно, непрерывно не получится. То, что поменялось в ОЗУ и еще не записалось, потеряется
Вот проходишь большую зону с группой игроков полчаса, до конца прохождения еще где-то полчаса надо и тут сообщение приходит: «закругляйтесь, сейчас перезагрузка будет». Игрокам ничего не остается кроме как развести руками и заканчивать игру. А после ребута нет никаких гарантий, что группу снова получиться собрать. Координировать действия нескольких игроков — тот еще гемор.
И мне кажется, что частые плановые перезагрузки — признак того, что с сервером проблемы какие-то. Как минимум утечки памяти или еще что-нибудь. Для чего еще его перезагружать то так часто? Можно сделать так, чтобы ребуты несли минимум неудобств (например, делать их когда онлайн минимален), но не более.
Начнем с того, что сервера работают на железе, а железо имеет свойство стареть и умирать. И чаще всего смерть происходит мгновенно и без предупреждения типа деградации сервиса. И не всё можно сдублировать (типа raid массивов). Поэтому главное в поддержании работоспособности сервера — профилактика, а именно замена старых деталей по графику, хотя они еще работают.
И перезагрузка в ВоВ происходит по графику, каждый четверг, об этом знают все и рейды не планируют.
Они каждую неделю меняют железо что-ли? Но для мадов это не нужно так часто делать.
Есть пример многочисленного семейства LPmud'ов которые годами прекрасно работают без перезагрузок, то есть ребут — это не абсолютная необходимость.
2. В общих чертах это работает так: все скриптовые объекты сохраняются в Berkeley DB. Происходит это постепенно в конце каждого такта и ограничено по времени так, чтоб каждый такт по прежнему был равен 0.25 секунды. Все изменения сохраняются в контексте долгоиграющей транзакции. Когда нечего сохранять, состояние базы на диске полностью соответствует состоянию виртуальной машины и текущая транзакция завершается. Berkeley DB гарантирует что даже при аварийном отключении питания при повторном открытии базы ее состояние будет соответствовать одному из последних коммитов. Не важно какому именно. Т.е. всегда есть шанс, что какие-то изменения не сохранятся, однако есть гарантия, что состояние виртуальной машины (да и мира в целом) будет согласованным (consistent). Например, если ты бросил предмет в комнате, то после выключения/включения питания предмет окажется или на полу, или в инвентаре, но никак не «и там, и там», или «ни там, ни там». Статистика показывает что полное сохранение состояния занимает 3 мс. 10 лет назад, на старом железе сохранение 100,000 долгоживущих объектов было размазано на десяток тактов. Разумеется, если бы в мире тогда был скрипт, который бы это делал каждый такт, транзакция бы никогда не завершилась.
Вот, приведу близкий мне пример: есть операционные системы Виндовс и Линукс. В Винде (особенно в старых ее версиях) любая найстройка, смена параметров, установка доп. софта требовала перезагрузки, а о и не одной (виновато, наверное, monolitic ядро Винды). В Линуксе модульная архитектура и многие модули ядра и сервисы можно перезапустить без перезагрузки всего сервера. Но не все. И порой таки надо перезагружаться.
Так вот, у меня создается впечатление, что многие авторы современных мадов то ли боятся перезагрузок, то ли из спортивного интереса создают код, который перезагружать не надо никогда. (Либо перезагрузка там длительный и громоздкий процесс)