One of the parts of my text adventure (and so many others I see) is going to be a maze.

The maze will be full of twisty passages so that you might exit a room to the north, but enter another room (or even the same room) from the west. Make sense?

Now, I want to do something a little more tricky than that, as the above is easy to do.

I want to drop the compass directions - your disorientated so after wandering around and doubling back you won't really know which way is north, especially if the walls are impregnated with magnetic rocks .

So we have now changed (N)orth, (S)outh, (E)ast, & (W), to (F)orward, (B)ack, (L)eft & (R)ight. Again, I think this is relatively simple.

The tricky bit is getting the orientation based on which way you entered a room.

Lets say to start with that you enter the maze by going SOUTH, once in you could have the 4 exits F, B, L, & R. Going BACK would take you back the way you just came (back at the entrance to the maze).

Here comes the tricky bit, so firstly I will give a 3 room map.

+---+     +---+
| 1 |  #### 3 |
+-#-+  #  +---+
  #  +-#-+
  #### 2 ####
     +-#-+  #
       #    #
       ######

In this map, Room 1 is the Entrance to the maze with exits SOUTH (into the maze) and UP to ground level.

Room 2 is a standard maze room with exits F, B, L & R - depending on where you entered the room from.

Room 3 is a dead end with 1 exit (BACK), although it could easily be another maze room.

What I want to centre on is Room 2, and how the exits change depending on how you enter the room! I will append all exits with their relative cardinal points for ease of reference, but the use of the compass directions in the maze will not be allowed (with the exception of the entrance as you know where you are).

So lets say you enter the maze S (effectively entering the maze room from the W), B (W) will take you back to the entrance, L (N) will take you to the dead end and F (E) & R (S) will bring you back to where you are.

Lets say we have gone L (N), we have reached a dead end, turned round and gone B (in this case W) on ourselves. The exits have now changed! B (N) now leads back to the dead end and R (W) will take us back to the entrance, F (S) and L (E) now loop back on themselves to room 2.

If we go F (S), we leave the maze room and re-enter the maze room, but now the exits have changed again, B (E) will lead us back the way we came, F (W) will take us to the Entrance, L (S) will just make us make the same loop again and R (N) will take us to the Dead End.

Confused we decide to go B (E), we re-enter the maze room again. Now F (N) will take us to the dead end, L (W) will take us to the entrance and B (S) & R (E) will loop back into the maze room.

Does all that make sense?

=======

To combat the confusion of the maze, I would like the player to be able to drop markers. Ideally they would find a bag of markers somewhere. Then, when they are in the maze they could drop a marker to mark the room.

So we find "A Small Bag of Tiles", examining the bag reveals "A small bag of tiles, there seem to be about 20 tiles in the bag and each tile appears to be numbered individually".

When in a maze room and we use the command "DROP TILE" I want to avoid the dialogue "Which Tile: A Small Bag of Tiles, Tile 1, Tile 2, etc..."

If there is any choice, I would want it to be "Which Tile: A Small Bag of Tiles or A Tile"

I think I would rather go down the route of using 2 verbs though, provided that people would think of it.

So DROP TILE would drop the bag, but PLACE TILE would result in "you place tile N on the ground"

Once a tile has been placed, I don't think I want the player to be able to pick it back up again - this saves issues with a counter if they have placed 9 tiles and pick up tile 5.

So TAKE TILE would result in something like "You decide not to pick the tile up, you don't want to get lost now do you?"

I am presuming a simple script will allow the tile number to be increased by 1 each time a tile is placed so that you don't have to choose.

There is one last thing here, where the tile is placed.

I could only allow one tile to be placed in a room - "There is already a tile here" OR I could allow the player to place a tile at each doorway that they enter the room from.

For example, using the above map, we have entered the maze and we place a marker, we decide to go F (E) and loop round back on ourselves.

If we have 1 tile per room the description would read something like, "You are in a maze room, there are 4 exits, F, B, L & R. On the floor you see a tile with the number 1 on it"

If we have 1 tile per entrance, it would read something more like "You are in a maze room, there are 4 exits, F, B, L & R. On the floor in front of the left exit, you see a tile with the number 1 on it"

