Detour at the end of the internet

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

Ok maybe not quite a manual. Here's a few quick tips for anyone working with Whirlwind. Maybe some of these things are obvious to people more experienced with the technologies involved but they had me scouring docs for answers. Hopefully they save someone else some time working them out on their own.

Working with MongoDB's ObjectIds

MongoDB has a great unique id system, unfortunately the Whirlwind developers didn't use it in the only model provided by the example project. I like using them so I muddled through some of the MongoKit docs to figure it out. Here's a quick example model using Mongo's ObjectIds

Output JSON for AJAX requests

AJAX and JSON are obviously pretty standard communication protocols for developing modern web apps. This one comes from the Tornado docs. Instead of using self.render_template() do something like this:

@authenticated

This one is pretty obvious but isn't covered in the docs. The @authenticated decorator can precede a method in your controller to ensure that a user is currently logged in.

So far, I really like Whirlwind. These are my initial impressions.

Likes:

The app structure is incredibly similar to Zend Framework as I mentioned in the previous post. I've found that this really helps me navigate around the codebase quickly and easily. It all seems very familiar and logical.

The example project covers all the basics, providing just enough of a springboard to get a project going.

I really like the use of the decorator pattern. Very useful to easily provide behaviors in your controllers.

Fast. Very fast. Looks like it will live up to its claims. Obviously I'm not under heavy load or working with a large dataset but seems promising.

Neutral:

I wish that the whirlwind-admin cli tool could generate controllers/views for me the way the zf tool does. E.g. $ whirlwind-admin --create-controller my_controller would give me a controller class with an index action, a view folder and an index view.

Mako is a pretty unique approach to templating for me. Its straightforward enough but I feel like its going to trip me up eventually.

Dislikes:

The documentation is pretty lacking, though the authors admit as much. A general knowledge of Python, web frameworks, and MongoDB was sufficient for me to grok the code but if they want to gain traction they'll have to step it up. I suppose the good netizen thing to do would be to contribute to the docs.

I don't like the db saving idioms. Too verbose. Why use Mongo.db.ui.users.insert(user) instead of user.save() ? Are we writing Java now? I'm not sure why it's done this way, maybe it doesn't need to be.

I know its nitpicking but... The example project could be tidied up a bit. Python lends itself to making code elegant and consistent. Yet the authors seem to have some bad habits: inconsistently using either single or double-quotes, inconsistent spacing between function arguments, etc.

As I've discussed, Python is quickly becoming my new favorite programming language. However as a web developer, I'm accustomed to using a framework; namely Zend Framework. I like ZF because it blends "kitchen sink" comprehensiveness with flexible modularity. ZF is a "use what you like" type of framework, you're not married to any particular piece. Don't like Zend_Db? Go ahead and use Doctrine instead. ZF never assumes that you're doing things a certain way or using certain technologies in your stack. I'm partial to MongoDB so this is important. 

That said, I'm obviously a noob regarding what Python frameworks have to offer. Here's my perspective.

Django / Django-nonrel

Django is obviously the 800-lb gorilla Python framework. Every web developer has heard of Django just as every web developer has heard of Ruby on Rails. Django offers everything you'd expect in a modern framework: ORM, url routing, templating engine, command line tools, it even has a built in admin interface that you can enable. Overall, its easy to see why Django is so popular, its easy to use, powerful but not overly complex, and fast to get up and running. Documentation was pretty good though I found a few things to be strange and lacking in places.

My first problem was that out-of-the-box Django assumes you are using a SQL-based RDBMS such as MySQL. That's fine for most but I'm a Mongo man. This eventually led me to Django-nonrel which is a fork of Django that fixes some SQL assumptions in the Django code.

My next major problem was figuring out how to correctly serve static files. This was way more complicated than it should have been! Apparently, Django assumes that all your static files will be served either via CDN, static caching server, or just generally anywhere but the web app itself. Again, that assumption is fine in some cases but the reality is: I'm on a local dev environment, I've got a template to work from that includes some basic assets such as a css file and some images. I did eventually get it working but was rather turned off by this point that such a simple thing was a blocker to getting up and running.

Pylons / repoze.BFG / Pyramid

The history behind this framework seems to be long and interesting; long story short - Pylons and repoze.BFG were competing frameworks that eventually decided to merge and formed Pyramid. Pyramid aims to be a minimalist framework that allows the developer to choose "best of breed" libraries and packages they prefer into their app. Initially, I liked the minimalist approach; particularly that it seemed to make few assumptions about your stack. 

Unfortunately, Pyramid seems somewhat over my head. Its great to have choices except that I don't know what choices to make in certain places. For example, once I got it up and running the next step in the tutorial is to decide which of a half-dozen app templates are going to fit my project. Do I want url traversal or dispatch? Do I want to use ZODB or SQLAlchemy? Is either of those even compatible with Mongo?

I'm certainly not discounting Pyramid but for the time being it seemed to require much more research than I really want to put in when initially evaluating a framework. Pyramid seems more suited to the experienced Python web app developer who is familiar with and has preferences for the various libraries and packages that are available.

Whirlwind

Whirlwind is obviously a new comer to the Python web app scene as it was only just released earlier this week. However, the one thing that really drew my attention was that it was built to use MongoDB. I've been getting a bit weary of digging for NoSQL support in Python frameworks so this was a win for me. Looking over the docs it seems to fit what I've been looking for: supports MongoDB out-of-the-box, has one preferred way of doing things, fast and easy to setup, and as a bonus provides many nifty features baked in such as authentication, pagination and flash messages. I also quite like that the app structure is similar to ZF. I'm going to play around with Whirlwind a bit and see if it is a fit for me.

I'm a PHP developer at heart. It's what I "grew up" on. I've built a successful career constructing PHP apps and I'm certainly thankful for its existence. That said, I've recently become enamored with Python. Clean, consistent syntax and many interesting advantages such as Google App Engine. I've decided to code my next pet project in Python using Django as a framework and put it up on Google App Engine. Actually, I'm thinking of writing it in both PHP and Python side-by-side for comparison. I found it interesting that Django doesn't natively support NoSQL databases such as my new favorite MongoDB. I'm going to be working with the Django fork, Django-nonrel and the Django App Engine Backend.

I'm toying around with some machine learning stuff, but I haven't found a solid Naive Bayes classifier class written in Python. I've found a few implementations but no clear winner, such as the PHP library B8.

I am giving up on supporting MySpace in FriendLocator.info, at least for the time being. It took me 2 days of frustration to finally figure out that they haven't completed their implementation of the OAuth spec. The dev post mentioning this is from a few months ago, perhaps I'll revisit it when they decide to give their developer program some love.