Ok, so I've gotten the hang of a lot of things so far. A small query here in regards to exits:

Essentially, I've done away with the Side menus (compass, inventory, etc.) to make way for a more minimalistic & less intrusive interface ( or, more importantly, something that I hope is easily transferable between different mediums). Therefore, for the player to see what's in their inventory - they'll just type I. Now, I'm looking at exits & trying to incorporate them effectively.

Scenario 1: The Player is given a ShowMenu of options to choose from that'll take the player from Room 1, to either of 3 new Rooms (or stay in the same room). Is there a simple way to let the player look at the exit prior to accessing it? Thus, in theory, when the ShowMenu appears, I can give some of the choices a clickable-drop down - just like one has with Items (Use, Look at, Drop, etc.), so they can either "Look at" or "Go through/To".

Scenario 2: If Scenario one is tad too complex for a recent novice... I'd instead opt for granting the player the ability to look at them when they've chosen the "I'll look around first" option - which simply leaves them in the Room. In this situation, I've presented the Player with 2 opportunities to access a new room. Looking at one approach, after they've opted to "Look around the same room" instead of going elsewhere, I've presented the player with this:

msg ("Let's look around dawg, maybe there be gold.")
msg ("<br/>When done, you can either go to {exit:ToRoom2A} directly, or {exit:ToRoom2B} to approach it carefully, or just make a run for {exit:ToRoom2C}.")

Again, the "Exits" don't have the ability to look at - and simply transfer the player over. Can I word it in an easier way to allow players the ability to either "Look at" or "Go through/to" here?

Other query - Creating hyperlinks to objects in messages.
i.e. Let's say I have the sentence,
"You could use the key to open the door from within your inventory." (Assuming I've already done an if check...)...how do I make Key a URL link to the object? Akin to the {exit:[Room]} concept with options to interact with it?

this is probably too advanced for you (Lists+Dictionaries), but here's a non-exit 'explore' and 'travel' system if you want to just get some ideas or take a peak, and~or for if~when you're learning quest's coding:

(the code is old and can be fixed up a bit to be better)

viewtopic.php?f=18&t=5138

you can test~play it out though just to see it if you want, if it still works for the current version of quest...
(ask if you need help on how to test~play it out, if interested in doing so, and don't know how to)

it's based upon, having to 'explore' to find new locations, and once you found those new locations via 'explore'-ing, they're added to the list-menu of places that you can select to travel to (and back).

----------

I know we've had a post~thread on improving the 'look in exit direction without moving to that room-location' somewhere... argh. I thought it was in the 'library and code samples' forum board, but I'm not recognizing any thread titles on it... hopefully it is somehwere in there, otherwise... it's in this main forum... yuck... in trying to find it... lol

--------

the blue hyperlinks in the text are controlled two ways:

1. the text processor commands: http://docs.textadventures.co.uk/quest/ ... essor.html
(you use the 'print a message -> print [expression] ' Script, and the text processor commands put into the 'msg' Scripts will be as hyperlinks for you to click on ~ see the text processor commands link above)

2. http://docs.textadventures.co.uk/quest/ ... ments.html (see 'displayverbs')

http://docs.textadventures.co.uk/quest/ ... verbs.html (Pixie's guide on it, I believe)
viewtopic.php?f=18&t=4953 (this is another Pixie guide, about~on Verbs)

'displayverbs' is a built-in special Stringlist Attribute, and can be manipulated just like any List Attribute (adding and removing items from it, and etc).

------

3. there is the in-line (in-text) 'showmenu' Script, as somewhat-the-same-effect producing

Thanks again HegemonKhan - I really need to go through that docs.textadventures area more thoroughly... I'll think twice before posting hopefully next time...

That first explore & travel system is pretty snazy - though I'm currently trying to see if I can get things to be 90% "just click here". I'm pretty sure that's not how text adventures go normally, but I find it easier for myself - for now ^_^;;

once you get the basics of using quest (and especially coding), the 'documents' link are all your commands~etc for you to code in (so it really advances your knowledge and opens up for you, in your quest usage capabilities)

-----------

the 'displayverbs' and 'inventoryverbs' is quite hidden (in that weird 'asl_whatever' link area), and it's a much more advanced concept too (as it's a list of your verbs, and thus verb manipulation), especially for people new to quest, it's not something until much later on, when people have more knowledge of quest and especially its coding.

Though, Pixie's guides, can probably help anyone understand, hehe Pixie has so many great guides! Most guides and libraries are his~hers, laughs. (though some of Pixie's libraries~guides are still far too advanced for HK, sighs. I'll get there...)

I use the approach of no compass, no UI in my game that I'm currently working on. I use your "scenario 2" approach in that I use the text processor commands to expose exits and objects that players can interact with.

I found that with "look only" exits that they were quite painful to work with. Also for exits that you can actually go through I created a proxy object for the exits which allow you to interact with them so "look at door" and so on works. Basically I have in-room descriptions turned on and my "door_proxy" object has this as its in-room description:

"An oaken door in the south wall leads {exit:door}."

In game this prints "An oaken door in the south wall leads outside." - because my actual door exit has as its user visible "alias" the word "outside", and its that which the text processor subs in. Clicking the link will attempt to go through the exit to the neighboring room.

Its quite useful also as I can also make the "door_proxy" object a container with the open/close option set, and then I have a script on the open & close options which sets the actual door to be locked or unlocked. I changed the "its locked" message on the actual door to be "Its closed".

This way you can have doors that you explicitly open or close. In my case I have a hatch in the floor which has to be propped open in order to get down. Or you may have other reasons to want to close & open a door explicitly.