Is JavaScript enough for browser based games

Most Browsergames these days are done  with Flash. Sure, Flash is a nice technology and it has lots of benefits over X3D, Quicktime, Silverlight and others. The main reason Flash is used for games though is because it has a huge market penetration. Somewhere around 98%  if you believe in Adobe’s  statistics.

That there is another, mostly underestimated player is a fact that this article want’s to shed some light on. (more…)

Tags: code performance, pbbg

Thoughts about OOP advantage

Having recently refactored my JavaScript Game Engine (or what it will eventually become one) and the associated Level Editor to use OOP techniques I noticed that this has some issues besides the obvious advantages.

Using OOP can save disk space

In one particular case I read about memory requirements of large tile maps on Xalthorn's Blog. A commenter (horRAiN) mentioned that his map used up about 5 MiB if he saved it to a text file using the php serialize command on the server.

Due to it's nature the serialize command has a serious overhead which can in some cases be between 30% – 50%, even more so if you just serialize an array containing objects and / or a huge number of duplicate objects.

The serialize command is useful, no question, but for things like saving a game level or map it is just a huge waste of space, even though it is the easiest and fastest solution (in the short term).

In the long run it is better to make use of Objects and Object references. Saving an array of 200 x 200 Map Elements containing just references and a description of each object obviously saves loads of space and troubles in the long run.

A randomly created map with 40.000 reference numbers and the 18 used objects, formatted as xml takes up  128 KiB.

Using OOP frees up your namespace

Creating an application requires a substantial amount of variables to hold all the data you'll need at runtime. Using objects will most likely save you from overwriting one or the other variable you need at a certain point.

Especially in Javascript wrapping your variables and functions into an object means that you'll save the Interpreter a lot of work at runtime.

You have to access any variable or function directly.

Java(Script) example:

You might not see the immediate benefit in this, but here are some (some can be translated to php as well):

• Your variables are isolated and can't conflict with reserved variables or functions.
• Your code is more reusable because you can use the same vars and functions on multiple objects (myEventObject.add, myDomElement.add, myOtheObject.add)
  without having to to think about naming conflicts
• The interpreter is able to look up your variables faster because the global object doesn't grow as much (each variable and function call starts looking in the global object and digs down)

OOP needs more discipline

What I noticed coding on the game engine and the editor was that using objects literally  enforces a disciplined usage of coding conventions.

Because you can use object variables,  object functions, local functions and local variables it is important to keep an overview of what you have defined.  Variables should be declared at first in a function or object to make it more clear what variables are used inside this statement.

Objects can be costly

If you use Classes to define new Objects, any object you create needs memory.  Think first if you really need an object to perform a certain task or if it is enough to call the functions from a static context.

