Трёп про JS в Quest Navigator
Я правильно понимаю, что сейчас реализован интерфейс QSP->JS только в одну сторону?
newsash,
конкретизируй вопрос. Что нужно?
Nex:
newsash,
конкретизируй вопрос. Что нужно?
Вчера увидел модуль работы с картой, там довольно тяжелый (ресурсоёмкий) программный код. Вот и подумалось - а не будет ли работать быстрее, если выносить тяжелые вычисления в JS. Для этого нужен интерфейс обмена данными между JS и QSP. Из QSP в JS передачу данных уже сейчас можно организовать, а вот обратно из JS в QSP - я не знаю.
А заодно это очень сильно поднимет гибкость движка и позволит авторам с шилом творить чудеса.
Что касается “тяжёлых вычислений”, то им вообще не место в текстовых играх. Это обычные страдания “программизмом”, когда автор от безделья или творческого бессилия придумывает тысячу способов забить гвоздь микроскопом. Ни в коем случае нельзя позволять в разработке плеера ориентироваться на подобную ерунду.
Во-вторых, “тяжёлые вычисления” должны происходить по-хорошему не в JS и не в интерпретируемом коде, а в “нативном” коде, написанном например на C/C++.
В-третьих, исполнять QSP-код из JS можно, но в этом нет никакой нужды для нормальной текстовой игры. JS-уровень должен обеспечивать только интерфейсную часть, то есть скин оформления. Выносить туда игровую логику было бы неправильно и чревато тяжёлыми последствиями.
В целом согласен, если не расширять круг применимости QSP, всё это не нужно.
newsash:
В целом согласен, если не расширять круг применимости QSP, всё это не нужно.
А что такое “круг применимости QSP”? Игра с окном текста, окном инвентаря, окном команд в виде меню?
А это уже другой вопрос, мне тоже хочется от QSP всего и сразу и сделать его совсем универсальным, базы данных там для себя писать и т.п., всё равно игры не пишу. Nex прав, если заморачиваться, нужно туда C/C++/ассемблерные вставки прикрутить. Сейчас главное Навигатор допилить до состояния, когда им активно пользоваться можно будет. А потом уже за всякие плюшки для кодоизвращенцев повоюем.