Inventory System for Adventure Gameplay

Find detailed help from the AAO community, or write your own tutorials.

Moderator: EN - Forum Moderators

Post Reply
User avatar
Ferdielance
Posts: 778
Joined: Sun Mar 09, 2008 12:46 am
Gender: Male
Spoken languages: English

Inventory System for Adventure Gameplay

Post by Ferdielance »

NOTE: This is really meant for people who have some significant experience with AAO or programming in general. A novice could do it (I'd never made a trial before I tried this!), but is likely to get very frustrated with the labor involved unless they know how to be efficient.

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 :
Image
Step two: In every one of the frames you've added, set the timer to 1. They should pass near-instantaneously.

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 :
Image
517 - 549: These are the frames to respond to all the possible presents. At the end of each set of frames for a response, be sure to redirect the player to some frame that will bring them back to the investigation. (I use a 1-wait time "dummy frame" after all of the Present frames for this purpose.)

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 :
Image
553-however many it takes: This part can be a little bit of a grind. For the target frame corresponding to every location on the screen, you'll need to read itemused and see what item was used. If the item can be used there, redirect to a frame that holds the response. Then don't forget to jump to your dummy frame after that!

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 :
I reasoned as follows:

We could either have the player examine objects and then choose an object to use on them, or present objects and choose a target. After experimenting with the first system and talking to people, I decided that presenting objects feels more intuitive.

I then needed a way to deal with cases where the player could either use objects or present them to someone. The obvious answer would be to leave the character on the screen, and handle presents by letting the player use objects on their sprite. If I were doing this again, I might actually use that solution, in hindsight, even if it means that useful items all have to be on the edges of a scene.

But in my game, several key background items are partly obscured by characters, and can only be seen when examining! In addition, AA players are used to seeing characters "get out of the way" when they examine a scene, so it would be jarring to see that they couldn't use objects on anything behind a witness!

So I decided to use the slightly clumsy "present or use" prompt.

But the problem is, there's no easy way in AAO to access what item the player last presented. I therefore needed to use a temporary variable for each present (unless I actually re-implemented the use dialogue for every single piece of evidence, which would be a huge waste of time and potential source of bugs). So I decided to make the variable equal to the evidence ID for evidence, and evidence ID + 100 to easily distinguish profiles (since that's easy to remember).

In hindsight, it may have been more advantageous to not even let profiles go to the "use/present" routine, but I was afraid that players would get frustrated when they tried to "use" profiles and couldn't figure out how to do so. So I let them try to "use" the profile, and give an error message telling them just to present profiles instead. This would be consistent, even if it wasn't efficient.

(Likewise, I allow the player to "present" if nobody is present, but return a message telling them that this doesn't work.)

Once I was committed to doing it this way, the handling of the examine routine seems pretty straightforward. I generally err on the side of trying to catch as many cool/goofy combinations as possible so that people enjoy messing around with the game, but the balance between the potential for fun and the potential for bugs is not an easy one to strike.

The key thing, I believe, is to handle unexpected combinations gracefully with a sensible default message!
"A slow sort of country!" said the Queen. "Now, here, you see, it takes all the running you can do, to keep in the same place. If you want to get somewhere else, you must run at least twice as fast as that!"
User avatar
Kroki
Admin
Posts: 7475
Joined: Fri Nov 23, 2007 10:05 pm
Spoken languages: Français, English, Español, 日本語
Contact:

Re: Inventory System for Adventure Gameplay

Post by Kroki »

Ferdielance wrote:In hindsight, it may have been more advantageous to not even let profiles go to the "use/present" routine, but I was afraid that players would get frustrated when they tried to "use" profiles and couldn't figure out how to do so. So I let them try to "use" the profile, and give an error message telling them just to present profiles instead. This would be consistent, even if it wasn't efficient.
But that makes it useless, you have a function that can never be used. If players try to use a profile (most likely just for fun) they will wonder why they even have the choice if there is in fact no posibility to use it. Simplifying the system is better for the player's experience, giving a false feeling of liberty is not a good thing.
ImageImage Image Image Image
User avatar
Ferdielance
Posts: 778
Joined: Sun Mar 09, 2008 12:46 am
Gender: Male
Spoken languages: English

Re: Inventory System for Adventure Gameplay

Post by Ferdielance »

Hmm. I can buy that it's usually bad to give people options that never really get used. But it's also bad to be inconsistent; if people get different interface responses from presenting Profiles and presenting other Evidence, it could be confusing.

I'll have to think this through a little more. One option might be to bite the bullet and rewrite it so that presenting Profiles when nobody is present just says "there's nobody to present that to," and presenting them when someone IS present assumes that the player really DOES want to present them, and not use them. At no point would the use vs. present dialog come up for profiles.

I just realized that there's another even MORE elegant solution that skips the menu altogether, but doesn't cover up the screen too much or get too far away from how examining works in AA. I could put a mugshot of the character present in a corner of the examine screen, and handle ALL presentation and use that way. To use an object on the environment, the player clicks that object on the screen. To present it, they click on the mugshot!

It wouldn't require an INSANE amount of recoding at this point, and definitely is more streamlined. Shoot, shoot, shoot, I might just have to do it this way!
"A slow sort of country!" said the Queen. "Now, here, you see, it takes all the running you can do, to keep in the same place. If you want to get somewhere else, you must run at least twice as fast as that!"
Post Reply