Подземелья, драконы, лопаты и телепатия

Краткий взгляд на дизайн MUD'а

I. Введение

MUD - сокращение от "Multi-User Dungeon" ("Многопользовательские подземелья"), что должно знать большинство из вас. Имеется ряд похожих сред, которые выделились из первоначальной идеи MUD, вроде MUSE, MUSH, MOO и так далее. В этой статье я буду говорить только о MUD - частично потому, что я чувствую себя в них более комфортно, частично потому, что различия в терминах разработки не столь значительны.

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

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

Обычным делом является то, что одна среда может понимать только очень простые команды из двух слов, в то время как похожая среда понимает невероятно сложные структуры. В TUBMUD'е, единственном MUD'е, который я фактически программирую, имеется квест, в котором от игрока требуется взять высохшую голову с помощью команды "взять высохшую голову оркского шамана с подушки на пьедестале рядом с западной стеной". Если синтаксис неточно выдержан, появляется - дико смешное - сообщение об ошибке "Взять что чего из чего на чем рядом с чем?".

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

II. Реальное время

В то время как в большинстве текстовых адвенчур время протекает только между последовательными командами от игрока, побуждая его тщательно обдумывать каждый свой шаг, время в MUD течет постоянно. Это приводит, между прочим, к критическим во времени результатам, которые являются весьма хаотичными: игроки должны набирать свои действия настолько быстро и аккуратно, насколько возможно, и последствия не могут быть отменены.

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

      Медведь гризли нервно расхаживает взад-вперед.
      > ущипнуть медведя гризли за бок
      Вы действительно хотите сделать это? (Д/н)
      Внезапно медведь оборачивается, смотря на вас с очевидным гневом!
      > убежать как можно быстрее
      Пожалуйста, ответьте да или нет: Вы действительно хотите сделать это? (Д/н)
      Медведь бьет вас с хрустом ломающихся костей.
        ...

С другой стороны, среда в реальном масштабе времени учитывает манящие маленькие подробности: часы, которые бьют; волшебную микстуру, которая действует на пять минут (поэтому напоминающую игроку подумать, _прежде_ чем выпить); красивую орхидею, которая цветет только один раз в месяц ...

III. Игроки в мультиплейере

Игроки в мультиплейере требуют разнообразных решений. И это не альтернативный вариант; это - требование! Глыба, которую вы не можете поднять, потому что она слишком тяжелая и требует от вас выпить микстуру силы Циклопа, просто не годится: втроем ее смогут поднять и так.

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

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

Так, если Бельфегор уничтожает волшебной палочкой землетрясения Ллиану, должны появиться следующие сообщения:

Бельфегор: "Вы поражаете этой волшебной палочкой землетрясения Ллиану. Земля яростно трясется под ее ногами".

Ллиана: "Бельфегор поражает волшебной палочкой землетрясения вас. Земля яростно трясется под вашими ногами".

Другие, в этой же локации: "Бельфегор поражает волшебной палочкой землетрясения Ллиану. Земля яростно трясется под ее ногами".

Другие, в соседних локациях: " Внезапно земля яростно сотрясается".

Другие, в дальних локациях: " Внезапно можно услышать слабую вибрацию".

Заметьте различное использование "этой волшебной палочкой" и "волшебной палочкой". Альтернативно может использоваться "ваша волшебная палочка" и "его волшебная палочка".

IV. Придание ощущения целостности

Игроки имеют неотъемлимые способности, которые должны быть учтены при разработке объектов и персонажей. Рядом со скиллами, статами (вроде силы или конституции тела) и визуальными характеристиками (типа рубцов и татуировок), есть одна сила, о которой следует сказать особо: сила телепатии. В большинстве MUD'ов (которые я знаю, конечно), игроки могут "сказать" и "кричать". Разговор - это способность телепатически общаться с другими игроками независимо от того, как далеко они; и крик - способность кричать что-то настолько громкое, что любой другой игрок будет это слышать.

Если игрок превращен во что-что другое, или его восприятием управляют, его способ общения изменится. LPMUD'ы (MUD'ы, использующие интерфейс, который был первоначально разработан Ларсом Пенсйо (Lars Penssjo)) имеют особенность - проклятие, которое превращает игрока в лягушку. Все крики этого игрока будут изменены на

 Большая лягушка кричит: Кваак! Кваааак!

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

  Вы говорите: я снова чувствую себя совершенно нормально.

в то время как другие игроки в комнате видели бы (если игрока зовут Джеронимо)

    Джеронимо говорит: Аргл! Арр арргл!

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

V.Объектная ориентация

В то время как в текстовой адвенчуре автор ответственен за каждый отдельный объект, это совсем не так в MUD. Фактически, хорошее программирование учтет даже те объекты, которые еще не существовали до того, как игра была написана.

Худшее, что можно вообразить, это ситуация, в которой игрок пытается окопаться, скажем, в стоге сена и получает возражение парсера ("Копать где?"), в то время как лопата, купленная в магазине на углу, будет в этом стоге прекрасно копать. Программист должен убедиться, что такие проблемы обрабатываются достаточно гибко: он должен создать процесс рытья способом, который воздает должное цели, а не действию, даже если это означает предупреждение плохих задумок других программистов.

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

Правильная объектно-ориентированная разработка - самая сложная часть дизайна MUD. Я мог бы решить, что лестница будет равнопригодной для того, чтобы взобраться на мое дерево; так что я сообщил бы дереву, что объект, удовлетворяющий описанию "лестница", может прислоняться к нему для того, чтобы подняться наверх. Веревочная лестница, однако, удовлетворяет описанию и, тем не менее, не может прислоняться к чему-угодно. Так что я должен бы также предупредить эту возможность. В любом случае, сколь много работы я не вкладывал бы в мое дерево, я никогда не смог предвидеть каждое возможное решение: Невероятное Устройство Супермастера "Восхождение Подобно Белке" тут бы не работало.

VI. Правила

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

Это также работает и в обратном направлении. Противоядие пыталось бы "исцелить яд", так что опасный плод "знал" бы, что его эффект может быть изменен на противоположный этой микстурой.

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

VII. Наконец, квест подготовлен

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

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

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

Если квест разработан для одного игрока, что произойдет, если он приведет друга? А если двоих? Неприступная стена будет намного меньшей проблемой, если один персонаж сможет стать на плечи другого. Сэр Арчибальд Рыцарь не так опасен, если его одновременно атакуют четверо. Опускная дверь не будет внезапно закрыта, если один персонаж посторожит сверху.

Об этих возможностях следует подумать при написании квестов. Простым решением было бы не впускать других игроков, как только один принял квест (телепорт-устройство, силовое поле, въезд на поле битвы на коне).

VIII. Заключение

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

MUD'ы, также как все их многочисленные близнецы, являются interactive fiction на различном уровне. Не обязательно верхним уровнем, но, несомненно, достаточно особыми, чтобы получить от них удовольствие.

Если вы еще не готовы - решайтесь. Я буду рад провести вас через чудеса TUBMUD. Только сбросьте мне сообщение.

содержание