Issue Management and Other Tidbits

I just wanted to give a short heads up of what’s to be expected in the near future.

Recently I started a new job as developer which was originally supposed to give me more spare time. This thought turned out nice but well, I still need to earn money on the side so most of my spare time is spent coding for other people…

Nonetheless I am still busy working on my game engine and I am making good progress here. To keep track of my own status and to gather notes and links for this as well as other projects I installed Mantis, a bug and issue tracking system. Soon I’ll probably sign up with an open-svn account too to make my (coding-)life even easier…

I must say it is pretty neat and works well. Installation was relatively easy, though it took me about 6 hours to set it up, configure and install additional modules such as jpgraph.

A few of the added benefits now are:

• automatic roadmap generation (with progress indicator)
• changelog
• activity charts

It can be found under mantis.magicrising.de or bugs.magicrising.de, a link is also added to the Game Engine Links page (members only).

Other things right now in the works include:

• tutorial on isometric coordinate handling
• tutorial on how to implement automated terrain transitions
• a first demonstration of the game engine

Have fun and leave lots of comments

Tags: bug tracking, mantis

Isometric vs. Top Down

Xalthorn posted an interesting article at his blog comparing isometric to top down perspective. His main focus was on the field of view each method offers when 2 players look at the same map area.

This article will focus more on the technical bits and on the pros and cons each method offers in terms of a browser based game. (more…)

Tags: Games, isometric, tile graphics

Fast map scrolling with Javascript

Chatting about moving objects around on an html page with Xalthorn the other day we came to an interesting conclusion. There is indeed a method available that works (almost) independently of  the number of objects to be moved around. There are certain restrictions to this method however.

This article aims to provide a short overview over the pros and cons of using an elements scroll property rather than its children’s style attribute. (more…)

Tags: code performance, Games, tile graphics

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