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)