Choosing a Game Development Framework

Lately I’ve had an idea for a game that I just can’t get out of my head.  Combined with the recent unveiling of the Nintendo Web Framework I’m compelled to make an attempt to get a demo of the game running on the Wii U.  At a recent presentation from Unite ’13, Nintendo touted how easy game development is for the Wii U using JavaScript and HTML5.  I’ve always wanted to explore the limitations of HD gaming within the browser so this is the perfect opportunity to test Nintendo’s claims.

Our weakness as developers is that when we have an idea we just want to code.  I don’t want to plan or design, I want to get something up and running and see the fruits of my labor as soon as possible.  As much as I love technology, some times I’m so compelled to code that I don’t even want to vet the best framework for the job.  Sometimes I’ll just grab what I’m most familiar with and start working.  With game development, that is difficult to do.

I wrote a previous post about the pitfalls of game development in JavaScript where I mentioned not reinventing the wheel.  I see so many horror stories of indie developers spending all of their time on an engine and not ever making a game.  I suggested a couple of frameworks in that post, but now that I’ve completed a more extensive vetting process I’d like to share some insight on the decisions that I made.

2D vs. 3D

If you are planning on making a 3D game, you should look no further than Unity.  You can quickly get prototypes of your game running by relying on Unity as a backbone.  There are a number of resources already available that you can take advantage of for development.  These include 3D models, plugins and tutorials for your project.

If you insist against Unity, CryEngine, Unreal Engine and the Source Engine are other options, but aren’t exactly targeted to indie developers.

I was dead set on making a 2D game; many aspects of my game rely on it.  Making a true 2D game in Unity is just not possible.  You can create a game with a fixed camera that limits movement to two dimensions but ultimately the assets and game will run 3D.  My inexperience with 3D game development had me a bit nervous going that route.

Web, Mobile or dare I say it…consoles?

I mention above that I already had some interest in the Nintendo Web Framework as a potential target, so the decision to make the game using JavaScript and HTML5 was practically made for me.  However, that wouldn’t make for a very interesting post now would it?

If I wanted to make a game for mobile platforms and perhaps PC/Mac/Linux, my previous experience would lead me to look toward cocos2d.  I have previously worked with cocos2d-iphone and found it easy to work with.  cocos2d-x is essentially the cross platform version of cocos2d, which has support for those and many other platforms.

Whittling It Down

A quick Google search turns up many JavaScript game development frameworks.  How do you decide which one to use?  I ended up filtering out options based on features that I saw as valuable to me.  This is obviously a subjective process, so your criteria may lead you to a different result than mine.

First, I needed something free and open source if possible.  I would hardly even consider myself an indie developer and I really can’t see myself financially contributing to a pet project like this.  Second, I’d prefer a framework that can work out of the box with standard tools such as Tiled for tile based map creation.

At this point I had narrowed my decision down to two options: cocos2d-html5 and melonJS.  It is going to sound odd based on my recommendation of cocos2d above, but after working with both options I eventually settled on using melonJS.  cocos2d has its applications but for lightweight, simple JavaScript game development it is my opinion that melonJS is the best framework out there.

Thanks to the great documentation, I had a simple platformer up and running using the melonJS boilerplate project within an hour of getting started.  I have yet to thoroughly stress test, but I’ve had no hiccups running the game at 720p within Chrome.

Why did I turn away from cocos2d-html5?  After some exploration it just didn’t seem like the best way to go for a lightweight JavaScript game.  Ultimately, cocos2d-html5 is meant for cross platform games between the web and iPhone, and the API reflects that.  I wanted something built for JavaScript from the ground up.

Have you been working with a framework that you really like?  Leave a comment to let me know.

Advertisements

Using jQuery 2.0 and supporting IE 8?

jQuery 2 has been released and the most talked about addition is actually the removal of a feature.  Notably, support for Internet Explorer versions 6, 7 and 8.  The jQuery blog notes that Android 2.x browsers are the next on the chopping block.  You may think that the new features in jQuery 2.0 would have to be substantial to encourage developers to use it and leave IE 8 behind, but at this point the APIs of jQuery 1.9 and 2.0 are identical.  In other words, they provide the exact same set of features, they just support different browsers.  In addition, both the 1.x and 2.x versions of jQuery will continue to be supported side-by-side for the foreseeable future.  jQuery 1.10 is will be released in the coming months with bug fixes from the 2.0 cycle.

The only noted benefit of the change to jQuery 2.0 is a decrease in size of the JavaScript file from 93kb to 83kb.  Some developers may see this change as negligible and continue to use jQuery 1.9, where those who support systems with much higher traffic may see a benefit in the reduced file size.  Why choose when you can serve the larger file to the browsers that need it and save the bandwidth for those that do not?

How To

Through the use of conditional comments, a site can use jQuery 1.9 to support just the IE 8 and lower users, and use jQuery 2.0 for all others, taking full advantage of the bandwidth savings when possible.  Conditional comments are commonly used to create IE-only stylesheets for those pesky quirks that only seem to occur in Internet Explorer.  However, there is nothing preventing them from being used for JavaScript as well.  See the following code example:

<!--[if lt IE 9]><!-->
<script src="http://code.jquery.com/jquery-1.9.1.min.js"></script>
<!--<![endif]-->
<!--[if gte IE 9]><!-->
<script src="http://code.jquery.com/jquery-2.0.0.min.js"></script>
<!--<![endif]-->

The first line checks to see if the requesting browser is lower than IE 9.  If it is, then we load jQuery 1.9.  The second line checks if it is greater than or equal to IE 9.  If it is, then we load jQuery 2.0.  Since the 1.9 and 2.0 APIs are identical, the rest of the calls to jQuery on the page will work properly with no additional changes required.  Take note that there are some additional comment tags included to make these checks visible to non-IE browsers such as Chrome or Firefox.

Conclusion

Many developers considered jQuery’s support for a wide range of browsers to be a significant benefit for choosing it over other alternatives.  Often a project’s targeted audience or the client themselves will determine what browsers need to be supported, leaving the developer out of the decision entirely.  With the newest version shifting from that support, the door may be left open for a competitor product to gain usage in the developer community.  At this point, there is no cause for alarm since the jQuery 1.x line will continue to be supported in the future.  However, if jQuery 2.0 begins to add features that are not available in 1, developers may demand a version of jQuery 2 with support for older browsers, or just move on to something new.  Only time will tell.