Delphine's adventure games basically had the following interface: when you click on an object, it opens up a list of verbs you can do to that object. Now, I'll admit that I'm pretty much a total newbie with AGS who's just been looking around tutorials for the last few hours, and probably I misunderstood half of what I've read.
Now, I guess I would have to use a GUI that pops up when you click on anything interactive on the screen. Now, can you make the location of the GUI relative to the location of the pointer? Then there would apparently need to be some kind of scripted safeguards to prevent the GUI from appearing partially outside the screen. Next, the commands would preferably vary from object to object, and in some cases even with the same object. Is it possible to alter the composition of a GUI in-game, or would it be necessary (or more feasible/rational) to make a whole load of different GUIs for different objects?
QuoteNow, I guess I would have to use a GUI that pops up when you click on anything interactive on the screen. Now, can you make the location of the GUI relative to the location of the pointer?
Yes, that is easy.Ã, Mouse.x and mouse.y are the locations of the pointer.Ã, SetGuiPosition can be used to set the position of the GUI to that spot.
QuoteIs it possible to alter the composition of a GUI in-game, or would it be necessary (or more feasible/rational) to make a whole load of different GUIs for different objects?
You can change the composition of the GUI within bounds through scripting.Ã, You can change the position of buttons on the GUI, make them active or inactive, and make them appear and disappear through scripting.Ã,Â
edit: You could also change the text of the buttons (or animate them) or change their picture...and you can obviously change their effect.
happy? :P
I'd probably do it with a listbox on the gui. And then use object/hotspot property's to specify the available options for each object/hotspot. Assuming that you'd never have more actions for an item than there are available cursor modes, you could have properties like this:
Hotspot: Door
property LookAction = Examine
property InteractAction = Open
property PickUpAction = Knock
property TalkToAction = Listen
Object: Christmas present
property LookAction = Read note
property InteractAction = Unwrap
This would allow you to still use the normal Interaction editor to set up responses. But of course you'd have to remember the sometimes arbitrary links between the options in game and the engine interactions they refer to.
The GUI in The Hamlet (http://www.adventuregamestudio.co.uk/games.php?action=detail&id=469) works just like that, so it's very possible.
Garage, your idea of using object properties is a good one, but it's not limited to list boxes. Since there are a short number of interaction possibilities, you could also make a button for each interaction type, and hide the buttons which have no interaction for the object. I see why you wanted to use the listbox -- so that the list has no gaps -- but it would also be easy to script 4 or 5 buttons to be in a "list" order on a GUI, and the button text/visibility could be set by the object properties.
Yes, The Hamlet is very close to what I'm looking for. I have one question, though: the tutorials I've read warn against having a GUI window extend outside the borders of the screen, since that would cause the game to crash. Why doesn't that occur in The Hamlet?
this is due to the clever use of if statements. there wpuld be an if statement like this
If (mouse.x > 190){
mousex = mouse.x - 10
SetGUIPosition(GUI3,mousex, mouse.y)
}
this checks to see where the player clicked, and how close to the edge of the screen they clicked. IF it is closer to the screen than it should be, ie. the gui will be blocked, then it moves the gui slightly so it isn't.
I figured something like that could be done, but apparently Hamlet does something else entirely. Here's a screenshot:
(http://img167.echo.cx/img167/2839/hamlet0fs.jpg) (http://www.imageshack.us)