Автор: Эмили Шорт
Ссылка: http://ifprint.org/articles/needparser1/

Перевод статьи публикуется с разрешения Эмили Шорт (ссылка на оригинал: http://emshort.wordpress.com/2010/06/07/so-do-we-need-this-parser-thing-anyway/)

…или: Что значит писать интерактивную литературу?

Когда меня спросили о способах популяризации ИЛ на PAX East, я сказала следующее:

У парсерных игр есть проблема. Даже целых две.

Одна проблема — это интерпретатор: люди не хотят скачивать разрозненные файлы и не хотят разбираться в форматах файлов. Такой подход не слишком привлекателен и абсолютно не соответствует тому, как люди сейчас привыкли играть в игры — и, в особенности, тому, как новые игры пытаются привлечь к себе внимание игроков. Мы (как сообщество) работаем над этой проблемой, разрабатывая все более качественные интерпретаторы для веб и упрощая процесс публикации игр на веб-сайты. Это неправда, что не существует Java версии Glulx, однако этот интерпретатор тоже необходимо скачивать и, к сожалению, он не предоставляет возможности создать привлекательнo выглядящую игру в браузере. В последние несколько месяцев можно наблюдать серьезные подвижки на этом фронте — Quixe и ZMPP уже достигли той стадии, когда они могут исполнять Glulx игры непосредственно в браузере. Zifmia — это проект, позволяющий исполнять игры в веб с помощью серверного интерпретатора, а FyreVM представляет собой эксперимент на основе системы Channel IO. Для TADS 2 есть Jetty, и Майк Робертс активно работает над изменениями в TADS 3, которые позволяют запускать игры на этой платформе как веб-сервисы. В общем, у нас здесь неплохой прогресс.

Вторая проблема — это сам парсер. Когда вы наблюдаете за реакцией новичков на интерактивную литературу — что несложно делать по отзывам на ИЛ на посвященных инди-играм сайтах или по впечатлениям студентов, играющих в ИЛ впервые, — то все, что вы как правило видите — это глубокое разочарование парсером. Первые несколько (или несколько дюжин) ходов новичка в игре обычно состоят из множества неудачных попыток сделать хоть что-то, и все эти ходы, конечно же, никак не продвигают игру вперед.

Это совершенно чуждо большинству игроков в наши дни. Сейчас даже довольно сложные консольные игры обычно гарантируют, что по крайней мере в начале игры практически невозможно сделать что-либо неправильно и, тем более, потерпеть сокрушительную неудачу в попытках освоить игровую механику. Игровая механика приоткрывается постепенно. При этом большинство текстовых игр не имеют ни режима обучения, ни какого-нибудь введения, предлагая вместо этого (да и то, в лучшем случае) лишь длинное меню инструкций. Есть исключения («Dreamhold», «Blue Lacuna»). Моя собственная маленькая игра включает в себя необязательный режим обучения (я предпочитаю считать его чем-то вроде тренировочного уровня сложности), который дает пошаговые контекстные советы игроку, основываясь на том, что происходит в настоящий момент времени.

Мне, правда, неизвестно, насколько преуспели все эти игры в миссии по привлечению игроков к интерактивной литературе (я просто не знаю это — я бы с удовольствием послушала историю о том, как благодаря какой-нибудь «Blue Lacuna» целая толпа людей открыла для себя текстовые игры).

У нас есть однако и куда более фундаментальная проблема, которая заключается в том, что командная строка лжет. Она говорит игроку — «напечатай что-нибудь, а я это пойму». И при этом не понимает.

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

Adrift частично основан на распознавании по маске (wildcard) и, благодаря этому, способен принять большее количество вводимых пользователем команд, чем TADS или Inform, однако результатом зачастую является комическое непонимание того, что на самом деле хочет игрок, так как парсер не учитывает множество важных нюансов. Более продвинутые системы анализа естественных языков также нередко разочаровывают пользователей, когда либо не выполняют то, что от них ожидается, либо выполняют это так, что становится непонятно, какое именно влияние на игру оказали предпринятые действия («Starship Titanic», «Façade»). Я (вместе с другими членами нашего сообщества) спорила несколько месяцев назад с Брайаном Мориарти о том, нужны ли текстовым играм продвинутые системы анализа естественных языков. С тех пор мое мнение несколько изменилось, однако я по-прежнему считаю, что Мориарти заблуждается, когда считает, что ИЛ-сообщество не заинтересовано в улучшениях в парсере, и я по-прежнему в основном придерживаюсь высказанной точки зрения о том, что системы анализа естественных языков не очень хорошо подходят для игр. Многие, конечно же, все равно работают в этом направлении. Но я считаю, что даже парсер, который гораздо лучше справляется с разбором пользовательского ввода все равно создает значительные проблемы для гейм-дизайнера, если он начинает принимать выражения, которые требуют гораздо большей проработки игрового мира, чем в действительности нужно самой игре.

Именно поэтому работа над парсером в основном сфокусировалась в нескольких областях: лучше угадывать, что именно хочет игрок, не запрашивая дополнительную информацию (т.е. не спрашивая игрока, хочет ли он открыть дверь черным ключом или черным эклером); производить более качественный разбор ошибок ввода и, соответственно, выводить более вразумительные сообщения об ошибках. Аарон Рид провел некоторые исследования в этой области и предложил свои корректировки для Inform-а в виде набора расширений, воспроизводящих то поведение, которое он реализовал для своей «Blue Lacuna».

Но в конце концов я согласна с Майком Робертсом, что задача вовсе не сводится к тому, чтобы заставить парсер понимать все, что может ввести новичок, так как среднестатистический игрок в ИЛ, недавно открывший для себя этот жанр, предпочтет интеллектуальному парсеру более компактный словарь глаголов, который к тому же будет ему заблаговременно известен.

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

Это помогло бы и с другой проблемой, с которой часто сталкиваются новички — своего рода параличом выбора. Если ты можешь совершить любое действие, ввести любую команду, то с чего, собственно, нужно начинать?

Вот такие дела, да. Командная строка — это проблема.

* * *

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

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

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

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

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

Так что же теперь? Должны ли мы отбросить парсер и перейти к другим системам, где возможности игрока явным образом описываются в виде списка?

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

Но и этот способ далек от идеала. Если я играю в текстовую игру, то предпочитаю, чтобы окно, в которое текст выводится, не было сдвинуто к самому краю экрана, уступая место картинкам, компасам и прочим подсказкам. Это некрасиво — а еще это представляет собой тот самый тип пользовательского интерфейса, который сейчас стремительно уходит из моды. Все больше и больше игр в коммерческом секторе вообще убирают все эти бесчисленные элементы управления, стараясь не захламлять экран, на котором происходит основное действие.

* * *

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

Когда люди говорят о CYOA, они имеют в виду игры, в которых игроку предлагается список четких действий («Чтобы пройти через дверь слева, перейдите на страницу 51. Чтобы пройти направо, перейдите на страницу 75. Чтобы выпрыгнуть в окно, перейдите на страницу 9»).

CYOA также зачастую ассоциируется со своей ранней реализацией в книжном виде — Выбери свое собственное приключение (Choose Your Own Adventure), от которой и пошла эта аббревиатура. Книжные CYOA либо заставляют игроков вести заметки (и верят в их честность), либо вообще отказываются от какого-либо моделирования мира и состояния, кроме того, что может быть отражено в номере книжной страницы. Некоторые компьютерные CYOA также исповедуют этот подход, представляя собой игры без состояния и моделирования мира.

Это ведет к большим проблемам при построении сюжета.

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

В плане структуры это не сильно отличается от самого простого гипертекста. Литературный гипертекст часто предлагает схожую, лишенную состояния модель, хотя и подходит к ее созданию с несколько иных позиций. Впрочем, некоторые платформы для литературного гипертекста идут дальше, предлагая (к примеру) специальную систему ссылок, которые становятся доступными, только если вы уже видели какой-то другой контент.

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

* * *

Однако «менюшные» игры с моделированием мира тоже существуют. Мое (пока бездоказательное) впечатление заключается в том, что последнее время они становятся все более и более популярными. (На самом деле меня даже попросили написать обзор одного сайта, посвященного подобным играм: это «Неизвестные истории», однако я пока что ничего не могу сказать о нем, так как была занята написанием этой статьи…).

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

Серия текстовых игр «Выбор…» пользуется некоторой популярностью у казуальных игроков, используя модель, при которой развитие протагониста в игре отражается через специальную статистику, хотя сами игры сконцентрированы (согласно их же собственному манифесту) на том, чтобы игрок принимал «интересные решения». (Я думаю, Крис Кроуфорд поддержал бы этот подход, но, возможно, не остальные элементы тамошнего геймплея).

«Echo Bazaar» певернул эту модель: он целиком полагается на «статы» и заставляет игроков много заниматься «гриндингом» — т.е. постоянно совершать одни и те же действия, чтобы эти «статы» поднять, — однако предлагает при этом и большое количество побочных историй-приключений, в которых игрок может принять участие (причем некоторые из этих приключений также включают в себя интересные развилки, где определяется сюжет истории). В «Echo Bazaar» многое зависит от статистики вашего персонажа; игра также сохраняет информацию обо всех «квестах», в которых принимает участие игрок. А еще в «Echo Bazaar» есть инвентарь, деньги и ограниченное взаимодействие с другими игроками, благодаря чему «Echo Bazaar» кажется куда больше похожим на игру, чем типичный представитель сериала «Выбор…». Платой за это является серьезное ослабление повествовательной части и то, что игрокам приходится выполнять одни и те же утомительные действия.

Однако ни у серии «Выбор…», ни у «Echo Bazaar» не получается добиться того, что мне хотелось бы видеть в идеале. «Echo Bazaar» слишком медленный и слишком полагается на «гриндинг», тогда как я предпочла бы более сильную повествовательную часть. Играм серии «Выбор…» не хватает того погружения, за которое я ценю интерактивную литературу, так как они не дают действительно почувствовать изменения своего персонажа, глубже понять мотивы, на которых основываются решения. Однако и «Выбор…» и «Echo Bazaar» гораздо, гораздо ближе к идеалу, чем CYOA без моделирования мира.

Возможно, кстати, что большой интерес к «менюшным» играм в ИЛ-сообществе объясняется не только «духом времени», но и, не в последнюю очередь, популярностью «Выбора…» и «Echo Bazaar».

* * *

Это однако не означает, что CYOA игры совсем потеряли свою актуальность. В IFDB можно найти 43 таких игры, и наверняка это не полный список игр, исповедующих подобную модель и представленных ИЛ-сообществу и/или реализованных на какой-либо ИЛ платформе. (Это, конечно, не исчерпывающая коллекция всех компьютерных CYOA, однако ИЛ-сообщество имеет склонность не замечать или не обращать внимание на все, что не было сделано с использованием популярных ИЛ платформ, либо не было представлено на каком-нибудь конкурсе).

Платформа «Книга приключений» Джона Ингольда позволяет создавать CYOA с моделированием мира и инвентарем, и сейчас есть официальное расширение для Inform 7, которое по сути воспроизводит эту систему.

В течение нескольких лет также проводился Lotech comp, соревнование исключительно для CYOA игр. Две игры из этого конкурса особенно интересны в контексте нашего текущего разговора — это «Одна неделя» Папиллона и «Королевство без конца» Шэннон Кочран.

«Одна неделя» — это игра по управлению ресурсами с сильной моделью мира, которая близка к симуляторам свиданий и виртуальным новеллам, в которых действия игрока определяют, сколько времени протагонист потратит на зарабатывание денег, общение с людьми и обучение, что в конечном счете влияет на всю историю.

«Королевство без конца» использует движок «Книги приключений», чтобы создать нечто такое, что больше всего напоминает традиционную парсерную ИЛ — игрок может совершать привычные для таких игр действия (передвигать предметы, подбирать вещи), что позволяет создавать головоломки в духе самых настоящих «парсерок», однако с гораздо более ограниченным диапазоном возможных действий.

* * *

Критика «менюшных» игр часто основывается на том, что они фактически уничтожают саму возможность создавать головоломки. Если игрок всегда выбирает из списка опций, то ему и решать в действительности ничего не нужно, правда?

Но в реальности я не считаю, что это такая большая проблема, как некоторые думают — мы говорили об этом на нашей апрельской встрече в Сиэтле. Если за вашим «меню» стоит стройная и непротиворечивая модель игрового мира, то и в «менюшной» игре можно будет сделать то же самое, что и в парсерной: совершать выбор, изменяющий мир так, что появляются новые возможности для выбора.

На мой взгляд, наиболее серьезной проблемой является то, что «менюшные» игры сужают поле взаимодействия игрока с игрой. В среднестатистической ИЛ игре можно найти дюжины глаголов и сотни существительных, и все это складывается в непомерное множество возможных действий. В «менюшном» стиле представить такое количество команд попросту невозможно, в противном случае интерфейс подобной игры будет находиться где-то за гранью добра и зла. И хотя я до этого жаловалась на ту работу, которую приходится выполнять, чтобы научить парсер давать вразумительные ответы на невразумительные действия игрока, мне вовсе не хочется значительно сужать диапазон возможных действий в своих играх.

Наличие большого количества глаголов — это отличительная черта ИЛ, и это наполняет интерактивную литературу повествовательной глубиной. Количество действий, которые вы можете совершить, к примеру, в «Halo» совсем не велико — и это имеет прямой эффект на то, какие именно истории вы можете рассказывать с помощью подобной системы. Консольные игры вообще можно считать в каком-то смысле «глагольными», хотя бы на основе того, как именно они демонстрируют игроку все его игровые возможности — вы всегда держите в руках игровой контроллер с довольно-таки небольшим количеством кнопок на нем, и всегда есть эти индикаторы на экране или тренировочные миссии, которые помогают вам разобраться, с каким именно глаголом связана та или иная кнопка.

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

В этом плане ИЛ ближе к игре «Sims 3»: здесь есть мир с большим количеством различных объектов (существительных), с каждым из которых могут связаны определенные действия. Так, двери в ИЛ могут быть открыты, лампы зажжены; в «Sims 3» телевизор можно использовать, чтобы заниматься тренировкой по аэробике или же смотреть видео-фильмы.

Другая проблема заключается в том, что когда я просто щелкаю мышкой или каким-либо иным образом выбираю нужный вариант из списка действий, я по какой-то причине чувствую себя менее вовлеченной в игровой процесс. Я не знаю, почему это так, но это так. Меня вполне устраивает щелкать по картинкам или радиальным меню в «Sims 3», но ведь в этой игре весь интерфейс тоже графический. Есть что-то привлекательное в том, чтобы общаться с компьютером на том же самом «языке», на котором он общается с тобой.

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

Но все-таки я считаю, что нужно сделать интерактивную литературу более доступной для игроков.

В некоторых играх вполне работает графический интерфейс c меню или кнопками для глаголов — Дэйв Корнельсон недавно предложил некоторую вариацию такого подхода, — но во многих случаях игры, оформленные подобным образом, выглядят довольно-таки уродливо, и всевозможные подсказки и кнопки занимают слишком много полезного места на экране. Мне лично некомфортно читать текст, когда текст этот помещен в маленькое окошко, которое сдвинуто в самый угол экрана. Более того, довольно сложно представить, как подобный перегруженный интерфейс будет работать на мобильных устройствах. (Добавлено: Дэйв утверждает, что нам пока что неизвестно, как все эти вещи проявят себя в реальности, и он, конечно же, совершенно прав — все, что я здесь пишу, представляет собой лишь мое частное мнение, а не указания для других по поводу того, что им стоит делать. Однако лично меня это решение с интерфейсом не устраивает).

Другой подход заключается в том, чтобы оставить визуальные подсказки, однако интегрировать их непосредственно в сам текст. «Бронза» и «Blue Lacuna» подсвечивают в тексте (жирной гарнитурой или цветом) важные существительные. «Blue Lacuna» идет дальше и позволяет игроку вводить лишь сами существительные без глаголов, чтобы совершить наиболее очевидные действия с ними (например, рассмотреть объект или пройти через дверь). «Walker and Silhouette» делает еще один шаг вперед и практически полностью управляется с помощью таких вот ключевых слов без каких-либо глаголов, хотя и позволяет игроку вводить что-либо, кроме ключевых слов, если он сам того пожелает.

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

Еще один подход — это делать подсказки, однако разрешать игроку набрать все, что он хочет, а не только предлагаемую команду. Именно в таком ключе реализован тренировочный режим «Бронзы». Также, в немного измененной форме, работает и игра Джона Ингольда «Мертвые города», предоставляя и командную строку и самую простую гиперссылку, кликнув на которую, можно ввести предлагаемую команду. Разница между этими играми (помимо, собственно, интерфейса) заключается в том, что «Мертвые города» предоставляют по сути «солюшен» для игрока, через который можно прокликать, при этом ни разу не введя команду вручную и рассматривая игру скорее как обычную книгу (хотя я подозреваю, что наиболее интересные игровые ситуации таким образом не откроются). («Черные кольца» также исповедуют этот подход, позволяя игроку выбрать режим — от традиционного парсерного до простого просмотра прохождения игры).

Есть и такой вариант — предоставлять что-то в стиле диалоговых подсказок на манер TADS 3/Alabaster, однако делать это для всех действий. К сожалению, это нарушает ритм игровой прозы, прерывая повествование механическими инструкциями и опциями для дальнейших действий, гораздо менее интересными и разнообразными, чем они обычно выглядят в игре. Я не представляю, как подобная система может оказаться приемлемой.

* * *

У меня нет полного и окончательного решения для этой проблемы, однако есть некоторые мысли, которыми я хотела бы поделиться.

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

С другой стороны, в типичной парсерной игре мы в принципе не можем отображать все возможные варианты действий игрока в заданный момент времени, не превратив игровой интерфейс в уродливое нагромождение кнопок. Даже просто перечислить список всех глаголов — это не слишком привлекательное решение и, как я уже говорила ранее, не лучший способ подойти к решению этой проблемы, так как интересное пространство игровых возможностей лучше описывается через существительные (и те взаимодействия, которые они позволяют), а не через глаголы. (Есть несколько исключений — смотреть, инвентарь — однако все эти вещи можно рассматривать как действия над игроком или над комнатой, в которой он находится. Inform делает внутреннее преобразование «без-объектных» команд слушать и нюхать в слушать {звуки в текущей комнате} и нюхать {запахи в текущей комнате}).

Если бы у нас была система, в которой игрок может выбрать существительное, посмотреть список действий, которые он может с ним совершить и выбрать одно из этих действий, то это (в стиле игры «Sims») прояснило бы игроку его возможности и одновременно позволило бы нам избавиться от проблемы с потрогать луну.

Реализация такого подхода в графическом ключе имеет однако некоторые сложности. Одно дело кликнуть по картинке телевизора в «Sims» и открыть радиальное меню. Совсем другое — кликнуть подсвеченное слово на странице и получить радиальное меню с еще большим количеством слов. А что делать в случае, когда то или иное существительное подразумевается в текущий игровой момент, однако явно ни в одном из описаний не упомянуто? Это заставляет игрока набирать осмотреться и инвентарь гораздо чаще, чем ему бы хотелось, что не слишком позитивным образом влияет на игровой процесс и повествование. Наконец, это не совсем то, что текущие интерпретаторы умеют хорошо делать (и, соответственно, предполагает серьезную разработку новых инструментов), и мне не совсем понятно, как все это может работать для пользователей с нарушением зрения.

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

Вообще я думаю следующее: делайте так же, как сделал Джон Ингольд для повествовательного режима «Моего ангела» и переносите командную строку в отдельное окно, которое обновляется при каждом шаге. Оставьте место в основной части экрана только для игрового вывода. Тогда набор существительного (или щелчок по этому существительному непосредственно в тексте, если гиперссылки у нас тоже работают), будет приводить к открытию окошка автодополнения там, внизу, в отдельной области для текстового ввода, и игра не будет показывать вам всю историю вводимых вами команд.

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

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

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

Можно дальше совершенствовать эту систему, сортируя список глаголов так, чтобы сначала показывались наиболее очевидные и часто используемые опции. Можно сделать и по-другому — дать игроку возможность вводить глагол, а затем показывать список объектов, с которыми этот глагол будет работать, так, чтобы привыкший к традиционным «парсеркам» игрок мог бы набирать по старинке открыть дверь вместо дверь открыть, и попросту не давать возможности выбрать глагол (или объект), которые недоступны на текущей сцене.

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

Здесь вы можете найти очень грубый прототип того, о чем я говорю.

Система, подобная этой, способна полностью устранить игру в «угадай глагол», хотя и за свою цену — те ситуации, в которых мы как раз и хотим, чтобы игрок угадал глагол (например, покрутить усы) станут невозможными. Что-то, бесспорно, будет потеряно.

* * *

Однако только представьте себе — нет больше никаких потрогать луну. Не нужны интеллектуальные системы, помогающие разбираться с неоднозначностями пользовательских команд и предоставлять реакции на действия «по умолчанию». Мы можем вводить новые действия и глаголы совершенно прозрачно даже для новичков в ИЛ — такие как шантажировать, анализировать или сопротивляться. Мы можем отойти от строго физической природы текстовых игр и делать интерактивными более абстрактные существительные и идеи. У нас появляются прямые пути к организации более систематичного бета-тестирования. Гораздо меньше проблем и ловушек для авторов-новичков. Более гибкая и удобная система, благодаря которой написание больших игр перестает быть таким обременительным.

Не знаю, я сошла с ума?

btimofeev> Прошел сейчас эту игру: какая-то странная концовка, незавершенная. В игре "Лифтер 2" раскрывается тайна?

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

> Прошел сабж. Игра сделана очень хорошо: великолепный текст, музыка, оформление, все на высшем уровне. Концовку правда я ожидал несколько иную.

Если понравился сабж, то рекомендую и другие игры Василия: "Переход" и "Лидия". Игры у него сильные, интересные и достаточно длинные.

> Теперь попробую пройти квантового кота, когдат-то давно я в нем застрял и забросил.

А вот игры Петра хороши, хотя и сложны порой весьма.

btimofeev> А я тут наткнулся на игру "Лифтер 3. История 1. Тима". Это не продолжение? Ночью на работе попробую поиграть.

Это продолжение, но в такой минималистичной дозе, что ответов не даёт. Жека обещал его развить в масштабную игру навроде второй части, но переехал в Киев и устроился мидлом куда-то. Теперь редко к нам заходит.

Это нарезка с форума, где Пётр описывал особенности нового стека движка Instead.
----

== Объявление объектов в stead3.

obj {
    nam = 'яблоко';
}

Вроде, похоже на stead2? Да, но есть важные отличия.

nam может быть только строкой. Он не может быть функцией. Не может быть булевым значением. Только строка. nam -- однозначный и достаточный идентификатор объекта. Что это значит? После того как вы создали объект, вы всегда можете получить к нему доступ с помощью:

std.ref 'яблоко' или (более кратко) std 'яблоко' или (еще более кратко) _'яблоко'

То-есть, можно написать что-то вроде: _'яблоко'.variable = true

Если вам нравится старый стиль, как это было в stead2, вы можете сделать ссылку при объявлении:

apple = obj {
    nam = 'яблоко';
}
apple.variable = true

Или получить временную/постоянную ссылку позже:

apple = _'яблоко'
local a = _'яблоко'

В обработчике вы можете сопоставить объект его имени просто:

use = function(s, w)
    if w/'яблоко' then p [[Я откусил яблоко.]] end
end

Или, конечно, так:

use = function(s, w)
    if w == _'яблоко' then p [[Я откусил яблоко.]] end
end

Итак, nam стал единственным идентификатором. Для отображения объекта в инвентаре используется он-же, или, если вы задали disp -- то disp. disp уже может быть и строкой и функцией (впрочем, как это было и раньше).

При размещении объектов в списках (в комнатах, например) мы используем имя объекта, то -есть:

obj {
    nam = 'яблоко';
}
 
room {
    obj = { 'яблоко' };
}

Вы можете не задавать nam у объекта (или комнаты), при этом имя будет сгенерировано автоматически в виде цифры. Это удобно для деккораций или динамически создаваемых объектов.

Имена объектов должны быть уникальными. Если вы создадите еще один объект с тем-же именем, вы сразу же получите ошибку.

Но иногда нет смысла именовать объект руками. Например, когда мы создаем его прямо в сцене:

obj {
    nam = 'main';
    obj = {
        disp = 'стол';
        dsc = 'тут стоит стол';
    }
}

Или у нас очень много однотипных объектов, типа фраз в диалоге. Мы же не собираемся каждой фразе давать уникальное имя? Если мы не зададим имя, движок сам создаст числовой индекс для такого объекта, но пользоваться им неудобно. Для таких случаев предусмотрены теги. Тег - это строка, которая начинается с символа # (таким образом в коде игры всегда понятно о чем мы говорим, о тегах или именах). Теги не обязаны быть одинаковыми, но они должны быть уникальными в пределах комнаты (вернее говоря, просто при поиске по тегу мы найдем 1-й такой объект).

obj {
    nam = 'main';
    obj = {
        tag = '#стол';
        -- nam = 'имя стола'; -- мы могли бы дать имя стулу, но зачем?
        dsc = 'тут стоит стол';
    }
}

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

obj {
    nam = 'main';
    obj = {
        nam = '#стол'; -- на самом деле мы задали тег, 
                              -- который может мыслится как локальное имя
        dsc = 'тут стоит стол';
    }
}

При этом, в качестве отображения в инвентаре используется disp, если его нет, то тег, с убранным первым символом #. Большинство функций STEAD3 умеют работать как с тегом, так с именем, например:

walk '#переход1'

Будет искать объект с тегом #переход1 среди доступных переходов.

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

Говоря об объектах, нужно еще сказать, что в room появился новый атрибут -- title. Теперь disp (или tag/nam) используется для показа названия перехода в эту комнату, а title -- становится названием комнаты, когда мы в нее перешли. Если title не задан, то стандартная схема disp/tag/nam.

== Про переменные.

В stead3 вам не нужно определять переменные объекта, которые вы хотите сохранить, через var {}. В stead2 было так:

apple = obj {
    nam = 'яблоко';
    var { eaten = false }; -- сохранится
    _red = true; -- сохранится, так как начинается с символа _
}

В stead3:

obj {
    nam = 'яблоко';
    eaten = false;
}

eaten сохранится, если в процессе игры значение этой переменной менялось.

То-есть, если где-то в коде было _'яблоко'.eaten = true, то такая переменная сохранится.

Если где-то в коде есть _'яблоко'.newvar = 1, то такая переменная тоже сохранится (создание переменных на лету).

UPD: По результатам обсуждения решили, что по умолчанию создание переменных на-лету запрещено. Все переменные должны быть объявлены заранее. Если вы не указали std.nostrict = false в начале игры. :) Либо, для добавления переменных на лету используйте:

apple 'variable' (10) -- создали переменную на-лету

Есть только определенная особенность с таблицами. Дело в том, что таблица будет сохранена в save если к ней в процессе игры был доступ хотя бы на чтение.

obj {
    nam = 'яблоко';
    tabl = { 1, 2, 3}; -- будет сохранена, если к таблице были обращения
}

Это сделано из-за того, что модификации внутри таблицы сложно отследить (без лишнего усложнения кода движка), поэтому таблицы сохраняются целиком. Но что если вы не хотите, чтобы таблица (или переменная) попадала в save файл? Тогда придется написать так:

obj {
    nam = 'яблоко';
   {   -- блок переменных, за которыми не следит instead
        tabl = { 1, 2, 3}; -- не будет сохранена
        x = 8; -- не будет сохранена
    }
}

Что с глобальными переменными?

В stead3 теперь отслеживается доступ к неинициализированным переменным. Таким образом, описки в именах переменных, обращение к несуществующей переменной -- сразу дадут ошибку. Присвоение неинициализированных переменных разрешено только если:

значение - это объект
значение - это функция

Всего теперь есть три вызова:

global -- объявление глобальной переменной
const -- объявление константы (стед3 сдедит за тем, чтобы переменная не менялась)
declare -- объявление переменной, за которой не следит stead3

Форма записи допускает следующие варианты использования:

Как раньше:

declare {
   a = 1,
   b = 2, 
...
}

Или одиночное объявление:

declare 'myfunc'  (function() pn "Hello!" end)
global 'X' (11)

Все формы объявлений контролируют уникальность имен переменных. Вы не сможете создать две переменные с одинаковыми именами.

Для чего нужен global и const -- понятно. Но зачем declare?

В stead2 единственным способом записать функцию в save была конструкция code [[ ]]
В stead3 такой конструкции нет. Зато тут можно объявлять функции!

declare 'myfunc' (function() pn "Hello!" end)
global 'X' (myfunc)

X сохранится и в save будет записана ссылка на функцию! Так что, теперь вместо code можно декларировать функции. Но это можно делать только заранее, в глобальном контексте игры, примерно как определяются объекты/комнаты.

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

Что с динамическими объектами?

У нас есть new, но прототип теперь другой. В качестве иллюстрации, напишу пример:

declare 'mycat' (function(nam)
    return obj { nam = nam; dsc = 'Тут сидит котик!' }
end)

где то в недрах игры:

act = function(s)
    p [[Я взял еще одного котика.]]
    take(new(mycat, "Барсик"))
end

Как видим, теперь new принимает на вход не текст, а задекларированный конструктор и параметры к нему в виде параметров функции.

