ПРОБЛЕМА
При заполнении в параграфе БЛОКА ДОСТУПНЫХ ДЕЙСТВИЙ И ПЕРЕХОДОВ (далее – блок ДДП) часто возникает следующая проблема: если параграф, на который надо перейти в одном из действий ещё не записан, указанный переход обнулится (номер параграфа не сохранится). Чтобы не допустить в дальнейшем пустых переходов, автору приходится много тестировать свой сторигейм и много возвращаться на один и тот же параграф, чтобы дописать в него те переходы, которые из него исчезли. А от этого возникает ещё вторичная проблема: при повторном возвращении на редактирование параграфа обнаруживаешь, что все записанные опции в блоке ДДП вдруг удвоились, а то и утроились, и нужно тратить дополнительное время, чтобы это всё зачистить.

КАК ВСЕГО ЭТОГО ИЗБЕЖАТЬ?

Простое, но элегантное решение: пишите ваши сторигеймы с конца!

Тогда, заполняя блоки переходов/доступных действий, окажется, что все нужные для переходов параграфы УЖЕ БУДУТ СУЩЕСТВОВАТЬ, и переходы сохранятся после первого же редактирования!

УРА!!! ЗАР-Р-РАБОТАЛО!!!
Итак, долгожданное событие – в Митриле появилось множество новых инструментов для работы с ресурсами. Джу, безусловно, ОЧЕНЬ МОЛОДЕЦ, что это сделал. Ему, и всем, кто ему помогал – ОГРОМНОЕ спасибо.
Но неплохо бы теперь дать мануал для работы с новыми инструментами. Это могу сделать я. Я уже немного потестировал Митрил и мне есть, что сказать.
1. Несмотря на то, что теперь появилась операция ДЕЛЕНИЯ значений ресурсов, дробным числом ресурс быть НЕ МОЖЕТ. Поэтому результат деления округляется до ближайшего целого числа. Дробная часть, равная 0.5, округляется до целой единицы.
2. На ноль, как известно, делить нельзя, однако Митрил как-то нестабильно реагирует на попытку такого действия. Один раз у меня всплыло какое-то окошко с сообщением, которое я не успел прочесть, так как оно быстро исчезло и тестирование сторигейма перезапустилось. В другие разы операция деления на 0 была попросту проигнорирована и никак не срабатывала.
3. Чтобы не делить на 0, этот вариант необходимо каждый раз отслеживать вручную. Но, учитывая, что оператор условия ЕСЛИ всё ещё доступен ТОЛЬКО в области выбора действия игрока, каждая проверка на 0 будет связана с переходом на новый параграф. Как этого избежать – рецепт будет дан ниже.
4. Значение ресурса НЕ МОЖЕТ БЫТЬ отрицательным (меньше 0). Если в результате ВЫЧИТАНИЯ должно получиться отрицательное число, оно автоматически обнуляется. При этом, если соответствующий ресурс отображался на экране, строка с его названием исчезает из списка. Она появится снова, когда значение ресурса станет ненулевым.
5. Точно так же при сложении и умножении: если значение ресурса A лимитировано сверху, эти операции не могут превысить установленный для него предел.
6. На основе вышесказанного для ресурса A можно построить ИНДИКАТОР НУЛЯ: величину B, равную 1, если A – ненулевое число, и равную 0, если A равно 0. При этом можно обойтись без использования условного оператора ЕСЛИ.
Для этого требуется, чтобы значение ресурса A было лимитировано каким-нибудь числом (возьмем, к примеру, число 100).
Рассмотрим серию команд (ресурс B, как и A, лимитирован числом 100):
1. СКОПИРОВАТЬ B ИЗ A
2. УВЕЛИЧИТЬ B НА 99
3. УМЕНЬШИТЬ B НА 99
Тогда B будет равен 1 во всех случаях, кроме случая A=0.
7. Чтобы построить ИНДИКАТОР ПРЕВЫШЕНИЯ величины A над величиной C (величину B, равную 1, если A строго больше, чем C, и равную 0, если нет), надо построить ИНДИКАТОР НУЛЯ для величины (A-C).
8. Пример реализации условного оператора: Допустим, мы хотим реализовать команду: ЕСЛИ(A>C) ТО УВЕЛИЧИТЬ D НА 5, ИНАЧЕ УМЕНЬШИТЬ F НА 2.
Пусть B – ИНДИКАТОР ПРЕВЫШЕНИЯ A над C. Исполняем команды:
1. СКОПИРОВАТЬ E ИЗ B
2. УМНОЖИТЬ E НА 5
3. УВЕЛИЧИТЬ D НА E
4. УСТАНОВИТЬ E = 1
4. УМЕНЬШИТЬ E НА B
5. УМНОЖИТЬ E НА 2
6. УМЕНЬШИТЬ F НА E
Легко проверить, что они правильно исполнят нужные нам условия и действия.

