1 (edited by SSN 2010-06-28 11:26:54)

Topic: Web-интерфейс.

Здравствуйте.

Рассматривался ли вопрос о создании веб-интерфейса для instead наравне с консольным и графическим sdl-интерфейсом?

Re: Web-интерфейс.

Вопрос всегда есть, в принципе -- stead.lua писалься с расчетом на то, чтобы быть сервером. Например в кота можно вообще без интерпретатора играть. wink

Но... Не приоритетно сейчас (у меня нет на это времени). Нужны игры, версия 1.2.0, документация...

Если кто-то будет заниматься, хорошо -- но мне кажется кроме меня -- просто некому.
А так -- анализ gui.lua + stead.lua + запуск кота без интерпретатора и можно писать smile Но игра видимо будет cgi на lua.

Re: Web-интерфейс.

А не подскажете ли ДЛЯ ЧЕГО нужен веб-интерфейс? Цель какая?

Re: Web-интерфейс.

Наверное, чтобы крутить квесты через браузер. BBIF, типа того.

Re: Web-интерфейс.

Кстати, цель интересная. Думаю, тогда бы реально бы расширилась аудитория. Челам не надо ничего скачивать - зашёл браузером и поиграл. "Туалет" можно будет лучше пиарить. smile А то "Crimson Room" все знают, а "Туалет" - только горстка русских маргиналов. smile

Но конечно вопрос - кто этот интерфейс будет делать.

Re: Web-интерфейс.

В web-версии мы можем потерять трекерную музыку, а без неё как-то не айс..

Re: Web-интерфейс.

Peter wrote:

А так -- анализ gui.lua + stead.lua + запуск кота без интерпретатора и можно писать smile Но игра видимо будет cgi на lua.

Спасибо. Буду смотреть кота. Может что и получится.

Re: Web-интерфейс.

Odyssey wrote:

В web-версии мы можем потерять трекерную музыку, а без неё как-то не айс..

Мож какие java-проигрыватели есть? Будет онлайн играть. smile

SSN, всё в твоих руках! Если сделаешь - внесёшь реальный ВКЛАД в общее дело Инстеда!  cool

Re: Web-интерфейс.

я всё равно не понимаю зачем нужен web-интерфейс.
сам инстед да и игры к нему весят не так много.
не так уж и напряжно стянуть с инета и поиграть. а с ланчером вообще дело двух нажатий на кнопку.
реально не понимаю преимущестув веб-морды.

Re: Web-интерфейс.

vvb, ты рассуждаешь слишком здраво. smile Но как ни странно, я уверен, что если будет вэб - публики будет в разы больше. Большинство людей не захочет заморачиваться с установкой ланчера ради какой-то сомнительной игры. smile А здесь - клик - и результат. Например, люди на корпоративных работах (где поставить что-то своё вообще часто невозможно) смогут кликать в браузере. И т.д.

Хотя я понимаю, почему этой идее Петя противится. smile Реализовать вэб также качественно, как щас сделан движок - будет проблематичным. Есть большая вероятность, что вэб будет более ущербным, чем движок. И может сложиться тухлая ситуация, что ущербный вэб-движок будет более популярен, чем правильный и работоспособный standalone.
Так что в этом плане вэб может и повредить. Нахлынет много гопников, использующих некачественный вэб.
А сейчас instead является как бы фильтром - если ты установил instead - значит ты уже несовсем гопник. smile
То есть инстед щас - слегка для избранных. Избранных маргиналов. smile))

Чо-то я разогнался здесь. smile

Re: Web-интерфейс.

Хотя я понимаю, почему этой идее Петя противится.

Я не противлюсь. Есть личные предпочтения -- это да. smile Мне нравятся настоящие программы, я не могу играть в длинные игры по web (также как читать в броузере книги) НО -- если бы была веб версия -- думаю, мы бы нашли как ее применить. smile Пусть даже она будет хуже standalone проги. Просто я этим сейчас не готов заниматься. Помогать смогу -- но не больше.

12

Re: Web-интерфейс.

