Основные типы квестов
Классический квест обычно предполагает, что если ружьё висит на стене, то оно обязательно выстрелит. Иначе говоря - если с объектом можно взаимодействовать(брать, применять, совмещать, нажимать, уничтожать) - то что-то с ним сделать - необходимо для прохождения. Плюсы - простота разработки, удобство прохождения и т.д. Минусы - на мой взгляд, линейность.
Альтернативные варианты типов квестов позволяют, например, делать некоторые действия трагичными. Например, убить персонажа, который должен потом открыть проход дальше для ГГ. Или уничтожить ключ, до того как дверь будет открыта. В тех случаях, когда такие тупиковые ветки сразу же не заканчиваются, а позволяют играть дальше, игрок может зачастую и не подозревать, что ему уже не выиграть без рестарта игры. Это на мой взгляд, скорее минус.
Так же бывает, что существует несколько вариантов прохождения, в зависимости от каких-либо действий во время игры. Это несомненно хорошая особенность игры, повышающая её реиграбельность, но сильно повышает временные затраты на разработку.
Вариант, когда в мире много объектов, взаимодействие с которыми не приводит ни к чему, несомненно, разнообразит игру, заставляя игрока экспериментировать, но с этим главное не перебарщивать - искать среди десятков ключей тот единственный, который подойдёт к этому сундуку - развлечение не из увлекательных.
Самый, на мой взгляд, интересный вариант, хотя и ещё более энерго-затратный, это когда для решения стоящей задачи можно предпринимать разные действия, например - нам нужно оставить записку. Нужна бумага, и чем писать - можно оторвать кусок обоев, вырвать листок из блокнота, писать прямо на двери при помощи - ручки, карандаша, а губной помадой можно так же на двери, как и баллончиком с краской. Если варианты решения многоэтапны, это реально интересный способ разнообразить свой квест. Представьте, что это вы оказались в такой ситуации, и придумайте несколько вариантов решения проблемы!
К последнему варианту можно отнести также и построение взаимодействий не конкретных предметов, а предметов, обладающих требуемыми свойствами. Примерно 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.:
Даже если не брать в расчёт мои разработки, то свойства можно сделать через те же массивы
Так и в урке так можно. Говоря про объектную модель я имел в виду не свойства объекта, а механизмы наследования и полиморфизма. Когда можно описать поведение абстрактного класса “что-то, на чём можно писать” и “что-то деревянное”, отнаследовать от них класс “дверь” и получить свойства и поведение деревянных предметов, на которых можно писать. Плюс переопределить некоторые методы и задать дополнительно поведение, специфичное для “двери”. Вот так ты в куспе не сделаешь.
Вообще-то уже сделал кое-что подобное, но разговор идёт всё же не о столь высоких материях, а о реализации вполне конкретной задачи — производить некоторые манипуляции с определённым перечнем предметов без прописывания этих манипуляций с каждым из них.
Задача: обеспечить возможность написать одним предметом на другом какую-либо надпись (пусть она будет вполне определённая по сюжету).
У предмета, которым мы хотим писать, должно быть свойство “ИмМожноПисать”.
У предмета, на котором можно что-то написать, должны быть свойства “НаНёмМожноНаписать” и “НадписьНаПредмете”.
Формирование перечня действий во многом зависит от интерфейса взаимодействия игрока с окружающим миром. У меня, например, нужно сначала ткнуть в один предмет, выбрать из появившегося меню что-то типа “Сделать что-нибудь”, далее ткнуть во второй предмет — и в появившемся меню выбрать конкретное действие.
Так вот, при формировании списка конкретных действий мне достаточно проверить значение свойства “ИмМожноПисать” у одного предмета и “НаНёмМожноНаписать” у другого. Если оба свойства установлены, то я добавляю в перечень действий пункт “Оставить послание”. При выборе этого пункта заполняю свойство “НадписьНаПредмете” предмета, у которого я обнаружил свойство “НаНёмМожноНаписать”, значением по сюжету, например “Помогите! Меня (и сто тонн золота!!!) увозят на остров!”
Вроде как всё.