О ПЕРЕХОДАХ С ВОЗВРАЩЕНИЕМ
Зачастую в книгах-играх попадаются параграфы следующего содержания: "Вы приобрели новую способность/вещь/заклинание и чтобы перейти к просмотру информации по их использованию, не закрывая этот параграф, перейдите туда-то. Прочитав, возвращайтесь обратно сюда." Эти и подобные случаи я буду называть переходами с возвращением.
Как переходы с возвращением реализовывать на Митриле? Для этого в редакторе предусмотрено специальное действие: "Перейти на предыдущий" (далее – команда возврата). Это действие доступно как в разделе "Автоматические изменения", так и в разделе "Действия и переходы". Давайте рассмотрим особенности использования этого действия.
1. Будучи размещённым в разделе "Автоматические изменения", эта команда будет исполнена раньше, чем произойдёт изображение текста параграфа, картинки и блока доступных действий. Поэтому показать так информацию игроку абсолютно не получится. Только автоматические изменения, прописанные до команды возврата, будут исполнены.
2. Логично разместить эту команду в блоке доступных действий и переходов, создав действие "Вернуться обратно". В этом случае в настройке действия указывать номер параграфа для перехода нет смысла и это поле надо оставлять пустым (если его заполнить, это всё равно никак не отразится на исполнении).
Но что делать, если переход с возвращением нужно сделать не глубиной в 1 параграф, а в два и более? Такое требуется, например, в книгах Джонатана Грина "Вой Оборотня" (при получении новых способностей Оборотня) и "По ту сторону смерти" (при обнулении ВЫНОСЛИВОСТИ главного героя, когда он вынужден направляться к Вратам Смерти, но с возможностью последующего возвращения).
Команда "Перейти на предыдущий" тут не поможет – применённая 2 раза подряд, она создаёт зацикливание. Решение тут одно (собственно, как оно и делается в книге "По ту сторону смерти") – осуществлять переход с возвращением, предварительно запомнив номер параграфа, куда потом выходить. Но Митрил не предусматривает команд перехода на параграф, номер которого содержится в какой-нибудь переменной. Решить вопрос, тем не менее, можно путём полного перебора всех возможных значений – их обычно не так уж и много: например, в книге "По ту сторону Смерти" вариантов для возврата из Врат Смерти всего 46.

Где ещё такой приём можно применить?
1. В написании боёвок. Можно представлять, что при встрече с противником, с которым нужно драться, вы условно переходите на специальную локацию (Боевую арену), где проигрывается стандартный бой с вашими текущими параметрами и параметрами вашего противника. После чего вы возвращаетесь на параграф, с которого переходили, к дальнейшему прохождению. Тогда, если организовать переходы на Боевую Арену с возвращением, как указано выше, и если в игре у вас 20 различных боёв – их не придётся программировать 20 раз, а всего лишь только один – экономия получится весьма и весьма существенная.
2. В написании лабиринтов. Можно в игре в разных местах использовать единый лабиринт с переменными стенками и входами-выходами – каждый раз для играющего он будет существенно разным. Для каждого из лабиринтов используются одни и те же параграфы, но с вариациями. Вход и выход из лабиринта реализуются по схеме перехода с возвращением. Экономим на параграфах описания лабиринтов.
3. В написании мультиперсонажных игр. Переключение управления с одного персонажа игры на другого тоже осуществляется по схеме перехода с возвращением – мы получаем полностью независимое управление персонажами, притом с любым их количеством: просто нужно будет запоминать текущий параграф каждого персонажа.

ОБ УПРАВЛЕНИИ ТЕКСТОВЫМИ СООБЩЕНИЯМИ

