Dreamland Fenya: пообсуждаем?
Собственно, хотелось бы поговорить об их собственном языке программирования.
Меня почему-то очень сильно смутили ответы (как я полагаю, разработчика этого языка).
Тот момент, как я понимаю — это начало 2000-х? На данный момент я точно уверен, что такое можно провернуть с питоном, и скорее всего можно было провернуть с ним это 18 лет назад.
Э, если это вполне сформировавшийся язык, такой как Lua, зачем расширять его функционал ?:) Если тут имелось ввиду расширение функционала мира на основе языке без ребутов — так это можно сделать на любом существующем скриптовом языке (и всегда можно было, что сейчас, что 20 лет назад).
Просто я со стороны не вижу никаких плюсов этого языка. Для сохранения состояния между ребутами можно было тупо писать на диск и делать бекапы. А вот минусов, на мой взгляд куча:
У языка нет поддержки коммьюнити, у языка малый функционал. Нет поддержки большинства популярных структур хранения данных, нет новомодных фишек, нет дополнительный библиотек. Из этого вытекает еще один минус — увеличение трудоемкости в некоторых случаях. Понятно, что для квестов подай-принеси нет особой разницы, будет это свой язык или какой-нибудь популярный, а вот для расширения функционала игры — разница есть. Например, мне будет нужно что-то, что может хранить дерево и проводить простейшие операции с ним. Для любого популярного языка, я найду библиотеку/готовую реализацию, что займет минут 10 максимум, и начну делать что-то для мада, а для Fenya, сначала придется писать свою реализацию, а потом уже реализовывать свою идею в маде.
Еще хотелось бы добавить пару предложений о самом маде. Тут я уже обращаюсь к имморталам дримлэнда:
1) Допилить бы цветовую схему мада, например, чтобы попадания мобов по мне, отображались определенным цветом.
2) Зачем эти англоязычные вставки в маде для команд? Времена, когда человек мог принмать русский текст, но не мог на нем писать — давно уже прошли
3) Желательно, добавить одной кнопкой генерацией чара для новичка. Т.е. создаешь чара, вводишь имя, вводишь команду новичок, и твой чар имеет оптимальную профессию, расу и другие характеристики, чтобы начать просто осваиваться в мире. (примерно такое я делал в былинах)
4) Кидайте чара сразу к мобам, которых можно бить. Мад — это сначала гринд, потом эксплор. Имхо, надо делать так, чтобы чар изначально чувствовал себя «нагибатором» и видел быстро увеличивающиеся циферки.
Меня почему-то очень сильно смутили ответы (как я полагаю, разработчика этого языка).
На тот момент я не нашел ни одного существующего скриптового языка, виртуальную машину которого было бы легко и итеративно сохранить на диск.
Тот момент, как я понимаю — это начало 2000-х? На данный момент я точно уверен, что такое можно провернуть с питоном, и скорее всего можно было провернуть с ним это 18 лет назад.
— должна быть возможность расширять функциональность языка без ребутов.
Э, если это вполне сформировавшийся язык, такой как Lua, зачем расширять его функционал ?:) Если тут имелось ввиду расширение функционала мира на основе языке без ребутов — так это можно сделать на любом существующем скриптовом языке (и всегда можно было, что сейчас, что 20 лет назад).
Просто я со стороны не вижу никаких плюсов этого языка. Для сохранения состояния между ребутами можно было тупо писать на диск и делать бекапы. А вот минусов, на мой взгляд куча:
У языка нет поддержки коммьюнити, у языка малый функционал. Нет поддержки большинства популярных структур хранения данных, нет новомодных фишек, нет дополнительный библиотек. Из этого вытекает еще один минус — увеличение трудоемкости в некоторых случаях. Понятно, что для квестов подай-принеси нет особой разницы, будет это свой язык или какой-нибудь популярный, а вот для расширения функционала игры — разница есть. Например, мне будет нужно что-то, что может хранить дерево и проводить простейшие операции с ним. Для любого популярного языка, я найду библиотеку/готовую реализацию, что займет минут 10 максимум, и начну делать что-то для мада, а для Fenya, сначала придется писать свою реализацию, а потом уже реализовывать свою идею в маде.
Еще хотелось бы добавить пару предложений о самом маде. Тут я уже обращаюсь к имморталам дримлэнда:
1) Допилить бы цветовую схему мада, например, чтобы попадания мобов по мне, отображались определенным цветом.
2) Зачем эти англоязычные вставки в маде для команд? Времена, когда человек мог принмать русский текст, но не мог на нем писать — давно уже прошли
3) Желательно, добавить одной кнопкой генерацией чара для новичка. Т.е. создаешь чара, вводишь имя, вводишь команду новичок, и твой чар имеет оптимальную профессию, расу и другие характеристики, чтобы начать просто осваиваться в мире. (примерно такое я делал в былинах)
4) Кидайте чара сразу к мобам, которых можно бить. Мад — это сначала гринд, потом эксплор. Имхо, надо делать так, чтобы чар изначально чувствовал себя «нагибатором» и видел быстро увеличивающиеся циферки.
16 комментариев
Например, Godot использует собственный скриптовый язык — GDScript, так как решили, что существующие скриптовые языки по требуемым параметрам не подходят для движка. В Unity используют собственный диалект Javascript и т.д. Да и в Circle'ах используют DGScript, больше нигде не используемый. В общем, не вижу в Фене ничего странного.
Собственно их цель была повышение скорости работы языка для скриптов. Ну и сам пример не очень удачный, годных проектов на нем практически нет.
Который, опять же, практически никто не использует.
Только для триггеров. Если бы fenya использовался только для триггеров, в принципе было бы не так плохо.
Я это веду все к тому, что вероятность привлечения новых кодеров на этом языке для мада близится к нулю.
Нет, тут имелось в виду расширение API, т.е. добавление доступа ко все большему количествау игровых структур и их полей и методов.
> Зачем эти англоязычные вставки в маде для команд?
Для новых игроков это может и не нужно, а из старожилов (включая меня) достаточное кол-во людей до сих пор использует англ команды.
Про цвета повреждений запишу себе, спасибо за идею.
Тут идея появилась, а почему бы в клиент не добавить опцию отображать или нет англоязычные вставки. Идея в том, что в Юникоде коды разные у латиницы и кириллицы, клиент может просто отрубать начальный диапазон символов. Если конечно нагрузки слишком большой не возникнет на ресурсы компьютера.
1) Некрасиво будет смотреться, если брать текущую версию дримлэнда
2) Всякие ASCII-рисунки будут отображаться криво
3) Латиница все же иногда нужна в маде (например, в общении).
Тогда может быть какой-нибудь режим сделать ?
Так если вся игровая логика написана на скриптовом языке, API не нужно расширять.
Но помимо этого, еще есть не до конца переведенные сообщения и зоны, над этим работаем.
Кто сказал что вся игровая логика на скриптовом языке? Там ниже Филдс привел статистику, сколько строк кода на С++ и сколько на Фене.
Если в Фене написать что-то типа: ch.profession.name — должен быть соответствующий кусок кода на С++, который обернет нативный класс Character и предоставит read/write доступ к его полю profession, а также обернет сам нативный класс Profession и даст доступ к полю name. Вот именно это и имеется в виду когда говорят «расширение API»: предоставить из Фени доступ к нативным классам, их полям и методам.
Годно. Но, имхо, лучше по дефолту, чтобы отображались по русски.
Что именно? Кто должен контролировать запись? И главное — когда это должно происходить?
Эти аргументы применимы практически к любому DSL. Однако вся суть DSL заключается именно в том, чтоб снизить трудоемкость в узком диапазоне задач. Да, на Фене сложно написать операционную систему, или, например, навигационную систему для баллистических ракет. Но с этими задачами вполне справляется С++. Феня хороша для описания поведения комнат, предметов, мобов, написания квестов, простых активных/пассивных умений/заклинаний и, пожалуй, все. Однако это уже больше половины кода некоторых мадов. Если для перечисленных задач не хватает какой-то структуры данных, или библиотеки — можно без всяких ребутов за пару минут добавить пару нативных классов/вызов с необходимой функциональностью и продолжить строгать скрипты. Подсказка по существующему API встроена в сам язык (сперто из питона).
Синтаксис языка не такой уж и экзотический. Кто угодно с опытом работы на яваскрипте сможет без проблем читать существующие скрипты. Еще через пару часов экспериментов прямо в мире, вполне сможет написать и отладить что-то вроде этого: dreamland.rocks/fenia/fire.html
Варианты по сложнее и по интереснее, например, ZODB или Prevayler (для питона он тоже есть).
Я с этим и не спорю, но как мне показалось, вы переписали на феню большинство логики мада, например, создание персонажа. К примеру, вам нужно добавить автоматическое склонение имен. В nodejs я просто добавил библиотеку и написал пару строк кода. У вас же это все займет несколько больше времени.
Нативные классы и вызовы у вас пишутся на Си и подгружается в виде модулей?
Я говорю про сохранение состояния всей виртуальной машины целиком, включая выполняемый код, глобальные + локальные переменные, потоки, стек, и тд. Теоретически интерпретатор можно остановить в любой момент выдернув сервер из розетки и продолжить с того же места 10 лет спустя. При этом с точки зрения выполняемых скриптов ничего не произойдет. Мне известно только об одном очень специфическом клоне jvm который позволяет делать нечто подобное, но дальше тезисов этот проект вроде так и не сдвинулся — слишком узкая область применения.
Пока далеко не большинство. В Дриме где-то 250к строк кода на с++ и всего 25к строк кода на Фене.
В Дриме с момента выбора кодировке персонаж сразу в мире. У него стандартное имя Stranger и ему недоступны почти все команды. В остальном это полноценный персонаж.
Вся процедура создания персонажа сводится к общению с мобом. Феня для таких задач и создавалась.
Руффина прикрутила автоматическое склонение имен при создании персонажа где-то месяц назад. Может рассказать сколько это заняло у нее времени.
Да. Не только нативные классы — почти весь код перегружается налету. Начиная с работы с сокетами и заканчивая игровой логикой. Так было в Дриме задолго до Фени. Нельзя поменять без ребута только несколько системных библиотек.
Сдаюсь. Только до сих пор не понял, зачем надо сохранять полное состояние вм. Как я понимаю, сейвится состояние комнат, объектов, игроков. Файты тоже сейвятся ?
Что касается склонений, ну я взяла перловую либу, которая делает склонения, и за обеденный перерыв переписала ее на феню.
Состояние игрового мира: объекты, мобы, комнаты.
Игровой движок
А когда это происходит у вас? Понятно, что писать на диск не получится так же быстро, как в БД, но это не критично. Просто размазывать сохранение на большое количество игровых тиков.
Как на счет состояния потоков, глобальных/локальных переменных и тд?
Даже если отбросить многопотоковость (без которой, кстати, очень сложно было бы построить нормальный диалог с персонажем) и полное состояние виртуальной машины, только на то чтоб сохранить все мобы и предметы с помощью какого-нибудь pickle уйдет значительно больше времени чем четверть секунды. А делать это итеративно не получится если нет возможности получить список измененных с прошлой итерации объектов. Когда-то давным-давно предметы записывались «тупо» на диск. В итоге можно было ксерокопировать шмотки тупо подняв их с пола, тупо набрав save и тупо крашнув мир одним из тысячи доступных на тот момент способов. Ну, или сделать все то же самое прямо перед плановым ребутом. В общем, тупо пробовали до нас. Тупо не работает.
Я в ветке про Дримленд уже описывал в общих чертах.
Без специальной поддержки языка это не так уж и просто по описанной выше причине. Даже если писать в базу с транзакциями, надо знать когда можно завершить транзакцию так, чтоб, например, при передаче денег от одного персонажа другому деньги не исчезли бесследно и не появились из ниоткуда в случае внезапного краща, или отключения света.
Ну уйдет несколько минут, и игровой мир откатится на несколько минут в случае краша. Не думаю, что краши частое явление у вас.
Я думаю, что было понятно, что из коробки все это сразу работать не будет, надо будет кое-что допилить.
В остальных мадах такая схема работает. Ксерокопирование шмоток в былинах фиксится с помощью уникальных id.
Если не нравится хранить состояние мада в файле, можно хранить в базе данных считывая/записывая отдельно каждый объект по мере необходимости (как в браузерных играх).