Forum.iFiction.Ru

iFiction.Ru · ifHub · FAQ · IFWiki · QSP · URQ · INSTEAD · AXMA

форум об interactive fiction, текстовых приключенческих играх и всём таком...

Вы не зашли.

0    0    #26
19.04.2009 19:02

ASBer
Модератор (+161, -20)
Откуда: Москва
Зарегистрирован: 19.07.2007
Сообщений: 816
Вебсайт

Эники-Бэники
ели вареники,
а Джоники-Мнемоники
ели психотроники.

Re: ООП IF платформы vs линейное программирование

это- совершенно естественная идея, и- хороший способ избежать 'комбинаторного взрыва'

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

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

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

Но что мы имеем для РИЛ?

рТАДС комментировать не буду, смотрите документацию. smile

ТОМ
1. Добавлен объект для действия.
Выбор действия зависит не только от глагола и его предлога, но и от классов и свойств объектов, упомянутых в команде. Т.е. для одного глагола "съесть" может быть несколько действий - "съесть_съедобное", "съесть_несъедобное", "съесть_отравленное" и т.д. Это изначально разные объекты действий. Проверки на возможность выполнения действий также привязаны к объекту-действию и и могут быть различными для разных действий.
2. Обработчики действий привязаны к объектам-актерам, а не к объектам. Перегрузки пока нет, но надеюсь когда-нибудь появится.

Отредактировано ASBer (19.04.2009 20:13)

Неактивен

0    0    #27
19.04.2009 20:00

uux
Участник (+884, -80)
Откуда: Москва
Зарегистрирован: 02.12.2006
Сообщений: 1624

Re: ООП IF платформы vs линейное программирование

noname написал:

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

Поправьте меня, программисты-профессионалы - но, по-моему, инкапсуляция методов (обработчиков) в объекте - это составная (и практически неотъемлемая) часть ООП.

Неактивен

0    0    #28
19.04.2009 20:21

ASBer
Модератор (+161, -20)
Откуда: Москва
Зарегистрирован: 19.07.2007
Сообщений: 816
Вебсайт

Эники-Бэники
ели вареники,
а Джоники-Мнемоники
ели психотроники.

Re: ООП IF платформы vs линейное программирование

я так вижу, по сообщениям of ASBer, что он скорее позиционирует её, как 'универсальную'. т е ООП-платформу с Си-подобным языком, предназначенную для создания как парсерных, так и менюшных квестов

Да, примерно так и есть. Менюшные квесты на ТОМе вполне реально делать, и это неплохое начало для освоения платформы с возможностью в дальнейшем перейти к использованию парсера.

to ASBer: будешь писать библиотку - не молчи, дай знать. для начала хотелось бы команд 'идти' и 'смотреть', затем- 'открыть' и 'закрыть' - двери, окна, сейфы, шкатулки и т п, потом - 'взять' и 'выложить' - хочу потестить по 'горячим следам'

Да, обязательно! noname, я на тебя рассчитываю smile

Неактивен

0    0    #29
19.04.2009 22:44

noname
Участник (+36, -9)
Зарегистрирован: 04.04.2008
Сообщений: 729

noname

Re: ООП IF платформы vs линейное программирование

Невозможно заранее предусмотреть все свойста, которые могут понадобиться автору игры

похоже меня совершенно не поняли. не надо предусматривать ВСЕ свойства. ты щазз о библиотеке? я скажу, что нужно в библиотеке:
1) чтоб она не мешала делать всё по-своему, что бы могла быть легко изменена
2) при создании любого объекта значение всех неописанных свойств равно некоторому дефолтному значению(напр =0). это как в QSP и URQ- автору платформы не было известно заранее, какие переменные я буду использовать, но все они ДО изменения равны нулю(или пустой строке). и мне не нужно их специально прописывать ДО сравнения с чем-либо- операция сравнения вполне может оказаться первой операцией с впервые встреченной в коде переменной. в этом случае автору квеста достаточно прописать ТОЛЬКО те свойства объекта, которые важны для данного конкретного квеста
3) ну, раз уж платформостроителям так не можется без того, чтобы прописать за квестописателя реакции на команды, то пусть кроме "дефолтных" реакций (съесть_0, взять_0), которые _всегда_ выдают просто какое-то сообщение, и ничего не делают(раз уж в квесте не предусмотрено такое действие, то это- единственный нормальный способ реагирования, без риска похерить квест), будут ещё "нормальные" реакции. т е обычная реакция на это действие с предметом, исходя из того, что это действие над предметом возможно напр:(съесть_1, взять_1). (хотя, на моё ИМХО- эту работу можно оставить на долю автора. НО автору должно быть понятно, как это делать!). ну, и конечно, автору должно быть легко и удобно создавать свои нестандартные реакции съесть_2..съесть_n

// и да, идея называть свойства 'нормальными' именами, типа 'съедобно', 'отравлено', и т п сама просится в голову. НО она порочна в корне. числовое описание 0..n прямо указывает на то, как именно будет обработан такой объект, в то время как в случае описаний 'съедобный, мягкий душистый' и 'съедобный, но твердоватый, кислый, да ещё и отравленный'... ну, блин, если б мы задались целью создавать ИИ, то наверное так и стоило бы делать- между командами и объектами ввести ещё и третью сущность- свойства. НО в данном случае, процесс создания квестов это никак не упростит, а только усложнит. причём совершенно зря. так что вместо обработки смысловых свойств, предлагаю завести некий формальный суррогат свойств, а именно- просто указатель(номер) на конкретную функцию-обработчик. в этом случае сочинение словесных описаний только всё запутает, поскольку не всегда краткое описание будет полностью отражать все ньюансы в различии обработки

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

uux, ну и причём тут ООП? ни Русский язык, ни Аристотелевская логика, ни моё больное воображение, никогда не претендовали на то, чтобы быть объектно-ориентированными. "по логике вещей"- я имел ввиду, что если для каждого предмета задавать способ его обработки, то это- херня полная, в перспективе ведущая к 'комбинаторному взрыву'. к счастью, ни RTADS, ни ТОМ не вынуждают пользоваться таким подходом. далее, развивая эту мысль- логично иметь отельно полностью прописанные объекты с их отношениями и свойствами, и отдельно- функции-обработчики, НЕ для каждого объекта, а по кол-ву свойств, связанных с данной командой(ну, раз уж свойства такие 'бутафорские',- то так). напр съесть_0, съесть_1 и съесть_2, которые вызываются из функции съесть- это уже больше, чем нужно в большинстве квестов. для некоторых команд может понадобиться чуть больше функций- зависит от квеста и от авторской задумки. это даже не особый подход, это- просто такой способ упорядочивания записи данных и методов

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

Неактивен

0    0    #30
19.04.2009 23:03

noname
Участник (+36, -9)
Зарегистрирован: 04.04.2008
Сообщений: 729

noname

Re: ООП IF платформы vs линейное программирование

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

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

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

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

Неактивен

0    0    #31
20.04.2009 06:39

uux
Участник (+884, -80)
Откуда: Москва
Зарегистрирован: 02.12.2006
Сообщений: 1624

Re: ООП IF платформы vs линейное программирование

noname написал:

uux, ну и причём тут ООП? ни Русский язык, ни Аристотелевская логика, ни моё больное воображение, никогда не претендовали на то, чтобы быть объектно-ориентированными.

Ладно, согласен, был неправ - слишком засмотрелся на заголовок темы. Про ООП ты действительно ни слова не говорил.

Неактивен

Powered by PunBB
© copyright 2001–2024 iFiction.Ru