Следует признать, что в настоящий момент Текстовый блок каждого параграфа игры, создаваемой в Митриле, абсолютно статичен, неизменен.
Данное обстоятельство сильно ограничивает возможности фидбэка (отклика системы на управление и события в игре), что снижает интерактивность игрового процесса.
Например, в каком-то месте игры персонаж теряет случайное количество единиц ВЫНОСЛИВОСТИ – как об этом можно написать?
"Вы теряете несколько единиц Выносливости." (сам отследи, сколько)
ИЛИ:
"Вы теряете 3 единицы Выносливости."
Вторая запись более конкретна и более предпочтительна, чем первая, но чего она будет стоить автору сторигейма?
Автору нужно создавать кучу однотипных действий и связанных с ними вспомогательных параграфов, чтобы выдать одну-единственную запись:
ДЕЙСТВИЕ1. ДОСТУПНО ЕСЛИ (ПОТЕРИ = 1). ПЕРЕЙТИ на ПАРАГРАФ1
ДЕЙСТВИЕ2. ДОСТУПНО ЕСЛИ (ПОТЕРИ = 2). ПЕРЕЙТИ на ПАРАГРАФ2
ДЕЙСТВИЕ3. ДОСТУПНО ЕСЛИ (ПОТЕРИ = 3). ПЕРЕЙТИ на ПАРАГРАФ3
ДЕЙСТВИЕ4. ДОСТУПНО ЕСЛИ (ПОТЕРИ = 4). ПЕРЕЙТИ на ПАРАГРАФ4
ДЕЙСТВИЕ5. ДОСТУПНО ЕСЛИ (ПОТЕРИ = 5). ПЕРЕЙТИ на ПАРАГРАФ5
ДЕЙСТВИЕ6. ДОСТУПНО ЕСЛИ (ПОТЕРИ = 6). ПЕРЕЙТИ на ПАРАГРАФ6
ПАРАГРАФ1. ТЕКСТ "Вы теряете 1 единицу Выносливости.". ПЕРЕЙТИ НА ПАРАГРАФ7
ПАРАГРАФ2. ТЕКСТ "Вы теряете 2 единицы Выносливости.". ПЕРЕЙТИ НА ПАРАГРАФ7
ПАРАГРАФ3. ТЕКСТ "Вы теряете 3 единицы Выносливости.". ПЕРЕЙТИ НА ПАРАГРАФ7
ПАРАГРАФ4. ТЕКСТ "Вы теряете 4 единицы Выносливости.". ПЕРЕЙТИ НА ПАРАГРАФ7
ПАРАГРАФ5. ТЕКСТ "Вы теряете 5 единиц Выносливости.". ПЕРЕЙТИ НА ПАРАГРАФ7
ПАРАГРАФ6. ТЕКСТ "Вы теряете 6 единиц Выносливости.". ПЕРЕЙТИ НА ПАРАГРАФ7
Можете оценить соответствующий объём работ, если потери определяются двумя, а то и тремя бросками кубиков (в "Спектральных сталкерах" может быть до 6 бросков кубиков). Ясно же, что автор попросту откажется от фидбэка, и будет вынужден либо просто смолчать о потерях, либо сказать что-то неконкретное.

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

Что нужно авторам сторигеймов для управления текстами:
1. Для повышения гибкости и интерактивности необходимы текстовые сообщения, формируемые динамически, содержание которых заключается в ТЕКСТОВЫХ ПЕРЕМЕННЫХ.
2. Очень удобной была бы возможность дописывать динамический текст к статическому тексту параграфа – для этого нужно добавить в редактор Митрил действие "ПОКАЗАТЬ ТЕКСТ". Кроме того, нужно ещё, чтобы блок текста и блок действий параграфа были разделены по разным фреймам (один под другим).
3. Для текстовых переменных нужны всего 2 операции:
СОЕДИНИТЬ ТЕКСТ(A,B,C,D,...), где A,B,C,D,... – текстовые переменные, текстовые константы, значения ресурсов и спецзнаки EOP (End of Paragraph, конец абзаца). Эта операция осуществляет сборку единого текста из разнородных частей.
УМНОЖИТЬ ТЕКСТ(T, n), где T – текстовая переменная, n – число (ресурс). Эта операция кратно воспроизводит содержание текстовой переменной T.
4. Поддержка HTML-тегов в текстовых переменных может быть, но она необязательна.

