клиент может просто отрубать начальный диапазон символов.
1) Некрасиво будет смотреться, если брать текущую версию дримлэнда
2) Всякие ASCII-рисунки будут отображаться криво
3) Латиница все же иногда нужна в маде (например, в общении).
А когда это происходит у вас? Понятно, что писать на диск не получится так же быстро, как в БД, но это не критично. Просто размазывать сохранение на большое количество игровых тиков.
Можно подробней, потому что у меня есть подозрение что мы говорим о совершенно разных вещах.
Самый простой вариант — использование 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, больше нигде не используемый. В общем, не вижу в Фене ничего странного.
Очень даже неплохо, только бы побольше действий для такого контекстного меню. Желательно, чтобы вообще все, кроме разговоров, можно было делать мышкой.
P2w стали нормальным явлением, т.е. нормой индустрии. Я согласен с вашей оценкой с точки зрения нравственного аспекта данной проблемы, но реальность уже изменилась, проще всего под нее подстроиться и просто напросто не пытаться «выиграть» в pay2win — если нет стремления 'win', то и 'pay' безразличен. Просто играть в свое удовольствие без вложений или с минимальными (на чашку кофе разработчикам). Именно это я имел в виду в своем прошлом видео.
Не согласен с мнением, что p2w-игры это нормально. Я считаю, что p2w допустимо лишь в однопользовательских играх или играх без pvp. Но если в игре есть pvp, то делать ее p2w это подло. Создатели игры сталкивают игроков кошельками и побеждает тот, у кого он толще. Я отношусь к играм как к виду искусства и думаю, что пользоваться в них таким приемом — бесчестно.
По поводу голосового интерфейса. Так на Западе он только только появляется, а мы как всегда безуспешно пытаемся пытаемся догнать его. Через несколько лет все это появится и у нас. Тут еще дело тормозится тем, что английский — это аналитический язык, а русский — синтетический, то есть английский проще запрограммировать, да и вообще он проще русского.
Я пару лет назад присматривался к CMU Sphinx: сами команды вполне можно забить в jsgf (местный формат грамматики), аргументы (названия предметов и мест, а также имена) — тоже. Наибольшая сложность — непосредственно с прямой речью, но ее можно «скармливать» гуглу или яндексу.
Но — нужен специальный клиент, чтоб со Сфинксом работать.
Так-то любая игра, будучи запущенной в браузере, является браузеркой. Это инструмент — он ни хороший, ни плохой.
Сейчас ситуация такова, что браузер есть на всех современных операционных системах (Windows, Linux, Mac, Android, IOS и прочие) и пользователь к нему привык, в то время как телнет (а также ssh или специализированные клиенты) требуют какого-никакого освоения и/или установки-настройки.
Из этого следует, что наимение затратной реализацией клиента для игры с клиент-серверной архитектурой является веб-клиент. Посудите сами: он не требует установки на устройство пользователя, избавляет разработчика от привязки к магазинам или репозиториям, не требует написания какой-либо системы проверок обновления, позволяет абстрагироваться от вывода графики (нужно просто сверстать страничку — рисование берет на себя браузер), а также кросс-платформен и аппаратно-независим.
Разумеется, есть и минусы: веб-клиент практически не имеет защиты от пользователя, работает не очень эффективно и превращается в тормознутого макаронного монстра при попытках сделать что-то по-настоящему сложное или ресурсозатратное. Но так как речь идет о клиенте для мада, эти минусы не так уж и важны.
Я предусмотрел жалобы вида «браузер — фу, я телнетом 35 лет пользуюсь», «хочу ssh» или «а почему нет совместимости с моим мад-клиентом пятнадцатилетней давности?», поэтому писал сервер с рассчетом на то, что протоколов взаимодействия с пользователем может быть много и разных. Тот же телнет может быть встроен за час-полтора.
Если считаете, что нормальный мад просто не может жить без {PROTOCOL_NAME} — пишите сюда или на почту. А лучше — создайте issue в репозитории nmud.
Ну, я не вижу ничего плохого в браузерках. Я это предложил потому-что если в тексте есть какие-то интерактивные блоки, то встает вопрос чтобы они были активны только в текущей комнате и не были активны в предыдущих, доступных при прокрутке текста.
Мады по определению работают через текстовый терминал. Так что интерфейс не проблема, это просто набор текста под диктовку. Опять же, можно запилить текстовые макросы на кнопки или сочетания клавиатуры, чтобы набирать одной рукой или одним пальцем. Есть игровые клавиатуры специально для левшей или правшей.
Проблема больше в самом распознавании голоса и том, что команды MUDов ни грамматически, ни орфографически не укладываются в словари распознавателей.
Время и так отображается по команде 'эффекты', можно по нему сортировать и тд. Панель служит для удобства держать это всегда перед глазами и сразу замечать, что слетело а что вот-вот слетит, не заглядывая в команду каждый раз. Время на нее тоже можно докрутить, но уже придется сражаться за место на экране по ширине.
1) Некрасиво будет смотреться, если брать текущую версию дримлэнда
2) Всякие ASCII-рисунки будут отображаться криво
3) Латиница все же иногда нужна в маде (например, в общении).
Тогда может быть какой-нибудь режим сделать ?
Так если вся игровая логика написана на скриптовом языке, API не нужно расширять.
Состояние игрового мира: объекты, мобы, комнаты.
Игровой движок
А когда это происходит у вас? Понятно, что писать на диск не получится так же быстро, как в БД, но это не критично. Просто размазывать сохранение на большое количество игровых тиков.
Варианты по сложнее и по интереснее, например, ZODB или Prevayler (для питона он тоже есть).
Я с этим и не спорю, но как мне показалось, вы переписали на феню большинство логики мада, например, создание персонажа. К примеру, вам нужно добавить автоматическое склонение имен. В nodejs я просто добавил библиотеку и написал пару строк кода. У вас же это все займет несколько больше времени.
Нативные классы и вызовы у вас пишутся на Си и подгружается в виде модулей?
Тут идея появилась, а почему бы в клиент не добавить опцию отображать или нет англоязычные вставки. Идея в том, что в Юникоде коды разные у латиницы и кириллицы, клиент может просто отрубать начальный диапазон символов. Если конечно нагрузки слишком большой не возникнет на ресурсы компьютера.
Что именно? Кто должен контролировать запись? И главное — когда это должно происходить?
Эти аргументы применимы практически к любому DSL. Однако вся суть DSL заключается именно в том, чтоб снизить трудоемкость в узком диапазоне задач. Да, на Фене сложно написать операционную систему, или, например, навигационную систему для баллистических ракет. Но с этими задачами вполне справляется С++. Феня хороша для описания поведения комнат, предметов, мобов, написания квестов, простых активных/пассивных умений/заклинаний и, пожалуй, все. Однако это уже больше половины кода некоторых мадов. Если для перечисленных задач не хватает какой-то структуры данных, или библиотеки — можно без всяких ребутов за пару минут добавить пару нативных классов/вызов с необходимой функциональностью и продолжить строгать скрипты. Подсказка по существующему API встроена в сам язык (сперто из питона).
Синтаксис языка не такой уж и экзотический. Кто угодно с опытом работы на яваскрипте сможет без проблем читать существующие скрипты. Еще через пару часов экспериментов прямо в мире, вполне сможет написать и отладить что-то вроде этого: dreamland.rocks/fenia/fire.html
Нет, тут имелось в виду расширение API, т.е. добавление доступа ко все большему количествау игровых структур и их полей и методов.
> Зачем эти англоязычные вставки в маде для команд?
Для новых игроков это может и не нужно, а из старожилов (включая меня) достаточное кол-во людей до сих пор использует англ команды.
Про цвета повреждений запишу себе, спасибо за идею.
Собственно их цель была повышение скорости работы языка для скриптов. Ну и сам пример не очень удачный, годных проектов на нем практически нет.
Который, опять же, практически никто не использует.
Только для триггеров. Если бы fenya использовался только для триггеров, в принципе было бы не так плохо.
Я это веду все к тому, что вероятность привлечения новых кодеров на этом языке для мада близится к нулю.
Например, Godot использует собственный скриптовый язык — GDScript, так как решили, что существующие скриптовые языки по требуемым параметрам не подходят для движка. В Unity используют собственный диалект Javascript и т.д. Да и в Circle'ах используют DGScript, больше нигде не используемый. В общем, не вижу в Фене ничего странного.
По поводу голосового интерфейса. Так на Западе он только только появляется, а мы как всегда безуспешно пытаемся пытаемся догнать его. Через несколько лет все это появится и у нас. Тут еще дело тормозится тем, что английский — это аналитический язык, а русский — синтетический, то есть английский проще запрограммировать, да и вообще он проще русского.
Но — нужен специальный клиент, чтоб со Сфинксом работать.
Сейчас ситуация такова, что браузер есть на всех современных операционных системах (Windows, Linux, Mac, Android, IOS и прочие) и пользователь к нему привык, в то время как телнет (а также ssh или специализированные клиенты) требуют какого-никакого освоения и/или установки-настройки.
Из этого следует, что наимение затратной реализацией клиента для игры с клиент-серверной архитектурой является веб-клиент. Посудите сами: он не требует установки на устройство пользователя, избавляет разработчика от привязки к магазинам или репозиториям, не требует написания какой-либо системы проверок обновления, позволяет абстрагироваться от вывода графики (нужно просто сверстать страничку — рисование берет на себя браузер), а также кросс-платформен и аппаратно-независим.
Разумеется, есть и минусы: веб-клиент практически не имеет защиты от пользователя, работает не очень эффективно и превращается в тормознутого макаронного монстра при попытках сделать что-то по-настоящему сложное или ресурсозатратное. Но так как речь идет о клиенте для мада, эти минусы не так уж и важны.
Я предусмотрел жалобы вида «браузер — фу, я телнетом 35 лет пользуюсь», «хочу ssh» или «а почему нет совместимости с моим мад-клиентом пятнадцатилетней давности?», поэтому писал сервер с рассчетом на то, что протоколов взаимодействия с пользователем может быть много и разных. Тот же телнет может быть встроен за час-полтора.
Если считаете, что нормальный мад просто не может жить без {PROTOCOL_NAME} — пишите сюда или на почту. А лучше — создайте issue в репозитории nmud.
Проблема больше в самом распознавании голоса и том, что команды MUDов ни грамматически, ни орфографически не укладываются в словари распознавателей.