Как сделать?

Poganec37,
Есть opengame, savegame и addqst. Можно использовать сохранение игры

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

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

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

debug=1

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

В справке все достаточно хорошо расписано. Если все ещё сложно, можете скачать старые игры с сейвами.

Poganec37,
особо не разбирался и не тестировал, сам все проверишь, если тебе это необходимо.
Из всего вышесказанного товарищами получается что SAVEGAME - это команда для сохранения игры. Но так как оно сохраняет даже окно и текст, то надо сделать следующее:
1. В части игры, в момент ее завершения пишешь локацию завершения, к примеру, endloc типа

SHOWSTAT 0
SHOWOBJS 0
SHOWINPUT 0
DEBUG = 1

'Часть вторая'

act 'Начать игру':
SAVEGAME 'part2.sav'
gt 'nextloc'
end

В локации nextloc напишешь что-то типа продолжение еще не готово или инструкцию, какой файл нужно открыть плеером.
2. В игре-продолжении на стартовой локации предлагаешь либо начать с дефолтными условиями либо загрузить файл part2.sav из предыдущей версии и пишешь DEBUG = 1. Так же создаешь копию локации endloc:

'Часть вторая'

act 'Начать игру':
gt 'nextloc'
end

где nextloc будет стартовой локацией второй части.
Предварительно, выписываешь все ключевые переменные, от которых будет зависеть сюжет, и пишешь развилки в зависимости от их значения.
Т.е., если ты хочешь, как МЕ, то у тебя будет переменная, отвечающая за жизнь персонажа lifepers, если жив =0, если умер =1. В новой части пишешь условие:

if lifepers=0:
'Этот персонаж живет припеваючи'
else
'Этого персонажа сбила машина и он похоронен на местном кладбище.'

Это теория, на практике не проверено.

Вопрос к специалистам.
Товарищ mkir в своем проекте добавляет монстров в битву при помощи локации, в которой расписаны все характеристики всех монстров, но выбираются они по условию, которым является имя монстра. Поэтому, перед каждым боем эта локация перечитывается. Если взять 20 монстров и 30 характеристик, получим 600 строк.
Когда я делаю что-то подобное, я создаю массив на монстров и на каждую их характеристику и все это объединяю через индекс, локацию инициализирую один раз за всю игру, а потом путем поиска по массиву имен нахожу нужный индекс, а по индексу все остальные значения.
С точки зрения игры, в памяти будет находится одинаковое количество переменных в обоих случаях, но т.к. во втором случае это массивы, то значений получится больше. Суть вопроса - какой метод наиболее предпочтительнее использовать и почему?
Понятно, что при текущих аппаратных мощностях оба варианта будут срабатывать мгновенно, но все же.

Любой. я однажды всю игру сделал в одной локации через замену переменной для отображения текста, а в другой раз всю игру засунул в 140 символов, которые прокручивали голосовые записи.

Коротко: это конкретно ваше дело как написать игру. Даже если кто-то и полезет в код, вам будет глубоко до фени, что он о нем думает.

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

dmvikar,
Каждая переменная в qsp - это массив. Всего можно использовать 12800 имён переменных/массивов одновременно. Вот отсюда и надо думать, что правильнее.

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

dmvikar,
Ну там есть ограничения, насколько я знаю. По производительности попробуй погонять Истребление, там ДеГросс что-то про лимиты писал

Последний из Гаяр,
Да ну нет же!) Наверно, я как-то не так объясняю. Мне интересен процесс обработки кода в принципе, а не конкретно qsp. Потому как для qsp 600 строк и 30 переменных это ничто и обрабатываются они незаметно для пользователя. Проблемы начинаются после 4 миллионов или 40-ка, я уже точно не помню. Ну да ладно, вопрос не столь важный, т.к. предела ресурсов достигать не предполагается.

dmvikar,
Конкретно, насколько я помню, писал ДеГросс, что корректно обрабатываются только 50 действующих нпс, а так вроде до 300 субъектов, это Svartberg вроде писал, в теме Sanctuary[разработка], а также мой личный опыт, что нормально и достаточно быстро обрабатывает таблицу на 740 ячеек, хотя, ну может это моё железо, ваше покажет больше.

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

обычно до 10 действующих лиц делают в играх

dmvikar,
QSP будет отъедать оперативку по мере того, как заполняются переменные/массивы, насколько я понимаю. Неважно, будут это именно отдельные переменные или ячейки массива, данным нужно где-то храниться. Само собой лучше бы неиспользуемые данные прописать в виде кода на локации (сделать базу), а уже потом тем или иным образом выдёргивать в массивы/переменные. Однако, evp говорил (кажется), что и сама игра на момент выполнения вся лежит в оперативке.

Если вопрос о том, где легче осуществлять поиск, в переменных, массивах, или по текстовому значению отдельной переменной, всё зависит от задачи. Я знаю, что даже arrpos для массива в 100 тыс элементов заметно подвешивает игру, большой объём HTML-разметки подвешивает игру. Приходится либо практически устанавливать пределы возможностей QSP, и уже отсюда решать задачи, либо лезть в исходный код и искать пределы в конкретной реализации.