Для чего нужна операция "УМНОЖИТЬ ТЕКСТ"?
Главное её применение – использование динамических текстов в сочетании с ИНДИКАТОРАМИ УСЛОВИЙ. Это позволит формировать динамические тексты в зависимости от выполнения различных условий (с учётом того, что оператор ЕСЛИ отсутствует в блоке автоматических изменений).
Если I – индикатор некоторого условия, а T – текст некоторого сообщения, то результат операции УМНОЖИТЬ ТЕКСТ(T, I) будет T, если соответствующее условие выполнено, и пустое сообщение, если оно не выполнено.
(Есть и другие возможные применения, например – для удобства рисования средствами текстовой графики, но лично я не считаю их достаточно вескими.)

О РАЗЛИЧИЯХ МЕЖДУ КНИГАМИ-ИГРАМИ И ИХ ИНТЕРАКТИВНЫМИ ВЕРСИЯМИ

Процессы игры при чтении книг-игр и при чтении интерактивных сторигеймов (даже если это одна и та же игра) отличаются порой самым кардинальным образом. Причины этого очевидны: при чтении обычных книг-игр читатель одновременно является главным оператором всех технических процессов, связанных с игрой, как-то: ведёт Лист персонажа, блокнот с полезной информацией, составляет карту своего маршрута, самостоятельно осуществляет все проверки, расчёты всех игромеханик, боёвок, уронов со случайным значением, внимательно вчитывается в параграфы и сопоставляет информацию, чтобы случаем не пропустить в нём наличие скрытого перехода и т.д. При этом также он имеет максимальный доступ к служебной информации по игре – нет ничего в книге, написанного НЕ для него.
Совсем не то с интерактивными играми – читатель отстраняется в них практически от всего, перечисленного выше, в той или иной мере. Теперь всю черновую работу за него делает машина. Доходит до того, что читатель отстраняется даже от ИНФОРМАЦИИ, которая в сторигейме считается служебной, но которая в книге-игре ориентировала бы игрока на поиски в нужном направлении.
Вот пример. Одна из лучших, на мой взгляд, интерактивных книг-игр – это "Скала ужаса". Ключевую информацию, без которой в игре не открывается ничего существенного для её прохождения, персонаж должен получить у лесника. А чтобы застать его в живых, К НЕМУ НАДО УСПЕТЬ ПОПАСТЬ ЗА 4 ЧАСА. Разумеется, читающий книгу-игру обнаружит это сразу же, как только вообще попадёт к леснику, а вот играющий в интерактивную версию в известность об этом не будет поставлен. Даже если случайно он и попадёт к леснику за 4 часа – он знать не будет знать, ЧТО ЖЕ ИМЕННО повлияло на то, что в этот раз лесник живой. В результате головоломка с лесником и зеркалом, которая и так трудно решается, в интерактивной версии становится практически нерешаемой
Чтобы этого избегать описанной выше проблемы, автору, конечно, нужно не скупиться на предоставление игроку различной и подробной информации, в том числе имеющей чисто техническое применение, а разработчикам редакторов интерактивных игр – обеспечивать авторов соответствующим инструментарием для вывода информационных сообщений (см. мой предыдущий пост).
Другой пример. Та же "Скала ужаса". Читающему книгу, при встрече в лесу с инквизитором предстоит поднапрячься, пораскинуть мозгами и посопоставлять различную информацию, чтобы ДОГАДАТЬСЯ, что захваченная инквизитором девушка – это Анна, дочь лесника. Применение игроком этой информации открывает скрытый переход в игре. В интерактивной версии напрягаться и сопоставлять не нужно – переход будет доступен и без этого (лишь бы информацию об Анне вы получали ранее), а то, что это была Анна – можете прочесть чуть позже, пройдя по нему. Машина всё догадалась за нас сама. Почему-то вспомнился Вовка с тридесятого царства: "Вы что, и конфеты за меня есть будете? – Ага! – Ну уж нет!"
Проблема скрывания скрытых переходов для САМОСТОЯТЕЛЬНОГО их раскрытия игроком может быть решена, при решении ещё одной проблемы – проблемы предоставления возможности игроку использовать инвентарь в произвольный момент игры.
В некоторых играх допускается на спокойных параграфах поесть еды, попить воды, применить заклинание ИСЦЕЛЕНИЯ, выпить восстанавливающие зелья, сменить оружие/доспех, выкинуть часть вещей и т.д. К этому списку можно было бы добавить опцию "ПРИМЕНИТЬ ИНФОРМАЦИЮ" как раз-таки в целях раскрытия скрытых переходов. Проблема же заключается в том, что в настоящее время возможности предложить интерфейс для распоряжения имуществом и информацией Митрил автору не даёт. Его можно было бы реализовать с помощью перехода с возвращением (на экран инвентаря), но точек возвращения слишком уж много.

