5.0. GETTING ITEMS FROM CONTAINERS
Intro

"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.

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.

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

"Oh, Damn, he spot us!... Chaz,
JUST SHUT UP!!"
|
Contributors

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

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