WWWest-Online Development Blog

I know I promised to write a bit about cross-domain issues, but before I do that, I think we first need to understand some of today’s web technologies and methods. These days almost all web applications are Ajax-powered, and we are no different. In fact, since our main game page has quite a long loading time, we try to avoid having to reload our game pages for anything which is not completely necessary; Ajax technology enables us to give you the feeling you never leave the page. However, like any good thing, it also comes with its share of problems.

What Exactly Is Ajax?

I won’t try to teach you what Ajax is and how to use it, since it will be quite a long affair, and the web is already filled with articles with that exact purpose. Instead, I’ll just try to provide a short and simple explanation.

Ajax is an acronym for Asynchronous JavaScript and XML. Using the client scripting language (JavaScript), we can communicate with the web server asynchronously (meaning each component sends information continuously, without waiting for a communication session to end) and sends/receives new data all the time, getting rid of the need to load anything not related all over again. Say we just want to see how many adventure points you have after the last adventure; why load the entire page just for a simple answer? Instead, we can use JavaScript to send a separate, small request to the server, and the response will update the display.

When we load a script, we effectively halt the browser until we receive the server’s response with the script results. This is good when we are loading things for the first time, and need them to be in a specific order, but when we just want to update a detail or two in the display (like, perhaps, the new adventure point balance), stopping everything until that single detail is updated just makes no sense. And this is exactly what Ajax allows us to avoid.

Sounds Great! But… Where’s the “But?”

As you know, every good thing has its price, and even though this particular price is completely affordable, it’s still worth knowing about.
One problem with Ajax is that by loading and updating just bits of information in the web page we are actually putting more strain on the player’s browser: it will need to use some JavaScript to handle all the communications, and will probably work with the DOM by changing, removing and adding elements to the page. This means we’ll take a hit to performance, but not as big a hit as we would take if we’d perform a full webpage request.

Another issue, also performance-related, is memory. Since we’ll be sending requests all the time and updating content all the time, we need to make sure that we free the memory we use in our processing. This would be something to consider even if we weren’t using Ajax, but it’s even more important because we are. This is because when we use Ajax, every small leak can be multiplied by the number of requests, and with Ajax, we have a lot of requests. And somehow I’ve got this feeling that you will not want to leave your game and go out with your friends, only to come back later and find that, although you can see the latest chat messages and changes in the game, your browser is using so much memory that it can’t do anything else.

Another major issue with Ajax is caching. One of the “tricks” used by the browser (and the server) to save time is caching results per-request. Let’s say we want to find out how many adventures a player has left. To do so, we send a request to a URL (for example, www.wwwest-online.com/player/adventures). The first time we do this, we’ll actually talk to the server and get results. But every successive request to that exact URL might get cached results instead. Like the previous problem, caching is an issue regardless of whether we’re using Ajax or not, but it’s more of an issue with Ajax, because with Ajax we send the server significantly more requests. It’s kind of ironic, really: part of the reason we use Ajax is because we want to keep things up-to-date, but in using it we end up running a greater risk of getting cached (i.e., out of date) results.

There is one last issue to know about. Now, I know it’s usually “last but no least”, but this issue is actually the least of our concerns: if the player uses an old browser (old browsers tend not to support Ajax) or is paranoid enough to disable JavaScript on his browser, then Ajax will not work for him. We’ll discuss why we consider this to be such a minor issue in a moment.

Is It Worth It?

The million dollar question. And the answer depends on whether our players want to spend their time in the game actually playing, or waiting for things to load after every click . I think the answer to that question is obvious (rhetorical questions are like that), and we are doing everything we can to give you the Ajax desktop-like experience, while keeping the negative impact to the bare minimum. As for the last issue we mentioned—browser compatibilities—there isn’t much we can do here. These days so many modern applications support Ajax that we don’t even consider this to be a real issue, and if someone is blocking JavaScript on his computer, he won’t be able to do anything with our game anyway, so we won’t be addressing that issue, either. We feel that having a smooth game experience is worth losing a line or two from our list of supported clients.

See you next time.

Scopti