For this reason, I don't go into exhaustive screenshot detail about every step, because this involves a ton of frames. I assume you know how to evaluate conditions, set variables, and so on.
-----
Here's an inventory system that I've been using in my work-in-progress, All the Brooks and Soldiers! In making a good inventory system, the following criteria should be met:
1) It should be relatively quick to implement in every single location, so that it can be used consistently, rather than in special cases only. This means that there should be a default response for most combinations of item and location object, and they shouldn't need to be hard-coded. (I don't achieve this perfectly, but I get pretty close.)
2) It should not break too easily; there should be error messages that catch weird problems.
3) It should flow smoothly from existing gameplay, preferably from the Present option.
Here's what I came up with! If anybody can suggest any improvements, feel free to say so! It still feels a little clumsy in gameplay, but I really want to emphasize using stuff in my game, and I don't see a better way to do it.
****
From the player's point of view:
Whenever the player clicks present and a piece of evidence during an investigation, they see a dialogue box: "Do you wish to PRESENT this or USE it on something?"
If they choose to USE the object, they are then prompted click on the location where they wish to use it, as if they were examining. Easy as that!
****
Broad summary of how it works:
Every time the player presents something, the game stores the ID of the presented item in a variable, which we'll call itemused (with some modifications for ease of distinguishing profiles from other kinds of evidence.) It then jumps to a routine that asks the player if they want to PRESENT or USE.
If they want to PRESENT and a person is in the scene, it reads the variable and jumps to an appropriate response.
If they want to USE, it first checks if the item is a profile. If so, it tells the player that they cannot use profiles on their environment. If it is not a profile, it puts up a "select an area" window and jumps to a different frame for each area where an object could be used.
In each of those frames, itemused is read, and if the result matches any object that should give a custom response, it jumps to an appropriate frame. Otherwise, it jumps to the default response for that object. ("I don't need to use that on the door," for example.)
This must be implemented separately for every location the player visits, barring some really dicey frame-jumping magic that I don't want to attempt out of fear of messing up the investigation engine or creating graphical glitches. It is not insanely labor-intensive, but it does create a TON of frames, so be careful if your investigation is pushing the limits of AAO.
***
How to script this:
Step one: For every location the player can visit, go to the Present tab and add two frames of responses for every piece of evidence in the CR that the player could possibly have when they visit that location. In other words, click "Add" (long brown bar), and set the Profile or Evidence Id for the first piece of evidence. Then add two frames to that. Repeat for every piece of evidence.
The first frame will take note of which item the player tried to present. The second will redirect the game to the frame that handles all of our Present/Use Item responses.
(Note: Since implementing a room is a pain in the neck, I recommend re-using rooms as much as possible. If you need to have multiple intro convos in a room, just "reveal the intro convo" in the room during the intro convo itself, and use a conditional statement to decide which intro to show, if any.)
Spoiler : Two pieces of evidence being implemented this way :
Step three: In the FIRST FRAME of each pair, use the Define a Variable's Value action to set a variable called "itemused" to a number corresponding to the piece of evidence used. I recommend using the evidence ID.
HOWEVER, if the evidence in question is a Profile, set "itemused" to the Profile ID + 100! (For example, if the player presents Profile 2, set itemused to 102). It will become clear why later on.
Ignore the second frame of each Present for now. We'll fill those up in step six.
Step four: Dealing with attempts to PRESENT evidence
Now we need to create our routine for handling present/use. I like to put this set of frames in the Present for the last profile in the CR, but you can put it pretty much anywhere in the location's present routine (or possibly even its examine or talk routine) that the program won't accidentally run.
Here is what this routine consists of, in outline (screenshots wouldn't be very helpful here, I think). Let's pretend that in this room, we happen to be starting our Present/Use Routine at frame 515 or something. Let's also suppose the player character is Phoenix, and that Gumshoe is in the room.
First, we present a prompt to the user.
515: Text: "Does Phoenix PRESENT the evidence or use it on something?".
Action: Answer a question (2 answers)
Answer 1: Present
Answer 2: Use
Target Frame 1: 516
Target Frame 2: {FIRST FRAME AFTER ALL PRESENT FRAMES ARE DONE; let's say this is 550.}
Next, we handle presentation of evidence:
516: Text: None.
Wait time: 1
Action: Read a variable's value
Variable: itemused
Variable's value:
Okay, this takes some explaining. Remember how we set "itemused" to be the evidence ID of whatever the player chose to present, or 100 + the evidence ID of a profile? We use those values here. For each piece of evidence we want Gumshoe to have a special answer for, we redirect the player to that frame. On failure, we redirect to our default response from Gumshoe.
Here's what this action might look like if Gumshoe can respond to one piece of evidence (ID 2) and two profiles (ID 11 and 13). Ignore the numbers of the target frames; these are from my game:
Spoiler : A conditional for this part :
Step five: Dealing with attempts to USE evidence
550 (or whatever comes next): Now we have to handle USING objects. The first thing we do is check if our player used a profile, since those photographs probably don't have much use outside of "presenting" them to people. In this frame, evaluate the condition "itemused < 100" (no quotes). On failure, go to the next frame. On success, skip the next frame and go to the one after.
551: Text: Phoenix can't use profiles on his environment - only objects!
Action: Proceed directly to another frame (use the dummy frame at the end for this).
552: Text: Where does Phoenix use that object?
Action: Examine an area of an image.
For the image, use your background image. Then make a redirect for EVERY POSSIBLE area that shouldn't get default Use response. Sometimes, you may need to add so many areas that they can't fit on the screen. In that case, zoom out.
Here's an example of what this action might look like. Notice that the player can use things on five different places in this scene.
Spoiler : examine dialogue :
For example, let's suppose that examining a locked chest takes the player to frame 560, there's a crowbar in the CR with evidence id 3, and there's a key in the CR with evidence id 4. You might have the following:
560: Wait time: 1
Action: Read a variable's value
Variable: itemused
If itemused is 3, redirect to frame 561
if itemused is 4, redirect to frame 562
On failure, redirect to frame 563.
561: Phoenix: "RAAAAAAAAARGH! SMAAAAASH!" (redirect to a frame that leads to the next scene, with Phoenix smashing down the door.)
562: Phoenix: "The key doesn't fit." (Redirect to our dummy frame to return to the investigation)
563: Phoenix: "I can't use that on the door."
Do this for every object in every room (though some will require minimal effort), and you're done!
Step six: Take a note of the frame number where the use/present routine begins. Here, it's frame 515.
Now, remember how you had that second frame for every Present, with the wait timer set to 1? Use that to redirect the player to your use/present routine. Here, we'd use the action "Redirect to another frame" and set that to 515.
The reason I do this last is because it's easy to generate frame errors if you redirect to frames that don't exist yet on the assumption that you'll create them later!
Obviously, I only recommend this if MacGyvering stuff or using gadgets is a major part of your gameplay. I also recommend starting with very, very simple puzzles (use key on door) before requiring the player to really get the hang of this.
Questions?
-----
Below, I explain the logic of my design choices here, so that it can be critiqued:
Spoiler : Why I did it this way :