== Как работают ссылки?

Варианты использования:

dsc = "Тут лежит {яблоко}"

Это, как и в 2.4, следующий вариант --- аналог xact:

dsc = "Тут лежит {яблоко} и {груша|сладкая груша}. А еще {#неведомая штука|странный предиет}"

Это ссылка на другой объект. Если ссылка неверная, будет ошибка. Объект должен быть доступен игроку (быть в зоне видимости).

И, наконец, вариант с ссылкой на системный объект. В stead3 есть понятие системных объектов. Такие объекты не уничтожаются и существуют весь цикл игры. Их имена начинаются на '@'. Например, \@timer, \@sound, \@sprite и тд.

Так вот, можно создавать ссылки на системные объекты. При этом не обязательно, такой объект должен находиться в комнате. Например:

dsc = "Нажми на {@button|кнопочку}"

При этом вызовется act объекта button. Системные объекты могут получать параметры. Так, в stead3 уже есть стандартный объект с именем @, который удобно использовать как обработчик xact, например:

xact.walk = walk -- переход
dsc = "Идем {@ walk room2|вперед}

То-есть, берем объект @, у него вызываем act, передаем параметры walk и room (строки в данном случае). Стандартный обработчик _'@'.act действует сл образом -- находит метод, который совпадает с именем 1го параметра и вызывает его. Таким образом объект @ выполняет функции, которые выполнял модуль xact в stead2
При передаче параметров действуют соглашения:

Если это строка вида "something" -- идет как строка.
Если это число 1234... true или false -- идет как число или булево.
Все остальное становится строкой.
Параметры разделяются ,.

== Насчет обработчиков.

При переходах.

Было: exit/left/enter/entered.
Теперь: onexit/exit/onenter/enter.

Смысл примерно такой, onXXX обработчики способны предотвратить цепочку. Теперь onXXX обработчики есть у всего. У act, у use. При этом логика такая: сначала запускается onXXX у объекта game, потом у текущего игрока, потом у комнаты. потом выполняется действие.

Каждый из onXXX может прекратить действие, вернув false. onXXX обработчик для use -- это used, который вызывается у страдательного объекта. Надеюсь, я более-менее объяснил все корректно. :)

Каждое действие над объектом считается. Всегда можно получить число действий над объектом с помощью action(объект, имя действия). А visits и visited для комнат, работают как и в stead2.

disable/enable объекта теперь действует несколько по иному. Они влияют на видимость объекта игроку, но не на возможность найти объект из кода. Грубо говоря: и walk и take итд будут работать с disabled объектом, но игрок этот объект не увидит. Есть специальные функции для определения видимости: seen, disabled(), если это нужно.

Кроме disable/enable можно делать close/open. Это влияет на видимость перехода, видимость фраз в диалоге, а также видимость вложенных объектов в объект. Если объект закрыт -- его содержимое не видно, но сам объект -- виден (в отличие от disabled объекта).

Еще одно отличие в отображении сцены.
Есть dsc -- это описание, которое пропадает после 1го показа.
Есть decor -- описание, которое всегда показывается и служит для связного описания статических декораций с ссылками.
Есть объекты -- которые показаны всегда.

Необходимость decor назрела уже давно. Часто в комнате есть много статических объектов, которые хочется описать связанно. Теперь это можно сделать без создания фиктивного объекта.

Вследствие этого, forcedsc теперь нет.

vit01>Стих из комментариев (Subrisk):

Мило и по делу.

vit01>Пусть компактным будет метод,
vit01>Отделённым интерфейс,
vit01>Накосячил если где-то,
vit01>В этот код заткнут твой фейс.

В этой строфе мне нравится рифма. Напоминает бессмертное "кеды-полукеды". Но в целом

┌─┐
│✔│Нравится
└─┘

>Избавляемся от /x/t в пользу /x/count?
Всё таки это разные схемы. С другой стороны, кто у нас поддерживает /x/t?

>Предлагаю также /x/count переименовать в /x/c
Почему бы и нет. Это лучше соответствует общей стилистике именования.

>Ещё нашёл кое-какую недоработку в нашем алгоритме /u/e/эха/лимит.
>Поскольку мы постфиксы делаем необязательными, люди могут называть эхи только числами
>Тогда запрос /u/e/20/30 можно истолковать двояко: выбрать эхи 20 и 30, либо выбрать 30 первых сообщений из эхи 20.
Положим, я бы не стар разрешать обзывать эхи только числами, но тут надо голосовать - надо такое или нет.

