Forum.iFiction.Ru

Можете посоветовать какую-нибудь менюшную ООП платформу?
желательно с простым языком типа QSP, Паскаля

(в принципе не важно русская она или нет,
только бы русская кодировка отображалась правильно)

Убрано в спойлер.

 спойлер…

MixeratoR написал:

Можете посоветовать какую-нибудь менюшную ООП платформу?
желательно с простым языком типа QSP, Паскаля

(в принципе не важно русская она или нет,
только бы русская кодировка отображалась правильно)

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

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

Отредактировано Eten (18.04.2009 07:37)

В приложении микро-мини-демка для Милены.
Тестировалось на Милене 2.0 с подключенным модулем ТОМ.
Пример позволяет представить себе как бы выглядела менюшная игра на ТОМе.

--------------------------------------------------------------------------------
Прикрепленные файлы:
Milena_demo.tom, Размер: 2,031 байт, Скачано: 46

UPD: обновленный пример входит в набор примеров к платформе ТОМ, его можно скачать со станички ТОМа в иф-википедии.

Отредактировано ASBer (23.10.2009 09:55)

Eten, см. личку.

noname, а наследование у тебя будет? а перегрузка методов?

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

Для этого есть много причин.
Попробую перечислить главные:
1. Практически невозможно сделать универсальный класс на все случаи жизни. Даже перечисленные тобой свойства дают 16 типов различных объектов. Помнож их на количество возможных действий и оцени объем разработки и тестирования всех возможных реакций. Страшно? Мне страшно.
Например поверхность+переносимость. Что будет если мы возьмем такой объект? Предметы с поверхность должны упасть на пол, или останутся на ней как приклееные?
Еще пример: контейнер+общительность. Если мы положим туда предмет, контейнер должен говорить "спасибо"?
Поэтому стандарные библиотеки и содержат узкоспециализированные классы. Только это дает возможность написать библиотеку в сколь бы то нибыло приемлемый срок.
2. Производительность. Сейчас возможно это не так актуально, но узкоспециализированные классы просчитываются быстрее нежели универсальные.
Если у тебя в локации только один НПС унаследованный от 'общительного' класса, парсер не будет на твой "Привет" перебирать все табуретки в локации в надежде, что какая нибудь из них ответит.
3. Стандартные классы вполне подходят для быстрого создания антуража игры. Если же мы конечно хотим написать игру, а не реалити-симулятор.
Игра должна вести игрока чтобы у него не возникало желания говорить с табуретками или двигать недвижимое...
А если к этому еще дописать несколько нестандартных объектов на главные роли - вообще Супер!

Ох... Полный оффтоп пошел - прошу прощения у тех, кто писал в эту тему с совсем другими целями, нежели полемика по поводу ООП... Но не ответить noname просто не могу (настолько у него своеобразный -  при этом имеющий мало общего с реальностью - взгляд на объектно-ориентированное программирование). Модераторы, секите и гнобите меня - я этого заслуживаю!

noname написал:

ASBer, видишь ли, у меня есть своё видение того, как должен быть устроен парсер

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

Добиться некорректных реакций? Или у тебя проблемы с формулировками, или у меня - с пониманием (но никак не у ТАДСа со склонениями; вернее, они есть, но сильно преувеличены). Добиться некорректной реакции кто угодно c легкостью cможет от любого языка и для любой области применения - достаточно в первой же инструкции, например, выполнить деление на ноль - вот и некорректная реакция. В свете этого прошу пояснить, что же конкретно имелось в виду.

Так, комментировать про то, чем тебя привлекает/отталкивает та или иная платформа для написания собственного парсерного движка - не буду. Выбор твой, в конце концов.

noname написал:

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

А что, в RTADS - не так? Все это выполняется путем множественного наследования, например при следующем определении

Shtukovina: container, surface, item

будет одновременно контейнером (класс container), поверхностью (surface) и переносимым объектом (item). Чем тебе не свободная комбинация свойств родительских классов? (В нюансы сейчас не углубляюсь, чтобы не раздувать и без того оффтопный пост).

noname написал:

пойдём дальше:
почему бы каждому объекту не задать список свойств, связанных с каждым глаголом?

И опять-таки: что, в RTADS - не так? Да ровно так и обстоит дело - у объекта имеется метод-обработчик, отвечающий за реакцию на конкретный глагол.

noname написал:

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

По-моему, достаточно сделать для глагола один обработчик, в котором проверяются некие условия и в зависимости от их (не)выполнения выводятся различные реакции/сообщения об ошибке, не находишь?

noname написал:

допустим, создаём новый объект 'яблоко'. для начала все его свойства=0, т е задана дефолтная обработка // как правило, просто выдаёт 'стандартное' сообщение, и ничего не делает
если автор хочет, что бы его можно было съесть- делаем свойство 'съесть' объекта 'яблоко' равным 1 // т е - стандартное поедание объекта
задав ещё несколько свойств (взять, и т п - исходя из того, что с ним нужно будет делать) - автор уже добавил новый объект в игру! // ну, правда, просклонять его ещё надо
если нужно добавить ядовитый объект- без проблем: добавляем функцию съесть_2, вызываемую, если свойство 'съесть' какого-то объекта равно 2 // т е - объект ядовит
добавить новый глагол- без проблем! - для этих всех добавлений можно даже прогу написать, типа Adrift, через которую можно добавлять в квест любые объекты и реакции

вот это было бы простой и понятной парсерной платформой

Все, что ты написал выше - ровно описание того, как это делается в RTADS;).

Если ты описываешь яблоко как


Yabloko: item
;


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


Yabloko: fooditem
;


(это в случае, если тебя устраивает стандартная для этого класса реакция - исчезновение яблока из инвентаря и вывод текста "Было очень вкусно!").

Если не устраивает, можно просто переписать обработчик для глагола "есть", например, так:


Yabloko: item
Nadkusano=0
verDoEat(actor)={}
doEat(actor)={self.Nadkusano:=self.Nadkusano+1;
                      "Ты надкусываешь яблоко. Кисловато, но есть можно.";
                    }
;


Про "добавить новый глагол": непонятно, что имеется в виду - то ли определение новых глаголов для игры, не прописанных в стандартной библиотеке, то ли добавление нового глагола динамически во время игры. В подробности вдаваться сейчас не хочу - слишком обширная тема, да и пересказывать мануал - занятие неблагодарное, но и та, и другая задача средствами RTADS решается.

noname написал:

// давайте, разгромите мои бредни в пух и прах - буду рад конструктиву

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

– А вы что же изволите изобретать?
– Да еще наверное не знаю. Что нибудь да изобрету. Господи, мало ли еще вещей не изобретено! Ну, например, скажем, изобрету такую какую нибудь машинку, чтобы каждое утро, в положенный час, аккуратно меня будила. Покрутил с вечера ручку, а уж она сама и разбудит. А?
– Папочка, – сказала дочь, – да ведь это просто будильник.
Капитан удивился и замолчал.

Отредактировано uux (17.04.2009 21:44)

Хорошо, что Билли Хаст промелькнул в качестве примера примитивной разработки текстового квеста. Это действительно так. По теме я бы хотел сказать, что использование того или иного метода программирования исходит от понимания, что будет "в конце". ООП создано, что бы облегчить программирование, не для того что бы "оно было". С его использованием код становится меньше, логичней и проще в использовании, но только в тех случаях, когда это действительно необходимо.
Вот,  опять же, взять исходники моего квеста (Билли Хаст, исходники здесь - http://breakmt.narod.ru/billy_src.zip). Многие сказали бы, что это очень плохие исходники. Я сам понимаю, что они могли бы быть гораздо лучше, используй я ООП, да и, вообще, подходя к этому делу серьезней. Другой вопрос был бы ли этот Билли Хаст вообще, если бы я надумал усложнить задачу, сделать редактор карт, диалогов, расчет времени суток, используя ООП ввести всякие контейнеры, поверхности и т.д. да и вообще необходимы ли они были бы в данной игре?
Что лучше - сделать игру за несколько дней и затем оттачивать ее, либо сделать демку, в которую невозможно будет играть, но в ней будет все вышеперечисленное? Многие начинающие (да и знающие) разработчики переоценивают свои силы и пытаются сделать универсальный движок для разработки продолжений. Я считаю, что это не правильно лично из своего опыта.
Короче, мой вывод: если ты размышляешь использовать ли ООП или нет, если ты новичок - пиши как ты привык, потому что только в этом случае ты получишь результат (причем может быть в короткие сроки) + обучишься чему то новому... иначе пиши используя ООП, потому что это удобно, когда понимаешь, что это такое.

Извиняюсь, если не в тему, потому что писал не для платформ (в которых я не секу), а для тех, кто делает квест с нуля используя язык программирования.

BreakMT, абсолютно согласен, что такой простой подход к программированию парсера оправдан для игр определённого типа. пожалуй, любую задумку 'проходного квеста' (квеста на прохождение) можно реализовать таким способом. при таком подходе мир игры несколько 'огрублён', но в этом и плюс- гамер сосредотачивается на важном, не распыляясь на пустяки. НО у меня есть своя болезнь на эту тему, заключается в идее реализовать 'Живой Игровой Мир'. моё понимание ЖИМ постепенно меняется...

//

да, чуть не забыл: ТОМ = ООП платформа, с возможностью делать менюшные игры

RTADS- вроде бы тоже... в чём проще- не знаю

(хотя, вообще-то это парсерные платформы)

upd:

и ещё немного поддержки to BreakMT: дело, доведённое до конца заслуживает уважения

Отредактировано noname (18.04.2009 08:30)

Возвращаясь к вопросу MixeratoR'а - наверное, действительно единственная менюшная платформа с ООП - это ТОМ. Любимый мною (R)TADS, конечно, позволяет писать менюшные игры, но это все-таки извращение. Рекомендую поймать ASBer'а на слове и выжать из него техподдержку в плане написания игры по максимуму;).

Отредактировано uux (19.04.2009 13:35)

Рекомендую поймать ASBer'а на слове и выжать из него техподдержку в плане написания игры по максимуму

Всегда пожалуйста, я готов

Какая же ТОМ "менюшная" платформа?

В ТОМе есть поддержка меню.

Отредактировано ASBer (19.04.2009 13:21)

uux, недостаток RTADS для меня скорее в том, что я могу добиться вывода на 'ломанном руском'. хотя, да- проблемма скорее надуманная, чем реальная. поверхности тут ни при чём- их действительно можно сделать, и это сделать довольно просто, и это недостатком я не считаю

---

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

это- совершенно естественная идея, и- хороший способ избежать 'комбинаторного взрыва'

---

RTADS опять скачал... буду поразбираться ишщё

Платформа с "поддержкой меню" != менюшная платформа

а в томе специально предусмотрена автором возможность создавать меню. и автор постарался, чтоб это сделать было удобно... но да, парсерная платформа- уже не менюшная. я так вижу, по сообщениям of ASBer, что он скорее позиционирует её, как 'универсальную'. т е ООП-платформу с Си-подобным языком, предназначенную для создания как парсерных, так и менюшных квестов

to ASBer: будешь писать библиотку - не молчи, дай знать. для начала хотелось бы команд 'идти' и 'смотреть', затем- 'открыть' и 'закрыть' - двери, окна, сейфы, шкатулки и т п, потом - 'взять' и 'выложить' - хочу потестить по 'горячим следам'

Отредактировано noname (19.04.2009 18:05)

noname написал:

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

Поправьте меня, программисты-профессионалы - но, по-моему, инкапсуляция методов (обработчиков) в объекте - это составная (и практически неотъемлемая) часть ООП.

Невозможно заранее предусмотреть все свойста, которые могут понадобиться автору игры

похоже меня совершенно не поняли. не надо предусматривать ВСЕ свойства. ты щазз о библиотеке? я скажу, что нужно в библиотеке:
1) чтоб она не мешала делать всё по-своему, что бы могла быть легко изменена
2) при создании любого объекта значение всех неописанных свойств равно некоторому дефолтному значению(напр =0). это как в QSP и URQ- автору платформы не было известно заранее, какие переменные я буду использовать, но все они ДО изменения равны нулю(или пустой строке). и мне не нужно их специально прописывать ДО сравнения с чем-либо- операция сравнения вполне может оказаться первой операцией с впервые встреченной в коде переменной. в этом случае автору квеста достаточно прописать ТОЛЬКО те свойства объекта, которые важны для данного конкретного квеста
3) ну, раз уж платформостроителям так не можется без того, чтобы прописать за квестописателя реакции на команды, то пусть кроме "дефолтных" реакций (съесть_0, взять_0), которые _всегда_ выдают просто какое-то сообщение, и ничего не делают(раз уж в квесте не предусмотрено такое действие, то это- единственный нормальный способ реагирования, без риска похерить квест), будут ещё "нормальные" реакции. т е обычная реакция на это действие с предметом, исходя из того, что это действие над предметом возможно напр:(съесть_1, взять_1). (хотя, на моё ИМХО- эту работу можно оставить на долю автора. НО автору должно быть понятно, как это делать!). ну, и конечно, автору должно быть легко и удобно создавать свои нестандартные реакции съесть_2..съесть_n

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

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

uux, ну и причём тут ООП? ни Русский язык, ни Аристотелевская логика, ни моё больное воображение, никогда не претендовали на то, чтобы быть объектно-ориентированными. "по логике вещей"- я имел ввиду, что если для каждого предмета задавать способ его обработки, то это- херня полная, в перспективе ведущая к 'комбинаторному взрыву'. к счастью, ни RTADS, ни ТОМ не вынуждают пользоваться таким подходом. далее, развивая эту мысль- логично иметь отельно полностью прописанные объекты с их отношениями и свойствами, и отдельно- функции-обработчики, НЕ для каждого объекта, а по кол-ву свойств, связанных с данной командой(ну, раз уж свойства такие 'бутафорские',- то так). напр съесть_0, съесть_1 и съесть_2, которые вызываются из функции съесть- это уже больше, чем нужно в большинстве квестов. для некоторых команд может понадобиться чуть больше функций- зависит от квеста и от авторской задумки. это даже не особый подход, это- просто такой способ упорядочивания записи данных и методов

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

noname написал:

uux, ну и причём тут ООП? ни Русский язык, ни Аристотелевская логика, ни моё больное воображение, никогда не претендовали на то, чтобы быть объектно-ориентированными.

Ладно, согласен, был неправ - слишком засмотрелся на заголовок темы. Про ООП ты действительно ни слова не говорил.