Объекты в IF языках программирования это хорошо - можно задать общие для объектов вещи и более не мучиться... Проблемы есть, но их не много и они довольно просто решаются/избегаются. Это, например, приписывание не тех свойств объектам = простая невнимательность. Но, возможно, кто-нибудь скажет, что ООП (объектно-ориентированное программирование) сложнее, чем линейное программирование.
Короче не знаю.
Просто ищу оправдание внезапно наплывшему желанию написать простую платформу на Python для IF. Команды там будут обрабатываться совершенно линейно, как в "Васе". Т.е. те команды, кот. программист не задал пониматься просто не будут. Хотя будут некоторые вспомогательные механизмы - такие, как маски команд. Скажем, игрок набирает "отдать топор гоблину", находясь в комнате room1. Тогда последовательно будут вызываться следующие команды: room1_отдать_топор_гоблин, room1_отдать_топор_*, room1_отдать_*_гоблин, room1_отдать_*_*, room1, отдать_топор_гоблин, отдать_топор_*, отдать_*_гоблин, отдать_*_*, *. Вот примерно так. Надеюсь, что идея понятна. Следует ли пытаться сделать такую систему, или она по сути слишком примитивна и не стоит затраченного времени? А?
Неактивен
ТОМ под Миленой.
Простой С++ подобный язык.
А парсер можно не использовать.
Неактивен
В приложении микро-мини-демка для Милены.
Тестировалось на Милене 2.0 с подключенным модулем ТОМ.
Пример позволяет представить себе как бы выглядела менюшная игра на ТОМе.
--------------------------------------------------------------------------------
Прикрепленные файлы:
Milena_demo.tom, Размер: 2,031 байт, Скачано: 46
UPD: обновленный пример входит в набор примеров к платформе ТОМ, его можно скачать со станички ТОМа в иф-википедии.
Отредактировано ASBer (23.10.2009 09:55)
Неактивен
noname, а наследование у тебя будет? а перегрузка методов?
Неактивен
мне не нравится в существующих парсерных движках- разделение на типы объектов. почему бы не сделать 'контейнер', 'поверхность', 'переносимость', 'общительность' свойствами, которые можно комбинировать в любом порядке для любых объектов?
Для этого есть много причин.
Попробую перечислить главные:
1. Практически невозможно сделать универсальный класс на все случаи жизни. Даже перечисленные тобой свойства дают 16 типов различных объектов. Помнож их на количество возможных действий и оцени объем разработки и тестирования всех возможных реакций. Страшно? Мне страшно.
Например поверхность+переносимость. Что будет если мы возьмем такой объект? Предметы с поверхность должны упасть на пол, или останутся на ней как приклееные?
Еще пример: контейнер+общительность. Если мы положим туда предмет, контейнер должен говорить "спасибо"?
Поэтому стандарные библиотеки и содержат узкоспециализированные классы. Только это дает возможность написать библиотеку в сколь бы то нибыло приемлемый срок.
2. Производительность. Сейчас возможно это не так актуально, но узкоспециализированные классы просчитываются быстрее нежели универсальные.
Если у тебя в локации только один НПС унаследованный от 'общительного' класса, парсер не будет на твой "Привет" перебирать все табуретки в локации в надежде, что какая нибудь из них ответит.
3. Стандартные классы вполне подходят для быстрого создания антуража игры. Если же мы конечно хотим написать игру, а не реалити-симулятор.
Игра должна вести игрока чтобы у него не возникало желания говорить с табуретками или двигать недвижимое...
А если к этому еще дописать несколько нестандартных объектов на главные роли - вообще Супер!
Неактивен
пойдём дальше:
почему бы каждому объекту не задать список свойств, связанных с каждым глаголом?
Я библиотеку к ТОМу именно так и буду делать. У объектов будут свойства .МожноВзять .МожноНадеть .МожноСъесть и т.п.
насчёт ТОМа... попробовать что-ли сделать очередной заход?
Велком
Надеюсь в ближайшее время выложить обновленную версию ТОМа, и стандартную библиотеку начну выкладывать кусками.
что-то с трудом даётся его освоение. это- главное, единственное, и большое препятствие для меня. хотя, язык- соблазнительный.
Кста, а может тебе с менюшных игр на ТОМе начать? это на порядок легче. Освоишься с языком и классами там и к парсеру мона перейти.
Отредактировано ASBer (17.04.2009 20:03)
Неактивен
Рекомендую поймать ASBer'а на слове и выжать из него техподдержку в плане написания игры по максимуму
Всегда пожалуйста, я готов
Какая же ТОМ "менюшная" платформа?
В ТОМе есть поддержка меню.
Отредактировано ASBer (19.04.2009 13:21)
Неактивен
это- совершенно естественная идея, и- хороший способ избежать 'комбинаторного взрыва'
noname, к сожалению это очередное заблуждение.
Свойства объектов, как ты их хочешь использовать - это шаг назад.
Невозможно заранее предусмотреть все свойста, которые могут понадобиться автору игры. A код, который анализирует все свойства объекта, будет путанным и трудно модифицируемым. (см. спагетти-код)
Способ выполнения, результат и последствия любого действия зависят от субъекта действия (актера), прямого объекта действия, дополнительного объекта/ов и от окружающей среды, в которой производится действие.
Т.е мы имеем 4 фактора, каждый из которых выражен некоторым объектом, имеющим свой набор свойств и относящимся к различным классам.
Классический ООП позволяет разместить несколько обработчиков одного действия в методах одного из объектов с передачей остальных объектов как аргументов. Выбор конкретного обработчика зависит от классов переданных аргументов (см. полиморфизм, перегрузка методов).
В классическом объектно-ориентированнном языке мы смогли бы разнести обработку качественно отличающихся ситуаций по различным методам с одинаковыми именами. Появился нестандарт - пишем для него новый обработчик, не трогая существующих и все довольны.
Но это все в серьезных языках.
Но что мы имеем для РИЛ?
рТАДС комментировать не буду, смотрите документацию.
ТОМ
1. Добавлен объект для действия.
Выбор действия зависит не только от глагола и его предлога, но и от классов и свойств объектов, упомянутых в команде. Т.е. для одного глагола "съесть" может быть несколько действий - "съесть_съедобное", "съесть_несъедобное", "съесть_отравленное" и т.д. Это изначально разные объекты действий. Проверки на возможность выполнения действий также привязаны к объекту-действию и и могут быть различными для разных действий.
2. Обработчики действий привязаны к объектам-актерам, а не к объектам. Перегрузки пока нет, но надеюсь когда-нибудь появится.
Отредактировано ASBer (19.04.2009 20:13)
Неактивен
я так вижу, по сообщениям of ASBer, что он скорее позиционирует её, как 'универсальную'. т е ООП-платформу с Си-подобным языком, предназначенную для создания как парсерных, так и менюшных квестов
Да, примерно так и есть. Менюшные квесты на ТОМе вполне реально делать, и это неплохое начало для освоения платформы с возможностью в дальнейшем перейти к использованию парсера.
to ASBer: будешь писать библиотку - не молчи, дай знать. для начала хотелось бы команд 'идти' и 'смотреть', затем- 'открыть' и 'закрыть' - двери, окна, сейфы, шкатулки и т п, потом - 'взять' и 'выложить' - хочу потестить по 'горячим следам'
Да, обязательно! noname, я на тебя рассчитываю
Неактивен