#craftyjs

In the beginning of this summer, I decided to do a mini game and I put a time limit for that project. The reason for that time limit is avoiding from procrastination :) The time limit was 3 weeks, and I completed most of the game.

I love the idea of controlling two characters at the same time and I remember that  I first saw this game mechanic in Binary Land. (You can play this game here: http://www.atari.gen.tr/atari-oyunlari/binary-land.html) It makes you think twice while you're controlling the characters. So, I decided to use this game mechanic on my game. The name of the game is Money Or Love. It's a 2D puzzle game. In this game we have two characters; a boy and a girl. They move at the same time and in the same direction. The goal is collecting the gold with the boy; and collecting the heart with the girl, then putting them in any box. In some levels, avoiding from lava is needed.

Before starting this project I wanted to use and learn an HTML5-JavaScript game library to develop a game and I found Crafty(http://craftyjs.com/). It's free and easy to do a 2D game. It has a good documentation and it has some tutorials to make a game from the beginning.

For the levels, I use basic tile map logic by writing in a text file with different letters and then decode them. The movement of the characters are also tile based. They make their movement in one tile length(16 pixels) and this makes them move equally. I painted all the characters, tiles and items in GIMP and found the sounds from as3sfxr(http://www.superflashbros.net/as3sfxr/). 

A difficulty while I was working on this game was the colliding of the characters and other movable objects. The problem was if two objects, staying side by side, starts moving, then one of the object stay and other one moves. I guess one of them collides early and stops. So I changed the offsets of the colliders because the default collider component is not worked properly.

After I designed 10 levels, I decided to do some playtesting with my friends. I put a "How to play" image next to the game and waited for their feedbacks. One of the feedback was about the movement of the characters. Players wanted to move the characters while they are holding down the keys. They told me that pressing the key again and again for the movement is really boring. They were right :) I completely forgot that because I was concentrated on tile based movement(the characters have to move 16 pixels or multiples) The other feedback was about the sound when players accomplish the level. They told me that the sound was confusing; and they were not being sure that they succeeded or failed.

I have once again taken up my dream of creating a game. I had an idea for a game about a year ago and it still seems like something that would be fun to try. My idea is a card game, so its 2D and not terribly complicated (I hope). I originally tried to use Unity3D but ran into too many roadblocks and gave up. However, this time around I've decided to stick to my guns and use what I know, web technologies. Fortunately, there are several viable HTML5/Javascript game frameworks available. I've decided to dive in and give a couple of them a spin to see what suits me and my project best.

CraftyJS

CraftyJS is a nice little library that uses the Entity-Component System wrapped up in a jQuery-like syntax. The Entity-Component System will feel very familiar to anyone who has done development in Unity3D as it is essentially the GameObject model. Basically, you create Entities and assign properties to them such as Draggable, Text, or Twoway/Fourway (keyboard movement).

Of the libraries I reviewed Crafty felt the most intuitive and easy to use. An excellent quick start guide is available as well as a number of demo games that can used to help understand how it works. Once I'd started with Crafty I really wish I'd been able to stick with it. Unfortunately, it is currently pretty unstable and I kept running into bugs. The blocker came in the form of major issues in the Draggable component (even after the v0.4.3 update which fixed the most grievous issues in Draggable). I tried posting to the Google Group but did not receive a response. However, I will definitely keeping an eye on this one, it seems to have a lot of potential.

LimeJS

LimeJS is a full-blown framework that is built on top of Google's Closure library. I admit I'd never even heard of the Closure library before I started using LimeJS. It offers lots of built-in utility classes that cover many common tasks. Especially useful to game programming are loads of useful geometry calculations when using Closure types.

It took me a little bit to get started with LimeJS, but once I got rolling things have been pretty smooth. I guess I'd say that LimeJS is event-driven, more like traditional Javascript stuff. You create your Sprites and such and add listeners to them. Thanks to Closure it has pretty strong sub-classing support, so you can easily extend the Sprite class to add game specific functionality.

I am admittedly a little lost as to how I'm supposed to organize my code. Currently, I have been sticking everything in the start() function which feels horribly wrong. There are demo projects which I need to study or perhaps I'll pick up Closure: The Definitive Guide to help me wrap my head around the Closure concepts.

Other libraries

These other libraries looked promising but I mostly passed over them because they either hadn't been updated recently or the documentation/example were lacking.

EaselJS: last updated nearly 5 months ago. I should probably look into this one more, it seems likely to be a solid choice.

Cocos2D Javascript: v0.1 initial release 4+ months ago. Cocos2D has an excellent reputation as a 2D game engine for iPhone. In fact I had looked into during my previous venture into game programming. However, Cocos2D Javascript seems to still be in its infancy. We'll see how it grows up.

GameQuery: I use jQuery regularly, but the way its applied here just doesn't seem to fit. It didn't really offer amazing support for common things you'd want in a 2D game. Overall, I think other options seemed more robust.

Conclusion