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

А создание некой переменной debug в самом начале, от которой зависит в каком режиме запускается игра разве не подходит?

rrock.ru:

А создание некой переменной debug в самом начале, от которой зависит в каком режиме запускается игра разве не подходит?

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

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

Это реализуемо. Не уверен будет ли это востребовано. Хотелось бы узнать что на этот счёт думают авторы, уже имеющие несколько опубликованных игр.

Nex, тогда нужно будет хранить 2 версии игры - в папке с проектом дебажная, а релизную - куда-нибудь в другую папку.

Nex:

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

Ах ты. Точно! Есть ведь qproj. Я как-то забыл о нём. :=D

rrock.ru,
ну да, потребуется либо операция “публикации” - сборка финального варианта в отдельную папку для последующего распространения, либо просто безвозвратная операция “вычистки” всего дебажного кода.

Публикацию рано или поздно всё равно придётся встраивать в куген.

Nex:

либо просто безвозвратная операция “вычистки” всего дебажного кода.

не вариант. Потому что после выпуска обычно хочет что-нибудь еще переделать.

Еще есть вариант хранить текст игры в проекте в формате TXT2GAM, а публиковать уже в формате куспа.
Да и вообще хранить игру в самом проекте.

хранить текст игры в проекте в формате TXT2GAM

Не годится, потому что формат TXT2GAM не поддерживает базовые описания и действия.

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

rrock.ru,
не вижу причин для этого.

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

rrock.ru,
никто не предлагает “сохранять по два варианта”. Автор всегда будет работать только с “полной” версией.

Ты представляешь вообще процедуру публикации? Это автоматическая сборка всего что нужно - файл игры, файлы оформления, манифеста в отдельный архив либо готовый инсталлятор для последующего распространения. Естественно это всё будет собираться не в папку проекта, а в “Мои документы”, на рабочий стол или куда там укажет пользователь.

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

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

Ну так что? “Даёшь проектный файл и “публикацию”!”?

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

Nex:

хранить номера отмеченных строк по локациям

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