Основные типы квестов

К последнему варианту можно отнести также и построение взаимодействий не конкретных предметов, а предметов, обладающих требуемыми свойствами. Примерно 10 лет назад пытались обсудить подобное на ификшене. Сейчас я эту тему прорабатываю заново в рамках своего фреймворка для QSP, так, чтобы при указании взаимодействия объектов можно было указывать не ссылку на конкретный объект, а код проверки объекта на требуемые свойства.
Так, при взаимодействии куска угля на двери можно проверять свойство “МожноЧтоНибудьНаписать” у объекта “дверь”. Если такое свойство у объекта (двери) есть, то предлагать игроку действие “Накарябать углём послание”.

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

Да, такая идея очень интересна с точки зрения реализации, в случае качественной проработки может дать неплохие результаты)

Так TADS так устроен. - isReadable значит можно прочитать. isContainer - значит можно положить что-нибудь

bergano:

Так TADS так устроен. - isReadable значит можно прочитать. isContainer - значит можно положить что-нибудь

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

Есть стандартная библиотека, написанная на том же TADSе. Можно глядеть, как реализован тот же isReadable и сделать свое по подобию

bergano:

Есть стандартная библиотека, написанная на том же TADSе. Можно глядеть, как реализован тот же isReadable и сделать свое по подобию

Ну а почему бы не привнести сюда немного полезной информации для Куспа и не рассказать хотя бы в теории, как это сделано? Чтобы другие могли понять, как реализовать это у себя?

Согласен с Olegus’ом. Если знаешь, как работают такие интересные штуки, поделись знаниями.

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

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

fireton:

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

Даже если не брать в расчёт мои разработки, то свойства можно сделать через те же массивы:

$Предмет='Дверь'
...
$Свойства['<<$Предмет>>_МожноЧтоНибудьНаписать']=1

Вполне работоспособно, хотя, конечно, может это только мне такие приёмы уже не кажутся извращением…

tads libs tads библиотеки читабельны. Посмотрите advr.t

В большинстве случаев для свойств достаточно конструкций вида:
МожноЧтоНибудьНаписать[$Предмет]=1

Olegus t.Gl.:

Даже если не брать в расчёт мои разработки, то свойства можно сделать через те же массивы

Так и в урке так можно. Говоря про объектную модель я имел в виду не свойства объекта, а механизмы наследования и полиморфизма. Когда можно описать поведение абстрактного класса “что-то, на чём можно писать” и “что-то деревянное”, отнаследовать от них класс “дверь” и получить свойства и поведение деревянных предметов, на которых можно писать. Плюс переопределить некоторые методы и задать дополнительно поведение, специфичное для “двери”. Вот так ты в куспе не сделаешь.

fireton:

Olegus t.Gl.:

Даже если не брать в расчёт мои разработки, то свойства можно сделать через те же массивы

Так и в урке так можно. Говоря про объектную модель я имел в виду не свойства объекта, а механизмы наследования и полиморфизма. Когда можно описать поведение абстрактного класса “что-то, на чём можно писать” и “что-то деревянное”, отнаследовать от них класс “дверь” и получить свойства и поведение деревянных предметов, на которых можно писать. Плюс переопределить некоторые методы и задать дополнительно поведение, специфичное для “двери”. Вот так ты в куспе не сделаешь.

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

Задача: обеспечить возможность написать одним предметом на другом какую-либо надпись (пусть она будет вполне определённая по сюжету).
У предмета, которым мы хотим писать, должно быть свойство “ИмМожноПисать”.
У предмета, на котором можно что-то написать, должны быть свойства “НаНёмМожноНаписать” и “НадписьНаПредмете”.

Формирование перечня действий во многом зависит от интерфейса взаимодействия игрока с окружающим миром. У меня, например, нужно сначала ткнуть в один предмет, выбрать из появившегося меню что-то типа “Сделать что-нибудь”, далее ткнуть во второй предмет — и в появившемся меню выбрать конкретное действие.

Так вот, при формировании списка конкретных действий мне достаточно проверить значение свойства “ИмМожноПисать” у одного предмета и “НаНёмМожноНаписать” у другого. Если оба свойства установлены, то я добавляю в перечень действий пункт “Оставить послание”. При выборе этого пункта заполняю свойство “НадписьНаПредмете” предмета, у которого я обнаружил свойство “НаНёмМожноНаписать”, значением по сюжету, например “Помогите! Меня (и сто тонн золота!!!) увозят на остров!”

Вроде как всё.