In Java and PHP you would call functions and variables by prepending the class name (without the need to instantiating an object first:
PHP

Java / JavaScript

However, at this point there is a little trick that JavaScript provides to make this somewhat easier.

JavaScript has something called JSON (JavaScript Object Notation), which basically lets you define an object structure that won't be able to have instances. This has the advantage that you don't need the longish prototype notation to declare the objects. But to explain this to you I'll hand over to the excellent tutorial by  Dustin Diaz – JSON for the masses.

Tags: oop

Safari wins , Opera lost (real life JS performance)

To check performance on large maps in my level editor I included a little function that generates a map of a given size filled with random tiles. I am lazy I know, but try to click your way through a 200 x 200 (40000 tiles) map and you know what I am talking about

So while testing I found out that there are vast performance differences between the various browsers on my system[1]. I also rectified en Error with Event handling in Opera 9.5* while I was at it.

The test I ran was pretty simple, I used all three browsers to create a random 100 x 100 map and took the time before the function started and after it finished. The difference was output in an alert which you see here. (more...)

Tags: code performance, Firefox, Opera, Safari

Progress monitoring with JavaScript

If you ever happen do develop a web application using Javascript you might stumble upon the occasion where a process might take a fair amount of time to calculate.

The Problem

If your script needs more than a couple of seconds, most likely this fact will result in a message like this:

Okay, you might think just drop in some code to output something while your script processes an array with say... 40k Elements (200 x 200).  The issue we face is that JavaScript in Browsers is single threaded.

So the output code  you have in your processing loop will be stored in a queue until the processing is done. This of course looks like your browser is stalled until suddenly there is a huge amount of data on your page.

Several JavaScript applications offer an approach that is not very user friendly. Until the script is finished you'll see an animated gif of a spinning circle or a phrase like waiting... (usually with an animated ellipsis). The real solution is only slightly more complicated but gives far more feedback to the user.

Real Progress Bars (or other shapes) are something all modern desktop applications offer. Web Applications made with Flash or other Technologies offer this as well.

How to do this in JavaScript is what we look at next … (more...)

Tags: code performance

Level Editor Redux

I have dedicated more of my sparse spare time and refined my level editor quite a little bit.

I have found some very cool and useful information about tile based games on the net this week and parts of it are already directly influencing the current codebase.  The latest somewhat stable version is 0.92b which rectifies some problems with Firefox 2 and implements all features listed as current. Once I have a chance to cleanup the code I'll make it available for download in a new post.

The current development milestone is 0.95a  which incorporates already some of the planned features.

It still has to go a long way to be complete but the progress is going well. (more...)

Tags: Games, level editor, tile graphics

Generating Tile Maps

About nine months ago I discovered Open Sword Group's Pixen a really neat image editor for OS X, perfectly suited for Pixel Art. I was working on my BA thesis by that time and investigated the possibility of tile based graphics for the thesis project.

Though it turned out that tiles were not feasible. However this application and the sites I discovered through my research had sparked fond memories of long lost games and an idea was planted.

For a couple of months now I am working on my very own little game project. Initially I was trying to use RepTile to create my maps. But after trying to contact the author without getting any response it seems the project is abandoned. Though the concept of this little application is still neat.

It works like any other tile map generator in the way that you can paint your map using the tiles you provide. A great addition however is that you can already assign properties to map tiles. For example, the stone wall is not walkable and the grass has less movement cost than the dirt . You get what I mean.

As badly as I wished to use this little program, I am no Cocoa programmer and can therefore not ad features I need.
But luckily I can do JavaScript and this seems to be the perfect playing field for it. Since tile based games are mostly web related, why not create the maps straight in the browser. So I took the great RepTile idea and moved it over to JavaScript and the outcome was this (click to see the full image):

The generator is working and can perform the basic tasks of painting tiles and assigning properties to them. Clicking the generate button will present you an xml file which you can use with an appropriate engine (such as the one I am working on). However, the code is a bit messy right now.

But if there's enough interest I'll clean it up and post it here.
P.S. The tiles used in this screenshot aren't mine. Danc made them. Anyone interested can find the link in the Sprites, Sprites, Sprites post.

Tags: Games, level editor, tile graphics

Dynamically loading external Javscript Files

Some weeks ago I read a short tutorial over at JavaScript Kit about how to load JavaScript files into your document on demand. This was a thought that I already pursued for some time as I had seen something similar already in the Scriptaculous Library. The difference on the Scriptaculous side was that you appended the additional files you wanted to load as a parameter to the main scripts url (scriptaculous.js?load=effect,dragdrop).

The idea is basically great. In modern languages you have the ability to import or include files for compilation (i.e. the C Family Languages, Java and Actionscript) or at runtime (i.e. Python and PHP).

So why should JavaScript be any different ?

Mainly it is because JavaScript wasn't designed with such behavior in mind . JavaScript wasn't supposed to build big applications like the now so popular Web 2.0 Apps (i.e. Google Maps, Google Calendar and others).

Why would I want that?

Once you start to develop larger Applications with JavaScript (or other languages for that matter) you usually end up having the same functionality in different places. But you also have bits of code that are unique to certain parts.

What makes sense in my opinion is to split up your monolithic JavaScript files into pieces that are:

1. easier to maintain
2. faster to load
3. more reusable

But once you split up your files it can get messy rather quick too. On some occasions I had 6 or more Script nodes in one HTML file. Also keeping track of dependencies gets difficult.

Wouldn't it be a lot easier to have just a single script node where you would define what you need? Or better yet, let the script itself take care of what it needs.

How to do it?

I stumbled upon a great concept today that takes the initial idea a bit farther.  A few days ago Remy Sharp blogged how to do On Demand Script Loading. Since I was working on the same idea I found this extremely interesting.

His idea is basically  probes for the existence of an object and if it isn't found loads it.

My idea however was more similar to the initially mentioned Scriptaculous or Java approach.

You would need just a single script node in your html file to load either some

for all your scripts.

Okay, up until now this doesn't work different from Scriptaculous. So what I did further was to add a check for script dependencies.

For example I have one script that deals solely with event handling. Though this script is dependent on methods to check for different browsers and searching for nodes. I make a check if this object exists and if not I'll simply load it.

These checks are implemented in each file to make sure all dependencies are met. And since these checks are performed only when the script is loaded there is no performance hit.
The include function in turn looks like this:

Only the script name is submitted as parameter. Anything else is already stored in the object at the initial load.
Also note the fallback for browsers that have problems with inserting nodes via DOM.

This is just part of the whole script, though you could use this function independently. Once I have removed the kinks and quirks of this library I'll post the full version here too.

Tags: dynamic loading, JavaScript Library

Experimental Javascript

Javascript Benchmark

While it my not make a big difference for most people, I care about the performance of the code I write. Somtimes there are multiple ways to get to the same result, butto find out which way is better is not always easy.

Sometimes you'll probably decide to use a certain function or concept because it is easier to implement or read, but that doesn't necessarily make it faster to interpret for your browser.

To have some aid in what I do I developed a small Javascript Benchmark.

Searching through the internet I found some benchmarks that test the performance of Interpreters themselves but rarely one that is intended to compare performance of different functions or concepts.  If you find it in anyway useful feel free to use it. Though there is no guaranty that the results are correct measures.

Javascript Starfield

Back in the days of my trusty Atari 800 or later my Amiga, a starfield animation was a very popular effect. Unlike the Starfield screensaver that later shipped with versions of Microsoft Windows  these starfields were depicted from the side as if you flew by and not into it.

Trying to replicate this vintage look I quickly found out that Javascript and DOM might not be the ideal companions to do so. While the effect is quite nice in my opinion, the processor load to calculate the 150 stars' position is quite high. Maybe I should look into SVG and the canvas tag to replicate this effect and probably have less processor load.

For the time being check out this probably first serious Javascript experiment of mine I did early in 2007.

Javascript Starfield

Tags: code performance, starfield effect

Sprites, Sprites, Sprites

This is a repost of some posts to my old website from May to June 2007

Animated Sprites and Tile Mapping with Javascript

Based on a previous post about Javascript Sprite Animation  I decided a while back to create a little tile map and have a sprite move about it using keyboard controls.

Below is the original context:

Yesterday while surfing the net I found some very cool tile graphics. Luckily Danc the creator of these graphics released them to the open public. These will prove a rich learning resource for me.

Anyone who is interested might visit his blog at lostgarden.com

The game tiles are available from this post > more free game graphics

Javascript Sprite Animation with Tiles

* * *

Javascript Sprite Shading Algorithm

My curiosity led me to try my hand at simulating a light source with Javascript. While I had done this previously to fake a 3d lighting effect (use this link for the JS version) with just 5 layered graphics, I wanted to try a different approach this time.

My goal was to create the illusion of a light source fading with distance - much like a point light source, a light bulb for example.

The algorithm or one that is similar was probably used in tile based games that tried to simulate light sources. Some that I played myself were "Jagged Alliance 2"  and the original X-Com strategy games.

To see the algorithm in action click the link below:

Javascript Sprite Shading Algorithm

Tags: Games, lighting, tile graphics

Wordpress And Block Elements Inside Posts

Why It's Going To Be Complicated

Wordpress is nice so far, but after trying to repost some of my old stuff I noticed a major drawback.

I wanted to use this blog to share my coding experiments with the world. And sure enough I can post some source here, but including any Javascript or HTML that is not in a template or beyond text structuring elements is probably not as easy as I thought. (more...)