I'm working on my second game, have noticed that you can have exits that lead to objects instead of rooms, does anyone have any good examples of the type of tricks you can pull on the player with this? Or just useful hacks?

You could have a box that the player can go inside (though as we established recently, getting it to work so you can see things in and out of the box is a nightmare).

I don't think it would be useful in any way. The concept is a neat one but the mechanics of objects v rooms would quickly get messy I think. It would be just as easy to create a new room with the same alias as the object you want to be moved into. Say you have a box object you want to move a player into. It would be much easier to move a player into a room named 'inside a box' and account for the changes that way than to try and actually work the player properly as inside the object box.

Remember that the player does not need to be in/on the actual object. It just has to appear that way.

As far as I think I understand... lol...

Also note that in terms of coding whatever the type of Object (Room Object, 'non-room' Object, Room+'non-room' Object), it's an 'Object' Element. The different types of Objects, just provide/add different Attributes/coding/features/capabilities/abilities to it.

If you know what's needed, you can manually (via scripting) turn a 'non-room' Object into a 'Room' Object, I think.

just thought of this... design.... pretty cool/nasty-mean, lol:

"an existence-time-flickering Exit"

using a Timer to have an Exit toggle between 'NAME_OF_EXIT.visible=true/false', hehe. Example: the Exit is maybe only visible during/at 9 pm, and you only got 10 seconds to use it, before it becomes not visible again.

everything in the game, including the game, is an object remember. A room is just an object that there are some short cuts built in for. For example, when the game moves the player to a room, it knows to display a room description and a list of exits and a list of objects that can be interacted with.

You could reinvent the wheel by only making exits to objects, and when moving the player to those objects, code in functions for the game to display descriptions of where they are, what objects they see, what exits there are...

but

that's already been done for you.

sorry for putting everything in the code box... but I can't otherwise use the tag arrow symbols in my post... so my apologies for it.

I was jsut talking about the user-level 'Object' Elements, as indeed at the underneath code (programmer-level) of quest, everything (all of the types of Elements and Attributes) is an Instantiated OBJECT/CLASS nested/inherited/whatever within a single instantiated OBJECT/CLASS (the: "game itself", the: '<asl>entire game code</asl>' ), but not everyone here is a programmer, and it gets confusing between OOP/OOD/programmer-level 'OBJECTS' (as you see, I use all upper case for this, to try to separate it from...) and the user-level 'Object' Element.

(also, 'type' is used everywhere and for everythng too in programming... which can get very confusing as well due to it being such a good common/general word --- I really need to get a thesuarus to find alternative words for 'type', lol)

everything in the game, including the game, is an object remember. A room is just an object that there are some short cuts built in for. For example, when the game moves the player to a room, it knows to display a room description and a list of exits and a list of objects that can be interacted with.

In fact the only difference in rooms and objects is what tabs are displayed in the editor. When you do "Publish", Quest strips out the types that differentiates between them, making it tricky to tell if something is a room or an object in game.

Thanks all, looks like it's a dead end creatively then. I made a test game and messed around with it for a bit and now understand your point about re-inventing the wheel/rooms. Just for fun I made an exit that went to object 'player', unsurprisingly the game didn't like it!

The game wouldn't, because player never holds still. You'd have to make player be a vehicle, that is a moving room, or rather... a moving room inside a static room, and then you'd have to code in a way for the game to tell what room the vehicle was in, so that the exit always pointed at the correct thing.

A caution on vehicles before you go running off to try them:

1 - when in the vehicle, you have to have a command to look at the room the vehicle is currently in.
2 - when in the vehicle, you to have a different exit command, so that the vehicle, AND YOU are both moved into a new room
........2a - you have to tweak who knows how many master game functions to insure that once the vehicle, with you in it, moves into a new room, you are still INSIDE the vehicle.
3 - this is the same whether your vehicle is a car you ride in or a horse you ride on.

the game (the underneath and.or built-in coding of quest) is currently built around a special built-in 'pov' (point of view) Object Attribute of the 'game' Game Settings Object, which is the currently controlled Player Object (the default being the 'player' Player Object), and that Player Object must be within a Room Object:

http://docs.textadventures.co.uk/quest/asl_requirements.html

maybe Player Objects can be Room Objects (they ARE containers as they can hold Objects, aka as your 'inventory'), or maybe not. So, we'd need someone more knowledgeable to look into or let us know if an Exit can go to a (another non-currently-controlled) Player Object (logically, there's an issue with going inside of yourself, lol --- seems like this may be a code issue too, unless you just didn't set it up right)

I would not want the player object to be anything other than the player, actually. that could be major problems. PLAYER should be unique among objects, have a whole lot of predefined things it can't do as a safeguard, and have a number of predefined things it can do that other objects can't (without a bunch of extra scripting.

I wasn't suggesting you turn the player into a vehicle, either, if that was misunderstood.