or play it here: PLAY HERE

It even works on the iPad!

Some screenshots:

So today I’m making a small book introduction on the book Instant EaselJS Starter by PACKT Publishing, written by Fabio Biondi.

The main goal of the book is to provide the most basic information needed to instantly start creating nice looking HTML5 canvas-application. The techniques explained in the book have no special attachment to “gaming”.

The book consist of the follwing five sections

1. What is EaselJS? – A brief overview on the library, what you can do with it and why it is so great.
2. Installation – A short set of instructions on how to setup EaselJS for your project.
3. Quick start – Teaching the basics with a typical ‘Hello World!’-application.
4. Top 8 features you need to know about - This section explain the use of the eight more important features with examples.
5. People and places you should get to know - Introduction additional places to get help and find resources for your projects.

The Book’s main learnings

Again a small, but hopefully helpful file: CocoonJSAudioPlugin.js
As the native SoundJS-Plugins: WebAudioPlugin.js and HTMLAudioPlugin, don’t seem to go hand in hand with CocoonJS (yet?) I took the time and wrote a CocoonJSAudio-Plugin based on the HTMLAudioPlugin, may this be of help to someone.

Download: CocoonJSAudioPlugin.js

How to use: Just put the CocoonPlugin as the first entry to register and you can use everything else of the SoundJS-library just as is in CocoonJS now.

createjs.Sound.registerPlugins([
     createjs.CocoonJSAudioPlugin,
     createjs.WebAudioPlugin,
     createjs.HTMLAudioPlugin
   ]
 );

Why the change

1) From the beginning on I was not to certain about using DynamoDB – since DynamoDB is a very fast and very reliable db-system I wanted to give it a try. However, DynamoDB has some (in my opinion irritating) flaws. For example all numeric values will be saved and typed as ‘BigNumber’ so in Ruby e.g. before you can really work with the values from the db you have to cast them to integer or any other type that suits your needs. Also there was no way (yet?) to export data through the AWS console, also there was no way to edit data, only recently a feature was added to view data inside a table.

2) Redis is strongly string-typed, which is okay, but also made it neccessary to add a type-casting in Ruby for numberic values (maybe there is a special command that I don’t know? but with regular get/set redis only returns Strings afaik). But the far bigger issue was redistogo – as they were almost doubeling their prices for most of their plans, except for their free plan, which is still free. I did not really need a lot of space for redis, but 9$/month for a 20MB redis instance or 39$ for 100MB and I CAN’T upload a backup from the heroku-interface, I have to contact the staff by email to upload a backup file which takes time ect… sorry, that does not really sound reasonable to me, and that is also why I decided to stop using redistogo.

3) Debugging! Debugging! Debugging! It’s a lot easier if you have just one system. And on mongodb it is easpecially easy since all data is BSON (pretty much every UI displays it as JSON, easy to view/edit/create). Though this was not my original reason for a switch, it now is one of my biggest benefits!

So as a conclusion: I’m not saying ‘redis’ is bad – I still like redis a lot! However the plans and features of ‘redistogo’ on heroku are kind of overpriced. Also DynamoDB is a good db-system, however if you are utilizing different systems you usually do that for each of their benefits, and if the hassle gets to big that’s just not worth putting up with that.

MongoDB

So far I’ve only heard/read good about MongoDB, the data is saved in BSON-format and you can practically store any amount of data and still have good response-times and it has a very easy to understand API. Also on mongolab you get 240MB of space free, which is more than enough to possibly store playerdata from 400-500k users. And even the paid plans have a reasonable pricing. Also you just pay for the storage and not for the in-/output like with DynamoDB.

So for those of you considering a hybrid aproach: Maybe overthink it – do you really need it or might it be just fine with a “regular fast” db like mongo?