Есть желание заняться веб-интерфейсом. Пока разбираюсь в исходниках. Возникающие по ходу вопросы буду задавать, если не возражаете, в этой ветке форума.

Посмотрел исходные коды консольного клиента (src/instead/*.c).
Последовательность примерно следующая:

dofile("stead.lua")
dofile("../instead/tutorial/main.lua") -- собственно игра

Затем в цикле:

me():tag();
return here():str();
return me():str();
return here().way:str();
-- далее считывание и выполнение команды пользователя

Для того, чтобы подключить другой интерфейс вывода, надо начало заменить на:

dofile("stead.lua")
dofile("gui.lua")
dofile("../instead/tutorial/main.lua") -- собственно игра

При этом iface, определённый в stead.lua, заменяется iface из gui.lua.

Насколько я понимаю задача в написании альтернативы gui.lua, которая будет отдавать html, генерируемый по шаблону, и обёртки, подобной src/instead, которая будет реализовывать CGI.

Поправьте меня, если я ошибаюсь.

Re: Web-интерфейс.

В целом, верно. Я не очень сейчас помню как консольный клиент работает (давно не обновлялся он), но самый простой консольный клиент это:

http://instead.pinebrush.com/wiki/ru/do … 0%BA%D0%B0

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

Все проходит в конце-концов через iface.cmd.  Задача gui.lua сформировать разметку так, чтоб по кликам на ссылки генерировались команды, но кое-где этого недостаточно.

1) это режим юзания -- инвентарь на сцену и пр. Такие команды формирует sdl-instead
2) "Хак" меню -- stead.lua в некоторых случаях возвращает статус. который воспринимается sdl-instead как указание к тому, чтобы не генерировать вывод сцены, а только инвентарь.
Хак со стороны stead.lua выглядит так:

if stead.state and r == nil and v == true then -- we do nothing
    return nil; --- видимо тут надо будет переделать для cgi
end

3) ??? что то еще?

Предлагаю сейчас забить на 2 (все равно придется переделать видимо) и сосредоточится на простой игре -- туториал или кот.

Возможно 2 режима -- каждый клик -- перезапуск cgi с восстановлением из save и записью в save -- так работал первый tcl интерпретатор (жесть)

Или сделать так чтобы cgi висел весть сеанс -- вроде есть такая возможность в веб сервере?

У меня уже появилась надежда что что-то получится. smile Если надо будет что то переписать -- перепишем.

Re: Web-интерфейс.

Переделывать консольный INSTEAD под CGI интерфейс не советую.
Потому что будут тормоза.
Сколько раз за игру совершается кликов? А какие между ними интервалы?
А теперь представьте, что каждый клик - это обращение к серверу, вызов интерпретатора STEAD (ну или хотя бы lua). Даже если использовать FastCGI и AJAX, задержка будет заметна. На стороне клиента lua не запустишь.
Можно сделать порт инстеда на Javascript\Flash\Silverlight\Native Client\Java. Но это очень сложно.
Надеюсь, что меня переубедят.

Александр Яковлев, к вашим услугам.

Re: Web-интерфейс.

Имхо единственная возможность -- cgi. Насчет тормозов -- возможно, что так и есть. У меня мало опыта в этих делах.  Но с другой стороны -- объемы данных на реакцию -- очень небольшие. Клики - обычно не чаще одного в несколько секунд. Нехорошо -- но другого варианта я вообще не вижу. sad

Re: Web-интерфейс.

Задержка = отправка запроса+вычисление запроса+получение результата. По времени это в лучшем случае как 2 x пинг до сервера. Если сервер не рухнет (а без FastCGI DDoS вероятен), то тогда задержка будет 1-10 секунд по России.

Александр Яковлев, к вашим услугам.

Re: Web-интерфейс.

Гм... Вроде есть lua для flash какая-то... И для java. Возможно, не одна... Не знаю, что правильней.  Flash и Java я не очень люблю -- поэтому мое мнение лучше не учитывать. smile

http://code.google.com/p/lua-alchemy/

18

Re: Web-интерфейс.

Oreolek wrote:

Переделывать консольный INSTEAD под CGI интерфейс не советую.
Потому что будут тормоза.
Сколько раз за игру совершается кликов? А какие между ними интервалы?
А теперь представьте, что каждый клик - это обращение к серверу, вызов интерпретатора STEAD (ну или хотя бы lua). Даже если использовать FastCGI и AJAX, задержка будет заметна. На стороне клиента lua не запустишь.
Можно сделать порт инстеда на Javascript\Flash\Silverlight\Native Client\Java. Но это очень сложно.
Надеюсь, что меня переубедят.

Первая мысль была как раз о CGI. С восстановлением игры из сохранения на каждом вызове sad

Вообще, до того, как я полез в исходные коды движка игры, у меня уже было своё представление о том, как он примерно должен выглядеть. И оно существенно отличалось от того, что есть на самом деле. ^_^

Мне думалось, что движок должен представлять собой консольную программу, принимающую команды управления на stdin и отдающую состояние после выполнения команды на stdout. Формат входных и выходных данных - какой-нибудь стандартизированый (JSON или XML, например).

Фронтэнд, запускает данную программу, взаимодействует с ней. Состояние, возвращаемое движком обрабатывается фронтэндом через DOM интерфейс. Сам фронтэнд совершенно не зависим от движка и может быть написан на чём угодно.

В этом случае реализация консольного клиента тривиальна вплоть до bash+xslt.
А веб-интерфейс возможно реализовать в виде Java Web Start приложения, которое соединяется с сервером на нужном порту. А на сервере с помошью inetd на этот порт вешается в качестве сервиса тот самый движок.

В качестве примера подобного подхода можете посмотреть как всё было реализовано в Google AI Challenge.

В instead всё ограничилось программным интерфейсом. И, хотя данный подход может быть реализован и в текущий момент как ещё одна обёртка, вроде той, которая находится в src/instead, но на это врядли стоит расчитывать при уже готовом и работающем instead-sdl фронтэнде.

Re: Web-интерфейс.

SSN wrote:

Первая мысль была как раз о CGI. С восстановлением игры из сохранения на каждом вызове sad

Вообще, до того, как я полез в исходные коды движка игры, у меня уже было своё представление о том, как он примерно должен выглядеть. И оно существенно отличалось от того, что есть на самом деле. ^_^

Мне думалось, что движок должен представлять собой консольную программу, принимающую команды управления на stdin и отдающую состояние после выполнения команды на stdout.

В instead всё ограничилось программным интерфейсом. И, хотя данный подход может быть реализован и в текущий момент как ещё одна обёртка, вроде той, которая находится в src/instead, но на это врядли стоит расчитывать при уже готовом и работающем instead-sdl фронтэнде.

Ну я выше уже неоднократно писал, что instead и есть shell. smile  Что он изначально написан как CGI. smile Те вещи, которые в консольной версии с readline -- нужны только для авто дополнения.  sdl-instead привязан сильнее -- но это не обязательные вещи. Минимальный шелл ниже (я на него давал ссылку), я также не раз писал о tcl фронтенде который и работал в режиме запуска lua и передачи команд через stdin. Набор команд примитивен: use, ls, go, act, look, back ...
На всякий случай еще раз, на этот раз цитируя:

Вы можете отлаживать свою игру вообще без instead. Например, вы можете создать следующий файл game.lua:

dofile("/usr/share/instead/stead/stead.lua"); -- путь к stead.lua
dofile("main.lua"); -- ваша игра
game:ini();
iface:shell();

Просто надо запустить этот код на Lua. smile sdl-instead делает примерно тоже-самое, но через C api, это удобнее в случае C программы. С музыкой и меню -- есть проблемы  -- но ими просто можно было бы пренебречь сейчас. Какой именно протокол -- не так важно, главное что ядро API всегда только ОТВЕЧАЕТ. Формат API меняется несложно на самом lua.

20 (edited by SSN 2010-07-01 00:02:38)

Re: Web-интерфейс.

Peter wrote:

Ну я выше уже неоднократно писал, что instead и есть shell. smile  Что он изначально написан как CGI. smile

Прошу прощения, но я вас понял ещё в тот раз. Просто сейчас колеблюсь между CGI (который, несомненно, проще в реализации) и описаной мной выше связкой JavaWS+inetd.

А в приведенной мной схеме взаимодействия движка с фронтэндом 2 существенных отличия от того, что есть сейчас:

  • Абсолютная независимость фронтэнда от движка.

  • Стандартизированный интерфейс вплоть до верификации по схеме.

Менять же сам stead API, я уже написал выше, вобщем-то и не придётся. Если понадобится, будет просто ещё одна обёртка вроде src/instead. Просто уже есть instead-sdl, который будет продолжать работать по старому, с возможным использованием каких-то специфичных хаков.

Re: Web-интерфейс.

Избавление от хаков если что я беру на себя. wink

Насчет абсолютной независимости -- я не сильно разбираюсь в теме -- но я думал, что если не брать музыку и меню -- она и сейчас абсолютная smile То есть кот проходим в том шелле который выше на lua написан...

Насчет 2-го пункта ничего не могу сказать -- так как мне вроде xml не нужен, но если нужны будут какие-то доработки в stead.lua или очищении sdl-instaed от грязных хаков -- я конечно по возможности помогу.

Re: Web-интерфейс.

* По поводу инструментов:
теоретически есть Kepler, т.е. web-фреймворк для Lua, и если с ним разобраться, всю серверную часть при желании можно было бы написать на Lua.

* По поводу API с точки зрения sdl-фронтенда:
если я правильно понял, он состоит из двух основных частей -- instead_cmd и instead_eval. Через первую работает обработка кликов и получение основного текста. Через вторую подгружаются дополнительные данные (названия сцен, имена картинок/музыки и т.п.), выполняются доп. команды (инициализация, управление музыкой, и т.п.).
Имхо, большим шагом вперёд к новым фронтендам (и избавлению от хаков) была бы централизация всех вызываемых из интерпретатора функций stead в одной таблице. Тогда можно было бы:
1) не трогая интерпретатора, посниффить все вызовы и даннные, проходящие через API
2) использовать эту таблицу в новых фронтендах, в т.ч. в web-фронтенде
3) написать на Lua proxy API, которое позволило бы играть в instead-игры по сети через sdl-фронтенд. Т.е. sdl-instead'у вместо stead можно было бы подсунуть прокси, который редиректил бы все запросы на сервер. Это уже не относится к web-фронтенду, просто ещё один вариант развития, который также упрощается после централизации Lua-API в одной таблице.

Всё связанное с instead_cmd уже вынесено в таблицу iface, осталось только то, что вызывается через instead_eval.

Re: Web-интерфейс.

Да, примерно так и есть. Но что именно нужно делать точно станет ясно только после начала работы над web вариантом. Возможно некоторые вещи вообще не понадобятся, а технически избавться от заточек вопрос дней. Пока заточками можно просто пренебречь. Возможно не подходит сам текстовый протокол обмена -- так как, например, а отличие от xml не позволяет понять когда поток закончился.

По поводу 3) -- по-моему бессмысленно, если только мы не собираемся зарабатывать деньги на играх. 8) Весь смысл веба вроде в том, чтобы человек не ставил реальную прогу.

24

Re: Web-интерфейс.

Peter wrote:

...если только мы не собираемся зарабатывать деньги на играх.

по-моему только ради этого и была задумана данная тема... ни для чего другого смысла нет делать веб-морду... хорошо если я не прав...

25

Re: Web-интерфейс.

vvb wrote:
Peter wrote:

...если только мы не собираемся зарабатывать деньги на играх.

по-моему только ради этого и была задумана данная тема... ни для чего другого смысла нет делать веб-морду... хорошо если я не прав...

Такие мысли мне в голову не приходили. smile

Просто не всегда есть возможность установить программу локально. Тут выше уже приводились типичные случаи.