Posted by: Xalthorn | October 2, 2007

Isometric vs Top Down

Having played around with the graphic styles, and had a disappointingly low number of responses from the community, I’ve decided on the style I’m going to use.  I’m going to use the top down view, and I figured I’d share my thoughts and reasons for this decision.

Isometric

Although technically more impressive than the top down view, it requires edge clipping to make it look halfway decent unless you go for the diamond view which in itself needs to be incorporated into the centre of a layout to stop wasting screen real estate.

With a scrolling map that is bound to have large structures such as buildings, and given that I can’t draw ‘off screen’ to automatically clip to a viewport, I would have to cut up each large graphic into isometric building blocks, including drawing the cross section of the building unless I was to resort to paper thin walls between tiles.

I could have drawn the whole thing with PHP into a single graphic and sent that down to the browser, but that is very wasteful of both server processing and bandwidth to send such a large and unique graphic each page refresh.

I had also considered using Flash to create the image as that would also solve the clipping issue, but that would be giving temptation to create a fully animated interface which would not only move the goalposts of the project further away, but also move away from the overall aim of the site.

Top Down

There is a good reason why this view is favoured by many web based games, and it isn’t just because of its simplicity compared to isometric.

It’s because it just ‘fits’.  The graphics are easily split into rectangles, and tile together smoothly.  Having a rectangular display also allows for an interface to be easily built around it with no risk of overhangs on the left or right edges.  The top overhang is also predictable and can be allowed for in the view.

Large structures are easily done by cutting the image up into tile sized chunks and drawing them as appropriate, the only concern being the drawing of a tall object or character that is just off the bottom of the display but the top of which would be visible.  Although this issue also exists with the isometric view of course.

Advertisements

Responses

  1. Hehe,

    Having made this decision, I’ve just had it pointed out to me that css *can* clip to a viewing port, which removes a lot of the issues with the creation and display of the graphics.

    Time to do some more fiddling to see if I don’t go and reverse my decision.

    Ho hum 🙂

  2. Okay, I’ve just done some experimenting with the CSS clipping and it works very nicely. However, it has also highlighted another major difference with isometric tiles over square tiles.

    If you want a fixed viewport size (my example is 500×500), the square tiles can be scaled down in a sensible fashion with the amount of tiles displayed growing accordingly.

    For example:
    100×100 tile size = 5×5 tiles
    50×50 tile size = 10×10 tiles
    25×25 tile size = 20×20 tiles

    With isometric, because you have the overhang (to be clipped) and the staggered method of drawing them, the number of ‘Y’ layers, drastically increases if you still want to fill the viewport.

    Essentially, to fill a square viewport, you will have four times as many tiles vertically as you have horizontally.

    The actual figures from my tests are:
    100×50 tile size = 6×21 tiles
    50×25 tile size = 11×41 tiles
    25×12.5 tile size = 21×81 tiles

    Before anyone shouts, I know that the isometric tile sizes are a little silly and I should have worked from an integer for the smallest number and worked up by doubling, giving me:

    96×48
    48×24
    24×12

    But the tests were quick and dirty. If I elect to go down the isometric route, those will be the sizes I use.

  3. Hey,
    Isn’t it only twice the vertical points? as an Isometric tiles using the 45degree projection is 2:1 so if your tiles are 64px wide they WILL be 32px height.

    For example if your view-port is 192px*96px your isometric layout would look somthing like this:

    * * *
    * *
    * * *
    * *
    * * *

    But to get this information out of a database you need to query a 5×5 square grid, which is effectively 25 cells of data where you only need 13, though you can ignore the 12 bits of data the occur in the unseen corners of the isometric grid.

    If what I’ve said is hard to follow just ask, its kinda hard to explain random paper drawings in a textual way :S

  4. Isometric tiles are 2:1 in rectangular ratio, but don’t forget that they need to overlap. This means that as you draw another line of tiles, you are only moving down half a tile.

    let’s see if this diagram of a 5×5 *tilespace* grid works…

    ----------------
    |/\|/\|/\|/\|/\|
    |\/|\/|\/|\/|\/|
    ----------------
    |/\|/\|/\|/\|/\|
    |\/|\/|\/|\/|\/|
    ----------------
    |/\|/\|/\|/\|/\|
    |\/|\/|\/|\/|\/|
    ----------------
    |/\|/\|/\|/\|/\|
    |\/|\/|\/|\/|\/|
    ----------------
    |/\|/\|/\|/\|/\|
    |\/|\/|\/|\/|\/|
    ----------------

    If I take the rectangular markers away, we get a different type of lattice which shows more clearly, the tiles that need to be drawn in the spaces.


    /\/\/\/\/\
    \/\/\/\/\/
    /\/\/\/\/\
    \/\/\/\/\/
    /\/\/\/\/\
    \/\/\/\/\/
    /\/\/\/\/\
    \/\/\/\/\/
    /\/\/\/\/\
    \/\/\/\/\/

    So we’re now drawing 41 complete tiles, with the half tiles at the edges and quarter tiles at the corners counting up to 9 additional tiles, giving essentially an area of 50 tiles.

  5. Ahh, after reading your post again, I think I know where our x2 and x4 are coming from.

    I was talking about using the same size viewport for either square or isometric tiles, and the difference in view range of each system.

    If I had a square viewport of 196×196, and without overlapping or trimming, I would get 11 rows of either 2 or 3 complete tiles depending on where in the stagger it was.

  6. The grid you have drawn is 5*9, whereas it should only be:

    /\/\/\/\/\
    \/\/\/\/\/
    /\/\/\/\/\
    \/\/\/\/\/
    /\/\/\/\/\
    \/\/\/\/\/

    That is a 5×5 grid, i know it looks to short but you need to remember the narrow rows. So you have 3×5 and 2×4, gives you 23 cells. the above 5×5 grid will fit onto a square grid in the following fashion

    0000*0000
    000***000
    00*****00
    0*******0
    *********
    0*******0
    00*****00
    000***000
    0000*0000

    Notice that on the diagonal you get the 5×5, but projected onto a square grid you need a 9×9

  7. At the risk of going around in circles with this, that is why I said it was a 5×5 *tilespace* grid, not a 5×5 grid of tiles, to compare with a 5×5 *tilespace* top down view.

    I was trying to emphasise the point of overlap, and the comparison of tile style within the same size viewport, but I clearly failed somewhere 😉

  8. Hehe, sorry I took along time to type that, didn’t realise you’d posted in the interim. I see your point about needing more data to fill a given area of screen space.

    There is always the option of an isometric top down 😉 That way you get to play with the more complex nature of isometric rendering, and retain the more simple style of a square top down view.

    For my game I’m going to stay with an Isometric projection, as my goal is to make a clone of Simcity, or something very similar.

  9. yeah, that’s the problem of conversations that aren’t face to face, with both people ‘talking’ at the same time 😉

    I’ve written another post where I’m debating ignoring the argument and providing both styles, but there are ‘fairness’ issues with that…

  10. Hi Xalthorn,

    I just found your blog. Nice coincidence that we are working on the same problems. I am currently working on my level editor (Javascript) for my (Open Source) Game Engine. I am in the process of adding an isometric editing mode to it. Contact me if you think you can use it.

    Do you “need” to stick with the square viewport? Wouldn’t it instead be more efficient to use a widescreen viewport (2:1) that shows about the same number of columns and rows?
    http://trac.bookofhook.com/bookofhook/trac.cgi/wiki/OverviewOfIsometricEngineDevelopment

    Scroll down to the end (technical notes) for info.

    BTW, great information here. I probably need some time to skim through. Maybe we can share our experiences.

    Cheers, Misha

  11. Hi Misha,

    At the moment, I’m still messing around with the graphic decision. The editor shouldn’t pose too many problems, but I reserve the right to panic and come asking for help later 😉

    The square viewport was the obvious choice for a top down view and I appreciate that letterbox is an ideal choice for isometric views.

    However, I was taking the view that it would make sense to keep the same viewport in the game interface no matter which graphic style you used.

    This was mainly to stop the page contents expanding and shrinking as you changed the view, which might annoy the player.

    Thinking about it though, maybe it would make more sense to do that. Not only would the isometric view feel more natural and not quite as tall, but it would also allow people to play in that view with a shorter browser window. Perhaps ideal for people with widescreen displays that always lose height.

    My concern about keeping the display a fixed size is also assuming that people would be switching between the two displays. I wonder how many people would constantly switch between the two.

    Another classic case of chasing the wrong problem I think 🙂


Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s

Categories

%d bloggers like this: