Real Life Interference

Sorry, for the irregular posts, but I had some stuff coming up last week and on the week end, and I'm not sure that this will not also happen next weekend. I hope that I can establish a regular posting circle soon, but ... well ... it would be boring if you could predict life.

Tile Maps and how to draw them.

In the last post I covered what tile maps are and why we use them.

This time I will talk about how to draw tile maps.

For the Computer a tile map is just one long line of information, once in a while the may is a symbol that indicates that one row is over and the next one begins. It hold no real information on how to draw the whole thing.

Not only that, but also are there may ways how a tile map can look like. There can be square shaped tiles, there can be hexagon shaped tiles and I once even heard of things like circles and what not.

For simplicity I will cover here only the two main forms: square and hexagon.

Orthogonal Grid (Square Tiles):

A orthogonal grid is rather simple: you got X columns and Y rows. X is traditionally the left to right coordinate, and left the the top-down coordinate. Note that normally the position 0/0 is normally at the top-left and X/Y at the bottom-right. But when you program your own code yo are of course free to change the coordination-system as you please.

Beside the coordinates you also need the width of your square and the width and height if you use rectangles as tiles.

And in the end there is one last thing to consider before you draw your grid: When to draw what?

If you draw a simple 2D background you can skip this part, but imagine you want to draw a 2D Top-Down-View Level with some bushes. Some of them are in front of the player-character and some are behind. It would look stupid if your character stands on top of a bush that he is supposed to be behind. So you not only have to change the Grid-Drawing code a little, but you also have to place the drawing code of the character and enemies in that same code.

Here is my solution:

//X and Y being the dimensions of the Grid.

for (int y = 0; y < Y; y++)

{

//If the Y-Coordinate of a dynamic object (like the player) is smaller than y*height,

// and it has not been drawn yet, draw it here.

for (int x = 0; x < X; x++)

{

//Look up if there is a tile on that position

//Look if the tile actually exists in your Content/Asset Dictionary

//If yes, draw it at Position(x*width, y*height), else continue

}

//Alternative to drawing the dynamic object before you draw the current row,

//you can also check here if they are behind the next row ((y+1)*height) and draw them.

}

//If a object was not drawn in the loops and is on screen, draw it here.

Now that was the easy kind of a tile map, now lets make the more complicated kind.

Hexagonal Grid:

Unlike squares and rectangles, hexagons can have many different shapes and arrangements, but for the simple cause of lack of time I will only cover the normal uniform hexagons.

Basically I use the same Grids like orthogonal grids, but I shift every second row (or column).

What you can also see is that the placement of the tile depend on the orientation of the tiles. I will not go into too much detail here, as it is rather simple geometrics in the end, but I will say that you always should know how you Coordination system looks like and what you width and height is.

//In Code:

The code is similar to the orthogonal code, so I will leave some parts out so you can clearly see what makes the hexagonal code unique. Note: This code is the left grid arrangement of the picture above.

for (int y = 0; y < Y; y++)

{

for (int x = 0; x < X; x++)

{

//Every second column we have to shift the tile H/2 down.

//The other arrangement is the same, you only have to switch the multiplication of

//the width with the multiplication of the height (but not the values themself ;) )

if (x % 2 = 0)

Position(width * 0.75 * x, (height / 2) + (height * y));

else

Position(width * 0.75 * x, -(height * y));

}

}

Tile Map

Every game needs some kind of background or even environment, in the case of 2D games that would make 2D pictures. In the early days it was rather hard to draw and save pictures big enough to fill the entire screen, not to mention that have one for every Level in a game. There were and are games with hundreds and thousand of such screens after all.

So quite early someone had the brilliant idea to not use one big picture for the whole screen, but little ones that would repeat them self in patterns using a 2D map. The Tile Maps where born.

Even if modern PCs and Consoles have enough power to store and handle pictures for the whole screen without much ado, Tile Maps a still quite popular with game designers, as they present a way to quickly, without many resources, create huge and individual Levels.

That is also why I use it.

