Forum.iFiction.Ru

Считаю, что анализатор команд строго привязан к методу реализации самой платформы и речь об анализаторе должна быть неотрывна от концепции построения самого движка . Вообще нужно отдавать себе отчет в том, что анализатор это всего лишь один из элементов, а не сама платформа.  Так, на мой взгляд, существует два основных метода, на которых реализуются все текстовые платформы. Первый - когда к вводимым глаголам заведомо определяется какое-то действие.  Например глагол ВЗЯТЬ (ОБЪЕКТ) можно определить как процедуру добавления предмета ОБЪЕКТ в инвентарь. Не имеет значения что это за объект, если он был объявлен и имеется возможность его взять в данное время на данной локации, то он будет добавлен в инвентарь. Глагол ПРИВЯЗАТЬ будет, например, сопоставляться с процедурой соединения двух или более объектов. Таким образом создаются модели физического взаимодействия объектов, и как следствие в рамках созданной модели могут существовать и взаимодействовать различные объявленные объекты, в соответствии с объявленными для них же свойтвами. Используемая методика облегчит дальнейшую разработку игр на платформе, однако ограничит их возможности возможностями физического мира, предоставляемыми самой платформой.
   Другой подход основан на более низкоуровневом программировании. Тоесть физика поведения объектов описывается для каждого конкретного случая и эта задача возлагается платформой на разработчика. Это неоспоримо более гибкое решение, однако и не сравнимо более сложное для самого разработчика игры. Можно попытаться совместить оба подхода, путем возможности использования шаблонных заготовок (например поведение NPC в торговле, диалоге, битве, взаимодействие с предметами) опирающееся на свойства этих самых объектов. В этом случае NPC тоже объект со своими свойствами (например ЗДОРОВЬЕ,АГРЕССИЯ,ИНТЕЛЛЕКТ,ТОРГОВЛЯ), которые выражаются простейшими числовыми ограничениями например от 0 до 100. Иными словами разрботчику игры платформа должна предлагать возможность самостоятельного создания объекта "с нуля" так же как и возможность применения заготовок (шаблонов), включающие в себя стандартные методы взаимодействий.  Теперь по поводу собственно анализатора. В случае когда создается модель физического взаимодействия объектов (пусть даже самая простейшая). Все вводимые команды должны распознаваться интерпретатором собственно как ДЕЙСТВИЕ или ДЕЙТСВИЕ и ОБЪЕКТ(ы) над которыми этой дейсвие осуществляется. В таком случае возможные ДЕЙСТВИЯ предварительно запрограммированы в платформу и для разработчика на базе этой платформы они "прозрачны" . Тоесть разработчику по-большому счету требуется описать комнаты, расставить объекты, наделить их свойствами и указав стартовую локацию запустить свой проект на исполнение. Тогда применение мощного анализатора вводимых команд неоспоримо. Анализатор должен уметь делать главное - разделить команду на ДЕЙСТВИЕ и ОБЪЕКТЫ,учавствующие в этом действии.
В другом случае от анализатора не требуется вычленение действий и объектов из вводимого игроком текста, а требуется распознавние целой фразы в различных ее стилистических и орфографических формах и сопоставление этой фразы с соответсвующим действием над предопределенным объектом.  Этот метод основывается на распознавании вводимого текста по маске. Об этом упоминал еще Graham Nelson, его смысл в следующем. Под осуществление какого-то действие формируется маска типа:
ПРИВЯЗ ЛОШАД ВЕРЕВ ДЕРЕВ/ПРИЦЕП ЛОШАД ВЕРЕВ ДЕРЕВ

играющий может написать например:

>Привязать веревкой лошадь к дереву

но может изменить по-любому последовательность
слов и их окончания, а так же добавить какие то другие слова, например:
>Прицепить эту глупую ЛОШАДКУ к дереву веревкой.

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