Posted by: Xalthorn | October 4, 2007

Web Game Layout

Having made a decision about the content I want in the game interface, I have now hit the next stumbling block.  How to lay the site out.

The first question is of course, what resolution to support.  Having a website that is generally too wide for most people is a cardinal sin.  We’re all happy to scroll down a web page, but having to scroll sideways is just not on.

640×480 is generally not used by people who play web games nowadays, but 800×600 is, with some people moving to much higher resolutions.  Having looked at a fair amount of website tutorials, and the widths used there, I’ll be building the default web interface to be 760 pixels wide to allow for scrollbars and a little dead space around the page.

The next issue is the height of a header and other fixed content that pushes the actual game content down the page.  If most games require the player to click on a display area, each click causing a refresh, then having to scroll down the page to find that area would get annoying very quickly.

A header that is there simply to show the name of the site, often with a big graphic, seems to be a bit of a waste.  By the time the player has reached your site, logged in, and wants to play the game, they already know the name of the site.  Do they really need to be reminded by a large header?

To deal with this, the front page, and general site pages will have a fairly decorative header.  However, once you are in the game interface, this header will be tucked away in a small login status bar at the top of the page.  I’m not expecting this to be deeper than 20 or 30 pixels and it will have the name of the site (which itself is a link to the homepage), who you are logged in as, new mail/message/forum alerts, and so on.

Once you get past that small header, the content that you need to actually pay attention to will be displayed.  The more important (frequently used) stuff at the top of the page, the less important or occasional use stuff lower down.

Although it is tempting to have a horizontal menu bar underneath the header, this will again push the content down the page.  In the default layout I will probably have a sidebar menu with a quick link section in the header (if it fits).  Unless I have the game specific menu at the top of the sidebar, with less frequently used options beneath those.

Of course, the only way to find out what works is to try it in a browser and see what is easily accessed.  Time for a bunch of layout tests I think.



  1. 800×600 is a pretty tight box for a web-based game, although it might force you to be creative with the layout (which can be a good thing). Personally, I set my minimum testing to 1024×768. With a map-grid and other information on the screen, it’s extremely hard to fit everything. According to my Google Analytics data, 50% of my “visits” are at 1024, 17% are at 1280×1024, and 6% are at 800×600 (the rest are all using random widescreen and dual-screen resolutions that are all larger than 1024×768). I guess those 6% are just scrolling and dealing with it.

    The Web Developer add-on for Firefox has a button somewhere that shrinks your browser window to various resolutions – good for testing quickly.

  2. I used like 824 width I believe, I figured the geeky folks that would be playing my game would be running a better resolution. Even my dad is running 1024 X 768. 🙂

  3. I’m finding the depth harder to deal with than the width. The additional width would give me a third column quite easily, but two should be okay for most cases.

    It doesn’t help that I’m trying to have a main game display of 480×480. 1024×768 displays it fine without having to scroll down, but 800×600 still needs scrolling.

    I suppose I should toddle over to a bunch of game sites again and see what resolution seems to be the standard and if I can get away with ignoring 800×600, especially after your comments.

    I’m doing some simple screen mockups for assorted parts of the site, to see how it all fits together and how much I can fit in without it being crammed together.

  4. I had a look at a few PBBGs and there are enough of them that seem to fit nicely into 800×600 to warrant me making mine fit as well.

    Initial screen tests are working well, and I should be able to put the new user registration and login system together with the new layout quite soon.

    The biggest impact that is making things fit so far is reducing the depth of the header. Width isn’t as big a problem as depth for me because of the main game display that I still want to keep at 500×500.

  5. I am still working on trying to fit things into my view port so I feel your pain. Looking forward to your game. 🙂

  6. What I noticed is that the size of the display is essential if you use Javascript for animations and drawing.

    I’ve also been running a test lately to check what is actually taking the most time in loading (or generating) a tile map.

    I noticed that the DOM part of actually attaching the tiles to the view is what really slows the process down.

    It really does matter how many objects you attach to your view object at once. Though once attached t doesn’t really make a difference for scrolling if you have 400 or 40.000 tiles attached.

    for test results.

  7. I’m a little confused what you mean when you say the number of objects doesn’t affect scrolling.

    Your test results seem to record the amount of time it took to attach the objects to the view, rather than any sort of indication on the smoothness and speed of the scrolling.

    I’ve done a little code test to implement a scrolling map and it seriously suffers if I put too many tiles in there.

    If I keep the count low (20×20), then it scrolls at a decent pace. If I crank that up to 50×50, then there are serious speed issues.

  8. Yeah, if you have to scroll 20 or 100 objects it does matter.
    But I wrapped the tile images into a map div and instead scroll this div.

    It’s only natural to let the browser do the work and not your Javascript. set the position for one div instead of lots of images.

    Surely this enforces some tweaks on other ends but I think it is worth the effort.

  9. Sorry, forgot something 🙂

    My goal with this test was that it is more userfriendly if you attach only those items that come into view rather the whole world at once. But because of the discovery (I didn’t mention in this test) you don’t have to remove what is out of view. That’s much the way how google maps works.

  10. I was under the impression that Google maps had a small number of map tiles and they were absolutely positioned within the map holder. As one map tile scrolled off one edge, it was moved to the other edge and its image updated.

    This was certainly the way I was planning to advance my scrolling map, send the raw data from the server to the client and let JavaScript worry about which bits to display as the map was scrolled.

  11. ‘duh… I think I just outed myself as dummy 😉

    I looked at google maps and noticed that indeed it does reload the images that were out of view anytime I move the map. So it looks like it reattaches the nodes…

    I then ran another test on my editor and indeed the element count has a tremendous impact. When I mentioned it had no impact I used mouse scrolling and it was smooth as butter. I had now quickly tested out a keyboard scroll that changed the top and left attributes of the style and it was terrible already with about 625 images attached.

    It seems that moving an object with or similar takes much more power than scrolling it’s parent element.

    After running a quick test in FF3 it really seems that setting el.parentNode.scrollTop instead of has vastly different performance. Even with 2500 tiles the map scrolled smoothly using keyboard controls.

  12. That’s a cunning plan.

    I had a play with my code which was using to move things around.

    Quite a lot of messing around later to make things behave like a scrollable window (even though there are no scrollbars) and it all works much faster, even with 2500 tiles.

    I need a few conditional routines to deal with the difference in what I’m playing around with, but it’s certainly a workable solution.

    It’s probably faster because we’re directly moving an object rather than a style which then needs re-applying to the object.

  13. It’s probably faster because we’re directly moving an object rather than a style which then needs re-applying to the object.

    Yes that is probably it. scrollTop is an obeject property and doesn’t have to repaint the whole element you are changing. I wish you could access offsetTop / offsetLeft in the same way to move objects… but alas these are read only.

  14. After an extended period away from this blog, I come back with all sorts of confusions, contradictions, and (in theory) ‘better understandings’ (at least in relation to my own project).

    After standing on a little soap box about 800×600 and stating that I will adhere to this resolution, I’ve spent so much time on assorted projects that 800×600 really isn’t a necessary requirement for my projects any more.

    I now have a site design that is very adaptable and sits very happily in the 1024 resolution. The content is actually 960 wide and even on a 1024 gives a brief margin, and can look very nice centred on larger resolutions.

    960 seems to be a very nice width and there are templates out there for the ‘960 grid system’ as it breaks down into divisable chunks really nicely.

    I have an initial website that I’m using to test layout and code concepts, but with actual data and users so I can get feedback more quickly. If anyone wants to have a look it’s at:

    It’s a guild website for a game and therefore the content will only really make sense to players of the game. Most of the content is freely available without a login though.

    Should anyone have a look and notice any real or potential security issues, please be nice and let me know 🙂

    I plan to take the design and lessons learned on this site to my actual project.

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: