5.0. GETTING ITEMS FROM CONTAINERS

 Intro

"Chaz, don't complain. He is starting to look... oh, shut up"
"Chaz, don't complain. He is starting to look..."

In RPGs, it is most likely that your avatar will not be able to control his or her urges to steal or retrieve objects from other people's houses. Moreover, there will be some treasure boxes scattered over the world which are unspoiled and waiting for you (Good ^_^). However, you, as a designer (both game designer and level designer), must choose what your heroes can do with all those containers. They will just get all the objects? They can choose what to take and what to trash? Or they can put everything they want into a container?

This lesson will cover the different ways to store items inside a container, and how your avatars can interact with them.

 Basic approach - Just Gimme!!!

The most basic approach is when everytime your avatars open a container (e.g. the ubiquitous treasure box), they get all its contents. This approach is quite simple to program, and it is used in most Japanese-type RPGs.

Fig. 1
Figure 1: Just an Script

As seen in Figure 1, in this approach you only have to setup two things: The internal variable that indicates whether this particular treasure box has been spoiled or not, and its contents defined in a script. This way, when your avatar check the treasure box for the first time, he/she will get all its contents (put the items into the inventory), and indicate that the box has been investigated. In the second and subsequent checkings, your avatars will find nothing... unless you want to create a magic box that always return socks, or anything like that :-P.

When designing a level, the contents of a container must be defined inside the script that manages the container.

 Complex Approach - "Let's put something inside that box!"

A more complex approach is used by other RPGs, usually in the western type - "Ultima", "Knights of the Old Republic". Here you can get any item from a container, but at the same time you can put anything inside, return later ("I'm running out of ammo!"), and recover those items again.

Fig. 2
Figure 2: Database

Figure 2 shows the architecture of this approach. Usually all the objects from the world are stored in a database, along with the container where they belong. When a player opens a particular container, the engine will access to the database and get the items belonging to that container.
After that, the player can either choose to get an item from the container - deleting an entry from the database and moving the object to the avatar's inventory, or adding a new item to the container - adding an entry to the database and deleting the item from the avatar's inventory.

When designing a level, the contents of a container must be defined inside a global database, and the script that manages the container must call an special function for retrieving the data.

 Remarks

Both approaches are extreme cases, and it is possible to develop new, intermediate solutions when the designer needs to do so. For example, A script can define the contents of a container only if no player got any items from inside. Once the player inspects the container, it can choose to get only one subset of the items, leaving the others stored in a database.

However, there are some techniques that can be inserted into the container management for spicing up the user experience, and some remarks that must be taken into account when designing the system.
  • Limited inventory. In some games, avatars have only a limited amount of space inside their inventories (e.g. 8 slots). When getting items from containers (specially in paradigms where all the items must be taken out from the box at the same time), the designer must take care that there is enough space to store them in the avatars' inventory.
  • Weight of container. In the complex approach, a container should not be able to store an infinite amount of items (although magic containers could do the trick...). The designer must associate an "item limit" to a container and check whether this limit has been exceeded.
  • The danger of being a kleptomaniac. If you have not any Chaz (see Intro) in you party, it is most likely that you can inspect any library, closet, or whatever-you-want inside a house. But if you, as a designer, think that this is boring an unrealistic, you can do what the guys of "Ultima" and "Avernum/Geneforge" did: Create a Flag for every item that indicates whether it can be taken or not from a container. If you take any "flagged" item and somebody see you, people in the town will be pissed off. And if they caught you another few times, maybe they will attack you!. The decision is in your hands ^_-.
  • NPCs!. Enter "Star Ocean 2", and "Fallout". If you can get any item from the furniture... why not trying to steal items from people?. In this approach you have to define what kind of items have the NPCs in their inventories, and give a mechanism for stealing them. Of course, if somebody see you in the "crucial moment", you will have problems. An evolution of this approach: if you can steal, why not "give" items to people (like in the complex approach)?. I'm sure that this snake we got in the jungle can be used in this kind of situations...

 Conclusion

"Chaz, don't complain. He is starting to look... oh, shut up"
"Oh, Damn, he spot us!... Chaz, JUST SHUT UP!!"

 Contributors

REFMAP
For the graphics of the gold, the lamp, the basket, the treasure box, and the book ^_-.
http://www.mogunet.net/~fsm/

Chaz!
... and of course, Chaz and Alys from "Phantasy Star 4", game made by Sega for the Megadrive/Genesis. You rock!