QGen: предложения

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

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

Что относится к “критическим” ошибкам?

Нагенерившийся в процессе тренировочной разработки список пожеланий.
Если я какие-то функции просто по молодости и глупости не нашел, укажите дураку.
1 Переключатель код/текст чтобы можно было увидеть всю комнату в виде кода. Существующий способ (через экспорт) - долгий, и не всегда удобный.
2 Кнопка при нажатии на которую автоматически собираются все переменные введенные/задействованные в игре и выкидывающая их во внешний файл с указанием мест применения, и их возможными вариациями. Для автоматизации создания списков переменных.
3 Минимальные html функции оформления текста в окне описания, т.е. кнопки для форматирования.
4 Возможность открыть последние n открывавшихся игр прямо из меню “игра”.

1. Реализуемо только в одну сторону, когда базовые действия и базовое описание добавляются к коду локации.
В обратную сторону “извлечь” код будет нельзя.
Если задумать это как некий “предпросмотр”, то будет работать. Но я не слышал, чтобы это кому-то (кроме тебя) особо было нужно. То есть, те авторы, которые желают видеть “всю локацию в виде кода”, вообще не пользуются базовыми описаниями и базовыми действиями - отключают эти окошки, и ведут разработку исключительно в коде локации.

2. Все переменные собрать невозможно, благодаря такой фигне как “динамическая генерация кода”, он же оператор DYNAMIC. Поэтому, удастся отследить только “явно” заданные переменные. Более того, в некоторых местах они используются не “напрямую”, а через символьные выражения, содержащие их имя, например, оператор ARRPOS.
Так что, благодаря синтаксису языка, возможности в этом плане довольно ограничены.

У меня есть утилита для анализа кода игры, которая собирает информацию по явно используемым переменным, выявляет некоторые легконаходимые ошибки и т.д. Со временем, такую “препроверку” планировалось ввести и в QGen, но пока что я для этого слишком занят(делаю порт плеера на Андроид, плюс еще по сайту QSP куча дел).

3. Я бы все же предпочел, чтобы перед использованием html автор изучил его, а не просто “жмакал на кнопки”. В первую очередь потому, что использование html в рамках QSP далеко не тривиально, есть свои нюансы. Поэтому, более высокий “порог вхождения” благодаря отсутствию кнопок меня вполне устраивает.
Выгода от “кнопок разметки” небольшая. Автор не будет часто ими пользоваться, ну разве что в главном меню, во вступлении, в эпиграфе. Если текст будет “размечен” в самой игре, в описаниях локаций, это будет выглядеть ужасно. Не стоит.

4. Т.н. “recent files” - действительно, нужный пункт. Остается ждать, пока кто-нибудь реализует. Заняться QGen’ом вплотную сейчас особо некому, Бакс ушел, а Байт прикасается к QGen редко, т.к. другими делами занят.

Спасибо за разъяснения. Если что-то еще в голову придет писать?

Csahes,
пиши, конечно.

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

Думаю, полезная функция была бы в QGENe, на локации отображать информацию (модальным окошком, по кнопке или любым другим способом) с каких локаций есть в ход на текущую, т.е. нужно пробежаться по всем локациям с поиском gt,xgt, gs, xgs «текущая локация» и вывести список названия локаций в которых эти команд встречаются. Если будет не просто список, а список с возможностью ткнуть мышкой и перейти к локации, было бы ещё лучше.

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

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

ИМХО, те кто пользуют QGen для написания игр, в 90% случаев имена локаций задают явно и полностью.

HIman,
указанное ограничение, конечно, не отменяет полезности такой “фичи”. Просто следует это ограничение всегда учитывать, и самому автору игры, и разработчику “фичи”.

Насчет 90% я бы поспорил. Чем сильнее автор злоупотребляет техноприбамбасами, тем чаще у него встречаются “генерящиеся” имена локаций. Бой, извращения с инвентарем, всплывающие менюшки, использование ссылок, и т.д., все это так и манит каждого автора.

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

Пример:

$win_loc = 'победа1'
$death_loc = 'смерть1'
enemy_type = 1
GOTO 'Бой'

По окончанию боя, переход будет задан так:

IF win=1:
  GOTO $win_loc
ELSE
  GOTO $death_loc
END

Если пробежаться по GT, GOTO, XGT, XGOTO, GS, GOSUB, XGS, XGOSUB, то мы не встретим “явных” переходов на локации победы и проигрыша. Локации будут считаться “потерянными”, т.к. на них нет явных переходов.

Кстати, для проверки я бы добавил возможность в QSP выбирать определенную локацию… а то каждый раз для проверки приходится с начальной локации gt выполнять.

Dark[Ol(U23)leneri], это делается путем вставки в локацию “Начало” строчки ACT “проверка”: gt “твоя новая локация”, перед этой строкой также можно любые переменные вставить которые тебе нужны.

Что касается “фичи”, то нужно определиться для кого она нужна, в первую очередь начинающим, кто ещё не увлекается техноприбамбасами и не засовывает названия локаций в переменные.
Можно сказать, что это некое подобие того дерева всей игры, про которое многие говорят, но никогда не видели :)
Кстати, я за дерево, которое строится по том уже принципу “пробежаться по GT, GOTO, XGT, XGOTO, GS, GOSUB, XGS, XGOSUB”, да оно не будет обрабатывать вычурный код, но оно нужно для все тех же начинающих, чтобы видеть всю картину и не терять входы/выходы.

HIman:

Dark[Ol(U23)leneri], это делается путем вставки в локацию “Начало” строчки ACT “проверка”: gt “твоя новая локация”, перед этой строкой также можно любые переменные вставить которые тебе нужны.

Не нубсы, знаем. Просто задолбались.

HIman:

Кстати, я за дерево, которое строится по том уже принципу “пробежаться по GT, GOTO, XGT, XGOTO, GS, GOSUB, XGS, XGOSUB”, да оно не будет обрабатывать вычурный код, но оно нужно для все тех же начинающих, чтобы видеть всю картину и не терять входы/выходы.

Мой препод по высшей математике хотел собрать семейное древо романовых в нечто похожее. Вышло 24 листа А4 склеенных между собой при том, что вся родословная была написана 8мым шрифтом… Как-то это нечитабельно что-ли

Dark[Ol(U23)leneri],
если ты имел в виду “проверку во время выполнения”(что, само собой, не относится к QGen в обозримом будущем), то давно уже написан отладчик для QSP.

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

Итого: при “топорной” реализации не будет работать для большинства игр; при “правильной” же реализации профит небольшой, а усилий на это угрохать нужно гору.

Так что, лучше заняться более важными вещами. Благо их у нас всегда навалом.