Новый текстовый формат исходного кода игры: TXT2QSP

Базовое описание и действия.

#начало
!BASE
*P 'Базовое описание'
ACT 'Базовое действие':
    ...
END
!ENDBASE
! Ну а здесь уже код локации.
...
-

Будут применяться следующие правила.
1. Специальные комментарии !BASE и !ENDBASE могут иметь любой регистр.
2. Между этими комментариями, не должно быть: пустых строк, комментариев, меток и прочего кода.
3. Между этими комментариями, разрешается только “*P” при наличии базового описания, и “ACT … END” при наличии базовых действий.
4. Однострочная форма базовых действий не допускается.
5. При наличии и базового описания, и базовых действий, “*P” должен идти первым.
6. Комментарий !BASE, при наличии, должен идти на следующей строке, сразу после названия локации.
7. Между комментарием !ENDBASE и кодом локации, не рекомендуется вставлять пустые строки (так как они попадут в начало кода локации, и будет некрасиво).
8. При конвертации из QSP-формата в текстовый, операторы “*P” и “ACT … END”, а также комментарии !BASE и !ENDBASE будут в верхнем регистре. Поэтому рекомендуется оставлять и писать их именно в этом регистре.
9. Код базовых действий при конвертировании в формат QSP будет форматирован следующим образом: из начала строки будет удалено до четырёх пробелов включительно.
10. Код базовых действий при конвертировании в текстовый формат будет форматирован следующим образом: в начало строки будет добавлено четыре пробела.
11. Аргументами оператора “*P”, “именами” базовых действий, “картинками” базовых действий, могут быть только монолитные текстовые константы, без использования выражений (конкатенации, результатов функций, переменных). Строковые подвыражения допускаются.
12. Указанные текстовые константы рекомендуется обрамлять в одиночные апострофы, так как при экспорте в текстовый формат они будут в одиночных апострофах.

Почему так строго, без комментариев, пустых строк, форматирования?
Как только мы начнём эти файлы конвертировать из одного формата в другой, все нюансы форматирования пропадут. Поэтому, мы на ровном месте получим “расхождение”, при использовании систем контроля версий. Следует этого избегать.

Знаки “#” и “-”.

Если строка внутри локации (в описании, коде действий, коде локации) начинается со знака “#” или “-”, этот знак должен дублироваться, когда исходный код представлен в “текстовом” формате.

Таким образом:
при конвертировании из “.qsp” в “.txt”, соответствующие знаки в начале строки дублируются;
при конвертировании из “.txt” в “.qsp”, соответствующие продублированные знаки в начале строки “склеиваются” в один.

Пример.

! Локация в файле game.qsp
'Я сбросил полотенце.
- Ну и ну! - ахнула принцесса и покраснела.'

! Та же локация после конвертации в файл "game.txt"
'Я сбросил полотенце.
-- Ну и ну! - ахнула принцесса и покраснела.'

При этом, если имя локации начинается со знака “#”, то в текстовом режиме исходного кода, пробел между именем локации и соответствующим знаком начала локации обязателен.

Пример.

# #Бой
...
-

Для полноценного внедрения нового формата, следует:
1. разработать утилиту txt2qsp;
2. разработать утилиту qsp2txt.

главное, чтобы

!BASE
*P "бла-бла
!BASE
бла-бла
!ENDBASE"
!ENDBASE

не вызывало коллапса.

При наличии !ENDBASE и при условии, что базовое описание и базовые действия будут идти сразу после “начала” локации, кажется !BASE вовсе и не нужен.

Aleks Versus,

главное, чтобы
…
не вызывало коллапса.

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

При наличии !ENDBASE и при условии, что базовое описание и базовые действия будут идти сразу после “начала” локации, кажется !BASE вовсе и не нужен.

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

Добавил ещё два пункта.

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

Пароли в бинарном файле.

При конвертировании файла утилитой txt2qsp в бинарный формат, пароли поддерживаться не будут. При конвертировании в текстовый формат утилитой qsp2txt, будут обрабатываться только файлы без пароля.

Существующая парольная защита QSP-файлов, является атавизмом. Реальной защиты она не несёт (взламывается на раз-два виндовым блокнотом), неудобства создаёт. Поэтому нужно от неё избавляться.

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

Учитывая, что исходный код библиотеки и плеера открыт, вашу игру в принципе ничто не может защитить от “чтения”. Но применив обфускацию и PGP-шифрование, вы сделаете процесс взлома весьма трудоёмким, а результат - малополезным. К тому же, PGP-шифрование защитит вашу игру от подделок.

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

Поддержка старого бинарного формата.

Описание форматов можно найти в официальном репозитории: gam_desc.txt.

Старый бинарный формат QSP-файлов, поддерживаться утилитами не будет.

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

При конвертации в текстовый формат, файл старого бинарного формата выдаст ошибку “Неизвестный формат файла. Возможно, вы используете файл устаревшего формата. В таком случае, откройте его в редакторе QGen и пересохраните.”

Есть и другой вариант обработки строк, начинающихся с # и -:

#начало
.....
-начало

Это избавит от необходимости экранирования и сделает код более читаемым (видно, что за локация закончилась).

newsash,
вставив в код локации строку “-начало” можно будет точно так же сломать конвертацию. Поэтому от необходимости экранирования не избавляет.

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

Насчёт читаемости, сомнительно.

Так. Дублирование знаков “#” и “-” работать не будет.
Потому что при экспорте из кугена, конец локации выглядит так:

--- Меню ---------------------------------

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

Предложения принимаются. Чем заменить?

Нужно, чтобы экранирующий символ не слишком нарушал читаемость кода и описательного текста. Может, просто пробел добавить? Что думаете?

Предлагаю вместо экранирования попробовать разные варианты с концом локации.
1. Строка, начинающаяся с —
2. Строка, начинающаяся и заканчивающаяся с -, – или —
3. -ENDLOC
4. Другие варианты.

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

UPD. А что мешает рассматривать как конец локации только те строки с - в начале, следующая не пустая строка после которых начинается с #? (или конец файла)

Неудачные примеры с “-” в начале строк: TXT2GAM в данный момент умеет игнорировать строки QSP.
То есть “-” будет проигнорирован, если он находится “внутри” кавычек.

Byte,
ага, а если нет, то всё поломается. Может, просто принудительно окавычивать строку с “-” при экспорте в текстовый формат?

newsash,
1. не будут работать файлы с концом локации “-”.
2. не будут работать файлы с концом локации “— Моя локация ———————————”
3. громоздко.

Между локациями, ранее допускался произвольный текст. Следовательно, там может в данный момент храниться всё что впихнул туда автор. Например, комментарии, или директивы препроцессора.