Веб-версия QSP (выполняющаяся на сервере)

ComatoZZZ,
веб версия уже есть.

Nex:

веб версия уже есть.

Если я правильно понял она на флеше?
Т.е. играть в нее можно только с компьютера.
А не планируется веб версии в которой события будут обрабатываться на сервере чтоб пользователь мог пользоваться телефоном без поддержки яваскрипта/флеша или еще чего то.
Ведь играть как раз удобней с телефона потому что обычно где нибудь в дороге есть время.

Без поддержки как минимум яваскрипта ее сделать нереально, движок QSP слишком богат возможностями.

Веб-версия, которая выполняется на сервере, уже была когда-то мной реализована на PHP(называлась wiQSP). Я эту разработку похоронил по следующим причинам:

1. Самое главное - низкое время отклика. Даже с небольшими яваскриптовыми трюками, которые позволяли держать открытым соединение с сервером, часто были заметны “провисания” между действием игрока и реакцией игры - зависимость от канала связи, это сильно раздражало игроков.

2. Невозможность реализовать некоторые фишки языка QSP - там, где требуется прервать выполнение кода на взаимодействие с пользователем, а также адекватное выполнение локации счетчика.

3. Невозможность простого апгрейда - т.к. библиотека QSP была перенесена на PHP “вручную”, то любое изменение в библиотека(выпуск новой версии QSP) потребовало бы вручную повторять то же самое в wiQSP.

Просто на первый взгляд у квестов и мобильных игр типа hools.mgates.ru/ и других много общего.

ComatoZZZ,
хм, нет. Браузерная многопользовательская игра только на первый взгляд может показаться похожей. На самом деле это совсем другой жанр. В браузерной многопользовательской игре(браузерке) могут быть разве что мини-квесты, выполняющиеся на примитивной серверной версии QSP. Например, так сделано в браузерке “Герои Войны и Денег” - там используется упрощенная версия QSP на PHP, основанная на wiQSP.

На QSP нельзя написать браузерку, на нем можно написать только мини-квесты для браузерки.

А если не секрет какие могут быть сложности. Как я понимаю основная проблема это таймер. если нужно что то делать связанное с временем пользователь не будет успевать если хранить в сессии время например и пересчитывать при обновлении. Многопользовательскую браузерную игру понятное дело никак. но вот просто браузерных для одного человека. большинство игр думаю работало бы.
Текущие состояние сеанса можно хранить в сессии и пересчитывать каждый раз при обновлении страницы.

ComatoZZZ,
никаких секретов нет, просто тема сложная, объяснить на пальцах не смогу. Поверь на слово, что полноценную серверную веб-версию QSP сделать невозможно чисто алгоритмически. А версию с урезанными возможностями я сейчас не вижу смысла продвигать. Если кому-то очень захочется, пусть делает, тратит своё личное время.

ComatoZZZ,
если тема тебя все еще интересует, можешь посмотреть “Квестер” - там как раз все выполняется на сервере, а игроку выдается HTML страничка(без использования Flash).

Nex:

Без поддержки как минимум яваскрипта ее сделать нереально, движок QSP слишком богат возможностями.

Веб-версия, которая выполняется на сервере, уже была когда-то мной реализована на PHP(называлась wiQSP). Я эту разработку похоронил по следующим причинам:

1. Самое главное - низкое время отклика. Даже с небольшими яваскриптовыми трюками, которые позволяли держать открытым соединение с сервером, часто были заметны “провисания” между действием игрока и реакцией игры - зависимость от канала связи, это сильно раздражало игроков.

2. Невозможность реализовать некоторые фишки языка QSP - там, где требуется прервать выполнение кода на взаимодействие с пользователем, а также адекватное выполнение локации счетчика.

3. Невозможность простого апгрейда - т.к. библиотека QSP была перенесена на PHP “вручную”, то любое изменение в библиотека(выпуск новой версии QSP) потребовало бы вручную повторять то же самое в wiQSP.

Ну я бы не стал утверждать что это все нереально или сверхтрудно. Не берусь за создание этого софта, но хочу сделать замечание. Можно сделать без поддержки яваскрипта, если написать бэк-енд (небольшой по коду относительно движка) использующий обычный C-шный код QSP который реализовал бы web интерфейс, в то время как интерпретатор QSP выполняется на сервере. В таком случае прищлось бы написать минимальное кол-во нового кода и поддержка минимальна + простейший апгрейд (нужно только пересобрать и, возможно, внести небольшие изменения). И не надо ни PHP ни других скриптовых языков (но нужен выделенный сервак).

С низким временем отклика тоже готов поспорить, т.к. размер загружаемых данных при переходе на локацию исчисляется килобайтами (если много текста), а то и меньше 1 кб, даже если использовать навороченные CSS стили они кешируются браузером и тоже в счет не идут. Я сам в данный момент сижу на даче с GPRS (не EDGE и не 3G) и могу сказать что этого вполне достаточно, учитывая что юзер переходит на локацию несколько раз в минуту.

Единственное, что возможности действительно урезаются - но эти возможности меньше всего востребованы: локация-счетчик и wait(). То есть при желании такая веб-версия плеера вполне реализуема без лишнего гемороя. Но по-моему, лучше заниматься портированием под мобильные платформы.

С низким временем отклика тоже готов поспорить, т.к. размер загружаемых данных…

Размер загружаемых данных тут ни при чем. Слабое место оказалось именно время отклика, т.е. время установления соединения с сервером. Это, увы, зависит по большей части от пользовательского соединения. Можно сделать идеальный, супербыстрый сервер, но если при выборе действия придется тратить время на установление соединения, то скорость отклика будет зависеть от пинга сервера. Если задержка составляет >200мс, то игроку уже будет неприятно играть. Я небольшим трюком сделал возможность быстрого отклика на первое “пользовательское действие”, но если достаточно активно играть, “провисания” все равно станут заметными.

Единственное, что возможности действительно урезаются - но эти возможности меньше всего востребованы: локация-счетчик и wait…

Это не единственные “фишки” плеера, которые не смогут быть реализованы, есть еще например INPUT, MSG, MENU. Ну а локация-счетчик, увы, используется в каждой второй игре.

Ну я бы не стал утверждать что это все нереально или сверхтрудно. Не берусь за создание этого софта, но хочу сделать замечание. Можно сделать без поддержки яваскрипта…

Я не стану тебя переубеждать. Можешь попробовать взяться, и когда разберешься получше, поймешь, что я был прав. Я все проверил на практике, ты рассуждаешь в теории. Бери, пробуй, в любом случае для тебя это будет ценный опыт.

А я как-то думал о том, чтобы прикрутить двиг модулем к апачу..
А по поводу соединения - вполне возможно, что сгодятся вэбсокеты.
Ну и “умная подгрузка” доспупных на следующем шаге локаций.

rrock.ru,
я не стану с тобой спорить, пробуй и поймешь.