Quick example of a Tile Map
 

(And history repeats itself)

Anyway, I have attached an example of a tile map (this seems to be question of the month).

Note how the map is set up as a two-dimensional array of integers,
there is a bitmap for the tilesets, and the
GFX object draws onto the Backup bitmap object.

Backup = New Bitmap(304, 304)
'Backup will be initialzed to an empty bitmap
(There's no significance to the 304 in the example, either...
but it has to be large enough to accommodate the map.)

The map is drawn like:
And the project (in .NET 2003), although you only need the .vb file and the pictures, and you can make a new project in .NET 2002 that does the same.
:)

Tile Map with animating character on it.
 

Well, the second installment here. This time I have a character on the map.
I use a collision detection to check if the character collides with the chess tile or the edge of the board.

New highlights here:
The character animations are in separate frames.

The map is read from the included text file.

Since the character is animating, I have created a form object
Dim FormGFX As Graphics 'Draws to the form.
That draws the map on demand.

Dim Backup As Bitmap 'Backup picture holds the map that we've just drawn.

GFX = Graphics.FromImage(Backup) 'GFX draws onto the backup picture.
FormGFX = Me.CreateGraphics() 'Draw to the form.

And now, we can draw the map to the form in the draw subroutine.
The * 16 is the tilewidth, so this converts our player's tile location into a screen location, so that the player appears to be walking on the map.

We need to update the map display in order to show the character's animation.

And finally the collision detection.
Of course, I've attached the commented project as well.

Moving character on scrolling map.
 

Third installment here.
This demonstrates a possible way to have a scrolling map where the character remains in the center of the screen (except for when the character is close to the edges of the map).

The map display size in the attachment is 7x7 measured in tiles, so there are 7 tiles across and 7 tiles down, the character remains mostly on the 4th row and 4th column in this display, three tiles away from all edges of the screen, as indicated in the constant value.
The Bitmap display is set to be 112x112 (written as 16*7 so it's clearer)
Everything else is the same.

Now, to determine what part of the map to draw, I use two variables, CamX and CamY, to indicate the 'camera', which only indicate the tile that I'd like to use to start drawing from.

Under normal circumstances, the camera will always be three tiles to the upper left from the character.
Of course, I'd need to alter the camera's location when the player gets near the edges:Where each condition except for the Else checks if the character is close to the left, right, top, and bottom edges, respectively.

Then the drawing for the map with the camera becomes:
Of course, you can download this commented project as well.

Smooth Movement between Tiles
 

The previous post was about getting the character and the map to scroll as the character walked from tile to tile... but the movement was choppy.

Here, we get the character to move smoothly along the tilemap by allowing the character to occupy more than one tile. This can be accomplished by changing the Character location to represent their pixel location instead of their tile location.
Of course, the movements will have to be tweaked as well. In addition, the player can occupy up to four tiles... so the collision detection would have to check all 4 of these tiles for collision. This can be done by taking the X and Y locations and rounding down/up to the nearest tile. The four combinations (two for X and two for Y) will give all of the tiles that the player is occupying. If the player is only on one, all results will yield the same tile.
SymbolicTile contains the values of dividing the player's location coordinates by 16 (the tile size)
SymbolicTile is updated after the player moves the character.

Now, this is just the character's interaction with the map. Things still need to be drawn.
First, our camera's location is now in pixels as well. The display still has an odd number of tiles on the screen. The camera's X value is moved to 0 if the player is too close to the left end of the screen, and is also capped off at the other end at (Mapsize - Displaysize) * Tilesize
To simplify the explanation, I added six other variables:
StartX and StartY indicate while tile will be drawn in the upper left corner of the screen. This tile may or may not be wholly visible but as long as we know which tile is in the upper left, this can still be done.
OffX and OffY determine how far the upper left tile is off of the screen... it also determines the amount that all of the other tiles are offset.
EndX and EndY are the last tile in the bottom right corner... this is not always a fixed value from StartX and StartY... when the player is directly on a tile, there are 7x7 tiles on the screen, but if the player is not on a tile, there could be 8x7, 7x8, or even 8x8.

Hexagon Tile Maps
 

Setting up a Hexagon Tile Map is a bit different from the regular Tile Maps above.
First of all, it's important to figure out how the hexagon map will be laid out, how it will be shaped, and how the hexagons will be assigned tile locations.
After all, a hexagon map represents a two-dimensional array... so each hexagon on the map should have an X and a Y tile location.
The first thing to do is determine how the X and Y tile location values change as you move to adjacent hexagons. There are two examples in the hexref picture below of how you might do this: The left method is starting with a hexagon that has the tile location of (5, 5) and from there, linearly assigning
tile location to all of the surrounding hexagons (below, moving to the lower right hexagon, there will be the same Y value as on the previous hexagon).
The second method on the right is taking the six directions of movement and indicating how much each tile location changes as you move in this direction. for example, moving to the lower left hexagon causes the X location to increase by 1, but Y remains constant (changes by 0).

After you do this (its recommended that you do the 'differential' if you choose the left method), you should look at the hexagon that models the tiles in the map. Look at the hexmetrics picture - all of the properties of the hexagon are measured - find these properties by looking at the images that you are using for the hexagon tiles - these values will be constants in the program. (The hexagons in the file are 32 wide)

The map is still a 2D array, as well as the character location is still unchanged. The map is still read from the same type of file.

The next thing that needs to be figured is the drawing of the hexagon map.
Drawing it like a regular tile map leaves lots of holes and doesn't look hexagonal at all. The drawing subroutine needs to draw the map 'hexagonally'... and this is done by a 'transformation', (that's what I call it). The transformation will transform a tile location into a display location.

The tilemaps that have drawn before would have transformation functions of
xX = 16 * LX, where xX is a screen X location, and LX is a tile location.
and similarly, xY = 16 * LY
16 would be the width and height of each tile representing the amount to skip over in each direction when going to the next tile, and the first tile (the one at (0, 0) ) is drawn at the upper left corner of the map, at screen coordinates (0, 0).
These are not the same with a hexagon map.
In the project, you'll see the transformation function in the X direction also depends on the Y tile location as well as the X tile location... similarly xY depends on LX and LY.
In the project, they are xX = 24 * LX - 24 * LY and xY = 16 * LX + 16 * LY, or
xX = 24 (LX - LY), and xY = 16(LX + LY)
The 24 and 16 are expressed as constants in the project - keep your eye out for them :).
Also, you have to find the zero point (like the y-intercept for line equations in algebra)... this is the coordinates where the hexagon at tile location (0,0) will be drawn. In the project, each coordinate is a constant expressed in terms of the other constants (that define the hexagon sizes). The zero point in the project is (264,0), the 0 for the top would be pretty obvious.
These zero values need to be added to the expressions for the transform functions.

Also, there's the character movement, where the differential comes in handy to determine how much the character coordinates should increase with each direction. (I used 7, 8, 9, 1, 2, and 3 on the numpad for controls).
The collision detection is still the same.

Have fun. :cool: