Продолжаю работу над новым квестом...тут я опять возвращаюсь к прошлой проблеме.
Со времён Z-машины существует простой алгоритм парсинга строки. Она делится на 3 части: действие, объект и уточнение. К примеру: "отрубить голову напильником".
Сразу же возникает первая сложность: русский язык формализован меньше английского. Наши люди могут это же сказать как "голову отрубить напильником", и "напильником отрубить голову", и "голову напильником отрубить", как и "отрубить напильником голову".Эти варианты каждый в своей мере приемлимы и - что самое важное - все грамотны.Таким образом, в парсинге строки порядок слов не важен.
Возникает интересная ситуация. С чего начинать? Искать ли первое слово строки по дереву объектов, чтобы выцарапать нужный и производить все действия уже над ним, либо делать классический разбор действия, затем уточнять объект и анализировать остаток строки?
Оба варианта имеют право на жизнь. Если мы идём со стороны объектов, то логично сделать систему объектов - наследуемую систему объектов. Так, мы находим объект "красный шкаф" - и мы знаем, что это уже как минимум, шкаф. Значит, ему присущи все свойства шкафа. Это тем более удобно, что объектно-ориентированное программирование вошло в нашу жизнь довольно давно и прочно.
Если же мы выбираем путь действия? Мы определяем в точности, что собственно от нас хотят - и дальше уточняем, к чему и как это применять. Этот подход классически императивен и использовался во многих известных квестах - но не стоит забывать, что многие известные текстовые квесты были сделаны годах эдак в 80-х.Проверка временем не всегда говорит в пользу выбора, скорее наоборот - современные подходы часто оказываются лучше.
И тут у меня лично встаёт ещё один выбор. Выбор языка. В настоящий момент я веду разработку на C++, так как на нём очень продуман механизм ООП. Но также у меня есть выбор Perl, и чем я ближе приближаюсь к парсеру, я сильнее склоняюсь в его сторону. Там очень просто получить строку, преобразовать из Unicode, разбить по словам, обработать. Можно вспомнить,что существует такая вещь, как mod_perl и мне не обязательно выполнять программу в виде CGI, а можно предоставить её для Apache...Идеально? Почти. В Perl нет никакого механизма ООП - одни "заглушки".
Ну, вот он и выбор: к чему писать костыли. Либо я собственноручно пишу (подключаю из недр Интернета) модули AVL-дерева, работы с Unicode, работы со строками, либо я пишу (на этот раз действительно пишу) кучу-кучу классов с интересным интерфейсом, ещё более интересным наследованием и совсем уже интересным механизмом инкапсуляции.
До сего момента я писал на двух языках, практически. Обкатывал алгоритм на Perl и доводил до ума на C++, спускаясь на более низкий уровень. Это позволяло решать проблемы проектирования чуть-чуть раньше, чем они действительно и неисправимо появятся, и немного отвлекаться от реализации очевидно-неважных структур (в первую очередь это AVL-дерево).
Кстати: если кто-нибудь знает, где достать исходники РУССКИХ квестовых движков, я буду очень признателен.Переводы с английского меня никоим образом не интересуют.Спасибо.
понедельник, августа 17, 2009
Подписаться на:
Комментарии к сообщению (Atom)
Постоянные читатели
Архив
-
▼
2009
(174)
- дек. 27 - янв. 3 (1)
- дек. 6 - дек. 13 (3)
- окт. 4 - окт. 11 (2)
- авг. 9 - авг. 16 (1)
- авг. 2 - авг. 9 (2)
- июл. 26 - авг. 2 (1)
- июл. 5 - июл. 12 (4)
- июн. 28 - июл. 5 (5)
- июн. 7 - июн. 14 (9)
- мая 31 - июн. 7 (5)
- мая 24 - мая 31 (3)
- мая 17 - мая 24 (3)
- мая 10 - мая 17 (5)
- мая 3 - мая 10 (13)
- апр. 26 - мая 3 (1)
- апр. 12 - апр. 19 (10)
- апр. 5 - апр. 12 (5)
- мар. 29 - апр. 5 (6)
- мар. 8 - мар. 15 (7)
- мар. 1 - мар. 8 (3)
- февр. 15 - февр. 22 (13)
-
►
2008
(166)
- дек. 28 - янв. 4 (2)
- окт. 5 - окт. 12 (1)
- июл. 27 - авг. 3 (75)
- июл. 20 - июл. 27 (62)
- июл. 6 - июл. 13 (2)
- июн. 8 - июн. 15 (1)
- июн. 1 - июн. 8 (1)
- мар. 2 - мар. 9 (1)
-
►
2006
(1)
- дек. 31 - янв. 7 (1)
Комментариев нет:
Отправить комментарий