МОЁ ПОСЛЕДНЕЕ ЖЕЛАНИЕ (ХОТЕЛКА, ПРЕДЛОЖЕНИЕ)

Что ещё нужно редактору Митрилу, чтобы стать универсальным редактором для интерактивных книг-игр? Интерфейс ввода данных. Вот ряд примеров, когда это нужно:
во многие книги-игры включены те или иные азартные игры с возможностью произвольного размера ставки;
в "Мести Альтея" и её продолжениях каждый раунд боя нужно определять, сколько очков Славы задействовать;
загадки Лесного домика в "Подземельях Чёрного Замка" и головоломка МВК в "Тайне капитана Шелтона" требуют ввода либо числовых, либо текстовых данных;
в "Землях Сказаний" нужно определять, какую сумму вложить в банк, какую сумму инвестировать в морскую торговлю, сколько денег вынести из сокровищницы;
в "Болотной Лихорадке" игрок должен выбирать, какие цифры из комбинации он оставляет, какие – меняет, а на каких выполняет Форсаж;
практически во всех играх с инвентарём нужно выбирать (отмечать), какие предметы из найденных и в каком количестве взять с собой.

так можно вечно ждать и ничего в итоге не делать

Отчасти звучит так, как будто есть толпа людей, которые не пишут (публикуют) сторигеймы только потому, что митрил не поддерживает достаточно сложную механику, и буде Джу её внедрит – тут же повалит вал новых работ (или же "сторигеймизаций" книг-игр или чего-то ещё).
Алексей, а вот вы сами что-то на митриле пишете или может собираетесь писать? Своё там или адаптацию чего-нибудь? Или вам просто интересно разбираться с возможностями и ограничениями редактора? Если последнее, то похоже кроме "сториавторов" и "сторигеймеров" появляется "третье сословие" – технический консультант по возможностям редактора.

Замеченные косяки редактора (если всё работает, а это я не разобрался, ткните, пожалуйста, носом):

В списке ресурсов присутствует удобная кнопочка поиска, в каких параграфах этот ресурс задействован. Но поиск не учитывает использование ресурса для условий сложения/вычитания/т.п. А так же использование ресурса в "автоматических изменениях" параграфа (не при действии-переходе).

Работа с "авторскими пометками параграфа" не доделана. Добавляю пометку, сохраняю параграф, справа в списке пометок новая не появляется. Надо жать f5, чтобы она там появилась. Мало того, если добавить уже существовавшую ранее и отображаемую справа пометку к новому параграфу, поиск по имени пометки этот параграф не найдёт, пока страница не будет принудительно обновлена.
Ну, и автоподстановка по мере набора названия пометки не помешала бы (как с названиями параграфов происходит).

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

Добавил через 8 минут 56 секунд:

Нужна кнопка "вернуться к предыдущему параграфу" в редакторе. Хорошо бы иметь её в двух местах – в самом верху, над полем редактирования параграфа. И в самом низу рядом с кнопкой сохранения изменений в параграфе.

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

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

P.S. работаю с ПК с большим монитором.

Есть такая функция "Удалить сообщение" к сторигеймам, которая доступна только модераторам. Если на надпись щёлкнуть, то вылезет сообщение "Извините, но данное действие вам недоступно!"
Выглядит это словно раздражитель для простых пользователей ("Знай своё место, смерд!")
Поэтому почему бы не сделать функцию "Удалить сообщение" доступной для всех ЛИБО сделать её невидимой для немодераторов.
P.S. умная власть ловко скрывает свои полномочия.

Мне неудобно добавлять ключевые слова на смартфоне, поля микроскопические.

Добавить кнопки для формирования текста параграфа.

Нужно больше достижений в сторигейм. Трёх достижений для некоторых сторигеймов реально мало.

На данный момент в настройках действий есть два варианта "доступно если есть все/любое из ключевых слов", было бы очень неплохо еще иметь вариант "доступно, когда есть Количество из Всех" то есть действие доступно если у меня есть 3 из 5 возможных ключевых слов и тд

ну и еще кнопка "удалить все действия" была бы к месту, тк удалять по 50 действий не особо удобно

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

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

Как насчёт таблицы рекордов? Например, возьмём, скажем, Бесконечное Подземелье. Автор указывает по каким параметрам вести таблицу, и система сохраняет три лучших результата:
Набрано славы

1. Петя 30000
   
2. Вася 5021
   
3. Коля 76
   

Убито слизней

1. Джу 4567
   
2. Таро 765
   
3. Бинки 8
   

Джу, а реально сделать в Митриле вывод ключей и ресов в тескте параграфа? Например, чтоб, скажем, в стори наподобии Башне стихий генерить имена монстров из кусочков слов

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

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

Еще такая хотелка:
управление видимостью группы ресурсов/ключей из параграфа!

Я предлагаю добавить условия-триггеры. Чтобы они применялись ко всем действиям

Я знаю, у нас есть отдельное обсуждение по мультиплееру
https://quest-book.ru/forum/topic/6127
но оно хрен знает где, поэтому напишу здесь в "хотелках", какая у меня возникла мысль.
Это может быть первым шагом по внедрению мультиплеера:
Возможность создавать ресурсы с глобальной областью видимости.
Т.е. на данный момент в митриле можно создавать ресурсы только в области видимости игрока, а новый вид – в области видимости игры. Это значит, что ресурс не будет сбрасываться в ноль, если игрок начинает игру сначала. При этом значение ресурса не индивидуально для каждого игрока. Каждый игрок видит то же значение ресурса, что и любой другой игрок, и каждый игрок может своими действиями поменять это значение.
Например, мы делаем в Бесконечном Подземелье ресурс "уровень подземелья" глобальным. Тогда если вы начинаете игру спустя месяц после ее опубликования, вы можете обнаружить, что начинаете подземелье к примеру с 100-го уровня, поскольку другие игроки за это время продвинули уровень в игре до этой отметки. Поэтому "уровень подземелья" делать глобальным, конечно же, не следует!
Другой пример: В подземелье есть "глобальный" ресурс "аптечка" 1 шт. Если один игрок её берёт, то другой игрок её подобрать уже не сможет.
Тут, естественно, может возникнуть следующая проблема:
Два игрока в разных концах страны открывают более менее одновременно один и тот же параграф, и оба видят аптечку. Кто-то из них первым тычет "Подобрать". Второй, который хуже владеет мышкой, тоже нажимает "Подобрать". Понятно, что ему аптечку давать нельзя! Что делать в такой ситуации?
Очевидно, что либо сам переход "Подобрать", либо параграф, на который переход ссылается, должен содержать в блоке автоизменений как минимум два вычисления:

• Вычесть единицу из глобального ресурса "аптечка" (в области видимости игры)
  
• Добавить единицу к локальному ресурсу "здоровье" (в области видимости игрока)
  

Тут происходит следующее: т.к. "аптечка" уже равна нулю, то вычитания не произойдет, так что тут всё ОК.
Однако дальше мы бесконтрольно прибавляем единицу к "здоровью", и это – проблема.
Её можно было бы решить, если бы в блоке автоизменений параграфа можно было устанавливать условия, типа "добавить 1 к здоровью, если глобальный ресурс ‘аптечка’ больше или равен единице; затем вычесть единицу из глобального ресурса ‘аптечка’". Этого пока нет, а если и будет, автору придётся тщательнее контролировать этот момент. Но это пол беды.
Я не вижу решения для автоизменений, если они находятся внутри кнопки перехода! Следовательно, использование "глобальных ресурсов" внутри перехода должно быть запрещено!
Так же на совести автора остаётся выдача соответствующего текстового сообщения, мол, "увы, кто-то успел подобрать аптечку быстрее вас".

и еще хотелка: чтоб в таблице рекордом можно было устанавливать рекорд на минимум

Лично я сейчас чувствую нехватку: 1. возможности создавать параграфы не из действий (для набросков)
2. массового создания пачки параграфов из всех новых действий сразу
3. выделения из тэгов в отдельную сущность названий локаций/сцен и группировки по ним параграфов в навигации
4. статуса параграфа по степени его готовности и отображения этого статуса в навигации (например, цифрами). Но этот пункт не критичен.
5. Возможности перехода из концовки одного сторигейма в другой с (опциональным) переносом значений параметров. Правда для этого понадобится скорее всего обеспечить возможность централизованного ведения набора ресурсов/ключевых слов и его присвоения сразу пачке сторигеймов. И доп. контроли по тому, чтобы изменения в этом наборе не ломали ничего во всех стори "пачки".

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