Obviously the latter would make it much easier for the player to map out the maze, and perhaps they could even choose to place 4 markers when they enter the room? But how much more difficult will that make the code - especially considering the changing of the exits based on the perspective of which entrance you have come through.

I hope all this makes sense.

And thank you for taking the time to read.

I can probably offer some specific coding options, but I wanted to get clear the mechanics first.

I had at one point considered adding a "back" option to my room movement. I wanted the player to be oriented and going back would take you back to the room you were just in. Here was the problem (and why I gave it up): what happens if you do it twice?

Let's say you have three rooms in a row, west to east. You start in the west-most room. You go east once and east again, so that now you're in the east-most room. You have come in from the west, so you're facing east. Now you type "back".

1) What is your orientation? (Did you step backwards into the previous room, so you're still facing east, or did you turn around to go back into the previous room, so you now face west?)

2) If you are in the rightmost room and hit back, you will be in the center room. If you hit back again, do you go back to the right most room (since you were just there), or do you go back to the left most room - a bit like a web browser's "back" button?

I suppose the questions are related in some ways. If "back" is relative to your orientation, then it sort of makes sense. If "back" means you step backwards but don't change orientation, then back twice would take you all the way back to the west room. If "back" means you turn around and go back, then back twice would return you to the east room, since you keep turning around.

In the interest of consistency, how you implement "back" has implications for "left" and "right" - do you sidestep or turn in that direction? If "left" and "right" cause you to turn in that direction, then it seems "back" should as well (so after "back", you'd be facing the other direction, and hitting back repeatedly would cause you to move back and forth between two rooms.)

Another possible way to design this: left and right just cause an orientation change (you spin left or right, but stay in the same room). Then the only way to move is forward or back. In fact, you could eliminate back altogether in that case. To go back, you turn left or right twice to turn around. That would allow the player to always know their orientation since it wouldn't change unless they changed it. It is a different approach, though.

jaynabonne wrote:I can probably offer some specific coding options, but I wanted to get clear the mechanics first.

I had at one point considered adding a "back" option to my room movement. I wanted the player to be oriented and going back would take you back to the room you were just in. Here was the problem (and why I gave it up): what happens if you do it twice?

Let's say you have three rooms in a row, west to east. You start in the west-most room. You go east once and east again, so that now you're in the east-most room. You have come in from the west, so you're facing east. Now you type "back".

1) What is your orientation? (Did you step backwards into the previous room, so you're still facing east, or did you turn around to go back into the previous room, so you now face west?)

2) If you are in the rightmost room and hit back, you will be in the center room. If you hit back again, do you go back to the right most room (since you were just there), or do you go back to the left most room - a bit like a web browser's "back" button?

I suppose the questions are related in some ways. If "back" is relative to your orientation, then it sort of makes sense. If "back" means you step backwards but don't change orientation, then back twice would take you all the way back to the west room. If "back" means you turn around and go back, then back twice would return you to the east room, since you keep turning around.

In the interest of consistency, how you implement "back" has implications for "left" and "right" - do you sidestep or turn in that direction? If "left" and "right" cause you to turn in that direction, then it seems "back" should as well (so after "back", you'd be facing the other direction, and hitting back repeatedly would cause you to move back and forth between two rooms.)

Another possible way to design this: left and right just cause an orientation change (you spin left or right, but stay in the same room). Then the only way to move is forward or back. In fact, you could eliminate back altogether in that case. To go back, you turn left or right twice to turn around. That would allow the player to always know their orientation since it wouldn't change unless they changed it. It is a different approach, though.

Heh, I tried to make that clear with my example above. Basically, forward, back, left and right are relative to the player and not the room.

in your scenario of 3 rooms, you move east twice, then "back" once puts you in the centre room. From now on, just using "back" would Ping-pong you between the centre room and the east-most room.

I am envisaging the command, back, left and right have you turn in that direction and exit. I want to avoid having the player turn and then then exit in 2 separate moves (or 3 for back) as it just adds even more confusion.

I do not want it to be like a browsers back button.

I'm not sure what you want (it would take me too long to map, lol pun, everything you want in your posts), but as for the movement:

just have multiple (separate) verbs~commands:

go_or_move_back, walk_or_strafe_backwards, go_or_move_forward, go_or_move_left, go_or_move_right, walk_or_strafe_left, walk_or_strafe_right

go_or_move = you turn (orient yourself) in that direction and then go in that direction

walk_or_strafe = you just go in that direction without turning (your orientation doesn't change at all)

* Err... my usage of "go", "move", and "walk" aren't placed very well... switch them around as needed to make more sense

* Not sure how you would code in the orientation though... (maybe JaynneBonnie can figure it out).... lololololol

-------------

for the "hansel and gretzel dropping seeds", you could have them be directional (drop left_arrow_tile, drop right_arrow_tile, etc etc etc), but that would probably completely eliminate the challenge of the maze, lol.

------------

P.S.

there's a fun old school board game called, ~ the A-Maze-Ing Labryinth

That makes sense. Thanks for the clarification.

And now, at the risk of sounding thick again, what are your questions exactly?

I can see several challenges:

1) Knowing which way the player has come into a room. You can either override the "go" command to save the exit navigated (I've done it - it's a single line addition to the function), or you can set an "onchanged" script for the player's parent attribute, see what the old and new room values are, and work out what has been traversed.
2) Changing the exit names to be relative to the player's orientation. Some sort of "on enter" script which checks the data set by 1) and appropriately modifies the exit names. If you do that, then you should be able to navigate the exits without additional code, and the "You can go" text will be right.
3) Managing the multiple tiles. Since you want to be able to refer to the tile object, even to the extent of not being able to take it, the tiles must be separate objects. So you can either have 20 different tile objects, each uniquely numbered, or you can have a "prototype" tile object that you clone and assign a new index to when needed.

As far as one tile per entrance or one per room - I think (given my limited experience and thoughts about this) that one per room should be sufficient to enable tracking things (the player will need a map), and it's less complex than trying to manage up to four tiles, both for the player and the game. Just my take...

By the way, I have some code I can dig up that changes the compass directions to "F", "L" and "R". It could easily be expanded to include a "B".

HegemonKhan wrote:I'm not sure what you want (it would take me too long to map, lol pun, everything you want in your posts), but as for the movement:

just have multiple (separate) verbs~commands:

go_or_move_back, walk_or_strafe_backwards, go_or_move_forward, go_or_move_left, go_or_move_right, walk_or_strafe_left, walk_or_strafe_right

go_or_move = you turn (orient yourself) in that direction and then go in that direction

walk_or_strafe = you just go in that direction without turning (your orientation doesn't change at all)

* Err... my usage of "go", "move", and "walk" aren't placed very well... switch them around as needed to make more sense

* Not sure how you would code in the orientation though... (maybe JaynneBonnie can figure it out).... lololololol

-------------

for the "hansel and gretzel dropping seeds", you could have them be directional (drop left_arrow_tile, drop right_arrow_tile, etc etc etc), but that would probably completely eliminate the challenge of the maze, lol.

------------

P.S.

there's a fun old school board game called, ~ the A-Maze-Ing Labryinth

Thanks, the big problem I face is the mapping of the orientation. For the verbs to navigate, I will simple be using Forward, Back, Left & Right.

I know I seem a bit all over the place, but I assure you there is method in my madness.



MWAHAHAHAHAHAHAHA

*coughs*

Sorry

jaynabonne wrote:That makes sense. Thanks for the clarification.

And now, at the risk of sounding thick again, what are your questions exactly?

Hehe, no problem.

I can see several challenges:

jaynabonne wrote:1) Knowing which way the player has come into a room. You can either override the "go" command to save the exit navigated (I've done it - it's a single line addition to the function), or you can set an "onchanged" script for the player's parent attribute, see what the old and new room values are, and work out what has been traversed.

If a room has 4 exits, it has a possible 4 starting points, so each room would need coding individually. I only see one flaw with the "onchanged" script, and that is when the exit loops back into the room as per my map above. Is it possible to check the "onchanged" script, and if no change is detected query the direction taken (which would only need to be done if the room entered is the same as the one exited) to run the script?

jaynabonne wrote:2) Changing the exit names to be relative to the player's orientation. Some sort of "on enter" script which checks the data set by 1) and appropriately modifies the exit names. If you do that, then you should be able to navigate the exits without additional code, and the "You can go" text will be right.

That sounds quite easy when you say it like that :p

jaynabonne wrote:3) Managing the multiple tiles. Since you want to be able to refer to the tile object, even to the extent of not being able to take it, the tiles must be separate objects. So you can either have 20 different tile objects, each uniquely numbered, or you can have a "prototype" tile object that you clone and assign a new index to when needed.

I gathered I would need to distinguish the tiles as far as the back-end of quest is concerned, and that is fine.

There are 2 ways, based on what you have said, that I can see this working (and the second would in theory allow tile retrieval - but as they only serve 1 purpose, there is no real need for that )

1) Create a base tile object with a counter, and use a script to increment that counter each time a tile is dropped to set the value of the tile placed in the room - once placed that tile's value obviously should not change.

2) Either use a counter, or a random number script to select a tile from the remaining tiles that the player holds, then remove this tile from the players inventory.

Either way, I would like the player to only see a bag of tiles (and maybe eventually an empty bag), only ever seeing the individual tiles once placed on the floor.

Of the 2 options, I prefer option 1 as it requires less objects to be individually crafted by me and is therefore easier to expand should I decide to ad more rooms to the maze

jaynabonne wrote:As far as one tile per entrance or one per room - I think (given my limited experience and thoughts about this) that one per room should be sufficient to enable tracking things (the player will need a map), and it's less complex than trying to manage up to four tiles, both for the player and the game. Just my take...

Certainly from the coding point of view it will be easier. I also agree one per room should be sufficient. I was just trying to work out if I was going too far.

jaynabonne wrote:By the way, I have some code I can dig up that changes the compass directions to "F", "L" and "R". It could easily be expanded to include a "B".

That would be nice. I must admit I am considering a bare-bones interface - but I may still opt to use some or all of the panels. And if any make it in, the compass definitely will.

It's funny how I miss the subtle ramifications of things. The diagram hadn't even registered properly. Given my new understanding, my first option to you won't work, as modifying the "go" command would just record the "exiting" exit, not the "entering" one. And you can't make inference from that.

More to the point, even "changedparent" won't work, because as far as I know, that only fires if the value has actually changed. Which has even larger ramifications, as Quest uses a "changedparent" script to handle "enter room" scripts. In other words, if you try to move to the same room, basically, nothing happens. No events fired, nothing. It's like you didn't move. I haven't tried it, but that's what I think will happen, based on the code.

Given the unusual requirements that you have, I'd be tempted to forget exits altogether and use some other data structure. I could flesh that out a bit if you'd like, but basically I could see each room having four attributes, one for each room that the player can move to. I haven't worked out how to handle the entry direction, though, but I'm sure it can be done.

The other way to do it would be if somehow you could have "hidden" rooms that manage the bends. So if you have a room that has a north exit that re-enters from the west, then you could have an intermediary room that you go north to which would then have an exit heading east into the target room - and the intermediate room would need to automatically "forward" the player somehow on to the target room and also not print anything. I don't know if it's easy to do or not, but it could work, in theory.

Ok, more thoughts, along the first lines...

You could number the four directions: N = 0, E = 1, S = 2, W = 3. (North, East, South and West actually have no relevance, but just to help you visualize.) Order is important, as to turn right, you add 1 (mod 4) and to turn left you subtract 1 (mod 4). [or you add 3, mod 4, if mod returns negative results,].

The each room could have up to four main target attributes:

<exit0 type="object">otherroom</exit0>
<exitdir0 type="int">2</exitdir0>
<exit1 type="object">otherroom</exit1>
<exitdir1 type="int">1</exitdir1>
<exit2 type="object">otherroom</exit2>
<exitdir2 type="int">1</exitdir2>
<exit3 type="object">otherroom</exit3>
<exitdir3 type="int">0</exitdir3>

Only the exits you actually need would show up in each room. The number X in "exitX" is the exit direction. The value in the "exitdirX" attribute is the new (entry) direction.

The player/pov would have a "dir" attribute (or orientation or whatever you want to call it). To go forward, you'd do:

ChangeRoom(game.pov.dir)

To go right:

ChangeRoom((game.pov.dir+1)%4)

To go back:

ChangeRoom((game.pov.dir+2)%4)

To go left:

ChangeRoom((game.pov.dir+3)%4)

And ChangeRoom would be a function taking a "dir" parameter, with something like:

room = game.pov.parent
if (HasAttribute(room, "exit" +  dir)) {
  newroom = GetAttribute(room, "exit" + dir)
  // Set new player direction.
  game.pov.dir = GetInt(room, "exitdir" + dir)
  if (newroom = room) {
    // Same room. Force room description dump, etc
    OnRoomEnter(room)
  } else {
    // New room. Just move.
    game.pov.parent = newroom
  }
} else {
  msg("You can't go that way.")
}

You need to dump out the exits yourself, if you want the player to know (and not bumping blindly into walls). It may seem complicated. Perhaps there is a better way to do it. I'll think some more.

As far as tiles, I had originally thought of just marking the room with the tile number. Then you'd have to have the description dump out "You can see a tile with the number XXX on it." And that would work. But... people might try "x tile" or "take tile". You would not want it to spew out "I can't see that." So if you don't want objects in each room, then perhaps you could have custom commands in each room (use a base type to keep your sanity!) with commands for "x tile" and "take tile" that print out the messages you want.

Ok, I'll stop for now. Sorry for such a dump above. I hope it makes some sense.

jaynabonne wrote:It's funny how I miss the subtle ramifications of things. The diagram hadn't even registered properly. Given my new understanding, my first option to you won't work, as modifying the "go" command would just record the "exiting" exit, not the "entering" one. And you can't make inference from that.

Firstly, no need to apologise, it was a long post and that was right in the centre, so I can understand your brain skipping past it.

jaynabonne wrote:More to the point, even "changedparent" won't work, because as far as I know, that only fires if the value has actually changed. Which has even larger ramifications, as Quest uses a "changedparent" script to handle "enter room" scripts. In other words, if you try to move to the same room, basically, nothing happens. No events fired, nothing. It's like you didn't move. I haven't tried it, but that's what I think will happen, based on the code.

Given the unusual requirements that you have, I'd be tempted to forget exits altogether and use some other data structure. I could flesh that out a bit if you'd like, but basically I could see each room having four attributes, one for each room that the player can move to. I haven't worked out how to handle the entry direction, though, but I'm sure it can be done.

The other way to do it would be if somehow you could have "hidden" rooms that manage the bends. So if you have a room that has a north exit that re-enters from the west, then you could have an intermediary room that you go north to which would then have an exit heading east into the target room - and the intermediate room would need to automatically "forward" the player somehow on to the target room and also not print anything. I don't know if it's easy to do or not, but it could work, in theory. :)

That actually sounds like a semi-sensible idea

jaynabonne wrote:Ok, more thoughts, along the first lines...

You could number the four directions: N = 0, E = 1, S = 2, W = 3. (North, East, South and West actually have no relevance, but just to help you visualize.) Order is important, as to turn right, you add 1 (mod 4) and to turn left you subtract 1 (mod 4). [or you add 3, mod 4, if mod returns negative results,].

Agreed, which is why I used cardinal points in my very first scenario, albeit they were in brackets against the directions that were actually being taken.

jaynabonne wrote:The each room could have up to four main target attributes:

<exit0 type="object">otherroom</exit0>
<exitdir0 type="int">2</exitdir0>
<exit1 type="object">otherroom</exit1>
<exitdir1 type="int">1</exitdir1>
<exit2 type="object">otherroom</exit2>
<exitdir2 type="int">1</exitdir2>
<exit3 type="object">otherroom</exit3>
<exitdir3 type="int">0</exitdir3>

Only the exits you actually need would show up in each room. The number X in "exitX" is the exit direction. The value in the "exitdirX" attribute is the new (entry) direction.

The player/pov would have a "dir" attribute (or orientation or whatever you want to call it). To go forward, you'd do:

ChangeRoom(game.pov.dir)

To go right:

ChangeRoom((game.pov.dir+1)%4)

To go back:

ChangeRoom((game.pov.dir+2)%4)

To go left:

ChangeRoom((game.pov.dir+3)%4)

And ChangeRoom would be a function taking a "dir" parameter, with something like:

room = game.pov.parent
if (HasAttribute(room, "exit" +  dir)) {
  newroom = GetAttribute(room, "exit" + dir)
  // Set new player direction.
  game.pov.dir = GetInt(room, "exitdir" + dir)
  if (newroom = room) {
    // Same room. Force room description dump, etc
    OnRoomEnter(room)
  } else {
    // New room. Just move.
    game.pov.parent = newroom
  }
} else {
  msg("You can't go that way.")
}

I think I grasp it, changing to values makes sense, as does the adding and subtracting, and I can see how that works for determining which exit has been taken. But I am struggling to see how that sets up the orientation of the player when they enter the new room.

Just a thought, but maybe entering a room should trigger a flag, and then that flag could be used in similar way to the "changedparent" script you suggested.

So at the entrance, lets say a flag "current.room" is defined as 00 (each room in the maze would have a unique flag ID number).

My code stinks, this is just an example of what I want to happen. I'll have to read up on how to properly right it out

Entrance

set flag current.room="00"

When you enter a room in the maze, a script would run something along the lines of

Maze Room

set flag previous.room=current.room
set flag current.room="n"

"n" would be defined for each individual room somewhere

This in theory, should allow tracking of movement from room to room.

now we only have to work out how to parse the direction taken, and work out how to make that affect the players orientation in the new room. I see your numerical exits helping here somehow, but I am not quite sure how.

jaynabonne wrote:You need to dump out the exits yourself, if you want the player to know (and not bumping blindly into walls). It may seem complicated. Perhaps there is a better way to do it. I'll think some more.

Sorry, I am not sure I undersatnd the "dump out" bit.

jaynabonne wrote:As far as tiles, I had originally thought of just marking the room with the tile number. Then you'd have to have the description dump out "You can see a tile with the number XXX on it." And that would work. But... people might try "x tile" or "take tile". You would not want it to spew out "I can't see that." So if you don't want objects in each room, then perhaps you could have custom commands in each room (use a base type to keep your sanity!) with commands for "x tile" and "take tile" that print out the messages you want.

I had a thought on that, and came up with a much simpler solution than a bag of tiles that gradually decrease - a piece of chalk writing on the wall or a stick scratching in the dirt a number, with a counter every-time it is used to automatically increase the number inscribed and add it to the room description.

Also I think i want to add a hint saying something like "you don't know where you are, maybe you should mark this room before you continue", and if you don't have any chalk, or a stick, you can only go back from the first room until you find something to mark the maze passages with.

jaynabonne wrote:Ok, I'll stop for now. Sorry for such a dump above. I hope it makes some sense.

Don't be, you are being more than helpful.

I hope this thread might inspire other people too, as I have yet to have sampled a maze that has this sort of complexity

If I can get this (my first ever text adventure) fully off the ground in time, I may even enter it in the IFComp

I haven't read (both of) your posts (so my apologizes if this has already been thought up and mentioned), but I got an idea:

4 booleans on either a "data object" or your game.pov:

west_orientation=false
north_orientation=false
east_orientation=false
south_orientation=false

these can then be switched on and off, for quest to know what direction you're facing (you could also have two on, as for an example, north+west = NW direction, or you could just make 4 more boolean directions: NW, SW, NE, and SE)

then, you can just do conditionals upon the exits' descriptions or however (lots of neat other tricks you could do too, hehe)

you could also probably apply this same stuff to the previous room (the room that you came from) too.

I think I grasp it, changing to values makes sense, as does the adding and subtracting, and I can see how that works for determining which exit has been taken. But I am struggling to see how that sets up the orientation of the player when they enter the new room.

