Use of the "visited" flag
paul_one
27 Feb 2007, 12:48Right,
Here I am, for the (almost) first time actually writing a little Quest game.
I have a basic small story cobbled together from slugs, snails, and puppy dog tails, but need to flesh it out a bit into a full stew of newt eyes and tongue of rat, etc.
So, I thought I'd get underway and start with the simple things, like room description, simple/preliminary commands.
Now I, perhaps nievely, thought that the "visited" property could be used to help me..
"Visited.. That'd be good because it means if you've been there before, the description won't be shown fully again!"
But checking for it in the "description" tag (inside the game block) always returns true..
It appears you have already been in the room before even the description of the room is displayed to the player (which feels wrong to me).
I will be able to work around it, but just wondered if this behaviour would be considered correct by the masses.. Does this behaviour also effect the object's variable "seen"?
Here I am, for the (almost) first time actually writing a little Quest game.
I have a basic small story cobbled together from slugs, snails, and puppy dog tails, but need to flesh it out a bit into a full stew of newt eyes and tongue of rat, etc.
So, I thought I'd get underway and start with the simple things, like room description, simple/preliminary commands.
Now I, perhaps nievely, thought that the "visited" property could be used to help me..
"Visited.. That'd be good because it means if you've been there before, the description won't be shown fully again!"
But checking for it in the "description" tag (inside the game block) always returns true..
It appears you have already been in the room before even the description of the room is displayed to the player (which feels wrong to me).
I will be able to work around it, but just wondered if this behaviour would be considered correct by the masses.. Does this behaviour also effect the object's variable "seen"?
witch wyzwurd
27 Feb 2007, 18:19I'm not really sure how you have your game coded and why you're having that problem. Maybe you could include your code? Also, a flag would work also, like:
"(visited) 1st Part of Room Description here"
If "flagname" on "(not visited) Second Part of Room Description"
Flag on "flagname"
Then if you want to show long version again, just turn the flag off.
"(visited) 1st Part of Room Description here"
If "flagname" on "(not visited) Second Part of Room Description"
Flag on "flagname"
Then if you want to show long version again, just turn the flag off.
007bond
27 Feb 2007, 20:47I understand what you mean Tr0n.
And I have to agree with you on this one. Flags like that should be set after everything else, not before. Or, even better: be able to choose when it is set!
And I have to agree with you on this one. Flags like that should be set after everything else, not before. Or, even better: be able to choose when it is set!
paul_one
27 Feb 2007, 22:25I don't need to supply code, I simply described/asked for opinions on the way I noticed Quest acts.I'm not really sure how you have your game coded and why you're having that problem. Maybe you could include your code? Also, a flag would work also, like:
- but, for simplicity:
define game <bleh>
start room <start>
description {
if not property <#quest.currentroom#: visited> then _
msg <You have not visited this room before!> else _
msg <You HAVE visited the room before..>
}
end define
define <start>
look <err?>
end define
You'll see that it comes up with the "You HAVE been in this room before" when you first start the game... Why?
Because Quest puts that property in there as soon as you are placed in that room but BEFORE anything else (although I haven't tried the beforeturn or anything).
As I've said, I've worked around this 'feature' - but wondered why the property was set before anything else, as surely other scripts assuming going to a new room would not hold this property, would turn out wrong - and the only purpose is to tell if you had a function which relied on an external source being present (be that flag/variable/object).
I see no reason for the flag to be set first, as that devoids the whole purpose of the flag - surely?
007bond
28 Feb 2007, 05:32perhaps the flag should be set when leaving the room.
Dr.Froth
28 Feb 2007, 06:21I use multiple room descriptions for every room in my game and the following works very well and problem free for me.
1.) Select run script option when making your room descrption.
2.) Choose a conditonal (if/then) script option.
3.) Let's say you are making a room called "Front Porch." In the top box of the conditonal select the "if a flag is on" choice.
4.) Create a flag that is easy to remember. I always use the name of the room followed by a "d" so in this case the flag would be called "frontporchd"
5.) In the "then" box, type a shorter description of the room like a sentance or so. Something like:
"The front porch remains quiet, almost unaturaly so. The house is south."
6.) In the else box type the long room description. In this case we'll type the following:
"The concrete steps outside the house were probably made long before you were a twinke in your father's eyes. From the front porch you can see the long rows of pine trees that still bring back visions of your childhood. The door into the house is south."
After you type in the description add a command to turn on the frontporchd flag.
7.) One last step. Go to custom commands for the room and make one of the following:
"look;look room;look at room;look at the room;x room;examine room;examine the room"
Then copy and paste your long room description into the "print some text" block on the script.
This will allow someone to get the long description again at any time by typing look (this overides the natural look that will only give the short description becuase the flag "frontporchd" is on.
This has worked great for me. My game has over 200 rooms and I have yet to encounter a problem doing things this way. (on a side note, if you need a bunch of crazy stuff happening in a single room there is a good way to do it. Make several versions of the room (front porch 1, front porch 2, etc) and give them all the same alias. You can then give two differant descriptions for each one using flags and make scripts that change the surrounding exits to differant versions of the room. This will allow you to create some very complicated scenarios using QDK. Just do not forget to have a script that moves any items the player dropped in front porch 1 to front porch 2 when you change the exits.)
Good Luck,
Dr. Froth
1.) Select run script option when making your room descrption.
2.) Choose a conditonal (if/then) script option.
3.) Let's say you are making a room called "Front Porch." In the top box of the conditonal select the "if a flag is on" choice.
4.) Create a flag that is easy to remember. I always use the name of the room followed by a "d" so in this case the flag would be called "frontporchd"
5.) In the "then" box, type a shorter description of the room like a sentance or so. Something like:
"The front porch remains quiet, almost unaturaly so. The house is south."
6.) In the else box type the long room description. In this case we'll type the following:
"The concrete steps outside the house were probably made long before you were a twinke in your father's eyes. From the front porch you can see the long rows of pine trees that still bring back visions of your childhood. The door into the house is south."
After you type in the description add a command to turn on the frontporchd flag.
7.) One last step. Go to custom commands for the room and make one of the following:
"look;look room;look at room;look at the room;x room;examine room;examine the room"
Then copy and paste your long room description into the "print some text" block on the script.
This will allow someone to get the long description again at any time by typing look (this overides the natural look that will only give the short description becuase the flag "frontporchd" is on.
This has worked great for me. My game has over 200 rooms and I have yet to encounter a problem doing things this way. (on a side note, if you need a bunch of crazy stuff happening in a single room there is a good way to do it. Make several versions of the room (front porch 1, front porch 2, etc) and give them all the same alias. You can then give two differant descriptions for each one using flags and make scripts that change the surrounding exits to differant versions of the room. This will allow you to create some very complicated scenarios using QDK. Just do not forget to have a script that moves any items the player dropped in front porch 1 to front porch 2 when you change the exits.)
Good Luck,
Dr. Froth
Alex
28 Feb 2007, 12:07The "visited" property is set as soon as the player enters the room. I suppose what you really want is a "visited before" property, which would get set as soon as the player leaves the room. I'll consider this for a future version, but in the meantime you could use an afterturn script.
For example if the player starts in a room called "start" (I've not tested this but you should get the idea):
For example if the player starts in a room called "start" (I've not tested this but you should get the idea):
startscript set string <oldroom; start>
afterturn {
if (#quest.currentroom# <> #oldroom#) then {
property <#oldroom#; visited before>
set <#oldroom#; #quest.currentroom#>
}
}
paul_one
28 Feb 2007, 13:54Freak - that's rather long-winded, and a LOT of double effort put in.
It's easier to define a custom description script, which I am in the process of doing.
There's another stumbling block I've come across, which I'm putting into the features forum.
Not sure if they already exist or not - but it's a nice challenge for someone.
Alex - I've been using a "been_here" property instead. But yeah, you get my idea.
I'm setting it when the description get's kicked off, as that's what I'm mainly using it for.
Of course, once you're somewhere, you've been there before - so that's where my property is gonna stay.
It's easier to define a custom description script, which I am in the process of doing.
There's another stumbling block I've come across, which I'm putting into the features forum.
Not sure if they already exist or not - but it's a nice challenge for someone.
Alex - I've been using a "been_here" property instead. But yeah, you get my idea.
I'm setting it when the description get's kicked off, as that's what I'm mainly using it for.
Of course, once you're somewhere, you've been there before - so that's where my property is gonna stay.