Помощь в создании "Асатамы III"
Спустя годы я все-таки вновь возвращаюсь к мысли создать еще более глобальную и интересную игру в этой серии, несмотря на то, что, возможно, это практически никому не интересно (а вдруг станет интересно?). (и вообще я так понимаю в целом в “сообществе любителей текстовых игр” тишина, или это поверхностное впечатление?)
Новую часть делаю медленно, но кропотливо и аккуратно, не совершая прошлых ошибок. Это касается и общих моментов касательно геймплея, и более удобного кода - чтобы не рябило в глазах и все было понятно, если придется к нему возвращаться спустя какое-то время. Упрощая то, что можно упростить, оптимизируя то, что можно оптимизировать и улучшая то, что требует доработки, как-то так.
Но уже появляются вопросы, с которыми нет сил биться совсем в одиночку. В частности, это касается моих гуманитарных мозгов. Код я осваивал самостоятельно и с чем сумел разобраться, то и использовал в первых двух частях. А с чем не сумел - так и осталось темным пятном.
Поэтому создаю эту тему не только по тому вопросу, который волнует сейчас, но и впрок, если появятся новые.
1. Первый вопрос касается моего главного пробела в языке qsp, из-за которого для обеих частей я придумал собственный большой костыль, который сейчас уже кажется слишком неудобным. Это массивы. Я много раз пытался их освоить и уже не пытаюсь. Поэтому прошу просто подсказать, что и как писать, чтобы реализовать конкретную идею.
ЧТО ИМЕЕМ
1. Есть переменная $mon=‘’ - это имя монстра.
Когда игрок нападает на монстра, мы присваиваем ему имя, а затем переходим в служебную одноименную локацию gs ‘mon’
В ней содержатся все данные о любом монстре, выглядят это так:
if $mon = 'Крыса':
hp = 10
st = 10
... и так далее
end
Причем данных, особенно если монстр непростой бывает очень много, до 30+ строчек получается.
2 Когда игрок находится в свободном плавании, он рискует столкнуться со случайным монстром. Это зависит от типа локации “Лес”, “Поле”, “Горы” и т.д., и сложности конкретного отрезка местности - “1, 2, 3…”. Т.е. если игрок в лесу и сложность 1, он будет встречать всяких зайчиков и оленей и в худшем случае какого-нибудь волка повстречает. Если он в горах и сложность максимальная, то встретит какого-нибудь убер-страшного горного великана. А некоторые монстры могут встречаться сразу в нескольких типах местностях - разбойник, например. Также некоторые монстры могут встречаться на нескольких уровнях сложности. Т.е. мы не обязательно столкнемся с тем горным великаном, вполне, что за поворотом затесался горный козлик, мирно жующий травку. +какие монстры при одинаковых условиях встречаются реже или чаще остальных.
Сам код в этом месте определения монстра получился у меня жутко неудобным. Я просто на отдельной локации “checkmon” настраивал множество условий и вероятностей, типа:
if местность = лес:
if сложность = 1:
х=rand(1,12)
if x < 2:
$mon='Заяц'
end
if x > 1 and x < 5:
$mon='Разбойник'
if rand(1,100) > 80:
$mon = 'Матерый разбойник'
end
end
if x > 4:
$mon = 'Волк'
end
if x = 12:
$mon = 'Медведь'
end
end
if сложность = 2:
!то же самое, но если хотим чтобы какой-нибудь заяц встречался и здесь, то также вручную добавляем и его:)
end
end
Итого, при том что монстров очень много и условий то же, все это со временем превратилось в кашу.
ЧТО ХОЧЕТСЯ РЕАЛИЗОВАТЬ
Я представляю себе это так: есть некий пакет с именами монстров и с их “полевыми характеристиками”, типа каким местностям они свойственны, какая у них максимальная и минимальная планка сложности и какой уровень редкости.
Когда игрок должен столкнуться со случайным монстром он одной командой просто получает из этого пакета своего монстра, - т.е. оттуда сразу же исключается те, кому местность, в которой находится игрок не по душе, те, кому нынешняя сложность не подходит и из оставшихся рэндомно кто-нибудь вытягивается, но у кого-то в силу редкости шанс на вытягивание ниже или выше.
Вот как такой пакет “написать” без полного погружения меня в мир массивов :)
И какая должна быть команда в момент столкновения игрока с монстром и может ли она уместиться в одну строчку?
Я считаю, что скрывать код и картинки - неблагодарное и бесполезное занятие. Денуво игры защитить не может. Не тратьте время в пустую. Лучше потратить его на то, что бы игра получилась такой, чтоб ее механики не хотелось обходить.
Спасибо!
Снова вопрос. Хотел провернуть одну штуку, но qsp быстро сообщил что оно так не работает:
Допустим, есть несколько переменных
$travelforest, $travelhills, $travelmount, на каждую есть условный пакет [] из 16 событий, которые могут произойти, если путешествовать по лесам, холмам или горам соответственно.
Но есть и другой тип переменных $dungforest, $dunghills $dungmount - в которых также есть по 16 значений, обозначающих какие данжи можно найти на соответствующем типе территории.
Есть общие переменнаятерриторий которая много еще за что отвечает - $terra - среди значений которой есть те самые forest, hills, mount и так далее
Так вот я хотел все это совместить в одной формуле, например:
$travel<<$terra>>[x] - там, где требуется активировать случайное событие X из набора возможных для соответствующей территории. И то же самое: $dung<<$terra>>[x]
Но в обоих случаях - ошибка. Я, конечно, понимаю, что дело в этих << >>, но неужели нет способа делать имена переменных вариативными?
mkir,
Сложно разобраться, напиши пример поподробнее со значениями и кодом, а то непонятно, зачем совмещать переменные.
Пока нет доступа к коду. Ну, смысл в том, что часть переменной изменяется, в зависимости от того, какая сейчас территория. Все можнт было бы через ифы решить, но т.к. пытаюсь параллельно осваивать что-то новое и разбираться, хотел это решить таким образом
mkir,
Ты хочешь, чтоб в имени переменной было вставлено имя другой переменной и при этом, это было бы не имя, а значение? Напрямую так нельзя, можно через динамик, вроде…, вечером посмотрю.
dynamic ’$dung<<$terra>>[X]’
О! Попробую
mkir,
Пробуй, но думаю я, что это незадокументированная особенность, эдакий чит. В одном проекте использование таких имён приводило, через некоторое время, к ошибке. Правда, там в одном имени использовалось три значения.
dmvikar:
незадокументированная особенность, эдакий чит
http://wiki.qsp.su/help:dynamical
Советую обратить пристальное внимание на обработку подвыражений, если хотите избежать >80% проблем с dynamic.
Engineer, вот ситуация:
Re: Как сделать?
Ошибка 123
Слишком много переменных с одинаковым хэшем!Через 3 игровых дня начинает ругаться на эту строку.
Код:
!код добавляющий нпс на локацию
dynamic ‘$loc_<<X[num]>>_<<Y[num]>>_<<Z[num]>>_<<R[num]>>[] = num’
А чит в том, что символы <> недопустимы в названии переменной, согласно документации. Но я не исключаю того, что я просто мало знаю о qsp и dynamic специально для такого случая и придумали.
В названии переменной не участвуют символы <>, это подвыражение для dynamic.
В указанном примере проблема в том, что слишком много разных строковых переменных имеют одинаковое значение. Похоже, автор упустил утечку, или просто забыл их подчищать. К названию переменной это не имеет никакого отношения.
Опытным путем определил, что может быть максимум 8149 переменных с одинаковым хэшем.
i=0
:jump
i+=1
dynamic '$g<<str(i)>> = "test"'
dynamic '*nl $g<<str(i)>> + "+" + "$g<<str(i)>>"'
if i<=10000: jump 'jump'
!выводит строку 8149 раз, после чего - ошибка 123
Engineer, по документации 50 переменных может быть с одинаковым хешем.
Я ковырял аналог этого кода с этой переменной, там не было утечки и все подчищалось, даже там, где не надо. Я выводил список образованных переменных каждый ход и они топтались в районе количества 1100-1300 (если не путаю ничего), а потом внезапный крах.
Я сейчас использовал твой код:
сделал переменную <<str(i)>><<str(i)>><<str(i)>><<str(i)>>, получил 4617 записей;
сделал переменную <<str(i)>><<str(a)>><<str(b)>><<str(c)>>, где a,b,c =rand(0,10), получил 8407 записей;
сделал rand(0,100) - 9091;
сделал rand(0,1000) - 7615.
Возможно, из всего этого и можно вывести какую-то закономерность, но главный вывод - не злоупотреблять в dynamic <<>>.
Значит я перепутал, хэш действительно идет для имени переменной, но может быть одинаковым для разного, но похожего набора символов. И когда одного из вариантов полученного хэша становится больше 50 - игра выдает ошибку.
Трудно злоупотребить dynamic. Только может запутаешь себя кодом. Но вот 1100 сгенерированных переменных… конечно такой кошмар никогда не рекомендуется, с dynamic или без.
А на предыдущий мой комментарий не обращайте внимания.
Опять дам рекламу на свой канал, уж простите:
Подвыражения (те самые ДВОЙНЫЕ угловые скобки)
Массивы
Оператор DYNAMIC
Краткий пробег по Ограничениям QSP
Ограничения QSP на wiki
DYNAMIC на wiki
Подвыражения в статье о Строках
Добрый день!
Не могу разобраться с OBJ.
Колонка предметов у меня в игре оформлена так:
МЕНЮ
ИНВЕНТАРЬ:
Соответственно, все новые предметы, что появляются у игрока, добавляются в колонку под “инвентарь”, и меня это устраивало. Но как “obj” у меня оформлены не только мечи да луки, но и возможные спутники игрока.
Возможно ли сортировка? Возможно ли, если в начале игры добавить поочередно “МЕНЮ” “ИНВЕНТАРЬ:” “СПУТНИКИ:”. Какие-то obj добавлять строго под “инвентарем”, а какие-то строго под “спутниками”?