Posted by: Xalthorn | September 20, 2007

Graphic Heavy

Something that I probably won’t be able to resist is making Mondestia and its environments highly graphical.  I don’t make many apologies for this as after all, it’s a web interface and not a telnet interface.

However, I have to be practical.  If players have to sit there waiting a long time for each page or page update to load, they are likely to walk away and never return.  At the very least, if they aren’t sure whether they like the game or not, that could make their mind up for them.

I’ve personally visited game sites that are graphic heavy and been frustrated by the time taken to download the imagery, javascript, styles, etc. so I’m not blind to the issue.

One thing I’ve discussed on a few forums before is the idea of having local graphics. It’s a concept I’ve tested and proven already and is really easy to implement but like everything it has its advantages and disadvantages.

On the plus side, once you have the graphics stored locally, page loading is lightning fast.  My dynamic test page was visited by someone using a standard modem and they were amazed that it loaded almost instantly. 

On the negative side, it has been pointed out that the browser cache is designed to do this, however there are issues with that as well.  For example, if I’m providing a lot of detailed graphic files, the local cache may decide to drop a few, forcing a reload (especially if other graphical sites are visited).  Also, they still have to be loaded on the first view which will cause a page load delay for each page that contains a new graphic.  Initially this will be a lot of pages, but I appreciate that this should lessen as the game is played and explored more.

Another plus is that it removes the bandwidth use from my site (after the initial download, which could always be hosted elsewhere), meaning that the bandwidth can be used for pure game content.

Yet another plus is that I was intending that the graphics could be used by players to create their own ‘fansites’, wallpapers, cardstock models, and so on.  A talented artist could also completely change the graphics to their own style and I could even accept these modifications as alternative versions for download.  This alone would have a huge impact on the player community.

I am already going to have the site customisable to a certain level which would include:

  • language (this would be in a few core languages with more added as players needed them) 
  • stylesheet selection (already implemented at a basic level)
  • graphical style (in game graphics could be cartoony or realistic, at the players discretion)

Another negative is that the player has to download and unpack a file onto their local machine and then again if they move to another computer.  In some cases, they may be playing on a workstation that is locked to the browser and they simply cannot do this.  My argument against this is that the files can be unpacked ‘anywhere’.  Whether the files are on your local hard drive, or on a central web server somewhere is not important.  One person could unpack the files on a webhost and have friends simply point their interface to that central area.  Of course, having them on the web again sort of defeats the main purpose, but it’s possible and still draws the bandwidth away from my host.

Advertisements

Responses

  1. You could always do some initial checks to see if you can load an image from the player’s disk, using a local path and if that doesn’t work use the files from the web server. That requires that you have dynamic Urls for every image though, which could introduce it’s own set of headaches.

    I have played one game where the graphics where unpacked to your local disk and it does make game play a whole lot smoother.

  2. Hmm, the difficulty is in the checking, php can’t check local files but javascript can.

    I guess I can check for the presence of local files at the point of login and trust that the player won’t delete the files during their session.

    Having a check for each image that is to be displayed would be overkill I think. If a player is determined to start deleting random files then they’re only affecting their own gameplay and so I shouldn’t worry too much. As long as I have ‘reset graphics’ option or something similar and don’t leave the user with a broken installation I should be fine.

    If the file I’m checking for is there, I have to trust that the rest are as well.

    In my local graphic test (which I need to reproduce on the test site for some repeated speed/cache checks), the majority of the page was created on the fly by javascript.

    The exercise wasn’t just to have files stored locally, but to cut down the bandwidth as much as possible. As a result, the source code for a page was minimal, containing very little html. The javascript that accompanied it built the relevant parts of the page on the fly, meaning that I was sending about 1 KB from the server and the client processed the rest.

    Using javascript for page building is something I still use. On my test site for example, the navigation menu is stored on the server as XML for easy editing. The PHP loads this in, checks for user privileges for each option, creates a javascript variable containing the entries that the user is allowed to see and then the javascript uses this to build the actual menu which is then styled with the CSS.

    I was quite proud of that one 🙂

    In fact, there are quite a few things that I’m proud of on the site that most people won’t even realise are there 😦

    I’ve gone down the versatility route. As much as possible is thrown out to text configuration files. The idea being that I have a game/site ‘engine’ created in PHP which should never need changing once the site is up and running.

    Unless new game mechanics need adding (or old ones fixing), new content can be added with text files and database content.

  3. Hi,

    actually you can build a preloader with Javascript that will cache images during a session and most likely even between sessions.

    This even gives you the possibility to display a status bar to inform the player of the progress.

  4. I would like to see a continuation of the topic


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: