Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 33
прошу прощения за скомканность поста — у меня праздник ещё не закончился. Вокруг орётся музыка, пьётся пиво и танцуется народ :)
www.mudconnect.com/
Там и исходники есть, и все, что душа пожелает в самых различных направлениях. Это сборничек, так сказать, «текстовых квестов» :)
Там и исходники есть, и все, что душа пожелает в самых различных направлениях. Это сборничек, так сказать, «текстовых квестов» :)
Помоему автору стоит обратить внимание на конструктор который шел вместе в рейнджерами. С помощью того конструктора получались квесты практически любой сложности.
Вывод прежде чем приступать к изобретению велосипеда стоит изучить что до этого было сделано и извлечь соответствующие выводы, а не бросаться на проектирование и получать свои костыли.
Ещё раз повторю исследуйте конструктор с косморейнджеров и возьмите оттуда лучшее.
Вывод прежде чем приступать к изобретению велосипеда стоит изучить что до этого было сделано и извлечь соответствующие выводы, а не бросаться на проектирование и получать свои костыли.
Ещё раз повторю исследуйте конструктор с косморейнджеров и возьмите оттуда лучшее.
А еще клево бы добавить вставку алгоритма для генерации квестовых элементов (пример того, что я имею в виду — генерация случайных 'карт' квеста, математических головоломок с элементами случайности и т.п.)
> Интересно ведь было?
нет. угадай какую глупость задумал автор, одень машу, накопи бабла, убей их всех, собери 100 фантиков — это интересно только беспозвоночным формам жизни.
нет. угадай какую глупость задумал автор, одень машу, накопи бабла, убей их всех, собери 100 фантиков — это интересно только беспозвоночным формам жизни.
Вы играли в космические рейнжеры? Там реально были настолько интересные квесты что аж мозги кипели. Поэтому не стоит понимать под квестами что-то детское и тупое.
Я уже упоминал возможность получения/отдачи вещей. На мой взгляд это значительно расширяет возможности текстовых квестов. Кто играл в квесты вроде «Петьки и Василия Ивановича», тот, думаю, помнит вечную проблему «кому нужно отдать канделябр, чтобы получить презерватив, который в дальнейшем нужно использовать для похода к путане, что владеет важной информацией». Интересно ведь было?
краткий конспект специально для тех, кто не читает сообщения, на которые отвечает:
— как же всё-таки интересно заниматься тупой однообразной деятельностью.
— нет, нифига не интересно.
— зато какое в игре ХХХ описание локаций!
— в любой книжке есть тонны описаний локаций, персонажей и их действий; и чтобы их читать вовсе не обязательно выполнять тупую однообразную работу.
— как же всё-таки интересно заниматься тупой однообразной деятельностью.
— нет, нифига не интересно.
— зато какое в игре ХХХ описание локаций!
— в любой книжке есть тонны описаний локаций, персонажей и их действий; и чтобы их читать вовсе не обязательно выполнять тупую однообразную работу.
Я — безпозвоночная форма жизни. Учту.
делал года 3 назад что-то в этом духе… а сейчас это не сильно актуально и пишется за пару часов на коленке
Расскажу про то, как я делал что то в направлении текстовых квестов. В свое время, когда только начал увлекаться таким языком как C#, меня тоже зацепила мысль создать некий конструктор текстовых квестов (особенно из-за того что нормальных русских квестов просто небыло).
Сначала в голову пришла мысль описывать отдельные объекты (вещи и локации) и как они могут взаимодействовать друг с другом в виде простого xml. Соответственно движок заранее ограничивал возможности взаимодействия объектов, т.е. можно взять предмет и подействовать им на что нибудь, в результате получить другой объект или сменить состояние еще чего нибудь. Была отдельная ветвь в xml которая описывала взаимодействия объектов и результат.
Что бы просто так не тратить время на реализацию, решил практически описать маленький квест. И тогда я понял, что описать некоторые вещи довольно сложно, например для того, что бы сделать бутылку из которой можно было постепенно выливать воду, надо было делать у нее кучу состояний (полная, на треть пустая и т.д.) ну или кучу объектов (полная бутылка, на треть полная бутылка) и описывать их в xml. Ну а про то, что бы сделать более сложные вещи и речи быть не могло (например если у тебя есть факел и ты входишь с ним в темное помещение из темного, то его придется зажечь заново).
Многое из этого можно конечно решить путем расширения заранее возможных случаев (чтобы их можно было описать в xml), но это было довольно плохо, как минимум из-за того что для простого и сложного квеста использовался заранее очень сложный движок, зато теоретически более функциональный.
На этом идея была немного заброшена, но потом (вернемся к C# ;) я добрался до рефлексии. И тогда я решил реанимировать идею с текстовыми квестами, но в более «программистском» исполнении. Смысл движка сводился к определению нескольких интерфесов, чтобы определять локация это или предмет, а так же одному интересному механизму. С помощью рефлекции выбирались все необходимые классы, а потом рассматривались их методы на предмет взаимодействия друг с другом. Т.е. например, если на локации был объект «дверной замок» и у него был метод «открыть» принимающий в параметрах «ключ», то значит объектом «ключ» можно действовать на «дверной замок». При этом происходит взаимодествие именно этих объектов и в коде (который независим от движка) можно написать все что угодно, например замок может открыться, если ключ правильный, или нет, а может даже еще и сломать сам ключ. Возвращение новых объектов или смена состояний третьих объектов происходило за счет генерации определеных событий. Причем с помощью наследования параметров стандартного события можно было расширять возможности.
В итоге движок только взаимодействовал с «игрой» путем анализа всех объектов игры и построения того что с чем можно делать, отображал информацию на экран (через события или вызов определеных методов), сохранял текущее состояние игры (правда для этого надо было чтобы объекты хорошо сериализовывались), ну и принимал команды от пользователя и парсил их (на основе сделаного анализа + немного свое).
Теперь о грустном, на последний пункт движка меня просто напросто не хватило, т.е. легко было сделать прием команды типа:
door open key
но такой вид команды мало вероятно устраивал бы пользователя. Хотя тут наверное не только в послднем пункте проблема была, но и в анализе классов, он тоже немного храмал. Ну и последнее, созданием квеста мог заниматься только программист, а не любой человек, который понимает xml и может создать его в своем любимом текстовом редакторе. Так что идея по большей части осталась идеей, но сам подход использования принципа ООП для описания квеста меня тогда очень радовал :)
P.S. Большой же вышел комментарий, надеюсь интересно было его почитать ;)
Сначала в голову пришла мысль описывать отдельные объекты (вещи и локации) и как они могут взаимодействовать друг с другом в виде простого xml. Соответственно движок заранее ограничивал возможности взаимодействия объектов, т.е. можно взять предмет и подействовать им на что нибудь, в результате получить другой объект или сменить состояние еще чего нибудь. Была отдельная ветвь в xml которая описывала взаимодействия объектов и результат.
Что бы просто так не тратить время на реализацию, решил практически описать маленький квест. И тогда я понял, что описать некоторые вещи довольно сложно, например для того, что бы сделать бутылку из которой можно было постепенно выливать воду, надо было делать у нее кучу состояний (полная, на треть пустая и т.д.) ну или кучу объектов (полная бутылка, на треть полная бутылка) и описывать их в xml. Ну а про то, что бы сделать более сложные вещи и речи быть не могло (например если у тебя есть факел и ты входишь с ним в темное помещение из темного, то его придется зажечь заново).
Многое из этого можно конечно решить путем расширения заранее возможных случаев (чтобы их можно было описать в xml), но это было довольно плохо, как минимум из-за того что для простого и сложного квеста использовался заранее очень сложный движок, зато теоретически более функциональный.
На этом идея была немного заброшена, но потом (вернемся к C# ;) я добрался до рефлексии. И тогда я решил реанимировать идею с текстовыми квестами, но в более «программистском» исполнении. Смысл движка сводился к определению нескольких интерфесов, чтобы определять локация это или предмет, а так же одному интересному механизму. С помощью рефлекции выбирались все необходимые классы, а потом рассматривались их методы на предмет взаимодействия друг с другом. Т.е. например, если на локации был объект «дверной замок» и у него был метод «открыть» принимающий в параметрах «ключ», то значит объектом «ключ» можно действовать на «дверной замок». При этом происходит взаимодествие именно этих объектов и в коде (который независим от движка) можно написать все что угодно, например замок может открыться, если ключ правильный, или нет, а может даже еще и сломать сам ключ. Возвращение новых объектов или смена состояний третьих объектов происходило за счет генерации определеных событий. Причем с помощью наследования параметров стандартного события можно было расширять возможности.
В итоге движок только взаимодействовал с «игрой» путем анализа всех объектов игры и построения того что с чем можно делать, отображал информацию на экран (через события или вызов определеных методов), сохранял текущее состояние игры (правда для этого надо было чтобы объекты хорошо сериализовывались), ну и принимал команды от пользователя и парсил их (на основе сделаного анализа + немного свое).
Теперь о грустном, на последний пункт движка меня просто напросто не хватило, т.е. легко было сделать прием команды типа:
door open key
но такой вид команды мало вероятно устраивал бы пользователя. Хотя тут наверное не только в послднем пункте проблема была, но и в анализе классов, он тоже немного храмал. Ну и последнее, созданием квеста мог заниматься только программист, а не любой человек, который понимает xml и может создать его в своем любимом текстовом редакторе. Так что идея по большей части осталась идеей, но сам подход использования принципа ООП для описания квеста меня тогда очень радовал :)
P.S. Большой же вышел комментарий, надеюсь интересно было его почитать ;)
А через интерфейсы никак нельзя было реализовать взаимодействие «ключ-замок»? Мне кажется не обязательно лезть в Reflection чтобы это сделать.
Тут идея в том, что класс — это объект мира игры, а метод — это действие над ним, возможно путем использования другого. Например можно просто попытаться открыть дверь — это метод open без параметров, а можно используя ключ — если есть перегруженный метод принимающий объект ключ, или вообще есть метод от нескольких параметров.
К тому же не в каждой игре будет объект ключ или дверь, ну или в разных квестах этот ключ реализуется по разному, другими словами движок не имеет никаких заранее предопределенных объектов. И для него дверь и ключ — это просто объекты которые могут взаимодействовать на основе методов. Скажем так, такой важный элемент как инвентарь — тоже может быть отдельным классом и за счет этого можно делать интересные вещи, например ограничение по весу, или обыграть случай когда кладешь туда протекающую бутылку с водой — важный код с листочка бумаги стирается ;)
К тому же не в каждой игре будет объект ключ или дверь, ну или в разных квестах этот ключ реализуется по разному, другими словами движок не имеет никаких заранее предопределенных объектов. И для него дверь и ключ — это просто объекты которые могут взаимодействовать на основе методов. Скажем так, такой важный элемент как инвентарь — тоже может быть отдельным классом и за счет этого можно делать интересные вещи, например ограничение по весу, или обыграть случай когда кладешь туда протекающую бутылку с водой — важный код с листочка бумаги стирается ;)
Почти как статья)
>По-хорошему массив со итемами игрока нужно хранить в кэше по ключу связанному с id пользователя — но для такого дела надо брать как минимум vps.
Чего это вдруг? Для таких объемов данных вам shared хостинга надоооолго хватит.
Чего это вдруг? Для таких объемов данных вам shared хостинга надоооолго хватит.
сайт такой нужен. сейчас ссылку другу кину на топик…
на LOR пробегала новость про такой конструктор, можно в целях ознакомления поинтересоваться.
Сайт интересен только с точки зрения энтузиазма и собственного развития. Как проект не пойдет, аудитория в основном потребители, их нужно развлекать, они тоже готовы развлекать но не напрягаясь. Что бы сделать хороший квест нудно и талантом обладать и напрягаться. Поэтому не рассчитывайте на то, что у Вас получится востребованный стартап.
неужели я один вспомнил про ifwiki.ru?
Можно попробовать математический подход, определить сеть узлов и переходов, определить набор состояний системы и определять вероятность переходов исходя из этих состояний (количества денег у героя, например), а также систему триггеров меняющих состояния и/или сеть, что даст необходимую гибкость. Таким образом можно будет размазывать одну локацию на множество узлов, а узел не будет обязан быть только локацией. Таким образом можно будет свести объединить диалоги и путешествия в одной структуре, что уменьшит объём кода и трудоёмкость поддержки.
Иначе можно рисковать столкнуться с теми же проблемами, что имели разработчики Зорка когда им нужно было сделать воздушный шар, который был «комнатой»(локация в их терминологии) и должен был одновременно перемещаться по другим «комнатам».
Иначе можно рисковать столкнуться с теми же проблемами, что имели разработчики Зорка когда им нужно было сделать воздушный шар, который был «комнатой»(локация в их терминологии) и должен был одновременно перемещаться по другим «комнатам».
Начали бы вы сначала со своего квеста. Поняли бы что на самом деле нужно квестостроителям. А сейчас вы только напридумываете фукциональность, которая вам кажется логически правильной. А когда начнут на вашем движке квесты делать, будут плеваться…
Спасибо за то, что есть интерес к текстовым квестам!
Я сейчас далеко отошел от этого. Однако я до сих пор хостю сайт про платформу для разработки текстовых адвенчур на TADS для русского языка. Там есть живое коммунити. Приглашаю посмотреть:
www.rtads.org
Можно брать и разрабатывать довольно богатую адвенчу.
Я сейчас далеко отошел от этого. Однако я до сих пор хостю сайт про платформу для разработки текстовых адвенчур на TADS для русского языка. Там есть живое коммунити. Приглашаю посмотреть:
www.rtads.org
Можно брать и разрабатывать довольно богатую адвенчу.
На тему интерактивного сюжета мне попадалась занятная статья:
Master's Thesis: Mediating User Interaction in Narrative-Structured Virtual Environments
В которой предлагаются методы, в том числе — обхода «тупиковых квестов».
А в общем случае — адаптирование сюжета к действиям игрока, чтобы он не сбивался с задуманной сюжетной линии.
Master's Thesis: Mediating User Interaction in Narrative-Structured Virtual Environments
В которой предлагаются методы, в том числе — обхода «тупиковых квестов».
А в общем случае — адаптирование сюжета к действиям игрока, чтобы он не сбивался с задуманной сюжетной линии.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Любителям текстовых квестов. Конструктор.