Quest Navigator
Flash плохо поддерживает сенсорные экраны, поэтому попытка напрямую портировать AeroQSP на iOS провалилась.
В связи с этим я решил разработать новый плеер, взяв за основу AeroQSP и переписав весь код, отвечающий за вывод на экран и взаимодействие с пользователем. Название - Quest Navigator. В первую очередь плеер делается с расчетом на мобильные устройства. В будущем, возможно, этот плеер будет доработан для работы в Windows, с тем чтобы заменить нынешнюю версию AeroQSP.
Сначала планируется сделать его на iOS, далее попытаюсь собрать под Android, и уж потом для Windows.
Принципиальные отличия от нынешней версии AeroQSP:
1. Используется не самописный HTML-рендер Байта, а нативный компонент браузера. Грубо говоря, игра будет запущена в “браузере по умолчанию”. Как следствие, в Quest Navigator должно работать то, что работает в обычном браузере - атрибуты, теги, форматирование текста, списки, таблицы и пр.
2. Будет использоваться JQuery(последней стабильной версии).
3. Поначалу не будут поддерживаться эффекты переходов между локациями, возможно будет реализовано позже.
4. Поначалу не будет поддерживаться “выделение действия” при наведении на него курсора - т.к. в мобильных устройствах курсора нет, а тормозит работу сильно. Для совместимости, обработчик выделения($ONACTSEL) будет вызываться сразу перед событием “действие нажато”. Возможно будет доработано позже.
5. Поначалу не будет строки ввода - т.к. с ней нужно возиться, используется она редко, а времени на разработку мало.
6. Поначалу не будет стрелочек для прокрутки текста - т.к. на мобильных устройствах это неудобно, будет скроллирование как обычно, “перетаскиванием” текста. Возможно, стрелочки будут добавлены позже.
Статус проекта на сегодняшний день:
Все уже работает.
Quest Navigator для Android
Quest Navigator для Windows
Quest Navigator для iOS
Исходный код:
JS+HTML фреймворк (папка “www/qsplib”) - http://github.com/Nex-Otaku/quest-navigator-core
Библиотечный проект для Android - http://github.com/Nex-Otaku/quest-navigator-library-android
Плеер для Windows и Macos на основе Awesomium - http://github.com/Nex-Otaku/quest-navigator-awesomium
Основная библиотека интерпретатора QSP для Quest Navigator - http://github.com/Nex-Otaku/qsplib-experimental
Текст этого сообщения будет меняться по мере работы над проектом. Также в теме буду отписываться об изменениях.
Если есть вопросы, спрашивайте, отвечу.
KOLANICH,
обсуждение про яваскрипт и формат файла я перенес в отдельную тему, т.к. это уже не относится к плееру Quest Navigator, а относится к ядру движка QSP.
См. здесь.
На лету так на лету.
Что мешает изменять дефолтный стиль при изменении переменных.
Короче я предлагаю сделать как в браузерах.
Если вы поковыряетесь в настройках или в about:config, то вы там найдёте определённый дефолтный стиль, применяемый ко всем элементам. Но когда вы назначаете элементу класс или стиль, часть дефолтного переопределяется. Если вы отредактируете дефолтный стиль, то изменятся все элементы без стиля и все где изменённый кусок стиля не переопределён.
Именно потому, что движок работает “как в браузере”, и не получится сделать без каких-то доп. настроек, атрибутов, переменных.
Это довольно сложно объяснить.
Есть изначальный стиль игры, он определяется CSS. Есть также настройки из переменных игры. Первым, при загрузке странички, загружается CSS. Далее применяются настройки из переменных игры. Т.к. у нас все “как в браузере”, то вид определяется самыми последними применившимися стилями - игровыми переменными. Существующие переменные написаны с расчетом на использование фиксированных координат - размер окна фиксирован, следовательно отступами в заранее известное количество пикселов расставляем диалоги и прочие элементы интерфейса. Если оформление конкретной игры рассчитано на использование фиксированных координат, то все в порядке, мы должны просто задать необходимые значения переменных, которые “дополнят” CSS.
Если же оформление нужно сделать с относительными координатами, то его просто так сделать не получится. Настройки, заданные в CSS, “собьются”, как только применятся значения переменных. Для защиты от переопределения стиля игрой можно либо вводить для каждого блока новую переменную, либо разрулить это атрибутами в HTML-шаблоне. Я счел более целесообразным сделать это через атрибут. Можно конечно добиться того же результата различными хаками, но я предпочитаю обойтись без этого, т.к. все-таки это основной функционал плеера.
ясно
а если так:
1 грузим и применяем css
2 проверяем, задан ли css, дублирующий переменные игры
если задан - из css значения копируем в переменные игры
если не задан - применяем переменные игры
исполняем код кусп
KOLANICH,
как раз сейчас и осуществляется проверка - атрибутом “protected”.
а без атрибута эту проверку осуществить нельзя?
KOLANICH,
Для защиты от переопределения стиля игрой можно либо вводить для каждого блока новую переменную, либо разрулить это атрибутами в HTML-шаблоне. Я счел более целесообразным сделать это через атрибут.
Добавил в заголовок темы ссылки на исходный код.
По сегодняшним итогам разработки плеера и игр пришёл к выводу, что следует сильнее разделять оформление и игру. Это позволяет делать более красивое и универсальное оформление, и одновременно позволяет дорабатывать оформление без вмешательства в код игры. Суть разделения: всё, что относится к оформлению, выносится на уровень шаблона JS+CSS+HTML. Весь текст и управляющий код остаётся в файле “.qsp”.
К сожалению, AeroQSP ориентирован на полное управление оформлением из кода игры. В связи с этим, придётся в дальнейших версиях Quest Navigator отказаться от поддержки AeroQSP. На данный момент поддерживается большинство функций оформления, в дальнейшем список совместимых настроек будет сокращаться.
Сделал вызов кода JavaScript из игры, с помощью нового оператора “EXEC”. Выполнится строка кода, начинающаяся с “JS:”. Использоваться должно для вызова функций оформления.
Пример:
EXEC("JS:skinSetStage('main');")
Сделал функцию запросов к плееру “GETPLAYER”.
Позволяет получить данные от плеера. Используется в настоящий момент для определения платформы (”iOS”, “Android”).
Пример:
IF LCASE(GETPLAYER('platform')) = 'ios':
...
END
К сожалению, пришлось внести локальные изменения в код библиотеки. Это неудобно, т.к. нормального репозитория для библиотеки ещё не заведено, а с переездом Байт тянет беспросветно. Но другого выхода, увы, нет.
Известно, что нынешняя “рабочая версия” Quest Navigator для Windows реализована на AIR. Но AIR как платформа мне не очень по душе. Опять же, сообщают о жутких проблемах с Касперским, а это весьма популярный антивирус.
Сейчас ищу альтернативу. Вроде бы подходящие:
Пока что остановился на Awesomium. Буду пробовать.
Собрал “Hello world” в чистом проекте для Awesomium.
Поднял репозиторий основной библиотеки QSP на GitHub.
http://github.com/Nex-Otaku/qsplib-experimental
Сейчас туда залита копия библиотеки из SVN-репозитория. Ревизия 694, самая свежая на сегодня.
Для плеера Quest Navigator буду брать библиотеку из этого репозитория. Если будут появляться коммиты в SVN-репозитории, буду подтягивать их сюда по мере необходимости.
Ветка “master” будет “чистой”, свои заточки для QN буду вести в отдельной ветке “experimental”. В частности, там будет реализована функция запросов к плееру.
Ожидаю, что при такой структуре будет легко и быстро синхронизировать все изменения с официальным репозиторием, когда Байт перевезёт его на GitHub.
Ну а самое главное, наконец-то любой сможет в один клик форкнуть библиотеку, предложить патч и т.п.
Поднял репозиторий для плеера на Awesomium.
http://github.com/Nex-Otaku/quest-navigator-awesomium
Подключил библиотеку QSP со своими изменениями (experimental) к проекту, проверил, работает.
Удалось загрузить HTML-файл с диска.