Journey of creating HTML5 visual game programming tool.

The following article is mix between a short developer diary and a summary of the challenges we faced in developing HTML5 based visual programming tool - DASH. 

DASH is a HTML5 based visual programming tool for creating games. It is a quick and easy to use tool for students, teachers, hobbyists and designers and has features such as 

Throughout the course of development we had (and will continue to) face numerous challenges. We had a number of decisions to make especially due to a few developments we had not anticipated.

Selecting the right libraries

We were ideally looking for an HTML5 JavaScript library/game engine that could fulfill two roles –

We found a perfect match – LimeJS. LimeJS is based on Google’s Closure tools and framework and we found that it worked perfectly for both games and tools. Using the Closure library ensured that most browser quirks would be automatically taken care of and we would be able to perform a great deal of minification and optimization by use of the Closure compiler. This was great but in order to use LimeJS as the engine powering the created games we had to figure out a way to compile the code generated by the tool. We decided to use a different engine for that instead.

We decided to complete major portions of the development environment before starting with the portions that required that we make a final decision regarding our target engine (the code generation part mostly). That was when the Code.org video came out and went viral. We immediately felt a connection (we are after all a game programming school apart from being a studio). Dash was just supposed to be a visual game programming tool, although if you really wanted to you could use if for learning/teaching. We were now consciously trying to make it a good educational tool.

So our target engine had to be easy to understand. In the grand scheme of things we are planning to use Dash to introduce people to game programming and then extend their knowledge to the realm of game engines and how they work, should they so choose to. We found two – CraftyJS and Gamvas. CraftyJS is a very flexible entity-component based game engine, much like Unity3D. Gamvas puts focus on actors and actor states. A monster in an RPG would have states such as roam, threaten, attack and retreat; although that is not the only way that states can be used.  Taking the performance of both into consideration we went with Gamvas.

Browser Differences

One can’t work with HTML5 and simply forget about the differences between the major browsers. Closure is a good layer of abstraction that solved most of the compatibility issues for us. One still has to take care differences in performance, browser specific artifacts, slightly different behaviors, etc.

A lot has already been said about performance so I’ll just add a few notes from my side. Following are the loading times for various browsers on our test machine –

IE 10 beats the other browser's in loading the javascript files and executing them. But in terms of rendering performance chrome giving the better performance.

Audio presented its own share of problems. Chrome works the best when it comes to audio. Firefox and IE both have trouble playing the same audio file in quick succession. 

Loading resources is another biggie. The issue crops up when resources such as images and audio are missing. This is usually not a problem with standard game development as the distribution server has all the assets. But we have to take the possibility of missing files into account as the user can use files stored in their dropbox. What happens if the user deletes the file, even if accidentally? We have provided some empty audio and image files to take the place of the missing file. But even using those requires that we know that the original file is missing. 

Internet Explorer had numerous visual artefacts. Scaled images got clipped from the top very slightly. Moving an image on the stage left behind a trail of horizontal lines. These lines didn’t appear if the IE window is not maximized. Line orientation also changed with how the window was fit on the screen; i.e. whether it was vertically maximized or horizontally maximized or both. The problem seems to have disappeared in the latest version of IE.

Platform testing

Last I’ll mention the problems we faced while testing on different platforms.  

This will be all for this blog post. I’ll be back with more as we are sure to run into more problems as we implement new features.

The beta access for DASH is open for our campaign backers - http://bit.ly/14iKQI7
DASH main website – http://www.dashplay.net