Forums » Advanced Editor Forum » Read Thread

A real quick question: If players were able to accept or refuse quests, how would I be able to track that?  I mean, I'm using variables currently, but seemingly, that means that I'm going to have a TON of variables.

May I ask why you are using variables for said "quests"?

Probably so that multiple quests can be going on at the same time, saying "yes" doesn't mean "I'll stop whatever I'm doing and begin right away", et cetera.

...so he can track whether the player accepts or refuses them? Like he said in the OP?

But yeah, firelion, not sure what else to tell you. Each quest will need a yes/no toggle. How many were you planning on the game having?

If your game isn't going to keep tabs of what you've chosen to do so your choices can matter, then it's not going to be much of a CYOA, is it?

... Well, yeah. Some stories demand a lot of variables. xD Dunno what to tell you.

Could make a 'binary' string of em.

Say, 4 quests. Accept 1st, 3rd and 4th.

1011

Complete first

2011

Fail third

2031

Advantages of this, is that all your quest log is stored in one place, in one variable. First disadvantage, is you have to be very exact in your foreplanning, otherwise you're going to have to fix a lot of code later on to little benefit. Second, and more involved, is that later down the track when you want to check if Quest 2 was accepted, denied, finished or failed, you'll have to do a little.wizardry

%questvariableTemp = %questvariable (to keep your questvariable clean and unworked, you'll need another variable with the same value)

If %QuestvariableTemp >500 %questvariableTemp := %questvariableTemp -1000
If %QuestvariableTemp >500 %questvariableTemp := %questvariableTemp -1000
If %QuestvariableTemp >500 %questvariableTemp := %questvariableTemp -1000
If %QuestvariableTemp >500 %questvariableTemp := %questvariableTemp -1000

This'll check if the first digit is > 500, so there's something in the first quest line (which we don't want to deal with), and reduce it until it is zero. Then, you can put in your If QuestvariableTemp >400 then Blah, if >300 then Second blah. Etc.

Precisely what you're saving in headaches and time and cohesion and readability and good practice, I'm not sure, but it's A method of doing such. I'm sure others know far cleaner, but simply using a bunch of variables isn't a bad thing. You can, as hopefully has been demonstrated, make 1, 2, 3, 4 mean 4 very different things, and thus save a lot of information in it, for a simple digit.

And there's nothing stopping you resetting a variable once it's completed a function for you, and using it to track something else. In my own works, I've made Temp1, Temp2 to Temp5, just for such things that'll only be tracked for a short time. End of every chapter, reset em all to zero, and they're good to go.

I was considering whether something like this would work, but it was checking quest statuses after the fact that I couldn't get straightened out in my head, as far as I could see there wasn't any way to only check one specific digit in a string.

And keeping track of separate quest variables doesn't seem that difficult, I can't imagine they have so many it would become a serious issue, considering how many pages of writing each would represent. %RESCUECAT or %SLAYORCS with a range of zero to three for refused/accepted/failed/completed is simple enough.

That's part of the problem with combining two different questions into one answer, to call each variable a question (Quest 1 status? Y/N/Failed/Completed?). Cleanable with such as I posted, but why? But why why why?