UoKit.com Форумы [Русская версия Invision Power Board]

Автор: Stark 16.9.2011, 17:11

Пока что интеграция только в таком виде: игроки на сервере отправляют сообщение в чат, и оно практически мгновенно отображается и в игре и на сайте.
При желании не сложно сделать отправку сообщения из веба в игру, но это задача специфическая, для каждого сервера и ее нужно решать по-разному, при желании я расскажу как это сделать.

Работает все с помощью сервиса - http://partcl.com
Принцип можно разделить на 2 этапа:

Публикация сообщения
При добавлении нового сообщения в чат, рануо дергает спец урл, которую вы получаете зарегистрировавшись на партикле, примерно такого вида:

Код

http://partcl.com/publish?publish_key=publish_key&id=chat_message&value=msg

где:
publish_key - секретный ключ, с помощью которого можно публиковать сообщения.
chat_message - имя переменной, используемой для сообщений чата.
msg - текст сообщения.

Отображение на сайте
На ваш сайт вставляется javascript-код партикла, который при появлении нового сообщения, отображает его там, где вы захотите. Для этого просто вставьте в нужное место такой хтмл код:

Код

<partcl cell_id="chat_message" method="append"></partcl>

Установка:
1) Регистрируемся тут - http://partcl.com, после чего на http://partcl.com/user копируем свой publish_key.

Настройка RunUO:
2) Закидываем файлы Chat.cs и WebRequestState.cs в любую папку, внутри Scripts (например в Scripts/Custom/)
3) Открываем Chat.cs и в 12 строку вставляем ваш publish_key

Настройка сайта:
4) Со http://partcl.com/user копируем ваш web_key.
5) Открываем шаблон вашего сайта, перед закрывающим тегом </head> подключаем скрипт партикла

Код

<script id="partcl_client_script" web_key="web_key" src="http://partcl.com/partcl.full.js"></script>

вместо web_key вставляем свое значение.
6) В любое место, где хотите отображать чат, вставляем этот тег:

Код

<partcl cell_id="chat_message" method="append"></partcl>

Отправляются сообщения, с помощью команды [c (Изменить можно в файле Chat.cs)

Все готово, можете пользоваться

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

Вобщем придумать можно еще много разного, было-бы желание.

Сейчас сервис в стадии тестирования, но работает достаточно стабильно. Бесплатный тарифный план, думаю подойдет большинству типичных серверов (если в день вы будете отправлять меньше 100 000 сообщений), если народу у вас много, то премиум акаунт стоит 9.99 уе в месяц, для хорошего сервера не так много

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

[attachmentid=1041]

Прикрепленные файлы

partcl_chat.zip ( 1,91 килобайт ) Кол-во скачиваний: 571

Автор: Soteric 16.9.2011, 19:25

Спасибо за сервис. Может быть имеет смысл вынести работу с ним в отдельный поток и обернуть в try-catch? Насколько я понимаю, сейчас при проблемах с соединением или в случае недоступности сервиса, RunUO в лучшем случае повиснет, в худшем упадет.

Автор: Stark 16.9.2011, 19:30

Сделаю обязательно, спасибо за совет
Буду благодарен, за любые советы/дополнения по коду.

Только что сделал отправку данных о полученном уроне и кол-ве оставшихся хп игрока, во время боя и такие данные тоже можно отображать. Можно даже отобразить в виде прогрессбара, заполняющегося/убывающего, при измененении хп
На выходных обновлю пост, с исправлениями и дополнениями.

Автор: Juzzver 16.9.2011, 20:27

Может можно вовсе обустроить мониторинг действий игроков через сайт?
Выходить в роли "Spectator", и наблюдать за игрой через веб )
Хотелось бы увидеть реализованную идею, или несколько скриншотов, если возможно.

Автор: Warstone 16.9.2011, 21:02

Цитата(Juzzver @ 16.9.2011, 21:27)

Может можно вовсе обустроить мониторинг действий игроков через сайт?

Выходить в роли "Spectator", и наблюдать за игрой через веб )
Хотелось бы увидеть реализованную идею, или несколько скриншотов, если возможно.

С появлением Unity это стало возможно... Надо только осваивать и делать. Основная концепция:
Демон на сайте коннектится к серверу и начинает заниматься пересылкой всех пакетов с сервера на всех подключенных клиентов. Протокол - сильно обрезанный УОшный... Достаточно пересылать только те пакеты, которые за появление в мире нового отвечают.

По поводу чата... Гораздо... Правильней... Сделать интеграцию в IRC сеть.

Автор: StaticZ 17.9.2011, 1:19

В кои-то веки в данном разделе появилось хоть что-то серьезно и интересное

Автор: Stark 17.9.2011, 10:54

Цитата

Может можно вовсе обустроить мониторинг действий игроков через сайт?
Выходить в роли "Spectator", и наблюдать за игрой через веб )

Это сделать можно, без проблем

Начать можно с реалтайм отображения перемещения игроков, на карте мира. Каждые 5 сек. отправлять на партикл координаты игрока, а на сайте, джаваскрипт код, будет перемещать точки на карте, такой будет аналог "снимка из космоса" абисса, только обновляться будет в реалтайме

Цитата

Хотелось бы увидеть реализованную идею, или несколько скриншотов, если возможно.

У меня есть недоделанный свой серв, на котором все тестирую, поэтому показать пока нечего... Если есть желающие, стать подопытными, пишите в личку, помогу

Автор: Джелу 15.6.2012, 18:25

А почему бы лучше не реализовать связку RunUO + база данных для чата, например Mysql(или с xml), при отсылки в чат, сообщение сохранятеся в базу данных, ее же мы показываем на сайте, обновляя аяксом, тоже самое в обратную сторону, ранка считывает с базы данных и выводит свежие сообщения в игре. Во первых ненадо привязывать сторонний сервис, да и интереснее получиться реализация?

А понял, это рекламка своего проекта =) за идею +, молодец

Автор: Warstone 15.6.2012, 19:08

Лучше через файл с локом его.

Автор: Destruction 15.6.2012, 21:06

Цитата(Warstone @ 16.9.2011, 22:02)

С появлением Unity это стало возможно... Надо только осваивать и делать. Основная концепция:
Демон на сайте коннектится к серверу и начинает заниматься пересылкой всех пакетов с сервера на всех подключенных клиентов. Протокол - сильно обрезанный УОшный... Достаточно пересылать только те пакеты, которые за появление в мире нового отвечают.

По поводу чата... Гораздо... Правильней... Сделать интеграцию в IRC сеть.

Не лучше ли сайту конетится к рауно (или вовсе реплицировать эти данные в БД (не обязательно mysql, товарищи критики)) и собирать от него данные + RPC от рануо (или триггеров БД, или триггеров драйвера работы с БД: масса вариантов) на обновление данных ?

Автор: Warstone 15.6.2012, 22:08

Зависит от нагрузки. Вообще - тебе не надо весь чат, а только последние 100 строчек, допустим...
Я-бы для такой цели просто RabbitMQ использовал. Она для таких целей очень хорошо подходит. Но вопрос нагрузки... УОшная нагрузка - никакая, поэтому любое решение будет работать.

Автор: Destruction 16.6.2012, 17:42

Цитата(Warstone @ 15.6.2012, 23:08)

Зависит от нагрузки. Вообще - тебе не надо весь чат, а только последние 100 строчек, допустим...
Я-бы для такой цели просто RabbitMQ использовал. Она для таких целей очень хорошо подходит. Но вопрос нагрузки... УОшная нагрузка - никакая, поэтому любое решение будет работать.

RabbitMQ, в данном случае, - будет лишь частным случаем реализации RPC.. ;-)

Автор: Warstone 16.6.2012, 20:43

Только это не будет пиаром своего сервиса )) Так как на ErLang'е я писать не умею.

Автор: Destruction 17.6.2012, 0:01

Цитата(Destruction @ 16.6.2012, 18:42)

RabbitMQ, в данном случае, - будет лишь частным случаем реализации RPC.. ;-)

Да, а еще если сам сайт на пхп - то дергать PHP через RPC из RabbitMQ - будет не так уже просто, как хотелось бы (тут кстати можно устроить прямой коннект юзера к RabbitMQ на HTML5/Flash, но это уже из разряда глупостей :-D)..

Цитата(Warstone @ 16.6.2012, 21:43)

Только это не будет пиаром своего сервиса )) Так как на ErLang'е я писать не умею.

А неумение писать на эрланг тут каким боком?

Автор: Warstone 17.6.2012, 13:30

Цитата(Destruction @ 17.6.2012, 1:01)

