This page contains useful information on DGC, games programming and DirectX
IV-VII
----------------------------------
- VI : Disappearing Roof Tiles -
----------------------------------
This effect can be done using my multi-layer method by simply sectioning off a few of your
base tiles (say 48-63 for example) as 'FLOOR' types. These would have another tile in
memory as well as their normal tile, for when those floors are covered. In general, all of
the FLOOR types will be covered most of the time. When drawing your screen and come upon a
tile that is a FLOOR tile, then you'd check to see if the player was standing on a tile of
that type... If not, draw -only- the alternate 'ROOF' tile which corresponds to that FLOOR
tile. If the player -is- standing on a FLOOR tile of that type, draw the BASE, FRINGE and
OBJECT layers normally. This way you can have only the roofs where the player is,
disappear when they enter a building. (also see Appendix I)
------------------------------------------------
- V : Tilted effects, using the FRINGE Layer -
------------------------------------------------
I like the 'tilted' look in my tile projects, it gives a bit more of a realistic flavor.
If you have the memory, the best way to achieve this effect is to set aside a 4th layer to
your map, called the TILT layer or something (it can also be used for ROOF file management
if you like, think about it :) ). But since most people don't have the memory for four map
layers in memory, I'll discuss the memory-deficient method.
Just draw the main portion of your tilted walls as your BASE layer tiles, then use the
FRINGE layer to hold the extra bits that tilt off of the tile. You would have to do a
special check to see if the FRINGE
layer tile in question is a tilt-result or a normal FRINGE tile, because of the order of
drawing. If it's a tilt-result, then you would want to draw the OBJECT layer and the
PLAYER before drawing the tilt-result tile; and if not you'd follow the normal order of
BASE-FRINGE-OBJ.
This is where the 4th TILT layer makes like easier, for those who have the memory to use
for it. It allows you to skip this check and just draw in the normal order, since your
normal FRINGE and tilt-results are already split up...
------------------------------------------------
- VI : General comments on the OBJECT layer. -
------------------------------------------------
The OBJECT layer in my projects is an array the same as the other layers of the map, of
unsigned characters (or bytes). These have a value of 0 to 255, by the variable size. I
find this to be enough objects to cover my needs. Each number would be an index to a
particular object, 0 meaning there's no object in that map-space. I split the byte up into
various object categories...for example 1-127 would be monsters and towns people, 128-255
for inanimate objects...whatever. Anyway, I like to have an 'intelligence' (much like
walkability) assigned to various groups of objects.
These are usually broken into groups of 16, for the ease of the math to get the
values...Below is an example break down of 'Intelligence' of objects (more info on this
style of attribute, see the 'Walkability'
section)...
INT Index : What behavior is exhibited by the Object...
0 0-15 : Townspeople...wander aimlessly...
1 16-31 : Townspeople/Monsters who are afraid of the character.
2 32-47 : Docile Monsters, wander aimlessly until attacked, at
which point their INT is switched to...3...
3 48-63 : Same Docile Monster pictures, but now they're mad!
4-5 64-95 : Normal monsters, they charge at a slow pace...
6 96-111 : Baddie monsters, they charge right at you..
7 112-127 : Projectile firing monsters...
8 128-143 : Keys, and other door-opening things.
9 144-159 : Weapon objects...
10 160-175 : Armor and the like...
11 176-191 : Cash, and other booty.
12-13 192-223 : Normal, plain objects, like books and candles.
14 224-239 : Some other Obj category...
15 240-255 : Objs that hold other objs...bags, chests, backpacks.
The above is just a sample chart of how you might choose to lay out your OBJECTS to get
the most efficient use of the INT value. I like using an Intelligence to keep track of
behavior of OBJECTS. Thus in order to do the proper things for each OBJECT I would simple
have to check that object's INT and then do what I need to do for that OBJ. It's
helpful...understand? I hope so.
Many large projects will find that 255 just isn't enough objects, in these cases, you'd be
best advised to move to an array of unsigned short variables (short ints...16bits) this
allows for a value from 0 to 65535. That should be enough objects for any game I've ever
played!
------------------------------------------
- VII : Multiple OBJECTs on one space. -
------------------------------------------
The question was raised when I was discussing my methods with another programmer, how do
you handle multiple OBJECTs in one space? I never really thought much about it before and
just restricted OBJs to one per space. The simplest method I came up with is special INT
(see above section) values for OBJs that hold other objects. These are things like bags,
backpacks, treasure chests, etc. In the example above this is category 15, Indexes
240-255. The objects would have a picture assigned to them as normal, but they would each
have an independent array of other OBJECTS that they hold. Each of them could have a
certain max set by your particular array structures. This way, when you pick up those
objects, -all- of the object list gets added to your inventory. When there is a chest or
bag on the ground you could also drop a number of OBJs there and have them be filed off to
the independent array for that bag or chest.
This method is a good way to incorporate a way to have multiple objects in one map space,
without having a huge amount of additional map layers. It's relatively speedy, and still
memory efficient. Please note that the maximum number of bags and other such
mult-OBJ-objects, are limited in number by the number of array structures that you assign
to them, so never include more than the number that you can handle on one map.
Often times the above method is too restrictive or doesn't match the play style of the
game. The alternate method is a bit more complicated and requires a knowledge of the use
of 'linked-lists'. If you aren't familiar with linked-lists, pick up nearly any intro-book
for your programming language of choice and look up linked-lists on the index...you should
find it. Assuming a knowledge of linked-lists, I'll continue.
Change your object layer to an array of list pointers. Then as you place objects in a
map-location, add a node to the list at that location. When objects are removed, remove
the node. This will allow for an unlimited (well, memory limited) number of objects on any
particular map-location.