Shops and Bartering

Resources are commodities, so characters will want to buy and sell their wares from
and to each other. Only specific characters in a game are open to bartering. These
characters are commonly called “shopkeepers” because they tend to appear only in
stops. You know the drill—enter a shop, approach the counter, and begin dealing.

There are specific types of shops for each type of resource dealt with—item shops,
weapon shops, armor shops, and so on. You can use a standard approach to shops
in all instances.

Character inventory control systems are not just for PCs; here the inventory control
system (ICS) comes in great for shops and shopkeepers.
Shopkeeper characters have a unique ICS attached to them, one that determines
which items a given shopkeeper character can sell. You don’t have to worry about a
shopkeeper buying items; all shopkeepers can buy all items marked as sellable (for
a reduced cost as defined in the item definition, that is).

Buying an item from a shopkeeper is a matter of displaying the shopkeeper’s list of
items and their cost. Normally, shopkeepers never run out of stock, no matter how
many items the player buys; but occasionally you’ll want a shopkeeper to sell only
one instance of an item.

Some tinkering with the ICS is in order, but only in terms of quantity of items. If a
shopkeeper has an unlimited amount of an item, you set the quantity of that item
in the ICS as 2 or more.
A quantity value of 1 means that the shopkeeper can sell the item only once.
Ingenious, isn’t it?

You will find it better to work with shops outside the character code and in the
game’s main application code.

Working with Magic and Spells

Naturally, a first-rate role-playing game must have characters capable of harnessing
the mysterious magical powers of the unknown in order to reduce the game’s
denizens to small piles of charred flesh. Even if you’re not into the deadly side
of magic, don’t just dismiss the benefits of a well-timed healing spell. Magic plays a
major part in role-playing games, and now is the time to find out how to blast your
game’s players with awesome spells and their inevitable effects on the targets.

From a gamer’s point of view, a spell is a fancy flash of graphical goodness,
although from the game engine side, a spell is nothing more than a function that
alters character data. Your game engine can separate graphics and functionality,
the two components of a spell, thus making each component easier to handle.

Spell Graphics

Using 3-D meshes, you can easily deal with the graphical portion of a spell. These
spells originate from the spell caster and journey forth to their intended targets, at
which point, the spell takes full effect on some poor character. This happens in
three steps—origination of the spell mesh, traveling of the mesh, and when the
mesh reaches the target. With each step, you can assign an animated mesh, which
means that a spell can have up to three meshes graphically representing it.

To increase the choices in creating your game’s spell effects, the position and motion of those three
meshes are not fixed. In fact, any of the three meshes can hover over the caster or target, move from caster
to target or target to caster, or stretch out between the caster and target.

Whenever a mesh is hovering over the caster or target (or stretching out between the two), it remains
there for a fixed amount of time (measured in milliseconds). This gives your mesh the chance to
complete its animation cycle (or multiple cycles).

NOTE
Each mesh is displayed separately.Two spell meshes can never be displayed at once.When one
mesh completes its cycle, it is released, and the new mesh takes its place.

As for moving meshes (moving from caster to target or vice versa), a mesh is
assigned a speed of movement (measured in units per second). Once a mesh
reaches a target, that mesh is dismissed, and the next mesh takes over (if any
meshes are to follow).

Say that you have a fireball spell. Only two meshes are required. The first mesh,
a fireball, originates from the caster and moves toward the target, as illustrated in
Figure 16.8.

The second mesh, an explosion, takes over when the first mesh reaches its target.
The explosion mesh hovers over the target and cycles a few times to give the
appearance of some real damage taking place. You’re probably wondering about
those times when you don’t want a spell to move but still want it to extend toward
your target. That’s the reason for the stretch positioning of meshes.

If you define a mesh that extends outward in the positive Z-axis (which you should
always do), that mesh can hover over the caster and scale so that the farthest extent
of the mesh touches the target. This stretching (or rather scaling) is perfect for
spells such as lightning or a groundball spell that ruptures the ground between the
caster and the victim. Although not apparent at first glance, the groundball spell
described in Figure 16.9 shows a small brownish-colored mesh
that is stretched out from the spell caster to the target character.

As you can tell, tracking the three meshes of the spell graphics component is just a
matter of loading the appropriate meshes and rendering the correct one at its
proper position over a period of time. Upon completion of the required mesh
cycles, the graphics segment of spells is complete, and it’s time for the functional
portion to take over.