>Обходное решение - сделать двоеточие обязательным. Тогда запрос для выборки первых 10 сообщений будет выглядеть, как /u/e/echo/0:10
>Для последних -10:10
Как вариант, кстати, да.

>> Теперь нам надо думать, как отличать эхи от сообщений в бандле (они ж без постфиксов теперь). O_o
>Раньше проверка всегда шла по точке. Есть точка в названии - значит оно является эхой. Настоящая ситуация полностью ломает все фетчеры, и это реальная проблема.
Не вижу большой беды. Разве что ii-ссылки придётся переделать, а остальное нормально и так должно работать. Пока нет времени, но при случае попробую реализовать безточечный вариант. А вот имена эх в виде чисел это как-то излишне и я бы блокировал создание таких эх на ноде. Но тут думать надо, а я на вскидку говорю. Написать тесты, посмотреть какую логику взаимодействия можно реализовать и насколько она останется простой. Плюс надо сохранить совместимость как со стороны клиентов, так и со стороны ноды. В общем, я не готов сейчас писать что-либо адекватное по теме.

Проект iing у меня не заброшен, но пока приостановлен.

>Ладно, объясню конкретно:

>делаем /u/e/test.15/myechoarea/ii.test.15
>выводит

>====
>test.15
>msgid
>msgid
>msgid
>msgid
>msgid
>myechoarea
>msgid
>msgid
>ii.test.15
>msgid
>msgid
>msgid
>====

>Как фетчер поймёт, что myechoarea - это эха, а не сообщение? А если мы назовём эху 20-символьным именем, то и человеческим глазом спутать можно.

>Рома предлагал в таком случае ставить в начале имени эхи двоеточие. Но тогда ломается совместимость.

Ну тут у нас всего два варианта: либо схема /u/e будет принимать только один аргумент (есть ли у нас клиенты, которые вобше несколько аргументов ей отдают?) или ломаем совместимость с помощью того же двоеточия. Надо дифрекса звать. Я несколько дней думал, но однозначного ответа придумать не смог. С одной стороны двоеточие будет хорошим шагом, но тогда точно не останется совместимости и придётся пилить поддержку нового стандарта в своих клиентах (мне не тяжело, но как на нас посмотрят остальные? =)

>> А вот имена эх в виде чисел это как-то излишне и я бы блокировал создание таких эх на ноде. Но тут думать надо, а я на вскидку говорю.

>Можно сделать регулярку, которая требует как минимум одну букву в названии эхи. Хотя это не принципиально. Надо бы спросить остальных.

Можно много чего сделать. Наверное или Дифрекса надо звать или вобще эху уже делать открытой и написать объявлние в ii.14.

>Новые коммиты в сабже. Изменения:
>* Добавлено полностью рабочее расширение /x/file (со всеми деталями, что обсуждали в ii.14)

Я тут глянул. Есть предложение на общее обсуждение.

ii хоть и завязан плотно на http, но чисто теоретически является паразитической сетью, которая должна работать поверх произвольного протокола. Может стоит реализовать файлы с base64-кодированием, а не просто по http отдавать файл?

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

Что думаете?

PS: Это просто "набрасывание" идей. Пока без детального изучения ситуации и конкретных экспериментов.

>А давайте сделаем группу на гитхабе с реализацией эталонной ноды. А то сейчас пхп, питон, перл и еще что-то есть.

Если речь о текущем стандарте, то эталонная нода это нода, которую Рома писал. А если о том, что обсуждаем, то лучше сперва таки стандарт соглосовать и оформить.

>ЗЫ: Первый фичреквест(я все же клиент пилю, а не сервер): хочу получать последние сообщения от msgid типа
>====
>curl http://node/m/e/t/h/o/d/echo.15/MsGiD
>{
> [
> 'msgid': unixtime,
> 'msgid2': unixtime
> ]
>}
>====

Я думал это реализовать со стороны клиента, но это увеличило бы количество запросов.

>ЗЗЫ: Запилил(на самом деле не до конца) ноду, которая все отдает в JSON и реквесты принимает в JSON :D

Какой-то интересный у вас ii =)

Ещё вот надо что-то делать с сабжем, ИМХО. У нас цитаты совершенно не указывают на то, кто их писал. Что мне нравится в Fido, там принято писать первые буквы имени, потом знак > и рисовать им отступ в один пробел.

То есть если цитируют меня, то выглядит это примерно так:

AL>Вот я тут о цитировании задумался.

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

И да. Меня опять несёт в ломание совместимости, но я упорно продолжаю "накидывать" идеи.

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

Паразитичность сети это очень здорово. Я из этого исхожу. Конечно, это может показаться странным, но кто знает куда придут технологии, а ii иметь хочется независимо от них.

>AL>Вот я тут о цитировании задумался.
>А где пробел? =)

В начале строки =)

>VF> Может, вот так, с пробелом?

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

>> Ещё вот надо что-то делать с сабжем, ИМХО. У нас цитаты совершенно не указывают на то, кто их писал. Что мне нравится в Fido, там принято писать первые буквы имени, потом знак > и рисовать им отступ в один пробел.
>Идея хороша, но в стандарт это пропихивать не стоит. Пусть будет всего лишь наше негласное правило. Технических сложностей и так хватает.
Не то чтобы прям в стандарт. Стандарт описывает схемы и форматы, а это скорее рекомендации по квотированию. Просто идея для удобства чтения.

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

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

Если уж на то пошло, то я бы ещё внедрёжь для начала и конца сообщения присобачил, но мне кажется, что такое не пройдёт =)

PS: Зато как было бы красиво да.

Я тут основную мысль, видимо, обронил пока до эхи нёс. Которая почти изначально была.

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

Отказ от цифровых суффиксов уже ломает совместимость с некоторыми клиентами, но мы стиснем зубы и перепишем проверки. То же предлагаю и с квотированием сделать. Это может показаться немного неудобно в век форумов и социальных сетей, но по факту мы не будет зависить от построителей тредов и даже примитивнейшими средствами сможем удобно (!) читать почту. К тому же соглашение по цитированию никак не скадется на работоспособности сети. Только на представлении данных пользователю, что в принципе поправимо и почти безболезненно.

2vit01: я имел в виду такой формат:

 AL> А давайте цитаты переделаем?
 VF> Идея занятная, но могут же возникнуть проблемы с парсером.

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

Как-то так.

>> Кстати, я планирую одну интересную фичу в Qt клиенте.
>Это будет визуальный редактор для сообщений.

Я думал нечто подобное сделать у себя, но текстовый редактор писать на ncurses просто мотовство, когда рядом есть столько редакторов да с поддержкой aspell =)

base64 это было первое, что пришло мне в голову. В принципе, можно отдавать и бинарь, наверняка если мы заменим http на другой произвольный протокол, мы всё равно сможем гнать бинари. Надо думать и спрашивать бывалых, а я ламер =)

>Что, даже здесь особо никто не сидит? Чем быстрее проработаем схемы, тем быстрее на них перейдём.
Я здесь. Завтра попробую объединить всё, что наобсуждали и уже смотреть более детально.

>Обратный переход с base64 на бинари (по скорости лучше) до сих пор висит незакоммиченный, надо что-то делать со стандартами, в конце концов.
Бинари надо отдавать бинарями. Difrex всё правильно сказал.

>>ЗЫ: Первый фичреквест(я все же клиент пилю, а не сервер): хочу получать последние сообщения от msgid типа
>>====
>>curl http://node/m/e/t/h/o/d/echo.15/MsGiD
>>{
>> [
>> 'msgid': unixtime,
>> 'msgid2': unixtime
>> ]
>>}
>>====
>Я думал это реализовать со стороны клиента, но это увеличило бы количество запросов.
Вот я тоже думаю. В любом случае, такая штука может дать сбой, если "на лету" менять ноду. Но без переездов бы она сильно упростила жизнь.

Я тут немного покумекал и задумался. А что нода должна возвращать, если указанного msgid нет в эхе?

Моя реализация ноды теперь умеет три фичи в методе /u/e:
1. Классическое для ii поведение.
2. Если в поеследнем аргументе указаны начальное:сообщение:смещение, то возвращает указанный диапазон.
2.1. Если начальное сообщение находится за пределами списка сообщений то берётся первое или последнее (в зависимости от знака указанного индекса).
2.2. Если начальное сообщение + смещение указывает за пределы списка сообщений в эхе, то возвращаются все сообщения с указанного начального по последнее в эхе.
3. Если в последнем аргументе указан msgid, то нода возвращает всё, что есть в эхе после него.
3.1. Если такого сообщения нет, то возвращается вся эха целиком.

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

Какие будут предложения? Нужен ли вобще такой метод?

>> Вот я тоже думаю ... Но без переездов бы она сильно упростила жизнь.
>unixtime смущает. Это что получается: сервер должен распарсить все N тысяч сообщений на время?
Хых. Я unixtime там не углядел. Нет. Парсить все эти сообщения как-то слишком уж. Вечером выложу свою реализацию на поиграться в общий доступ. Посмотрим стоит ли вобще связываться.

>> Третий пункт позволяет очень много получить странного в текущем виде, так как можно указать несколько эх, а один msgid может быть только в одной эхе (в подавляющем большинстве случаев).
>Третий пункт попахивает костылями. Во-первых, хорошо было бы указывать начальный msgid для всех запрошенных эх, т.е. в текущем варианте от него мало пользы. Во-вторых, /u/e и так смещения еле-еле в себя вобрал.
>В общем, я за ещё одну схему для списка по msgid.
По доброму, я бы смещения тоже отдельным методом сделал. Хотя они и куда менее опасные, в сравнении с msgid.

В любом случае, это опция и она пока экспериментально. Сама по себе необходимость такой схемы в стандарте представляется мне весьма сомнительной.

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

Сабж без веб-интерфейса (пока что) лежит вот тут: https://github.com/spline1986/ii

Буду рад, если найдутся желающие потыкать это поделие палочкой =)

AL>>Буду рад, если найдутся желающие потыкать это поделие палочкой =)
vit01>Попробовал написать несколько сообщений в тестовую эху. Обнаружился баг: при обычном запросе /u/e/эха сообщений на 1 меньше, чем в индексе. Отсекается последнее почему-то.
Поправил. Теперь всё совсем жёстко. Если запись в индексе не является msgid (не проходит фильтр), то она не попадает в выхлоп запросов.

>> Только если нода хранит сообщения в файликах, а не в базе.
vit01> Да, ведь мы должны гарантировать полноценную работу ноды лишь на файлах. Это ключевая особенность ii. БД - опциональная зависимость.

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

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

AL>> Очевидно, что на разных нодах может быть разный порядок сообщений в эхах или даже разное содержимое. В связи с чем, я пока придумал только держать отдельную базу сообщений для каждой из нод.
vit01> В Qt-клиенте для всех нод одна и та же база. Алгоритм работы примерно таков:
vit01> 1. Фетчим одну и ту же эху с нескольких нод в одно и то же место

Пока что я так же сделал, но вопрос был задан в свете эхотага. Когда клиент забирает не весь список, а только n последних сообщений в эхе.

vit01> 2. Если отправляем туда сообщение, то оно уходит на первую ноду из списка

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

vit01> Я не стал городить раздельные базы, потому что юзер-НЕфрендли.

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

зы Вопрос пока что чисто теоретический.

AL>> Пока у меня одна база, так как нет смысла, но когда у нас будет возможность получить разный набор сообщений с разных нод, это может стать проблемой.
vit01> И где здесь проблема? Предположим, есть эха news.15. На станции 1 туда, к примеру, постят новости с Лора, а на станции 2 - с опеннета. Юзер фетчит их в одну базу. В итоге получает _одну_ ленту с новостями обоих сайтов. Так даже читать приятнее.

А когда в эту эху с ноды 1 приходят новости с опеннета, а со второй -- с хабры, и с обоих нод репостится ЛОР, то есть вероятность, что поинт будет получать не все сообщения. Причём весьма высокая. Просто потому, что тогда совсем разный порядок сообщений может оказаться. Я понимаю, что это будет не так удобно для пользователя, но зато позволит не изобретать извращённых алгоритмов для разруливания этой путаницы.

AL>>> Пока у меня одна база, так как нет смысла, но когда у нас будет возможность получить разный набор сообщений с разных нод, это может стать проблемой.
vit01>> И где здесь проблема? Предположим, есть эха news.15. На станции 1 туда, к примеру, постят новости с Лора, а на станции 2 - с опеннета. Юзер фетчит их в одну базу. В итоге получает _одну_ ленту с новостями обоих сайтов. Так даже читать приятнее.
AL> А когда в эту эху с ноды 1 приходят новости с опеннета, а со второй -- с хабры, и с обоих нод репостится ЛОР, то есть вероятность, что поинт будет получать не все сообщения. Причём весьма высокая. Просто потому, что тогда совсем разный порядок сообщений может оказаться. Я понимаю, что это будет не так удобно для пользователя, но зато позволит не изобретать извращённых алгоритмов для разруливания этой путаницы.

Хотя всё равно не очень верный пример. Я к тому, что на второй ноде могут быть сообщения и те, что есть и на первой ноде. И они могут идти вперемешку с уникальными сообщениями. И если мы забираем не всю эху целиком, то возникают потери.

>> И если мы забираем не всю эху целиком, то возникают потери.
vit01> А, теперь понял, в чём здесь суть. Нет, потерь не будет. Я хотел это реализовать с помощью дополнительной кнопки "закачать эху полностью", которую сначала жмёшь в первый раз, а затем уже трафик экономишь.

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

vit01> Ну а так они и без одноимённых эх могут теряться, тут разницы нет большой.

То то и оно, что в рамках одной эхи на одной ноде оно теряться не будет. И если создать разные базы для разных нод, то потерь не будет.

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

vit01> Надо придумать только, как это реализовать.
vit01> Можно сделать что-то вроде такого:
vit01> GET /x/features

vit01> ====
vit01> e/
vit01> m/
vit01> u/e/
vit01> u/m/
vit01> u/point
vit01> u/push
vit01> list.txt
vit01> blacklist.txt
vit01> x/c/
vit01> x/file
vit01> ====

vit01> Только вот как показать здесь расширенную версию /u/e, не очень ясно. Может быть, /u/e/lim ?
Нет смысла показывть e/, m/, u/e/ и u/m/. Они есть везде. Так же и u/point можно не показывать. Надо показывать то, чего может не быть: пуш, списки, файлы, каунтеры. Заодно, если показать u/e/, то этим можно обозначить и расширенную версию. Я так это представляю.

vit01> Когда уже можно будет полностью перейти на новые версии своих нод? Может, реализуем поскорее уже то, что намеревались?

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

vit01> // это сообщение не имеет ничего общего с тем срачем, что устроил Рома; хотел написать его ещё вчера

Ой да ну его. Я уже боюсь серьёзно воспринимать его заявления -- он путается в показаниях и считает это нормой человеческого поведения.

vit01> Планирую слияние features => master и переезд своих основных нод на завтрашний вечер.

Значит пока обновлюсь на твою ноду, а там как пойдёт. А то меня все ждут =)

vit01> И да, насчёт веб-интерфейса. Можешь взять тот, который был у твоего common-lisp клиента. Он очень милый и лично мне понравился. Просто мысли вслух.

Ну там будет примерно оно, но с некоторым переосмыслением.

>> Планирую слияние features => master

Difrex> Легаси же все работает?

Да. Оно полностью совместимо. Просто навороты поверх.

vit01> Ветки features и master слиты. Миграция ii-net.tk на новую версию ноды завершена.
vit01> Перед обновлением настоятельно рекомендуется перечитать файлы config.default.php и README.md.

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

vit01> Мне бы, наверное, хотелось снова рассказать, какие новые фичи появились в ноде за всё это время. Где это лучше сделать, здесь или в ii.14?

В идеале в Changelog.txt и кросспост тут и в ii.14 %) Чтобы наверняка.

vit01> Ветки features и master слиты. Миграция ii-net.tk на новую версию ноды завершена.

Сижу немного правлю под себя. Какая же новая нода у тебя классная. Вот прямо таки приятно зайти =)

vit01> Ээ, не надо нахваливать, мне неудобно =)

Ладно. Не буду. Просто понравилось. Особенно когда полез немного под себя перекраивать.

Обновил свою ноду. Тестирую.

Появились некоторые мысли о сабже. Не обязательно расспространять файлы только по предъявлению authstr. Можно так же делиться файлами свободно, если они не нарушают никаких авторских прав и лицезнионных соглашений.

Логику предлагаю такую:

Обращение без POST/GET-запроса вернёт список файлов для общего пользования. С указанным pauth - дополнит приватными файлами.

Обращение с указанием имени файла без pauth вернёт или файл из списка для общего пользования или ошибку, с pauth просто файл в любом случае (если, конечно, такой файл есть в списке).

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

AL>> Как думаете, стоит ли менять логику работы этого расширения?

vit01> Думаю, нет. Если надо предоставить к каким-то файлам доступ для всех, то проще дать ссылку.
vit01> А если только для ii-шников, то идёт схема с паролем.

Для доступа вполне будет ссылка http://node-addres.example/x/file/filename которую можно кидать кому угодно. А ii-шники тоже не всегда имеют поинты на всех станциях.

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

vit01> Кажется, что это какой-то "велосипед". Конечно, если он приживётся, я могу его тоже реализовать, но это пока не принципиально.

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

vit01> Всё, теперь осознал. Ещё и в lisp-ноде так же.

Лисп-ноды скорее всего не будет. Я вдруг понял, что не взирая на всю прелесть лиспа, пользоваться этим софтом будет меньше народу, чем аналогичным, но на пайтоне. Так что лисп у меня это теперь язык для себя.

vit01> Реализую, как время будет.

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

vit01> И да, ты собираешься у себя что-нибудь выкладывать по /x/file на этой неделе для теста? У меня на ноде уже давно пара тестовых файлов лежит, но никому нет дела.

Пока могу выложить свои музыкальные бадабдыщи и исходники к ним. Когда я всё таки допишу свою реализацию ноды и перееду на домашний сервер, хочу сделать /x/files основным местом для выкладывания файлов.

vit01> И насчёт домашнего сервера. Переезд - это хорошая идея, но всё равно не забрасывай, пожалуйста, spline.rooker.ru. У нас за последнее время устойчивость сети с 7 серверов упала до 5. Если mlpfim.ml со сдохшего хостинга перейдёт на моё попечение, то это так и останется. С твоим новым сервером в сети их будет 6, что вполне нормально.

Не вижу большого смысла на самом деле, так как у нас мало поинтов. Устойчивость сети есть, так как есть несколько нод. Плюсом у меня есть локальная нода, которая зеркалит spline.rooker.ru. Узлы сети это хорошо, но главное достояние - всё таки пользователи. Но тут я рискую скатиться в очередное нытьё о том, что никого нет, так что не буду больше на эту тему.

vit01> Жаль, я смотрел исходники iicl, и эта нода была довольно хороша. А что до народа, не соглашусь. Обычный народ не будет поднимать ноды, ему лишь бы клиенты использовать.

iicl - это клиент ^__^

vit01> В любом случае, с гитхаба её не удаляй, пожалуйста. Или если удалять будешь, предупреди, я форкну.

Удалять репозиторий я не планирую. Он мне дорог как память =)

AL> iicl - это клиент ^__^

Лол. Надавал названий -- сам запутался. Нода, конечно. Но она не очень мне нравится всё таки. К тому же она не дописана.

vit01> Это заметно :)
vit01> Если что, могу ей заняться вместо тебя.

Можешь форкнуть. Я в ближайшее время вряд ли к ней венусь. Потом видно будет: то ли солью обе ветки, то ли забью, то ли своё буду писать.

Буду через годик-другой тебе пул-реквесты слать %)

> Я, кстати, за. У нас давно по факту форк сети(именно сети, а не софта) произошел. Раз так сильно Роме не нравится, то, что у нас получается, а лицензию он выбрал неправильную, то можно и название сменить.

Да вот беда. ii это именно название софта. Кстати, ты как пользователь каноничной ноды, чувствуешь несчасться от новых стандартов?