Да, а еще если сам сайт на пхп - то дергать PHP через RPC из RabbitMQ - будет не так уже просто, как хотелось бы (тут кстати можно устроить прямой коннект юзера к RabbitMQ на HTML5/Flash, но это уже из разряда глупостей :-D)..

Есть плагин к RabbitMQ, который позволяет через JSON создавать очереди и подключать их к распределителям.

Цитата(Destruction @ 17.6.2012, 1:01)

А неумение писать на эрланг тут каким боком?

К тому что на нем RabbitMQ написан. Кстати - клевый язык... 90К потоков на одной машине держит легко... Но это функциональный язык. Тут есть проблемы... Допустим в том, что к переменной можно присвоить значение только один раз.

Автор: Destruction 18.6.2012, 0:44

Цитата(Warstone @ 17.6.2012, 14:30)

К тому что на нем RabbitMQ написан. Кстати - клевый язык... 90К потоков на одной машине держит легко... Но это функциональный язык. Тут есть проблемы... Допустим в том, что к переменной можно присвоить значение только один раз.

А разницы на чем написан продукт с которым ты просто работаешь ?..

Тебе ведь не обязательно знать как работает Windows (на уровне когда можешь написать свою ОС с нуля), чтобы под него программировать? ;-) Во всяком случае мне не обязательно - в студии сто кнопок тыкнул - программа готова.. ))

Кролик дает своё апи - вызывай его и не думай как оно работает. Разве нет?

К слову про апи, он реализует протокол AMQP, документацию читать пробовал - но там вода-водой (не ту документацию читал?) - как в byte-sequence (или через JSON-плагин, но это не энтерпрайз конечно, тут было бы круто SOAP, хотя конечно интереснее толковая дока по AMQP...) выглядит подписка на RPC ? - Как насчет подписки двух воркеров на один RPC-поток (например в режиме когда оба воркера обработают вызов (e.g. передать тыще юзеров один месседж), и когда только один из них (а кролик отработает балансировщиком нагрузки, т.е. горизонтальное масштабирование воркеров)).

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

Автор: Warstone 18.6.2012, 2:05

Цитата(Destruction @ 18.6.2012, 1:44)

А разницы на чем написан продукт с которым ты просто работаешь ?..

Я к тому, что RabbitMQ написал не я ))

Цитата(Destruction @ 18.6.2012, 1:44)

К слову про апи, он реализует протокол AMQP, документацию читать пробовал - но там вода-водой (не ту документацию читал?) - как в byte-sequence (или через JSON-плагин, но это не энтерпрайз конечно, тут было бы круто SOAP, хотя конечно интереснее толковая дока по AMQP...) выглядит подписка на RPC ? - Как насчет подписки двух воркеров на один RPC-поток (например в режиме когда оба воркера обработают вызов (e.g. передать тыще юзеров один месседж), и когда только один из них (а кролик отработает балансировщиком нагрузки, т.е. горизонтальное масштабирование воркеров)).

Про SOAP забудь, если мы говорим о скорости. А RabbitMQ нужен когда нужна скорость. JSON или Byte-sequence... XML уже долго (а SOAP - это XML с бешеными накрутками вокруг, вообще, когда на них смотришь - люди думали об Ентерпрайс, а не о скорости. То есть усложняли жизнь как могли). Кролик реализует не весь AMPQ, и AMPQ - это вообще Апачевская разработка. Тут надо читать доки по кролику, а еще лучше сразу забуриться в librabbitmq. Вообще, у него через брокеров, или как оно там, можно реализовать что угодно или несколько очередей на воркеры (сообщения будут доставлены всем) или несколько воркеров на очередь (тогда гарантируется что сообщение заберет только один воркер, но там в спец режиме. С этим постоянно были проблемы какие-то, но вроде там версию подняли).

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

Автор: Destruction 18.6.2012, 7:12

Цитата(Warstone @ 18.6.2012, 3:05)

Кролик реализует не весь AMPQ, и AMPQ - это вообще Апачевская разработка.

Вот этого совсем не знал. Кажется я догадываюсь где искать правильную доку по AMQP.

PS: AMPQ != AMQP. Мозг конечно эта аббревиатура надламывает ))

Автор: Warstone 18.6.2012, 8:25

Цитата(Destruction @ 18.6.2012, 8:12)