У каждого умника все получется всегда по своему. (цитата и народа)
Привет все поклоникам Адвентуры! Скажу в кратце в место введения. Я уже достаточно посмотрел разных текстовых квестов и платформ для их создания, но мне всегда не нравилось и не нравятся их короткие возможности или усложненный язык. Буду согласен, если мне скажут, что всегда делают свою платформу (т.к. знают ее хорошо) и под свой квест. Но почему бы тогда не сделать простой язык текстового квеста, который в одно и тоже время будет легким для понимания и мощный по своим возможнотсям. Опять же здесь вылезает мнение, что нашелся еще один умник, который создаст еще один горе язык. На это скажем, что язык СТК явялется специализированным языком, направленным на создание, как текстовой игры, так и текстового квеста. Понятие текстовой игры задается для большей свободы в написании хороших квестов. К примеру возмем редактор ТКР (автору движка: не обижайтесь на критику говорю по сущевству), сам пробовал ничего программа хороша, но есть один недостаток движок полностью ориентирован на создание только определенной группы текстовых квестов. Это конечно хорошо, когда не нужно лишний раз думать и изворачиваться в исходном коде - все просто и понятно, но характер перса может быть сложнее и даже задан по другому. Теперь возмем Урку, тоже хороша и проста, жалко что опять возможностей мало (опять же для хороших больших квестов) и плеер слетает при первой же ошибке. Конечно же скажете, что я бука и сам ничего лучше еще не сделал, но больше всего поражает, что никто (или почти никто) не делает редактор, с помощью которых создать простой квест плевое дело, а хороший самое то! Думаю, достаточно привел основных недостатков современного русского движения (можно привести и еще больше, но лень), поэтому решив не соглашаться с таким положением дел решил создать платформу поновее. Сразу огорошу, господа и дамы, всегда создаю универсально (дольше, но качественнее получается), мой СТК (только русскими) может сразу сбить с толку (многие вещи реализуются простыми командами, почти как веб страница по сути, но другое), создавать буду на языке ООП Visual C# 2005 с поддержкой .Net FrameWork 2.0. В конечном счете планируется создать ряд программ для СТК: редактор, прогрыиватели с разными варияциями испольнения, компилятор(в далеком будущем, если такое возможно). Естественно язык получится со своей концепцией и направленностью.
Чем отлчиается СТК? Ответ: Основное его отлчие в том, что он реализован на верхнем уровне тегами XML(на аглийском, увы таков стандарт), на нижнем кодом СТК, который позволяет влиять на квест и выполнять различные команды. Теги упрощают язык СТК и в плане восприятия, и в плане написания. СТК содержит простые команды как и у любого языка (т.е. стандартный набор), содержит специализрованные операторы, которые облегчают реализацию сложных моментов в квесте, а также полезны в обычном использовании (Например оператор множественного условия - содержит мно-во услвоий, связанных между собой не только по смыслу, но по зависимости от выполненных действий предыдущих условий, для тех кто хоть раз программировал хотя бы на Си - это среднее между простыми операторми условия и оператором выбора, но в тоже время совершенно другое. Использовать можно к примеру, для создания сложного замка, который игроку нужно взломать. Отвлеклись немного в подробности пора и меру знать, пойдем дальше.
Базовые типы данных (для тех кто не понял типы переменных: строка, целое и т.д.) мало, но их достатончо для реализации даже отменного квеста (кстати квест хорош не только возможностями исходного кода, но своим сюжет, а это главное). Типы, следующие: число (десятичное), строка, булев, массив, перечисление, структура. Возможно что-то и еще появится, но это будет если без него в действительности не обойтись.
С помощью тегов можно реализовывать характер перса, инвертарь, настройки квеста, стартовое меню (одно из особенностей СТК), события, окружение ( к примеру время тоже относится к окружению квеста), локации( мульти и обычная). Здесь тоже будут добавления. Одна из особенностей данных локаций в том, что для вывода текста после действия, вовсе не надо создавать лишную локацию, СТК будет хранить в памяти локалные переенные локации и выполнять ее снова и свнова, до тех пор пока вы не сделаете переход в другую (согласен звучит жутко, дико и возможно намудрено, но в коде выглядит во много раз проще, зато и писать короче будет). Также соглашусь, если скажут, что тут надо уметь писать алгоритмы, но ведь такие алгоритмы может и школьник научиться писать без всякой заморочки и направленность, такая что можно будет создать хороший квсет. Основной понт в XML тегах то, что они ОС независимы и просты, поэтому такой формат сможет прочитать любой проигрывател СТК квестов, а редактором можно спрятать само написание тегов и вам останется только думать о создании самого квеста. Также в редакторе будет эмулятор СТК, с помощью которого будет производиться отладка квеста. Короче с проектированнием все в норме, рассказывать могу до посинения. Единственная проблема остается - это само создание и мнение участников форума ( с вопросами конечно), о самом СТК и чего бы ему не помешало бы добавить. Для тех у кого есть сомнения в хорошести даного языка приведу к примеру еще одну фишку: Когда изучал ТКР (ради интереса), то наткнулся на понятие режима боя, реализованно хорошо, но специфично. Попробовал перевести на свой язык СТК такую возможность, оказалось, что у меня это уже запросто осущевствимо через одни только локации и СТК (сам с начало не поверил, но факты сами за себя говорят).
З.Ы.
Скажу для желающих принять участие, помочь сможе только своими вопросами и критикой, так уж сложилось, что писать программы, как у меня получется могут понять не многие и достраивается все окончательно, только когда все перепробую и код пройдет через все возможные варианты (Предаствьте, что я построил 5 раз дом на даче и мне, что-то не понравилось в нем, взял да начал все сначало, только что-то одно отсавил так как есть.). Времени тоже мало(как и у всех в общем), поэтому не так быстро движется разработка, щас работаю над созданием интерпритатора СТК, сложно, но реально (если кому интересно узнать об интерпритаторах и т.д. идите по этой ссылке: http://www.softcraft.ru). Также меня окончательно убедило, при создании данной темы, создать свой сайт на народе с описанием всего о проекте, как создам, ссылку напишу, но не раньше чем, через две неделе. Очень хочется услышать трезвую и коснтруктивную по сущевству критику, так как подобные вещи помогают больше выяснить об потребностях русского движения адвентуры. И не беспокойте, если вам кажется, что я пишу о проекте несколько туманно, все же реализуется в процессе создания.
Естественно это еще не все, будем и остальное, только переварю в нормальный вид.
Неактивен
Присоединяюсь к предыдущим ораторам.
Давай лучше для начала сделаем твою игру на RTADS. %)
Неактивен
Eten,
XML -- язык для описания структурированных данных, TADS -- язык программирования. Чтобы данные, описанные в XML, стали игрой, нужен интерпретатор XML, который знает определенный набор тегов (довольно большой набор, насколько я понимаю).
Автору, чтобы написать игру, нужно знать весь этот набор (или не весь) и знать как интерпретатор эти тэги обрабатывает. Для человека, знакомого пожалуй с любым ООП языком (C/C++/C#, Java, ...) будет проще писать на TADS, поскольку ему достаточно знать язык программирования (+ небольшие особенности синтаксиса языка TADS). Библиотека объектов для TADS написана на TADS и доступна в виде исходников.
Человек, не знакомый ни с одним с языком ООП скорее всего не знаком с концепцией ООП вообще и не сможет ею пользоваться.
Плюс, как уже отметили, для TADS есть отладчик, TADS имеет один из самых мощных парсеров, умеет сам сохранять и восстанавливать игру, и осуществляет вывод в HTML (что открывает определённые возможности).
P.S. Edit: Ели речь идёт только о менюшных квестах, то сравнивать твой проект с TADS большого смысла не имеет. В TADS, пожалуй, самое ценное -- это парсер.
программирование платформы текстовых квестов - задача весьма тривиальная для любого программиста
Alduda,
Если речь идёт не только о менюшных квестах, то я не стал бы делать таких скоропалительных выводов. Разработка нормального парсера, который может правильно разобрать предложение на русском языке, а не простой процедурки, которая выискивает в строке знакомые корни слов, задача отнюдь не тривиальная.
Отредактировано Gremour (25.05.2007 15:23)
Неактивен
HeRmiT написал:
Зачем нам руссифицировать ТАДС ,если можно написать свой движок? И все особенности парсера русского языка написать самому.
Потому что шансы довести свой движок до уровня ТАДС (тем более одному человеку) близки к нулю.
Библиотека для C++ это хорошо, но как ты себе представляешь обработчики действий объектов (реакция на глаголы), которые должен вызвать парсер? ТАДС -- язык программирования и обработчики действий это одна из языковых констукций, которых в языке C++ нет. В C++ можно сделать обход, но выглядеть он будет не очень изящно.
А сохранение состояния игры планируется или нет? А откаты хода?
Вобщем, писать платформы интересно и познавательно, но платформы у нас уже есть. Игр нет.
Неактивен
HeRmiT написал:
Обработка действий - указатель на функцию. Будут стандартные конструкции в каждом классе, надо будет описать шаблонный класс длинамического массива. В С++ можно довольно изящно написать все. Сохранения тоже придумаю. Откат - динамичемкий массив в который заносятся действия игрока, добавляясь по одному. Все это также можно организовать и на STL.
Сделать можно, не спорю. Но на языке TADS использовать это удобнее. Использовать приходится часто, поэтому удобство здесь играет роль. К тому же, для реализации этого нужен определенный механизм, спрятанный внутри базовых классов, который будет затруднять пошаговую отладку.
Для TADS уже есть библиотека стандартных объектов, которую придётся написать самому. Объекты в TADS описываются удобнее, чем в языке C++, для которого нужно описание типа и декларация объекта этого типа.
С какой целью затевать все эти мучения, вот в чём вопрос? TADS есть -- бери и пользуйся.
Что ты подразумеваешь под динамическим массивом? Дерево объектов?
P.S. Хотелось бы увидеть пример описания нового глагола и установления обработчика для него для базового объекта (чтобы работал на всех объектах мира) и переопределения его для определенного объекта (потомка базового).
Отредактировано Gremour (31.05.2007 17:04)
Неактивен
HeRmiT написал:
ТАДС - это ограниченный движок созданный для написания ИФ. Ты не выйдешь за рамки его возможностей. А С++ - язык программирования. На нем можно сделать все.
Возможностей у TADS для написания IF больше, чем у C++. Считай, что это C++, адаптированный под IF. И сделать на нём можно всё, что угодно. Кроме, естественно, задач, не относящийся к IF. Написать веб-сервер или сделать 3D игру, естественно, не получится.
Советую всё-таки обратить на него внимание, написать пробную игру, прежде чем начинать очередную платформу. Хотя бы для того, чтобы сказать мне, каких возможностей языка тебе не хватило.
Отредактировано Gremour (01.06.2007 13:52)
Неактивен
HeRmiT,
На заметку: я по профессии программист и пишу на C++.
Отредактировано Gremour (01.06.2007 14:15)
Неактивен
HeRmiT,
Очень тебя понимаю. У самого такое бывает. Хочется попрограммировать. Но, если бы ты пощупал TADS, может у тебя бы возник энтузиазм написать игру а не баловаться с движком? Это всё ж полезней будет для ИФ коммунити.
Неактивен
HeRmit,
Зачем тебе тогда движок? На C++ пишут программисты, большинство из которых не писатели.
Про функциональность я уже говорил. Меньше удобства -- меньша шансов игре дожить до появления на свет. TADS существенно удобнее для написания IF.
Неактивен
HeRmiT написал:
Вам то что от этого?
Мне лично ничего, я не согласился c твоим высказыванием, только и всего:
HeRmiT написал:
Я с тобой не совсем согласен. Если человек хочет писать - пусть пишет. И надо ему в этом помочь. Зачем нам руссифицировать ТАДС ,если можно написать свой движок?
Человек хочет написать платформу для того, чтобы на ней другие люди писали игры, а не только для себя лично. Начинания похвальные, но где те все люди, которые пишут квесты? Неужели дожидаются завершения СТК?
TADS, кстати, уже русифицирован. Конечно, поддержку русского языка можно улучшить, чтобы не приходилось прописывать все падежи лексическим свойствам объекта, но, насколько я знаю, разработчик платформы Майкл Робертс заниматься этим не собирается (он работает над TADS3), а без него сделать этого не получится. Пока обходимся программкой-генератором падежей, которая очень облегчает эту задачу.
Успехов твоим начинаниям. Надеюсь, что-нибудь из этого выйдет. И автору СТК, тоже.
Отредактировано Gremour (04.06.2007 21:27)
Неактивен
Парсер TADS выполняет одну задачу, однако делает это очень хорошо: разбор правильно построенных предложений (на английском языке; RTADS доработан для разбора русских) в повелительном наклонении, отождествление глаголов и предлогов с действиями, а существительных и прилагательных -- с объектами в игре.
Предложения могут содержать несколько инструкций, местоимения, собирательное "все". Например:
> Достать факел, зажечь его и войти в дверь.
Он уточняет, какой предмет игрок имел в виду, если имеется неопределенность. Например, у нас есть карманные часы, и в комнате на стене висят настенные:
> Снять часы
Какие часы вы имеете в виду, карманные или настенные?
> Настенные
Настенные часы намертво прибиты к стене, после нескольких безуспешных попыток оторвать их, вы бросаете это занятие.
Предлоги в английском участвуют в определении действия (в русском роль предлогов также играют падежи), например, "искать за шкафом" и "искать в шкафу" -- разные действия.
Парсер TADS не делает таких ошибок, которые делают самодельные парсеры, просто выискивающие знакомые шаблоны (корни слов). Он понимает, какие слова в предложении являются глаголами, предлогами, существительными, прилагательными.
Парсер не понимает наречий, но реализовать комадну "сидеть тихо" -- раз плюнуть, если это понадобится (есть несколько вариантов, можно например объявить составное слово "сидетьтихо"). Он не поймёт неправильно составленное предложение "ударить кролику нога", и правильно сделает. Игра выглядит глупо, пропуская такие предложения. В русской версии, правда, из-за обхода (падежи представлены синонимами) предложение "снять майка" (иеется в виду одежда, а не голубой друг нашего персонажа) пройдёт. Это пожалуй, один из двух основных недостатков руссификации (второй -- некоторое неудобство для автора, приходится указывать все падежные формы как синонимы, для автоматизации этого есть генератор падежных форм -- спасибо ГрАнду).
При разборе предложения парсер составляет список предметов, на которые мог ссылаться игрок. Затем из этого списка выбираются кандидаты. Например, для действия "сорвать цветок" не подходят предметы, не находящиеся в комнате, где находится персонаж (или у него в инвентре). Не подходят предметы, которые нельзя сорвать. Если, например, в саду (одна локация) есть железная ограда, деревья, лилии и тюльпаны, в локации рядом -- одуванчики, а у персонажа в инвентаре -- ромашка, то парсер спросит:
> Сорвать цветок
Какой цветок вы имеете в виду, лилию или тюльпан?
Может я еще что-то важное упустил, пусть меня дополнят.
Edit: Ромашку нельзя сорвать не потому, что она не в комнате, а потому что уже сорвана.
Отредактировано Gremour (05.06.2007 14:26)
Неактивен
Да, не упомянул. Возможны действия с двумя предметами:
> Достать из мешка факел, зажечь его и войти в дверь.
Фраза "Достать факел из мешка" будет иметь тот же эффект (правда, в примере выше персонаж попытается поджечь мешок, а не факел).
Парсер автоматом подставляет подразумевающиеся предметы. Если в данный момент у персонажа есть только спички, но нет другого источника огня, парсер автоматом предположит, что поджечь надо спичками:
> Поджечь факел
(с помощью спичек)
Ты чиркнул спичкой и поднёс её к факелу, который жадно подхватил пламя.
Пример использования "все" и "любой":
> Взять цветы
Какие "цветы" вы имеете в виду, лилию, тюльпан, ромашку или одуванчик?
> Любой
Тюльпан: взят.
> Взять цветы
Какие "цветы" вы имеете в виду, лилию, ромашку или одуванчик?
> Все
Лилия: взята.
Ромашка: взята.
Одуванчик: взят.
Можно сразу писать "взять любой цветок" или "взять все цветы".
Отредактировано Gremour (05.06.2007 14:22)
Неактивен
Eten, базы данных уже давно пишут не на C, C++, C# (целиком, наколько я тебя понял), а используют готовые средства работы с базами данных (Interbase, Oracle, ...). И получается гораздо быстрее и менее глючно. :)
Насчёт развития я согласен. После обкатки языка C++ выяснилось много неприятных мест, которые можно упростить и добавить в язык, снизив возможность ошибок (в том числе критических) в разы. Некоторые вещи всё равно делаются всеми программистами заново (велосипеды). Та же работа с памятью.
Есть такой язык программирования D. Вроде я уже о нём упоминал. Очень многие неуклюжие места языка C++ в нём разрешены.
http://digitalmars.com/d/2.0/overview.html
Отредактировано Gremour (28.02.2008 15:35)
Неактивен
Hind написал:
Во-первых, удобная работа с памятью - это не проблема, а большой плюс для программиста на C++. Я точно знаю, как, где и когда выделяет себе и освобождает память моя программа.
Практически любой C++ программист в конечном счёте сталкивается с необходимостью писать свои менеджеры памяти (пулы, сборщики мусора), интеллектуальные указатели и прочую бытовуху, которая, по большому счёту, является низким уровнем.
Этот самый большой плюс языка C++ является самым большим источником утечек и прописей памяти и изрядной доли геморроя для программиста. У нас в коллективе, например, memcpy и memset являются матерными словами (но в тихаря многие ими пользуются, причём неаккуратно).
Я знаю, в Яве вопрос с памятью уже решили, ограничив возможности программиста, но в Яве есть другие нововведения, которые в некоторых случаях неприемлимы.
Почему я упомянул язык D. Его разработчики давно занимаются разработкой C/C++ компилятора и хорошо знают шероховатые места языка (хорошо звучит :). По их признанию, написание полноценного компилятора C++ (который по совместительству и компилятор языка C), отвечающий стандартам языка C++, задача, мягко говоря, нетривиальная и очень хлопотная (более поздние стандарты вводили кучу заплаток на язык; эти заплатки усложняют алгоритм компилятора).
В двух предложениях, D вмещает в себя все хорошие находки языка C++, обходя его недостатки. При этом, сохраняются низкоуровневые механизмы языка C (по словам разработчиков, язык подходит для написания драйвера устройства не хуже, чем C) для тех, кому ОЧЕНЬ надо, но и предоставляются (и рекомендуются) языковые средства, на которых писать высокоуровневые программы гораздо легче (я имею в виду ООП подход). Разработчики уверяют, что эти новые средства интенсивно вылизаны на предмет быстродействия. Сравнивали скорость работы алгоритма, который работает с файлами и строками, реализованного на C++ и на D. C++ (использовалась библиотека std::) проиграл по скорости раза в два.
Если кто пишет на C++ и не читал overview языка, очень рекомендую. Это не реклама. Просто затронуло за живое. %)
Отредактировано Gremour (28.02.2008 17:16)
Неактивен