That's where the "exitdir" attributes come in. Let's actually mockup your room diagram.

<object name="room1">
  <!-- south exit (dir 2) landing in eastern direction (dir 1) in room 2-->
  <exit2>room2</exit2>
  <exitdir2>1</exitdir2>
</object> 

<object name="room2">
   <!-- north exit (dir 0) landing in eastern direction (dir 1) in room 3-->
  <exit0>room3</exit0>
  <exitdir0>1</exitdir0>
 <!-- east exit (dir 1) landing in northern direction (dir 0) in room 2-->
  <exit1>room2</exit1>
  <exitdir1>0</exitdir1>
 <!-- south exit (dir 2) landing in western direction (dir 3) in room 2-->
  <exit2>room2</exit2>
  <exitdir2>3</exitdir2>
<!-- west exit (dir 3) landing in northern direction (dir 0) in room 1-->
  <exit3>room1</exit3>
  <exitdir3>0</exitdir3>
 </object> 

<object name="room3">
  <!-- west exit (dir 3) landing in southern direction (dir 2) in room 2-->
  <exit3>room2</exit3>
  <exitdir3>2</exitdir3>
</object>

When you take the exit in direction X, you basically set the room parent to exitX and you set the new player direction to exitdirX.

Hope that helps!

The "dump out" bit is just the text like "You can go forward, left or right." (usually "You can go north, east, or south."). That won't happen automatically since there won't be any actual physical exits in the room. So you'll have to write a little script to do that yourself, if you want to show that sort of info to the player, using the exit attributes in the room.

I could help with that if you need it. It has to build a string, but it needs to check each direction, since the orientation changes. It could be something like:

