Posted by: Xalthorn | December 5, 2007

Map Display Boundaries

When you have a map that can be displayed in either top down or isometric view, one of the views is going to show more data than the other. Whether this is acceptable or not is a decision that needs to be made.

I’ve done a few images to demonstrate what I mean. In each image, the map data available is shown by the numbered squares.

The first image shows the map data available. The red square shows the main portion of the map that we want to display.

Top Down Grid

The next image shows how the main content would be displayed in a top down view.

Top Down Viewport

All nice and tidy, showing the content that we want and nothing more.

The next image, representing the isometric view, still has the red square to show the direct translation of the top down view to isometric. However, unless the display is intended to be a diamond shape, we need the additional map data to fill in the corners.

Isometric Map View

This means that the isometric view shows more map data than the top down view, but unless you display in a diamond shaped view, this is always going to be the way if you are going to display the same amount of main content (the bit of the map that reaches the edges of the display).

If you decide to allow the user to have a top down view that shows more data, you would need to provide map data to fill in the empty corners of the first image, which then means that the isometric view is missing data.

If you are only ever going to use one view, it isn’t an issue at all. But if like me, you want to give the player the choice of which view to use, they are going to be penalised in some way, based on their choice of view.

I guess it all depends on how much of a perceived advantage these extra spaces give a player.



  1. For an RPG style game, you could introduce something like mist of war or a view distance for your character.

    Having a circular visibility field would solve the main issue of the two view types. Though this introduces a number of new issues.

    I think the easiest solution – if you really must provide 2 view types – is to offer 2 interfaces (simple via an alternative style sheet) to also take care of the 2 different philosophies of the 2 perspectives.

    The wait for switching between 2 views shouldn’t be too long if you preload the images already in the background before the game actually starts.

  2. The fog of war system or limited view range would certainly restrict visibility, but surely it would simply be avoiding the issue and still give a diamond view of the map (okay circular with fading perhaps, but the corners would still be black and ‘waste’).

    Certainly possible though.

  3. Hey, I just finished a prototype for correct cursor positioning in an isometric grid. I just have to figure out to translate the cursor position into tile indices.

    Working on it I noticed that the diamond view might be the best solution to go if you offer isometric and top down. It’ll look better around the boundaries of your map – you won’t have dead space when you are in a corner…

    I like fog of war, but you could have only black tiles that haven’t been visited yet. Once you know the tiles you could make objects transparent to indicate their last known position. A circular field of view is more natural IMHO.

  4. I think the best thing I can do to come up with a system that works for me is to code up a few versions and scroll around the map, seeing which ‘feels’ better.

    It’ll give me a chance to dust off the random routine and dungeon generation as well.

    Actually, dungeon maps won’t suffer too much from dead corners, as you simply fill the rectangular map with things that ‘fit’, leaving the rest as dead space, the rooms and corridors having their own natural edge.

    Overland maps have more of an issue as every square will be filled with something. But there is no reason why the map can’t be irregular shaped, with water/mountains filling in all the edges.

    In other words, I might be worrying about nothing. I’m sure I’m missing something obvious, but I’m wondering what sort of map actually needs to fill both views perfectly. Most maps have an obvious edge or border to them to stop people wandering off the edge, which can easily extend to whichever diamond shape is needed to accomodate both top down and isometric.

  5. There’s a good point with the difference between overland and dungeon maps. I just thought that a square map might always be filled since a map usually has a rectangular data structure (2d array).

    For overland maps in isometric view it might be necessary to either restrict movement so a player won’t get to the edge or to have some algorithm for extending the map boundaries. Though I don’t think the later makes a lot of sense…

    I finished the mouse coordinate script for isometric maps today. I’ll post the code later this week.

  6. I don’t know if you are doing isometric design in the web browser….but here’s a tip if you are.

    I found that the layer technic works well. I create one div…with a z-index of 1….that has all the tiles in it.

    I then create another div… with z-index of 2….I then create the map…but every tile is a transparent gif. I then put all the click handlers on these tiles.

    I hope that made sense. I only mention it, cause I struggled with this for a while. (And it may not be the best solution out there)


  7. @mobeamer:
    If you’re doing it that way you might not get the full tile to be clickable but only the portion that is the top most visible part.

    I managed to put some code together that evaluates the mouse position on the map and choses the tile object based on the mouse position rather than the target reported by the click event. The difference to your method is that I have only a single element that has an onClick handler, the map itself.

    IMHO the advantage of this technique is that you can also use this code to place a cursor on the isometric map (or use highlighting) or other calculations because the code always returns the top-left corner of the tile and the tile position in the tile array. It also takes the scroll into account too.
    I am still working out a tutorial how this code works. I’ll hope to finish it soon and post it along with the complete code.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s


%d bloggers like this: