www.mudconnector.su

Всем привет!
Я занимаюсь разработкой муд-движка, главной особенностью которого является протокол передачи данных - http, вместо привычного telnet. То есть игра будет происходить через браузер в виде javascript "клиента", контактирующего с php-сервером методом "запрос-ответ". В отличие от telnet, где соединение устанавливается в обе стороны, этот браузерный муд способен только отвечать на запрос. Тем не менее, клиент все же может периодически запрашивать у сервера "последние события" относительно своего персонажа.

Выглядеть это будет примерно так: http://quank.org/mud/

Движок я назвал Utopia, он будет открытым и свободно распространяемым. Так же его можно будет запустить на обычном хостинге.
Репозиторий проекта: https://github.com/Rottenwood/UtopiaMud

Я хотел бы услышать ваше мнение. Спасибо!

1. Вероятно, довольно сильно просядет динамичность.
Насколько часто вы обновляетесь-то ?
2. Нагрузку на сервер не смотрели ?

В принципе, право на жизнь имеет, но яб лучше "зашил" телнет или какой-нибудь джаббер внутри http.
Боюсь не удастся качественного клиента в одно лицо написать.

ЗЫ. Я неверно думаю, что основной схемой в такого рода взаимодействиях является "постоянная подписка",
т.е. пришла пачка данных, ты тут-же подписался на следующую. Там-же по-моему даже в jquery всё для
этого есть, разве нет ?

PS. Как я понял на php ? Уверены, что будет номально работать ?
Какие-то стресс-тесты проводили ? По мне, так не лучший выбор.
Не очень понятно как вы будете поведение мира рассчитывать...

Наличие комментариев - это конечно хорошо, посмотрим что будет дальше.

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



При хорошо составленных запросах к базе данных, их кэшировании - нагрузку вполне выдержит даже средний шаред-хостинговый план (не VDS и не выделенный сервер). Здесь еще важно количество игроков.



Клиент в данном случае это просто сайт с ява-скриптом, который отсылает команды пользователя на сервер и обрабатывает пакеты приходящие от него. Минимальный клиент уже написан, начата реализация хоткеев, дальше останутся триггеры - что еще нужно? Я планирую еще выводить графическую/псевдографическую карту. Учитывая открытость платформы, клиент для игры (сайт) может допилить/изменить/улучшить любой желающий и знающий javascript.



Постоянной подписки нет, все базируется на модели "запрос-ответ", то есть чтобы получить что-то от сервера нужно ему послать какую-то команду. Это действительно решается с помощью регулярной отсылки своеобразного пинга (в jquery хорошо реализовано, его и использую).

Подписка на события реализована в технологии Node.js - но это уже другой формат, я хочу отталкиваться именно от php. В идеале я думаю что знаю как сделать так чтобы игрок не заметил разницы и видел мир динамично.



Да, использую php как серверную составляющую. Не чистый пхп, а фреймворк Symfony.
На счет стресс-тестов пока говорить не приходится, так как я только начал, и тестировать в общем-то пока нечего. Но да, большинство методов в классах будут покрыты модульными тестами, что обеспечит общую отказоустойчивость.

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

Спасибо за мысли, KadVar!

Хорошее начало, вариант сервер на php имеет право на изучение,
однако я тоже, как и KadVar, сомневаюсь пока в варианте на базе запрос - обновление.

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

Тут будет сильно зависеть и от качества кода скриптов и т д., так как их обработка будет идти
скорее всего в том же потоке что и обработка запросов от клиентов. Любой косяк в скрипте
будет тормозить весь сервер. Возможно я что-то не понимаю, я php знаю на уровне слабой троечки,
но я пока даже не представляю как Вы будете реализовывать боевку, причем параллельно
нужно работать и с обычными клиентами, обсчетом мира и прочим.

Система запрос-ответ как в Вебе очень плохо подходит под реалтайм игры, каким является мад.
Если есть представление того как это будет работать на системном уровне, я бы послушал/почитал.
Не думали на счет Вебсокетов ?

PS.
Я дописываю клиент, он достаточно близок к финишу (к первой публичной бете), после чего собирался
писать сервер. Из всех технологий я пока смотрю на Lua/LuaJIT и Node.JS.
Ноду я пока изучаю (я знаю JS примерно на 3+, сейчас изучаю более подробно), но пока прихожу к выводу что она не сильно подходит, так как является
аналогом php по механизму работы запрос-ответ (нода же на веб заточена) и работает в однопоточном
режиме на базе коротинов. Что никак не подходит к реалтайму имхо.
c Lua/LuaJIT все лучше, но я хочу провести еще небольшое тестирование (подходит/нет).
Сейчас я пока собираю информацию о том, на чем лучше писать движок.

Готов пообсуждать / чем то помочь / подключиться к проекту в каком то виде. Так как я рассматриваю вариант веб-клиента и онлайного веб-редактора зон и мира.

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

Редко очень. Какова длительность раундов ?


Откуда на среднем хостинге кеширование - там его нету. Кеш один на всех.
Или вы кешируете локально результаты ? По мне, так тоже не сильно поможет.
Конечно 1-2 игроков "потянет любой хостинг", но потянет ли он хотя-бы 100 игроков,
10.000 помещений, 10.000 что-то делающих мобов итп.
Не очень понятно как вы "длящиеся" скрипты будете запускатью


Нужно чтобы всё это было удобно. Достичь боюсь будет не так уж просто.


Т.е. мобы никакой активностью априори не обладают ?
Мир обсчитывается очень редко ?
Ведь 10с интервалы в крон пихать не станешь.

Я тут подумал... еще не очень ясно как вы синхронизацию будете осуществлять.
Хотя можно на уровне базы-кеша это делать конечно.
Производительность такого решения меня всё-таки беспокоит, но тут вопрос скорее
"какого объема проект планируется". Возможно в текущих реалиях это пустые страхи..

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

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

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

Для проверки динамичности модели нужно создать прототип боя (для начала с монстром). Бой должен выглядеть как бой в муде, с возможностью игрока каждый батлраунд применить скилл. Возможно баттл-раунды нужно будет сделать дольше чем в обычном муде, например на пару секунд.

Думаю когда будет готов функционал этих двух игровых моментов - сможем определить дальнейший вектор работы по улучшению.

Качество кода всегда имеет значение. С помощью объектного подхода, разделение слабо связанного кода вполне можно предотвратить определенный комплекс проблем. К тому же в таком подходе какой-то кусок приложения можно отключить на "ремонт", при этом даже не останавливая сервер.

На счет потоков и вебсокетов. В симфони, на которой я пишу проект есть хороший функционал разделения процессов, таким образом тяжелые процессы вполне можно пускать отдельным тредом. Вебсокеты мне нравятся, и это бы полностью решило проблему, но здесь есть некоторые особенности. Во первых это требует работы демона на серверной стороне, что скорее всего уже не подойдет для обычного хостинга. Во вторых, с вебсокетами я имел дело в формате Node.js, однако я не хочу использовать ее в серверной части. Тем не менее, пока обдумывал этот вопрос вспомнил так же и про PhpDeamon, который кроме вебсокетов к слову даже телнет протокол может слушать. Так же интересный вариант нашел - Ratchet (http://socketo.me). Буду смотреть в их направлении, особенно если "запрос-ответ" покажет несостоятельность.

На системном уровне сейчас это работает примерно так:
1. обработка запроса клиента
2. проверка условий по алгоритмам и по базе (например, закончилось ли произнесение длинного заклинания)
3. запись новых отметок в базу (например о времени начала длинного каста)
4. в зависимости от условий вывод результата сообщением клиенту

Node.js имеет свои плюсы, и я считаю она хорошо справится с функционалом муда. Я бы ее не назвал аналогом пхп, ведь клиент не посылает запрос и не ждет ответа - он подключается к сокету, устанавливая постоянное соединение в обе стороны. По сути аналог телнета, и для целей муда самое то. Запрос посылается лишь однажды - запрос на постоянное подключение к каналу, по которому уже передается вся информация без запросов и заголовков. Есть кстати реализация муда на ноде - на гитхабе видел.

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

Вот мои наброски по поводу формата: https://github.com/Rottenwood/UtopiaMud ... /rooms.yml

С рогаликами идею одобраю, тоже считаю карту необходимым элементом игры. Я это когда-то частично попытался реализовать вот тут: quank.org

Накладные расходы на каждое соединение могут быть слишком велики.


Да, конечно, именно об этом я и говорил (стресс-тесты), запустить сотню игроков, скопировать 10.000 мобов и посмотреть.


Это почти вдвое больше имеющихся.
Имеет смысл подумать над очередью команд. И автоповторением команд тоже.


А что с синхронизацией ?


Т.е. вы пишете в базу даже такие вещи, как "начал каст"-"закончил каст" ?
Может быть мемкешед итп использовать для хранения динамики (есть готовые движки
позволяющие хранить как минимум пары ключ-значение, дальше не рыл).
Иначе производительности точно не хватит.
По крайней мере предусмотреть layer в софте, чтобы можно было легко от базы отцепить динамику.


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

ЗЫ. И да... когда люди пишут в кучу разные параметры, называя это "флагами" как правило это
признак плохого дизайна. Лучше сразу сделать прямо.

Надеюсь что нет!

Кэширование я имею ввиду на стороне пхп: кэшируется одинаковый код, и одинаковые запросы к статичным частям базы данных. Длящихся скриптов как таковых не будет. Если игровое событие имеет длительный характер - оно привязывается ко времени его начала, оно пишется в БД, и дальше при каждом запросе пользователя производится проверка с обсчетом того, где "ситуация" игрового события находится в данный момент времени.

Про нагрузку согласен, тестирование будет целесообразно делать на уже имеющемся функционале (пусть даже тестовом). Очередь команд и их повторение - это то, что определенно будет реализовано. По батлраундам - думаю секунд 5 на один.

По поводу клиента - удобство субъективное понятие, не так ли? Мне удобно играть через консольный mmc, кто-то любит окошечки змуда. В качестве варианта могу предложить идею кастомизируемого клиента, где игрок сможет выбирать нужны ли ему те или иные функции. Но это пока лишь мысли.

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

Синхронизация происходит через свойства объектов или через запрос к базе данных. Разумеется не прямыми SQL-запросами а с помощью абстрактного слоя. Я использую Doctrine ORM.

Расходы по модели соединения "запрос-ответ" конечно больше (за счет заголовков и кукисов) чем при прямом соединении. Благодаря нашему общению я всерьез задумался о том, чтобы использовать веб-сокеты вместо аякс-запросов. Минус подхода, как я уже говорил - невозможность запуска системы на обычном хостинге.



Думаю что yaml формат вполне подходит под описанное Вами. Его легко читать человеку, можно перевести в данные для любого языка программирования (например чтобы создавать редакторы или отрисовывать зону в игре). Перенос строк по моему неплохо вписывается в удобство для восприятия человеком, пишущим в текстовом редакторе.
Не могли бы Вы объяснить подробнее. Про флаги мне не очень понятно.

Тут я полностью согласен с KadVar-ом. Накладные расходы на установку соединения будут очень большие. Подключение по необходимости скорее недостаток чем приемущество. Постоянный коннект не требует чтобы данные обязательно передавались. Они могут передаваться и по необходимости.

Для стресс теста можно создать лабиринт - 100 на 100 (10000 клеток) и соединить их коридорами на все стороны света, пустить туда сотню мобов и пусть ходят. Посмотреть на результат. Добавить бой с одним мобом и пару скилов с разными таймаутами.

По поводу хостинга. Думаю стоит забыть про классический хостинг MySQL + Apache + PHP5. Нагрузка будет слишком заметная и провайдер не даст столько CPU, так как там же будут и сайты других людей. Нужно смотреть в сторону VDS/VPS, где можно сделать так как нужно (поднять ноду или чтото-еще для вебсокетов к примеру).

На счет JSON-пакетов. Тут уже стоит вопрос протокола мада, а протокол должен основываться на геймплее и по сути на интерфейсе пользователя в клиенте. Думаю стоит идти по пути другим мадов и делать оконный интерфейс например как в TheBat. Тут нужно уже делить задачи на под задачи.


Я думаю синхронизация будет за счет MySQL, хотя может я что-то не понял.



Редактор если честно и я вижу его в виде текстового редактора. Визуализировать нужно только лабиринт (взаимное положение комнат),
можно чтото еще.
Только JSON как формат зон тут не подойдет из-за гемороя как раз с кавычками и скобками.
Возможно имеет смысл взять xml, он более удобен, чтобы не забыть какую нибудь скобка, но тут нужно подумать и пообсуждать.
А возможно нужен вариант json но без кавычек, например как предложил Rottenwood.

Чуть позже напишу больше.
PS. Rottenwood можем пообщаться и лично при необходимости. Я тоже и Питера.