For a Tile Map you need two things:

First a Content, or how I call them Assets (Content was already taken in the code).

Second you need the Map, a 2D Array of information (later called Grid).

Assets:

The Assets are the little tiles that will be drawn on screen.

Not always are the Assets stored in single pictures also can they have other special behaviour like offsets. Also can it happen that when you use a Editor (like me) that you may have one source picture for one and the same tile, but the Editor and the Game treat them differently.

For that it is quite useful to have a separate entity that holds those informations. Its is also good that this information is separately to the picture as you can safe it separately using less memory, and you can vary easier (without gaining much memory usage).

At the moment this results that I can have one source picture for the whole Level (Asset1) and multiple others that point to this picture as their Source, but showing only one part of it (Asset2 to 5). Then again I can have another Asset (6) that points at 5, but draws it with a offset.

Using this you can have a Stone centred on the grid at one place and then have the same Stone off the grid in a different place.

Creating such variations in a Tile Map is important as you don't necessary want the player to know that you use a Tile Map.

// In Code:

One Dictionary of 2DTextures that holds the actual pictures, and one that holds the AssetInformation. The two are linked together using unique Tags as Keys, like the file name of the picture.

Grid:

This is the same Grid about which I've posted earlier.

It is basically a 2D Array of information. Theoretically can a Gird for a Tile Map hold any kind of information, from Numbers up to Text. All it needs is a clear way to point out what tile it wants to draw where.

I use a 2D Text Array (string) for this, as I plan not only to store graphic information in it, but also scripting. Like the Dictionaries of the Assets, I use here the Tag of the Asset to point out what to draw.

//In Code:

There are two ways to implement a 2D array in a modern programming language: First a multidimensional Array (string[x,y]) and second a jagged Array (string[x][y], or a Array of Arrays).

Because it is easier to handle in some code (safeing, copying, changing dimension, etc) I decided to go with the jagged array approach.

So this is how a Tile Map is build up, in the next post I will write how to draw them, as this can be its own little problem.

Work, work, work, ...

Did not forget to update the blog, only had to build a stone wall with my bare hands. Will update by time.

Level Structure

Getting back into blogging is hard, especially if you want to do it right. Right now I plan to post once a week. Fridays probably. Anyway ...

The game that I plan has some inspiration form The Legend of Zelda, and not only gameplay wise but also level structure wise.

The goal will be that I have one 'Level' as super structure and multiple 'Sections' as actual screen to see by the player. If you every played the Original The Legend of Zelda on the NES (or Virtual Console) you may know this set up. But unlike Zelda I plan to add further levels of detail to the individual Sections using multiple Grids.

Level:

The level is 2D grid with user defined dimensions (X/Y). The Sections are planned to be linked together by scripts and not by positions in the Level grid, what makes the actual grid obsolete. I still hold on on the grid as a Level Design Help. The Level Editor later will (is supposed to) display little pictures of the actual Sections (like shown in the picture above) and links between the Sections. It may also display more script information if it turns out to be handy.

//In Code:

A Leve is its own class with a string[][] Array for the position of the Sections (using their tags) and List for the Sections themself. This is done to save memory when many placed is the grid are kept empty.

Sections:

A Section is a List of Grids. The position in the List will later determine when a grid will be drawn in the actual game. The second grid will be drawn after the first, and so will appear atop the first.

//In Code:

A Section is a class with a List for the Grid Class ... simple.

Grid:

The Grid is the backbone to the whole system. Basically it is a 2D Grid of text-information. I'm not far with the Scripting language yet, but by time a single Grid will hold Graphic-Information and Level-Design elements like a door (or portal if you want) to a different Section of the same Level.

//In Code:

The Grid Class has, similar to the Level Class, a 2D Array with Text-Information.

This is just a short summery of the Level Structure. The classes also hold some little meta information and some helping methods, but they are not that important.

So that is a little overview of the Level Structure that I use. I hope I will write more next week. Then it should be about the Tile System: How to come from a Bitmap, over the editor to a TileMap.

Greg