О компьютерных играх point-and-click quest.

[qkowlew]

По следам программы Adventure Maker вдруг образовалась такая логика построения игры типа "point-and-click quest":

Background комнаты определяет положение объектов в комнате.

Объекты бывают

- control  контрол  - неперемещаемый, реагирует на нажатие. меняет переменные.
- chest    сундук   - неперемещаемый, при нажатии генерит ключ и меняется
                      (пропадает, превращается в контрол)
- key      ключ     - перемещаемый, генерится из сундука, попадает в инвентарь.
                    - при доставании из инвентаря ползает за мышью пока не:
                    -- при столкновении со своим замком пропадает
                    -- отпустили мышь не на замке - возвращается в инвентарь
- lock     замок    - при совмещении своего ключа с оным меняется
                      (превращается в сундук, контрол или исчезает)
                      и-или меняет переменные.

Упрощённый вариант без таскания ключа (например, на телефоне!) - клик на замок
при отсуствии ключа в инвентаре вызывает сообщение "нужен ключ". А
при наличии ключа - его вставление и срабатывание.

Что я ещё забыл?

Comments

[aywen.livejournal.com]

В сундуке может быть несколько разных ключей?

[qkowlew.livejournal.com]

Полагаю, что сундук может сгенерить (и, соответственно, положить в инвентарь) не один ключ, а несколько.

Хотя это не будет столь стройно, как "сундук генерит ровно один ключ и превращается в контрол или исчезает".

[aywen.livejournal.com]

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

[qkowlew.livejournal.com]

Эээээээээ... Нелогично. То есть если уж мы кликнули на "сундук" - то всякое торможение процесса отдачи нам "ключа" будет скорее восприниматься игроком как глюк, ошибка программы.

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

При этом изображения предметов, взаимосвязи между ними могут быть очень сложными благодаря переменным и задаваемым условиям.

Но логика работы интерфейса должна быть всё-таки без подозрения на глюки.

[aywen.livejournal.com]

Я не то имела в виду. Вот есть у нас сундук с ключом. После того, как ключ забрали, он становится контролом или пустым местом. Через дельта т он может опять стать сундуком с ключом.
Дерево, на котором растут яблоки, например.

[qkowlew.livejournal.com]

А. Понял. Да, логично. Но не необходимо.
В логике "чистого" жанра квеста можно сменить статус сундука, например,
по факту прохождения какой-то другой точки. А не "по дельта т".

[vetta-vetka.livejournal.com]

В такой системе, кажется, сложно сделать кодовый замок, а они часто встречаются в таких адвенчурах.
Контрол должен мочь меняться при нажатии, чтобы опущенный рычаг выглядел не так, как поднятый.
Я бы сделала еще декорацию как объект, мне кажется, так было бы легче собирать комнаты.

[qkowlew.livejournal.com]

Кодовый замок описанного тобой типа - это "не замок". :) Это набор контролов, каждый из которых при нажатии меняется и меняет состояние переменных.

например 4 рычага - это 8 контролов и 4 переменных.

[skydigger.livejournal.com]

Я так полагаю, что ловушки и телепорты Вы будете контролами отыгрывать?

[qkowlew.livejournal.com]

телепорт, как и открытая дверь - игротехнически это просто смена комнаты в результате нажатия на контрол.

[skydigger.livejournal.com]

Хорошо, а ловушка, убирающая предметы из инвентаря?
("Кислотный душ! Ваша кольчуга заржавела!")

[qkowlew.livejournal.com]

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