<function name="HasExit" parameters="dir" type="boolean">
  dir = (game.pov.dir + dir) % 4
  return (HasAttribute(game.pov.parent, "exit"+dir)
</function>

// Then in your description code.
exitlist = NewList()
if (HasExit(0)) {
  list add(exitlist, "forward")
}
if (HasExit(1)) {
  list add(exitlist, "right")
}
if (HasExit(2)) {
  list add(exitlist, "back")
}
if (HasExit(3)) {
  list add(exitlist, "left")
}
// Then generate the string from it
// Stolen from the Quest core's FormatExitList function
s = "You can go "
count = 0
length = ListCount(exitlist)
foreach (exit, exitlist) {
  s = s + exit
  count = count + 1
  if (count = length-1) {
    s = s + " or "
  } else {
     s = s + ", "
 }
}
s = s + "."
msg(s)

Please note that all this code I'm handing you is untested!

jaynabonne wrote:[sinp]
Please note that all this code I'm handing you is untested!

No problem. I will have a play this afternoon.

What did you think on my idea about flags?

Also, I just noticed something about quest this morning, I created 4 rooms (room0, room1, room2, and room3). When creating exits normally, there is no selector for the room you are in. If I am in room2, I can only create exits to rooms 0,1 & 3. I appreciate, in the context of our conversation this is pretty meaningless as we are running scripts instead, but I just thought I'd mention it.

Also, again not relevant here, but checking the box to create an exit in the other direction doesn't allow you to select a different exit - it justs uses the opposite exit as standard (which in most cases is fine).

Yes, that's why I was saying to not use exits. They don't work the way you want. That's what all this attribute stuff is about - synthesizing your own exit scheme. You would not use Quest to create exits - you'd create the attributes to specify the directions. Then you'd have custom forward, back, left and right commands to do the room movement as opposed to the standard "go" command.

I hope that makes sense! ("Grasshopper, you must let go of exits before you can embrace disorientation").

[Note: If you did want to use Quest exits for something more standard but wanted different exits to have different directions, then just uncheck the checkbox to create the corresponding exit and then go to that room and manually create the other exit in whatever direction you want afterwards.]

Since I feel I've led you down this garden path, here is a complete workup of what we have discussed (attached). You'll see there are no exits, just custom commands and attributes to connect things together.

Note that this code works, which means I fixed the errors in what I have given you so far (there were several). I also left the room names in so that you don't get too disoriented!

Edit: I put some "Debug" logging in so you can see the room/dirs for each move.

jaynabonne wrote:Since I feel I've led you down this garden path, here is a complete workup of what we have discussed (attached). You'll see there are no exits, just custom commands and attributes to connect things together.

Note that this code works, which means I fixed the errors in what I have given you so far (there were several). I also left the room names in so that you don't get too disoriented!

Edit: I put some "Debug" logging in so you can see the room/dirs. for each move.

Thank you

*goes to download*

but are you sure it's a garden path?

Well I hope it's not too twisty a maze.

This is looking really good, thank you.

I have built a slightly larger (10-room) maze - well a 6 room maze with 4 additional rooms .

I had to play around with the value "dir" to get it to accommodate my wish to enter and exit the maze using cardinal points.

Please tell me what you think. I put most of it together in Notepad++, copy and pasting then editing the code from your .aslx, but I saved it in Quest and it knocked out all the comments Not good!

Anyway, please let me know what you think of this (I knocked out the debug message and added some "markings" to the rooms instead - after trialling it myself).



Now all I need to do is work on the Hansel and Gretel script for my breadcrumbs. I think I will go with a piece of chalk and writing the numbers on the wall.

So I think I need to create a command to mark the room, maybe MARK ROOM or just MARK.

This will check inventory for a piece of chalk, if a piece of chalk is available it will mark a number then increase a counter for the next time, it will then add that number to the room description (as a non take-able object).

If you have no chalk in your inventory, then exits F, L & R will be locked and you will only be able to go back the way you came (first maze room only as the chalk will not be a droppable item).

Also, eventually the maze will be dark, meaning entrance to it will be locked until you have a light source. Hopefully those last 2 are a bit simpler to tie in

Many thanks for your help so far.

It seems downright confounding (in a good way). I'm glad you have the rooms numbered for now. I think the chalk will be essential. Given that the player will know they have chalk, you might want to consider "use chalk" to be one of your verb choices.

I ran into one odd thing, but it might just be a bug. This is my initial sequence after going down:

You are in a Bottom of mineshaft.
You can go up or south.
You are stood at the bottom of the mineshaft. A ladder leads up and a dark passage leads south.

> south

You are in a T-Junction.
You can see a Number 1.
You can go right, back or left.

> back

You are in a Bottom of mineshaft.
You can go up or south.
You are stood at the bottom of the mineshaft. A ladder leads up and a dark passage leads south.

> s

You are in a T-Junction.
You can see a Number 1.
You can go forward, back or left.

It seems odd to me that the first time I come in, it shows "You can go right, back or left." and the second time from the same direction (an anchor point!), I get "You can go forward, back or left." Things are hard enough... lol

Looks good, though!

jaynabonne wrote:It seems downright confounding (in a good way). I'm glad you have the rooms numbered for now. I think the chalk will be essential. Given that the player will know they have chalk, you might want to consider "use chalk" to be one of your verb choices.

I ran into one odd thing, but it might just be a bug. This is my initial sequence after going down:

You are in a Bottom of mineshaft.
You can go up or south.
You are stood at the bottom of the mineshaft. A ladder leads up and a dark passage leads south.

> south

You are in a T-Junction.
You can see a Number 1.
You can go right, back or left.

> back

You are in a Bottom of mineshaft.
You can go up or south.
You are stood at the bottom of the mineshaft. A ladder leads up and a dark passage leads south.

> s

You are in a T-Junction.
You can see a Number 1.
You can go forward, back or left.

It seems odd to me that the first time I come in, it shows "You can go right, back or left." and the second time from the same direction (an anchor point!), I get "You can go forward, back or left." Things are hard enough... lol

Looks good, though!

Well spotted - I needed to change the "dir" value again. I forgot that because the bottom of the shaft is using a cardinal point rather than a relative direction, that I would need to adjust the exit direction to reset the player - like I did for the exit of the maze (does that all make sense?)

Try this one for size



Next question. When I finally implement this in a game, I am thinking of making it a little bigger still, and maybe over 2 or 3 levels.

How many rooms do you think is too many? How easy was it for you to map?