Leverage Browser Caching

Discussion in 'Game Development (Technical)' started by quaymat, May 19, 2017.

  1. quaymat

    quaymat New Member

    Joined:
    May 19, 2017
    Messages:
    1
    Likes Received:
    0
    So, after some reading I decided to take a pass on Starling and do the next game in HTML. It's (surprise) another financial strategy game so I don't need to have a gazillion sprites moving on the screen but hitting a lot of devices at once has high value to me.

    This AM I have a caching question:

    I have 32 property cards that are 300x300 pixels - would you store these in a single large sheet or as indvidual images? I'm leaning towards the latter for faster start up as I expect to eventually have an asynchronous loading scheme so that the game starts faster (with the expectation that all of these large jpg files will sit in cache).
     
  2. bantamcitygames

    Administrator Original Member Indie Author Greenlit

    Joined:
    Jul 27, 2004
    Messages:
    1,718
    Likes Received:
    75
    I don't have too much experience with browser games, but I would go with separate images. Some graphics buffers can't fit larger than 1024x1024, so if you combine, don't put more than 3x3 in each image file.
     
  3. Scoper

    Indie Author

    Joined:
    Nov 5, 2015
    Messages:
    70
    Likes Received:
    18
    The main purpose of sprite sheets is to improve performance (frame rate). Since you explicitly state that this is not a goal, I would advise against using sprite sheets unless you see actual performance problems. If cannot fit all your sprites in the same sheet, as bantamcitygames pointed out, then you are unlikely to get any significant performance improvement (if you are good you can cleverly group sprites to get around this problem, but that is complicated stuff).

    "hitting a lot of devices at once has high value to me."
    In that case, no amount of optimization or technical speculation can replace practical testing. You need to get your hands on some different old mobile devices and try to run your game on them and do some profiling. It is the only way to know. Try to get the oldest and weakest hardware. If it runs on that then it is likely to run on the higher end stuff too.
     
  4. NicolaLC

    NicolaLC New Member

    Joined:
    Jun 15, 2017
    Messages:
    1
    Likes Received:
    0
    I think the best way is using a single sprite image.

    The reason why is simple, if you have 300 instance of the same image going to compose the sprite animation, the server will download 300 images instead of 1.

    If a single image weight 128kb (for example) you will have to download 128*300 kb, wich could be really slow on high latency networks and the server has to cache a lot of contents.

    Instead if you have one single spritesheet image you will download a single content (e.g. 500kb) and the server will cache only one content, and the split process will be managed client-side using javascript.

    So if you use a single content the server will cache it one time, and the client will download it once until you clear the browser cache.

    Another scenario you could have with multiple image is the following:

    a) you use 300 single images for a sprite animation
    b) you change the image 299 because it has a problem
    c) the client has to download all the images to refresh one

    Instead if you use a single one:

    a) you use 1 single image for a sprite animation, a spritesheet
    b) you change the image because it has a problem
    c) the client has to download a single image to refresh the entire animation

    Cheers ^^
     

Share This Page

  • About Indie Gamer

    When the original Dexterity Forums closed in 2004, Indie Gamer was born and a diverse community has grown out of a passion for creating great games. Here you will find over 10 years of in-depth discussion on game design, the business of game development, and marketing/sales. Indie Gamer also provides a friendly place to meet up with other Developers, Artists, Composers and Writers.
  • Buy us a beer!

    Indie Gamer is delicately held together by a single poor bastard who thankfully gets help from various community volunteers. If you frequent this site or have found value in something you've learned here, help keep the site running by donating a few dollars (for beer of course)!

    Sure, I'll Buy You a Beer