Intlib logo RuMUDServerDescription



Disclaimer: я представления не имею, как это все устроено и работает на самом деле. Было бы неплохо, если бы автор внес необходимые коррективы в мое описание. Начало каждого абзаца на самом деле предваряется словами "Как я понял,", просто они как тот суслик. Желающие могут также пофиксить стилистику, грамматику etc., если сочтут нужным. -- RamosianGlider


Архитектура проекта MUD

Программа представляет собой TCP-сервер, предоставляющий клиентам интерфейс к движку игрового мира. Сервер реализован с помощью библиотеки SUE, игровая информация хранится в БД PostgreSQL?. В качестве языка для программирования игровых объектов выбран лисп, встраиваемый в программу посредством библиотеки InteLib.

Движок игры состоит из менеджера объектов и очереди событий. Любое действие объекта может инициировать событие, помещаемое в очередь на обработку. Также любой объект может оставить запрос на извещение его о наступлении какого-либо события. Процедура обработки событий заключается в получении следующего события из очереди и передачи его всем объектам, затребовавшим это событие. Для каждого из объектов вызывается процедура CatchEvent?, отвечающая за реакцию на событие и изменяющая состояние объекта соответствуюэим образом.

В основном цикле программы происходит обработка событий, инициируемых клиентами (что может повлечь изменение состояния игрового мира, в том числе и создание игровых событий). В случае появления событий игрового уровня серверный цикл прерывается для обработки всех игровых событий, а потом запускается вновь (это хак, связанный с отсутствием в SUE возможности встраивать в серверный цикл сторонние обработчики - AndreyStolyarov собирается это исправить).

Для обработки событий каждый объект имеет две встроенные программы - Low (реализующая физическую модель) и High (отвечающая за поведение объекта), написанные на лиспе. // Работающего примера я не видел, поэтому трудно что-либо сказать о деталях. Похоже, эта часть еще не реализована.

Игровое событие представляет собой список точечных пар.


[Тут раньше был список файлов, составлявших так и не доведённую до рабочего состояния реализацию имени Сергея Коломина. Поскольку никаких шансов на её реанимацию всё равно нет, я этот список убрал, чтобы он не занимал место и не отвлекал внимание -- avst]


Comments and talks

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

А что ты называешь "закрывающими тэгами для текста без форматирования"? -- MeDendik

Что-то типа <pre></pre>. A то пробел в начале действует до конца строки. -- RamosianGlider

Да, такого в нём нет. Учитывая, что pre в html является блочным элементом, оно вообще и бессмысленно. (То есть я-то понимаю, что ты хочешь \verb'...', но такого на самом деле даже в обычном html нет, если я ничего не путаю). -- MeDendik

<tt></tt> некошерен?

Да, вроде как нету. Я вообще писал драфт страницы в виме, поэтому удобнее всего было бы рендерить ее так же, как это сделал бы vim. Но это слишком нагло с моей стороны (:Р), поэтому проще натравливать на вимовский текст локальный препроцессор, чтобы исправлять ошибки форматирования до отсылки на сервер -- RamosianGlider

http://dendik.bpa.nu:82/dendik/awki.vim ;-) -- MeDendik


ЫЫ.. очередь событий.. Шутка в чем: сервер в цикле обрабатывает что-то, что поступает от клиента (сообщения типа игровые команды, общение в чате). Но вот запросы типа сообщите, когда что-то произойдет, они не этого уровня.. Их, видимо, в очередь событий.. Сначала думала сделать очередь каким-н списком, элемент которого имеет поле (что-то на функцию??). Но эти функции должен писать игрок, а если писать должен он, то .. на ЛИСПе наверна. Потом, насчет часов. Как (с какой скоростью) обрабатывать события?? эт я пост в ЖЖ продублировала местами. -- GenShen

Ох, как ты всё сумбурно тут изложила... Давай уж попытаюсь поиграть в ассоциации на твои слова %)... (Первая ассоциация: нужно собираться и обсуждать это голосом и у доски или, на худой конец, у листочка бумаги, притом хотя бы пару только на эту тему; очень продуктивно)... Очевидно, запросы на событие являются двойственной сущностью по отношению к событиям и уж точно никак не укладываются в очередь (в очереди есть последовательность, а запрос не знает, когда он случится), традиционно такие запросы отображаются в виде hook'ов/callback'ов -- и, как я понимаю, твой вопрос состоит в том, как они решают, относится ли к ним событие. Традиционно на этот вопрос есть два ответа: либо существует какая-то классификация событий со стороны движка и тогда хук выбирает, какие классы событий ему интересны, либо хук получает информацию обо всех событиях, а реагирует только на те, которые ему интересны... Вспоминая твоё устройство (если оно тебе унаследовалось), за это дело должна, мне кажется, отвечать всё-таки "нижняя программа"... Касательно часов существует два подхода: либо часы -- это внешняя сущность, либо часы -- это такой плугин к игре, который "тикает" (то есть периодически генерирует событие "tick"). В первом случае временем управляется mainloop программы (это, вероятно, будет последний комплект полей в select); во втором случае mainloop отвечает за вытягивание и обработку событий (вопрос в том, как сделать незатратное ожидание в этом случае) и чаще всего, как раз очередной тик и будет выводить mainloop из спячки (хотя иногда будут случаться и другие события). Можно сесть с карандашом посмотреть, какие будут особенности поведения в том и в другом случае (в разных местах в зависимости от выбора придётся делать разные странности и в разных случаях будет притормаживание)... Касательно ЛИСПа..: а давай я тебе как-нибудь за полчаса расскажу язык io? :)) -- MeDendik

[Я вот только не понял, зачем тут io -- AndreyStolyarov]

Как пример прототипного языка -- ибо без прототипов в теме MUD ооооочень противно должно быть по-моему... Альтернативы io: self (Глайдер рассказывал, у меня сложилось очень смутное понятие о языке, не знаю, как у Гали) и MOO (ссылку я кинул, но сам язык не смотрел; есть опасение, что из-за горы заточек в MOO не видно главного -- повторюсь, не смотрел -- MeDendik


На всякий случай дублирую сюда то, что написал в Jabber'е:

[14:46]<dr_croco> Во-первых, ты забываешь, видимо, что программ у объекта должно быть две: "нижняя", задающая физические свойства объекта в игре, и "верхняя", задающая его поведение. Ни о каких событиях "верхняя" не знает, это всё дела "нижней". Заметим, игрок на Лиспе будет писать только "верхнюю" программу, так что он ничего и не будет знать о событиях и прочей низкоуровневой кухне. [14:49]<dr_croco> Потом, твой вариант запроса кажется мне слишком уж детализированным. Если в игре есть событие "изменение числа игроков" (что логично), то заинтересованному объекту достаточно потребовать, чтобы его оповещали именно что о том, что число игроков изменилось. Если его интересует только изменение 4->5, то проигнорировать все прочие он вполне может и сам. Когда же он получит свои два события, он просто откажется от дальнейших, то есть скажет системе, что больше получать события об изменении числа игроков не желает. [14:57]<dr_croco> В очередь событий должны, видимо, складываться сами события, а не запросы на них Мне кажется, что это должны быть Lisp-списки, первый элемент которых задаёт тип события (видимо, символ, чтобы эффективно было), а остальные используются в зависимости от типа. Например, звук, следующий элемент - идентификатор пространства и пространственные координаты, потом сила звука (чтобы определить можно было, слышно данный звук или не слышно). Если звук слышно в соседних пространствах, надо, видимо, генерировать несколько событий. Заказ объекта на события этого типа будет выглядеть как (SOUND, <id_пространства>)

вот :) --AndreyStolyarov


Давно тута не была. Впрочем, не важно. Поскольку срочно надо все это дело разворачивать, прошу, если есть, кидаться полезными ссылками. Андрей Викторович уже начал : http://dtf.ru/articles/read.php?id=44593 и это прекрасно. -- GenShen


А почему не http://dtf.ru/articles/print.php?id=44593 ? -- MeDendik


Да вполне =) сиб =) -- GenShen


InteLibWiki PageList RecentChanges PageHistory