TDZ - движок для текстовых квестов

Dimouse, ой, то, что в файлике scenes.dat это скритпы, да? это... невыразимо. я понимаю, что подобную схему легче организовать и делается это быстро, но модернизировать её... будет не очень просто.

насчет холодильника: открываем, смотрим что внутри (объекты активировались), закрываем холодильник. то, что внутри, можно взять или нет?


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

ps: Dimouse, что есть TADS?

 

Я это понимаю. Естесственно это можно сделать по-разному, но я говорю не про реализацию. Я не понял логики, почему активным (подсвеченным словом) является именно кислота, а не колба с ней.

Нет уж, я не даром отказался от участия в конкурсе Времени на копании в чужих скриптах у меня в ближайшее время не предвидится.

 

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

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

есть и третий вариант (как например сделано в отечественных аналогах qsp и urq) - сделать простенький интерпретатор некого языка программирования с широкими возможностями.

так что выбор стоит между сложно реализацией движка при (возможно) простоте написания скриптов либо простой движок (но модифицируемый для добавления новых фич) с невообразимо сложной реализацией скриптов (сейчас есть одна комната и менее десятка объектов. что будет если их количество увеличить вдвое?)

 

Но можно ведь сделать все сразу:

Код:

//k- съедобен/несъедобен
//x- объект
//x=4 - дверь

if k=0 and x=4 than 
y="Попытка съесть дверь провалилась, так как она не влезла вам в рот" 
else y="Вы не можете съесть объект такой-то, так как он несъедобен".

 

А вообще в чем проблема? Текстовые квесты оперируют всего лишь тремя типами объектов - локации, предметы и действия. Если добавить ввод пользователя в схему - то еще появляются команды и ответы. Удовлетворительно прописать их все (хотя идеал здесь конечно - прямая реализация в объектном виде на ООП-языке), и движок будет поддерживать как весьма простые, так и весьма сложные вещи.

 

Dimouse,
Ну я просто так понял, что сейчас проблемы вызывает как раз жесткая привязка ответа к команде. Т.е. написали команду, получили однозначный (т.е. с учетом текущего внутреннего состояния игры, которое по ходу дела может меняться) ответ.

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

 

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

 

Ошибок не найдено.

Не очень удобно. Скроллинг листа команд идет как будто это одномерный массив - может его двухмерным сделать (раз уж у нас все равно два "этажа" команд) и добавить скролинг вверх-вниз, от элемента X11 к X21. И еще, в данный момент чтобы от первой команды дойти до последней приходится пролистывать весь список команд - может сделать так, что при нажатии кнопки "влево" на первом элементе, мы переходили бы к последнему? (X21)

 

скрипт выглядит также непонятно как и раньше ) но уже получше.

The_ShadoW и я, предлагаем универсальный вариант движка. примерно так:
объект "холодильник" класс "коробка"
род = м
описание с макросами
особые свойства (морозит)
особые действия
конец

объект "сыр" класс "предмет"
род = м
описание
особые свойства (отравлен)
особые действия (обнюхать, съесть)
трансформация по "съесть" в "ключ"
связи = находится_в "холодильник"
конец

действие "открыть"
описание = "Вы открыли %объект"
изменить_свойства(открыт_закрыт на открыт)
конец

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

главное отличие такого подхода от существующих - отсутсвие программирования. получается чисто декларативный язык (он и сейяас декларативный, но вот реализация...)

ps: в передложенном варианте можно реализовать несколько различных описаний для одинакового действия (для разнообразия текста ).
pps: всегда следует учитывать возможную сложность проекта. много объектов, много разных и однообразных действий, нестандартные ситуации (я хочу запихать кислоту в холодильник и чтобы она там замерзла!). практика показывает, что простые по началу решения перерастают в нечто невообразимое при усложнении проекта.

совсем ps: а можно разъяснить что значать цыферки перед действиями?

 

пример всего

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

 

наверное, ничего страшного, если я в этой теме прокоментирую игру Cosmic Madness ?

никогда не играл в текстовые игры (а может и играл, просто не помню)

некоторые вещи мне кажутся странными, например:

1) рамка окна не зафиксирована, её можно потянут мышкой за край и там окажется пустое место, через которое виден рабочий стол

2) видна консоль
насколько, помню если собрать в релизе, SDL прячет консольное окошко, и вместо этого выводит все в файлы stdout.txt и stderr.txt

3) почему бы не дополнять команды Tab'ом - то есть печатаешь 3 первых символа, жмеш Tab и слово пишется полностью

4) внизу окна, есть команды - выровнять столбиками и без переносов, а то смотрится ужасно;
и назначить им цифры - сооветственно при нажатии на клавиатуре, команда будет вписываться сразу

5) еще назначить клавиши:
открытие помощи - на F1
инвентарь - на F2
выход - F10 (но с предупреждением)

6) хотелось бы видеть команды введенные ранее
то есть, что бы они оставались в консоли выше

7) ужасное склонение для команд:
я не мог сразу догадаться, что вместо идти, надо писать идти на

8) не хочу склонять слова:
вместо поговорить с сэмом, должно быть поговорить сэм

9) сокращенный вариант не всегда работает, хотя не уверен
всместо осм, приходится писать полностью осмотреть

10) нельзя удалить слово добавленное пробелом

11) ощущение, что некоторые объекты вообще не работают
батарейки не берутся, или их не надо брать?

12) вывод предыдущих команд (клавишей вверх)

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

и ещё, в .cfg файле есть параметр casual, не могу догадаться на что его можно поменять
(такие вещи принято указывать прямо в конфиге в виде комментариев)