Forum.iFiction.Ru

Мда. XML-подобный язык очень хорошо подходит для обмена данными, но очень плохо подходит для описания вручную. Необходим хороший редактор. Но в целом согласен с Gremour - TADS намного удобнее, т.к. приближен к естественному языку более, чем XML-подобное описание.

Eten написал:

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

Я так понимаю, наследования у тебя не предвидится?

ООП ведь придумали не для того, чтобы добавить гемора программистам. Оно позволяет делать многие вещи проще и с меньшими усилиями. И IF как раз относятся к разряду программ, которые идеально укладываются в эту модель -- объекты и методы.

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

Вот череп из стандартного примера в комплекте TADS:

goldSkull: item
   sdesc = "gold skull"
   noun = 'skull' 'head'
   adjective = 'gold'
   location = pedestal
   doTake(actor) =
   {
      if (self.location <> pedestal or smallRock.location = pedestal)
      {
         pass doTake;
      }
      else
      {
         "As you lift the skull, a volley of poisonous
         arrows is shot from the walls!  You try to dodge
         the arrows, but they take you by surprise!";
         die();
      }
   }
;

Поясняю: Череп лежит на "заминированном" постаменте. Если его просто забрать, сработает ловушка (реагирует на вес). В игре есть камень. Камень можно положить на постамент, после чего череп можно забрать, не запустив ловушку. Всё это обеспечивает переопределённый метод doTake -- обработчик глагола "взять" (и всех его синонимов).

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

Естественно, автор может описывать новые действия, и добавлять стандартные обработчики на них следует в базовый объект. Например, стандартный обработчик глагола "нюхать":

doSmell (actor)
{
    "Пахнет <<tdesc>>.";
}

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


Проще ли будет выглядеть реализация золотого черепа в СТК (давай подсчитаем количество управляющих слов)? Возможно ли сделать это вообще?

fireton написал:

Программирование игр все-таки ближе к алгоритмам, чем к описанию неких структур.

Строго говоря, объекты - те же структуры, по большому счету. Кроме того, любая объектная модель мира - в основном описание неких структур
Но вообще согласен, TADS удобнее для кодера.

Вот если будет удобный специализированный визуальный инструмент для редактирования игр именно на CTK - условно, мышкой расставил комнатки, распихал предметы, вбил описания, добавил нестандартные реакции (а значит, должны быть и стандартные - что-то вроде библиотек TADS для игр) - запустил - работает, тогда я только за!

Отредактировано Hind (30.12.2007 16:40)

Нет, все-таки немножко опишу пусть хоть и на словах. Пъедестал будет объектом, как череп и камень тоже. Пъедестал будет иметь, следующие отношения: фикисрованный, поверхность. Череп: инвентарный, камень также, как и череп. Исходные отношения у объектов, такие: подвижный, простой, не контейнер, не поверхность, не инвентарный, не абстрактный. Задавая ему отношения, мы изменяем его исходные отношения, убирая эти отношения (программным путем), опять возвращаем отношение в исходное состояние. Итак, пъедестал имеет отношение фиксированный и поверхность - это значит, что его нельзя двигать и на него можно что-то положить. Череп и камень соответственно можно взять в руки (проще говоря положить в инвентарь) и убрать обратно. Т.к. вариант управления менюшный, то прописываем у объектов действия. В пъедестале прописываем действие "взять череп", в нем проверяем есть ли на пъедестале камень и т.д. также пробиваем действия "положить череп", "положить камень", "взять кмень", можно обойтись проще т.к. есть камень или череп понятие истина или ложь, то можно написать так "череп" и "камень", а внутри написать проверку есть ли камень на поверхности пъедестала, если да то снимаем его, если нет то ставим обратно, с камнем также. При этом я могу менять название пъедестала: "пустой пъедестал", "пъедестал с черепом" "пъедестал с камнем" и т.д., а могу вообще его не менять, но пропишу тэг описания пъедесталя, чтобы можно было вывести, что у нас там на пъедестале. Т.к. используем меню, то в локе с пъедесталом прописываем действия, через которые будем вызывать действия в пъедестале и вызывать добавление камня из локации в рюкзак героя. Как весь этот процесс заэвуалировать дело каждого. Вот мой вариант действий в локации: 1)взять камень/бросить камень, 2)поставить камень на пъедестал/забрать камень с пъедестала,  3)забрать череп с пъедестала/поставить череп на пъдестал, 4)осмотреть пъедестал, 5)осмотреть комнату. Все действия будут выводиться в определенной зависимости друг от друга, кроме 4 и 5, в тех действиях где стоит слеш взаимнопротивоположны друг другу и появляются в случае не доступности другого. В итоге у нас получается всего четыре или пять действий.  Когда камня нет на пъедестале, то доступно  1, но не доступно 2. Когда камень на пъедестале, то наоборот. Но если мы ни разу не выполняли действие 5, то ни 1, ни 2 не доступны (должны же мы с начала его посикать ). Что будет в случае 3, всем известно, как обычно стоит камень на пъедестале, когда снимаем череп, все окей, когда на пъедестале в этот момент был только череп хана герою. Получается, что когда заходим в комнату, то доступны только 3, 4 и 5. После 5, доступны 1 и 2. При отсутствии камня в инвентаре или присутствии его на поверхности пъедестала, не достпуно 1.

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

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

Отредактировано Eten (31.12.2007 22:15)

Eten написал:

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

А что, в СТК спеллчекер создать - как два байта переслать? (И не надо отсылок в духе, что СТК - платформа для менюшных квестов).

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

goraph написал:

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

Гор, какое описательное свойство имеется в виду? Актер - главный персонаж или непись? "Описательное свойство" - имеется в виду краткое описание (sdesc), подробное описание (ldesc), или описание актера в локации (actorDesc)?

Предположим последний случай (actorDesc):

actorDesc={if((self.HitPoints>=2) and (self.HitPoints<=7))
                    {ZAG(actor, sdesc); " тяжело дышит и выглядит уставшим.";
                    }
                   else
                     {if(self.HitPoints>7)
                          {ZAG(actor, sdesc); " держится молодцом.";
                          }
                       else
                         {ZAG(actor, sdesc); " практически сдох.";
                         }
                     }
                 }

Другие свойства (из вышеперечисленных в начале)  определяются аналогично.

Ответ на вопрос  "что делать" - читать документацию, а если все равно ничего не понятно - задавать вопросы на форуме;).

И последний встречный вопрос: что, 1-го января больше заняться нечем? Я вот лично сейчас дособираю дочке санки и отправлюсь трезветь... в смысле, отсыпаться;).

насчет актера, вот листинг:

...   
<описание>
   //допустим твой актер имеет имя вася.
   если вася.хит > 7 и вася.хит < 2 тогда
       вывод("Вася  тяжело дышит и выглядит уставшим. ");
   иначе 
       если вася.хит > 7 тогда вывод("Вася  держится молодцом. ");
       иначе вывод("Вася  сдох. ");
</описание>   
...

учитывая, что когда мы пишем

вывод(Вася);

то выводится не вася, со всеми его сво-вами, а его описание.

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

Если хочешь, чтобы информация о состоянии актера выводилась,после каждого действия, тогда написать в нем следующие:

<фондействие>
  вывод(Вася);
</фондействие>

И после каждого твоего действия оно будет выводиться на экран, можно и усложнить выполнение фонового действия, но это уже твоего ума дело.

Отредактировано Eten (01.01.2008 14:51)

goraph написал:

uux, я знаю как это делать в тадс, меня интересовало как это предполагается делать в СТК, это ж не раздел тадс, это раздел флейм

Ага, спасибо за пояснения (я в них действительно нуждался). Вот что значит зайти на форум в новый год с бодуна;).

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

goraph, +1

goraph

Получается внутри тегов и пишется код?

Хоть кто-то обратил внимание на эту изюминку. Да, именно так, но не во всех тэгах. Если тэг содержит в себе другие тэги, то он не может содержать код и наоброт. Это очень удобно когда тэги и код дополняют друг друга - в этом и вся особенность синтаксиса СТК. Где вы такое видели?

то поди догадайся как мне писать цикл - "для х от а до б"? нет "пока а<б"? снова нет, черт возьми "цикл ..."

А как вообще может придти в голову искать подобным образом? Когда слово цикл больше подходит для цикличного оператора, чем непонятные слова для и пока. Для чего х от а до 6 или куда это пока а < 6, проще на русском так: цикл х = а к 6 или цикл а < 6. При чем читается, это так: цикл х от а к 6 или цикл пока а < 6 истина.

Меня  больше всего поразило в английском, что  слово for и while вообще не имеют никакого отношения к циклу, но там это и не заметно, прижились или у них читается по другому, видимо отсюда и пошло такое написание цикла. По англ. с русского ситаксиса это будет так: Cycle а to 6. Разницы никакой, только сути больше.
З.Ы.
Зачем все усложнять, когда можно сделать проще?!

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

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

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

Другие платформы изучаю для большей совместимости, но все сразу за один заход, блин не реализуешь!

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

Читабельность тэгов определяется используемым ПО для их просмотра.

В СТК тоже будет наследование, но как в Паскале, а отношения будут иметь множественные отношения - это будет давать больше гибкости и простоты в иерархии объектов, чем множ. наследование. Учти, я это множ. наслед. уже хлебал и вариант в СИ шарпе, оказался куда практичнее, а главное с его помощью меньше оплошностей и затруднений.

Давай не будем говорить про возраст ТАДС, а посмотрим на его версию, насколько мне известно последняя версия 3.х. Не так уж много.

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

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

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

И в итоге, что же у тебя подразумевается под птичьим языком, я понял, что ничего путного, кроме того что на нем разговаривают птицы или я тебя не правильно понял? (раз уж сказал, то объяснись)

Отредактировано Eten (02.01.2008 10:16)